Part 3 — Alignment  ::  Chapter 17

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.

At that point, the controls themselves have become an engineering system. They must be understood and maintained as one. 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 gives the next two views stable identities to work from instead of forcing engineers and tools to rediscover controls from scripts, hooks, CI files, and institutional memory.

A catalogue alone cannot tell you whether two individually sensible controls conflict, nor whether an important obligation has no control. Those are relational questions. The first lives on the edges between 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.

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-2 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-2. 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.

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 Section 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 Part II: 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 Part V.

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 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.

Part 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, and place its mechanism where that obligation becomes legible; 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. Part IV turns those decisions into method.

© James C. Davis, 2026–present