3.2 From Engineering Intent to Enforceable Obligation

Authoritative evaluation requires two things: an obligation independent of the work being judged and a boundary where the evidence needed to evaluate that obligation is available. Without the first, a checker may only confirm that the system agrees with itself. Without the second, the mechanism tries to enforce a good obligation before the necessary evidence exists.

Part 2 supplied many ways to make obligations explicit. Some live in models: permitted service edges, legal state transitions, ownership relations, operational bounds. Others live directly in types, permissions, schemas, tests, or policy. Alignment does not require every obligation to originate in the same kind of representation. It requires that the obligation be distinguishable from the thing being judged and that an authoritative mechanism can act on the result.

Where an obligation permits variation, that independence applies to its tolerance as well. The acceptable region must come from the engineering intent that governs the work, not from the realization being judged. A measured implementation can tell us what latency it achieved or what dependencies it contains; it cannot, by describing itself faithfully, establish that those values are acceptable. The is may supply evidence. The ought supplies the boundary against which that evidence can support conformance.

Agreement is not correctness: a description and the implementation it describes can agree while both violate the intended property. Placement must follow the meaning of the obligation: enforce it at a boundary too small to make it legible, and the checker will confidently inspect the wrong thing.

3.2.1 Agreement Is Not Correctness

A drift check can establish a declared correspondence between two artifacts. It cannot establish that the correspondence expresses the right intent. Suppose an endpoint is required to be authenticated. If an independently authored policy says so, a check can compare the implementation against that obligation and flag an open endpoint. If instead the representation is derived only from the implementation, it may faithfully record the endpoint as open. Model and code agree; the security obligation is still violated.

The distinction is not whether the model was derived or authored. Derived models are useful throughout MAGE. The distinction is description versus independent obligation. A model extracted from code can supply the current is; an independently authored invariant can supply the governing ought. A hand-authored model can be just as wrong when it merely repeats the implementation's assumptions. Authority requires something against which the work can actually be wrong.

Drift checking therefore has a precise job: preserve a declared correspondence between model and implementation. If code and model diverge, surface the disagreement. Correctness requires another claim—the policy, invariant, requirement, or property that must hold. Once that obligation exists, a validator can compare evidence against it and a gate can decide what follows.

Three different relations matter, and they are not interchangeable. Figure 3.2-1 sets them side by side: correspondence asks whether two representations of one thing agree; conformance asks whether the artifact satisfies an independent obligation; acceptance asks whether the receiving environment will take the result.

DocAble's remediation computation graph gives a sharper correspondence example: its link to the implementation became mechanically strong without changing which side has authority. The C# pass registry and each pass's typed declarations — the Produces, Consumes, and ConsumesForControl facets — are the executable territory. The static computation graph is a projected description of that territory: 113 nodes and 33 projected edges, of which 10 carry data flow, 22 gate control, and 1 crosses a service boundary (11 payload-bearing edges, once the 22 control gates are set aside). A blocking edge-projection parity check fails when the projected graph and the typed declarations disagree.

That is strong correspondence, and it is nothing more than that. It does not establish conformance to an independent architectural obligation: a graph projected faithfully from a dependency an engineer would rather remove is still a faithful graph of an unwanted dependency. Nor does the graph run the pipeline — the runtime never consults it to decide in what order the passes execute. The correspondence grew stronger; the authority direction, from executable territory to model, did not move.

The edges tell the history compactly. They began as two hand-authored relations that could silently drift from the code; they are now projected from typed declarations and held by a blocking check. The model became more faithful without becoming more authoritative. Generating the pipeline from the graph would reverse the authority direction, giving the model authority over execution. DocAble does not do that.

Figure 3.2-2 draws the two axes apart.

Correspondence is not equally strong across DocAble, and the system states where it is weaker rather than concealing it. For PDF, nodes and edges are both projected and parity-enforced. For Office formats, node parity is enforced but edge projection is not built, so that edge check remains audit-only. The modeling ambition is the same, but the correspondence is weaker and explicitly recorded as a residual: DocAble can say exactly which model–territory correspondences it enforces and which it does not.^** The computation graph is static: it represents the declared structure, not any single execution of the pipeline. DocAble does record the typed mutations produced during an actual remediation session and can replay that record deterministically, but those runtime edits are not yet joined to computation-graph identities. An execution graph over that joined history is a model DocAble has not built.

