2.5 Decision Models: What Is Allowed?

The models so far have been descriptive: they say what the system is or does. A decision model says what the system may do. It represents alternatives and the rules that permit, require, or forbid them. That single change in mood — from does to may — is the whole subject of the chapter.

2.5.1 The Canonical Move: Permitted Alternatives

Engineering represents permission in several familiar forms: decision tables that map conditions to allowed actions, rule systems, access-control matrices that record which subject may act on which object¹1. Butler W. Lampson, “Protection,” ACM SIGOPS Operating Systems Review 8, no. 1 (1974): 18–24, https://doi.org/10.1145/775265.775268., policy graphs, feature models that constrain which combinations of options are valid, and constraint systems that declare which assignments are admissible. What unifies them is not their shape but their mood.

This is the sharpest instance of the earlier lesson that topology does not fix meaning. A structural edge and a decision edge can be drawn identically and mean opposite kinds of thing: A → B as a structural edge says "A calls B," a fact about what happens; the same arrow as a decision edge says "A may call B," a rule about what is permitted. The consequence lives in the absent edge. A missing structural edge means "no such call happens"; a missing decision edge means "no such call is allowed." The gap between those two readings is the reason decision models exist (Figure 2.5-1).

Once permission is declared, the claims a policy designer wants become expressible: which alternatives are permitted or forbidden, which are mutually exclusive, which imply prerequisites, whether the policy is internally consistent, whether it is complete over the cases that can arise, and whether it achieves least privilege. The analyses follow — evaluating a rule against a case, checking or solving constraints, detecting conflicts between rules, testing completeness and consistency. A declared policy turns "is this allowed?" into an evaluation rather than an argument.

2.5.2 DocAble: Service-Flow Policy

DocAble declares which of its services may communicate with which. The model is a graph whose edges carry the normative reading: an edge means the call is part of the sanctioned policy, and an absent edge means the policy does not permit it.

MODEL CARD

Service-flow model · Decision

• Engineering question — Which service may call which, and what may be reached from outside?
• Model — a declared graph of services and the permitted edges between them; the deployment is wired from the graph rather than the graph inferred from the deployment.
• Property — internal communication is permitted only along a declared edge; one declared node is the public entry.
• Quality attribute — least privilege; architectural integrity; security.

Figure 2.5-2 draws the permitted calls. One node is declared publicly reachable; every other edge is an authenticated internal call. The model is the single source of truth for those edges, and the deployment is generated from it rather than inferred from it — so a completeness check can require every gated edge to be fully specified before the deployment is wired. That check is real and enforced, but it governs the declaration's internal consistency, not the running traffic. The model declares the topology; it is not a runtime firewall.

Declaring the policy exposes a question the running system cannot answer for itself: do the services call only along declared edges? That is a correspondence between an observed structural fact and a declared decision, and the two are different claims. The observed call graph reveals that A calls C; the decision model states whether A may call C. Figure 2.5-3 sets them side by side.

Agreement between observation and policy would establish correspondence — the implementation matching the declared intent — not correctness: a faithfully-obeyed rule can still be the wrong rule. DocAble generates its deployment from the declared graph, but nothing at runtime reconciles observed traffic back against the declaration. That open correspondence is not a gap to hide. It is the clearest illustration in this Part of a model exposing a checkable property without, by itself, establishing that the implementation satisfies it. Modeling declares what is permitted; whether the code stays on the declared edges, and what a departure should cost, is Alignment's question in Part III.