Part 3 — Alignment  ::  Chapter 14

3.2 From Engineering Intent to Enforceable Obligation

Enforcement 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 a mechanism can enforce the result.

Software engineering already has a long tradition of connecting engineering intent to realization through requirements, traceability, verification, and acceptance. A requirement may be traced to design elements, implementation, tests, and other evidence so that engineers can ask whether the intended obligation survived realization. Alignment builds on that tradition but asks an additional question: should the resulting judgment merely inform the work, or should the environment enforce it?

Traceability can connect an obligation, its realization, and its evidence without any mechanism enforcing the obligation. A requirement may trace cleanly to a test whose failure is merely reported. Conversely, a permission boundary may enforce firmly without a rich traceability model. Alignment therefore separates the relation among intent, realization, and evidence from the decision to enforce the resulting judgment.

Where an obligation permits variation, the acceptable region must likewise come from the engineering intent that governs the work. A measured implementation can establish what latency it achieved or what dependencies it contains; whether those values are acceptable requires an independent engineering obligation.

A description and the implementation it describes can therefore agree while both violate the intended property. Placement matters as well: if an obligation is enforced at a boundary too small to make it legible, the checker may 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. Enforcement 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.

Figure 3.2-1 distinguishes the three relations.

Three relations an obligation can test: correspondence, conformance, acceptance Three stacked bands. Correspondence asks whether two representations of one thing agree — a bidirectional relation between an implementation and a representation, both of them internal. Conformance asks whether the artifact satisfies an independent obligation. Acceptance asks whether the receiving environment will take the artifact. Agreement, conformance, and acceptance are distinct kinds of evidence and are not interchangeable. CORRESPONDENCE agreement between two representations implementation representation “Do they agree?” agreement CONFORMANCE the artifact against an independent obligation artifact independent obligation “Does it satisfy?” conformance ACCEPTANCE the receiving environment takes the result artifact receiving environment “Will it accept?” acceptance Evidence of agreement, conformance, and acceptance is not interchangeable.
Figure 3.2-1. Three distinct relations. Correspondence tests agreement between representations; conformance tests an artifact against an independent obligation; acceptance asks whether the receiving environment will take the result. Evidence for one relation does not establish the others.

Worked Examples

Siemens. The Siemens reconstruction describes models, implementation, and engineering analyses kept in correspondence across a digital thread without making every disagreement a build-blocking event. In that account, a human confirms the bill of materials while physics solvers carry parts of the evaluation. The example is useful precisely because correspondence and gating are separate design choices: the coupling can hold without a hard gate deciding the instant the two diverge.

DocAble. DocAble uses all three relations. Wire-contract tests ask whether independently represented sides of an interface correspond; they establish agreement, not external compliance: a synthetic payload can satisfy both sides while the real producer emits something else. PDF output can instead be checked against veraPDF, an independently implemented conformance oracle for the ISO standard. In Office workflows, the acceptance question may be whether Microsoft's own checker accepts the result. Agreement, conformance, and acceptance are useful evidence, but they are not interchangeable.

DocAble's remediation pipeline gives a sharper example of correspondence and governance as separate properties. Its computations and their composition are represented explicitly rather than recovered from the bodies of the remediation passes. The execution machinery consumes that computation model to determine dependency order and readiness. The model therefore governs composition: node implementations determine what individual computations do, but they do not independently decide how the pipeline is assembled.** The computation model describes the pipeline rather than the history of any one remediation. Runtime telemetry can now be joined to computation identities for aggregate measurements such as latency and cost, but the per-session edit record still names realized document mutations rather than computation nodes. DocAble has not yet built a per-run execution graph joining that edit history to the computation model.

A separate Python remediation-graph view exposes that structure for analysis and governance. The current view contains 125 computations and 57 typed relations: 32 data-flow edges, 24 control gates, and one cross-service relation. Fifty-five relations are projected and two remain authored seeds. For Office formats, the projection derives edges from registry read/write metadata also used by scheduling. For PDF, the analytical relation is projected from typed Produces, Consumes, and ConsumesForControl declarations and held to the executable territory by blocking parity checks.

The two representations therefore play different governing roles even where their correspondence is strong. The computation model is consumed by execution. The analytical view is consumed by analyses and checks. Making the view more faithful does not by itself make it govern execution; a representation governs what the environment requires it to control.

The Office checks expose a second limit. Nodes and edges are now projected and their parity checks run green, but those checks remain audit-only while one live pass still runs outside the registration surface the checks can enumerate. Promoting them to blocking before that escape is drained would certify a green result over an incomplete observation surface. A validator should not receive more gating power than its evidence surface warrants.

Figure 3.2-2 draws governing role and correspondence apart.

Governing role and correspondence are different relations One authoritative computation model — computations, dependencies, and composition — sits at the top. Two relations run from it. On the left, an authority relation: the model is consumed by the scheduler, so execution follows it. On the right, a correspondence relation: the model, and the parity-bound declarations around it, are projected and checked into an analytical graph view used for analysis and governance. The authority arrow reaches execution; the correspondence arrow reaches the view. Making the view a more faithful correspondence does not transfer execution authority to it. Governing role and correspondence are different relations GOVERNING COMPUTATION MODEL computations · dependencies · composition consumed by scheduler projected / checked EXECUTION ANALYTICAL GRAPH VIEW analysis · governance GOVERNING ROLE computation model → execution CORRESPONDENCE computation model / parity-bound declarations → analytical view Strong correspondence does not make the analytical view govern execution.
Figure 3.2-2. Correspondence strength and governing role are independent. DocAble's execution machinery consumes an explicit computation model to determine remediation composition. A separate analytical graph view projects that structure and is held in correspondence with its upstream declarations. Stronger correspondence makes the view more trustworthy as a representation; it does not make the view govern execution.

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 11. 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 enforcement over engineering work. The design instinct is the same — put the deciding mechanism where the semantics needed to decide the property are available.

The semantic gap: move the mechanism to the boundary where the obligation is legible A property that spans several events cannot be decided from any event alone. The bottom row shows a sequence of small low-level events — commits, calls, a turn — under a line reading the obligation is not decidable here. An upward arrow, labeled move mechanism, rises to a single wide box at the top reading obligation legible, the completed unit of work. Move the mechanism to the earliest boundary where the evidence the obligation needs is assembled. OBLIGATION LEGIBLE the completed unit of work move mechanism obligation not decidable here commit commit commit call call turn
Figure 3.2-3. The semantic gap. A property that spans several events cannot be decided from any event alone. Move the mechanism to the earliest boundary where the evidence required by the obligation is assembled.

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 enforcement at the earliest boundary where the obligation is both legible and decidable.

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:

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 available boundary; 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 decidable.

Both rules keep irrelevant detail from driving the engineering decision.

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.

Works Cited

  1. Saltzer, Jerome H., David P. Reed, and David D. Clark. “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.
© James C. Davis, 2026–present