Skip to content
Chapter 3 — Alignment  ::  §3.5

§3.5 When Controls Become a System

As governance mechanisms accumulate, they become control machinery: the constraints, sensors, validators, gates, permissions, and other mechanisms through which the environment enforces its obligations. The machinery can fail even when every individual control is reasonable. Two controls can impose incompatible demands; their execution order can be ambiguous; an obsolete control can survive after its purpose disappears; an important obligation can remain uncovered. None of these failures is visible by reading one mechanism's code.

These interactions require engineers to maintain the controls as a system. MAGE asks three questions: What controls exist? How do they interact? Which obligations do they cover? These questions produce three useful views: a catalogue, an interaction graph, and a coverage relation. Represent that machinery explicitly, so engineers and tools can reason about how its controls compose and what obligations they cover—and, once the machinery materially affects engineering work, hold it to obligations of its own.

3.5.1 Catalogue the Controls

Start by giving each control a stable identity: the event or boundary at which it acts, the resources it reads or changes, the obligation or failure class that justifies it, and its governance role or roles. The catalogue supplies stable identities for the interaction and coverage views, so engineers and tools need not rediscover controls from scripts, hooks, CI files, and institutional memory.

A catalogue can describe each control individually, but it cannot reveal conflicts between them. Those conflicts appear in the relationships among controls.

3.5.2 Model Interactions Between Controls

Two collisions from the case study make it concrete. In the first, one control required a squashed commit while another treated the resulting broad diff as unauthorized scope expansion. Each was reasonable alone; together they imposed contradictory demands on the same commit set. In the second, two hooks fired on the same turn-end with no order declared between them, each able to block, and their composition was left implicit. Neither collision lives in any one control's code. Each lives in the space between two controls. That relation had not been represented. Figure 3.5-1 draws it.

The conflict is the edge — two valid controls impose incompatible demands on one shared resource Two control nodes — Control A, which requires a squashed commit, and Control B, which rejects a broad diff — each correct when read alone. Both point by a solid arrow to one explicit shared resource, the commit set, that they act on. Below the commit set, a rust node marks the incompatible demands: the conflict belongs to the relation among the two controls and the resource they share, not to either control's own implementation. acts on acts on Control A requires a squashed commit ✓ Control B rejects a broad diff ✓ shared resource COMMIT SET incompatible demands the conflict lives in this relation, not in either control
Figure 3.5-1. The conflict is the edge. Two controls may be individually valid yet impose incompatible demands on the same resource. The interaction belongs to the relation among the controls and shared resource, not necessarily to either control's implementation.

The interaction graph uses controls as nodes and shared resources as the principal join key. A resource may be ordinary — a lock, a file, a commit-set, a deployment slot — or operational, such as a lifecycle event or a context budget. Controls need not call one another to interact; they only need to make potentially incompatible demands on the same modeled resource.

DocAble's implemented governance graph is intentionally partial. It models only the high-value interactions for which recurring questions justified explicit representation, including those around the orchestrator lifecycle.

A shared resource is a conservative signal of interaction, not proof that every conflict has been captured. Within the represented surface, it lets engineers and tools ask useful questions before the controls interact in production work: which controls fire on this event, which touch this resource, which pairs have no declared order, and which known combinations impose incompatible requirements.

Some candidate conflicts are mechanically decidable: a lock cycle, two exclusive writers, or two same-slot mechanisms with no permitted ordering. Others are semantic. A static check can sense that two controls touch the same commit-set; a validator — or a human reviewer — must decide whether their requirements actually conflict. Again the four roles matter: producing evidence of an interaction is not the same as judging the interaction invalid. In the motivating commit-set collision, the machine could identify the shared resource, but judgment was still required to recognize the requirements as contradictory. The graph lets the environment surface the interaction for evaluation before the controls collide during work.

Not every conflict between controls reflects a conflict between the obligations they enforce. Two obligations may genuinely be incompatible, requiring engineers to revisit the requirements or specification. But compatible obligations can also be enforced by mechanisms that interfere with one another. In that case, changing the mechanisms or how they interact may resolve the conflict without weakening either obligation.

DocAble now represents the second of these conflicts in an explicit governance model. Among the automations that run when an agent finishes a turn, three matter here: one discourages premature termination, another prompts reflection on failures, and a third checks for stranded work. All three write to the turn's closing message. The governance graph contains twenty-five mechanisms and three conflict edges, all between these hooks. Figure 3.5-2 shows their shared resource and the modeled ordering.

