Part 2 — Modeling  ::  Chapter 9

2.5 Decision Models: What Is Allowed?

A decision model represents allowed or selected alternatives. In this example, the decision is whether one service is permitted to reach another. In DocAble, one such model describes which services may communicate, and under what conditions.

The implementation contains HTTP clients, endpoints, credentials, deployment configuration, and network calls. The model reduces that machinery to a declared flow.

MODEL CARD

Service-flow model · Decision

Figure 2.5-1 draws the permitted calls as a declared graph — a short list of arrows. The public internet reaches the web tier; the web tier reaches the worker, the document editor, and a few others; the worker reaches generation, render, and OCR. An edge means the relationship is part of the declared policy. An absent edge means the declared policy does not permit that relationship.

DocAble's service-flow model: which services may communicate A declared directed graph. The Internet reaches the web service. Web reaches worker, document editor, and other. Worker reaches generation, render, and OCR. Each edge is a declared, permitted relationship; an absent edge means the model does not declare that relationship. SERVICE-FLOW MODEL Internet web worker document editor other generation render OCR An edge means the relationship belongs to the declared policy. An absent edge means the declared policy excludes the relationship; enforcement is separate.
Figure 2.5-1. Service-flow model. A declared graph of which service may reach which. The public web tier is the only node facing the outside; an absent edge means the relationship is not permitted by the model, and enforcement is separate.

The model describes intended relationships; it does not, by itself, make an undeclared connection impossible. The decision model declares permitted relationships; enforcement is separate. This gives engineers and agents a more useful question than does the repository happen to contain a call from A to B? They can ask instead: Is A supposed to call B?

The first question is descriptive; the second requires represented intent. Figure 2.5-2 sets the two side by side: implementation reveals that A calls C; the decision model says whether A may call C. Part III returns to this distinction when it separates correspondence from correctness and asks which declared relationships should be enforced.

Observed structure versus declared structure answer different questions Two panels. On the left, the implementation, in gray: A calls B and A calls C, observed facts, asking does A call C. On the right, the model, in blue: A to B is a declared edge, and between A and C there is no edge, marked with a rust X, asking may A call C. Agreement between observed and declared establishes correspondence, not correctness. OBSERVED SYSTEM A B C “Does A call C?” DECLARED POLICY A B C declared no edge “May A call C?” Observation reveals what is; the decision model declares what belongs. Agreement between them establishes correspondence, not correctness.
Figure 2.5-2. Observation and intent answer different questions. The observed system can reveal that A calls C; the decision model can state whether that relationship is permitted. Agreement establishes correspondence, not correctness.

The next chapter leaves relationships for quantities: how much a workload consumes, how fast it runs, and against what envelope those numbers are read.

© James C. Davis, 2026–present