3.2.2 The Semantic Gap

A second problem is placement. An obligation can be stated clearly and still be unenforceable at the boundary where you try to check it. If the property exists only over a whole task, no single commit holds enough meaning to decide it. If data exfiltration appears only as a pattern across calls, no individual system call carries the whole property. A semantic gap occurs when an obligation requires meaning that the chosen boundary does not expose. Figure 3.2-3 shows the fix — lift the check to where the meaning is legible.

A footnote on where the placement rule comes from. It echoes the end-to-end argument in system design: a function that needs end-to-end knowledge cannot in general be implemented completely at a lower layer that lacks that knowledge ¹1. Jerome H. Saltzer et al., “End-to-End Arguments in System Design,” ACM Transactions on Computer Systems 2, no. 4 (1984): 277–88, https://doi.org/10.1145/357401.357402.. Their setting was where to place functionality in a distributed system; the setting here is where to place authority over engineering work. The design instinct is the same — put the deciding mechanism where the semantics needed to decide the property are available.

A deployment can pass twenty checks and still serve a blank page. No earlier check necessarily failed: the relevant property — does the deployed page correctly render the emitted data? — does not exist at the source-file, build, or emission boundary. It becomes legible only after those pieces compose in the served system. A smoke check that fetches the served page is the earliest boundary that can decide it.

The same gap appears inside a single task. Take a concrete obligation: if this task substantially changes the call graph, the corresponding architectural model must still agree when the task closes. A real task runs through several intermediate commits, and temporary disagreement during those commits can be legitimate. A pre-commit check therefore acts too early — it sees a fragment while the property belongs to the completed unit of work. At task return, the accumulated changes, model updates, tests, and other completion evidence can be weighed together — which is exactly where the companion repository places its definition-of-done audit, over the whole unit of work rather than any single commit inside it.

Epic. A tracked unit of work larger than one commit: a feature or effort with its own file, plan, and definition of done, carried out over several agent dispatches.

Definition of done (DoD). The explicit list of conditions a unit of work must meet to count as finished — tests present, docs updated, the model in sync — checked at the end rather than assumed.

3.2.3 The Earliest Decidable Boundary

The agent-return check is one instance of a rule that runs under the whole of this Part:

Place authority at the earliest boundary where the obligation is both legible and enforceable.

Earliest matters because delay makes a failure more expensive to repair. Legible matters because moving the check earlier than the property permits produces false refusals or meaningless checks. The rule explains the whole mechanism menu at a glance:

• Types act as soon as an expression is formed — a shape is legible the instant it is written.
• Action hooks act at one tool call, one command — where a single move is legible.
• Task-completion checks act at the work-unit boundary — where "done" first becomes readable across a body of commits.
• Deployment gates act after broader evidence has accumulated — the last boundary before the artifact is accepted.

And some properties stay illegible until later still — a leak visible only across ten calls, a cost overrun visible only across a season of jobs. No boundary makes them readable sooner. The correct placement is not the earliest boundary available; it is the earliest boundary that can actually decide the obligation.

Part 2 and Part 3 therefore use companion selection rules:

Modeling — choose the reduction that makes the engineering question answerable without carrying unnecessary detail.

Alignment — choose the earliest boundary at which the obligation becomes legible and enforceable.

Both rules keep irrelevant detail from driving the engineering decision.

• Modeling avoids carrying detail the question does not need.
• Alignment avoids binding a decision before the necessary evidence exists.

Choose the wrong abstraction in Part II and the required property is not represented. Choose the wrong boundary here and the required evidence is not available.

Real boundaries are sometimes approximate. In DocAble's own orchestration loop, the ideal moment to preserve durable session state would be the instant before a lossy compaction, but waiting for that exact hook leaves too little budget to write the hand-off comfortably. So the implemented mechanism fires earlier, when context is becoming full and the durable record has gone stale. The example is a useful warning: semantic placement is an engineering trade-off, not a demand for a theoretically perfect boundary.

With an independent obligation and a boundary where it becomes legible, the next question is what the mechanism at that boundary actually does.