Three turn-end hooks write one shared slot; the model resolves the conflicts with a declared order Three governance mechanisms, all firing when an agent ends a turn: one discourages premature stops, one prompts reflection on failures, one checks for stranded work. Rust arrows between them show the modeled order, left to right. All three write the same shared resource below — the turn's closing message. An annotation notes that the typed governance graph holds twenty-five mechanisms, that these three edges are its only conflicts, and that the order is computed by topological sort, with a cycle reported as an error. modeled order — first to last writes writes writes turn-end hook discourages premature stops turn-end hook prompts reflection on failures turn-end hook checks for stranded work one shared slot the turn's closing message the typed governance graph holds 25 mechanisms; these three edges are its only conflicts — all ordering, one shared resource; the order is computed by topological sort, and a cycle is an error
Figure 3.5-2. Three turn-end hooks, one shared resource. All three hooks write to the turn's closing message, producing three conflict edges. The governance model computes an execution order, but the generic runtime driver that would enforce it has not yet been implemented.

The graph distinguishes four kinds of conflict: contradiction, when requirements are incompatible; contention, when mechanisms compete for a resource; ordering, when their execution sequence matters; and soft versus hard, when one mechanism can prevent another from achieving its purpose. Each conflict can be resolved by merging mechanisms, ordering them, separating their execution points, accepting the interaction, or leaving it open for later resolution. The goal is not a conflict-free graph; it is a graph whose consequential interactions are understood and appropriately resolved.

The three turn-end conflicts are ordering conflicts. Their pairwise constraints establish a sequence: the premature-termination guard runs first, reflection second, and the stranded-work check last. The model computes this order by topological sorting; a cycle produces an error rather than an arbitrary sequence.

The model currently records conflicts and computes their resolution order. A separate check reports discrepancies between the model and the harness's configured mechanisms. The generic runtime driver that would execute hooks according to the computed order has not yet been built. The order is therefore an explicit, checkable design decision, not yet an automatically enforced one.

The original conflict was discovered only after two hooks interfered during development. The model records that pair and lets engineers identify similar interactions before installing another automation. Instead of discovering conflicts through failures, engineers can examine them as part of the design.

The governance model records conflicts according to a simple criterion. Each mechanism declares an execution event — its slot — and the sets of resources it reads (R) and writes (W). Two mechanisms have a potential conflict when they execute at the same event and at least one writes a resource the other accesses. Two readers do not conflict. The resulting graph G=(V,E) records these interactions as edges: an undirected edge joins distinct mechanisms u and v when

slot(u)=slot(v)∧(Wu∩Rv)∪(Ru∩Wv)∪(Wu∩Wv)≠∅

An edge identifies an interaction requiring attention; it does not establish that the underlying obligations are incompatible. The model separately classifies the conflict and records its resolution.

3.5.3 Trace Obligations to Mechanisms

Interactions are only half of governing the control machinery. A catalogue tells you what controls exist; an interaction graph tells you where controls may collide. Neither tells you what should be governed but is not. For that, join the mechanisms to the obligations or failure classes that justify them.

The result is a small requirements-traceability problem. An important obligation with no adequate mechanism is a coverage gap. A mechanism with no current obligation, failure class, or documented purpose is an orphan. The useful question is not "how many controls do we have?" It is whether consequential obligations have appropriate coverage and whether every surviving control can still explain why it exists. Figure 3.5-3 sets the three views side by side over the same control machinery.

Three views of one system of controls: catalogue, interaction graph, and coverage of obligations against mechanisms — the same three controls seen through three relations Three panels over the same three controls, carried by stable identities: [A] squash rule, [B] brief guard, [C] lint gate. Left panel, the catalogue, lists the three controls that exist. Middle panel, the interaction graph, relates [A] and [B] through a shared resource, the commit set, where they collide; [C] stands alone. Right panel, the coverage view, relates controls to the obligations that justify them: scope-bounded traces to [A] and brief-followed to [B], while the cost-ceiling obligation has no control — a coverage gap — and [C] traces to no obligation — an orphan. The same control identities appear in every view; each view selects and adds the relations its engineering question needs. Catalogue what exists [A] squash rule [B] brief guard [C] lint gate Interaction graph what collides [A] squash rule [B] brief guard collision commit set [C] lint gate Coverage what obligation justifies each control obligation control scope-bounded brief-followed cost-ceiling [A] squash rule [B] brief guard [C] lint gate COVERAGE GAP ORPHAN One system of controls, three questions same control identities, different relations
Figure 3.5-3. Three views of the control machinery. The catalogue identifies controls; the interaction view relates controls through shared resources; the coverage view relates controls to the obligations that justify them. Stable identities connect the three views while letting each answer a different engineering question. A missing mechanism appears as a coverage gap; an untraced mechanism appears as a candidate orphan.

Two findings do the diagnostic work, and neither verdict is automatic.

  • Coverage gap. A consequential obligation for which the intended evidence or enforcement is not adequately supplied.
  • Orphan. A mechanism that no longer traces to a current obligation, failure class, or documented purpose. An orphan is a finding to reconcile, not proof that the mechanism should be deleted.

3.5.4 Add, Reconcile, and Retire Controls

Governance conversion and coverage auditing provide complementary pressures. Conversion adds durable structure when experience exposes a recurring gap; coverage auditing finds controls that are missing, redundant, or obsolete.

The same audit also pushes against permanent accumulation. A control whose purpose has disappeared should be reconciled or retired; two controls that now overlap may be consolidated; a mechanism whose maintenance cost exceeds the failure it prevents may no longer be worth carrying. This echoes §3.4: engineering capital is not the number of controls. A control that no longer produces value has depreciated into overhead; the task now is to reconcile or retire it.

The control model must remain connected to the controls it represents. Where DocAble models controls explicitly, entries can be anchored to their implementations and checked for drift, so a control the rule cannot place fails explicitly rather than dropping into a silent default bucket. This applies the broader rule from Chapter 2: if engineers and agents are going to reason through a model of the control machinery, the model must stay connected to the territory it claims to describe.

Do not recursively govern every relation merely because it can be modeled. Extend the control model only when a recurring engineering question or observed failure justifies the added machinery.

The control-machinery model is grounded primarily in the originating case.** I found no comparable control-machinery model in the external systems reconstructed for Chapter 5.

Worked Examples

Two Safety Rules. A building's fire system unlocks doors when it detects smoke; its security system may lock those same doors under an intrusion policy. Each rule is sensible in isolation while the pair demands incompatible states of the same resource. The contradiction belongs to the interaction, not to either rule's own logic.

DocAble. DocAble models its governance mechanisms as a system rather than only as individual scripts. Controls are anchored to their implementations, interaction relations identify shared resources, and coverage traces controls back to the obligations or failures that justify them. The model does not make every possible conflict mechanically decidable. It exposes enough structure to ask, before the next collision, which mechanisms interact and which important obligations have no adequate coverage.

Takeaway. Governance conversion adds durable engineering structure; governing the control machinery keeps that structure coherent. Catalogue the controls, expose their interactions, trace them to the obligations they serve, and retire machinery that no longer earns its cost.

Alignment must preserve two kinds of freedom. The first is freedom of implementation: which acceptable realizations remain available after obligations are enforced. The second is freedom to extend the engineering environment: whether additional controls can coexist with those already installed. The realization-space model in §3.3 addresses the first question; the governance graph addresses the second.

This extends Modeling and Alignment to the machinery that performs engineering work. Product obligations motivate controls; controls interact; and those interactions must themselves be modeled and governed. The result is not unrestricted agent autonomy. Agents may be permitted to explore alternatives without being authorized to merge, deploy, or otherwise commit them. Engineers must still decide which freedoms can be delegated and which require stronger controls.

Alignment does not require comprehensive Modeling: permissions, types, APIs, and local gates can enforce local obligations directly. Explicit models expand the semantic reach of that enforcement.

Chapter 3 developed Alignment in five moves: locate the boundary where the obligation can be enforced; state an independent obligation, including its tolerance where acceptable variation matters; distinguish constraints, sensors, validators, and gates; convert recurring failures and judgments into durable structure; and govern the resulting control machinery as a system in its own right.

Modeling and Alignment are now both on the table. That still is not a method. The remaining problem is judgment: when a question deserves a model, when an obligation deserves enforcement, how work should move through the environment, and what to do when the available representation or control is insufficient. Chapter 4 turns those decisions into method.

© James C. Davis, 2026–present