Part 3 — Alignment  ::  Chapter 17

3.5 Governing the Control Estate

As controls accumulate within the governed engineering environment, they form a control estate: the portfolio of constraints, sensors, validators, gates, permissions, and other governance mechanisms through which the environment observes or exercises its authority. Every control can be reasonable in isolation while the estate as a whole remains inconsistent, incomplete, or obsolete. One mechanism requires a squash; another interprets the resulting large diff as unauthorized scope expansion. Two hooks fire on the same lifecycle event with no declared order. A validator survives long after the obligation that justified it disappeared. A newly important obligation has no control at all. None of these failures is visible by reading one mechanism's code.

Governance conversion and ex ante design can leave the environment with substantial machinery. Once that machinery becomes consequential, it becomes an engineering object in its own right. Durable controls can be engineering capital; the resulting portfolio must be maintained, reconciled, and sometimes retired. Which assets still produce value, which have depreciated, which controls conflict, and which consequential obligations remain uncovered? MAGE asks three questions of the estate: what controls exist, how do they interact, and which obligations do they cover? The answers are three views over one control estate — a catalogue, an interaction graph, and a coverage relation.

The GEE's control estate is itself an engineering system. Represent it explicitly so engineers and tools can reason about how its controls compose and what obligations they cover. Once the control estate becomes consequential, hold it to its own obligations.

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 authority 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 mechanism required several commits collapsed into a single squashed one, while another read the resulting combined diff as unauthorized scope expansion and flagged it — two controls, one commit-set, contradictory demands, exposed only when one real commit activated both controls. 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.

A governed environment depends on its mechanisms composing coherently. The interaction graph exposes enough of that composition to inspect likely conflicts before they occur: which controls fire on this event, which touch this resource, and which combinations require review?

3.5.3 Trace Obligations to Mechanisms

Interactions are only half of governing the control estate. 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 under-governance. A mechanism with no current obligation, failure class, or purpose is an orphan — candidate governance debt. 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 one control estate.

Three views of one control estate: 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 GAP, under-governance — and [C] traces to no obligation — an ORPHAN, candidate governance debt. 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 GAP under-governance ORPHAN candidate governance debt One control estate, three questions same control identities, different relations
Figure 3.5-2. Three views of one control estate. 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 definitions do the diagnostic work, and neither verdict is automatic.

3.5.4 Add, Reconcile, and Retire Controls

Governance conversion and coverage auditing work in opposite directions. Conversion adds durable structure when experience exposes a recurring gap; coverage auditing looks for controls that are missing, redundant, or obsolete. One adds structure from experience; the other checks whether the resulting estate has become incomplete, 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. 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 estate, 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-estate model is grounded primarily in the originating case.** I found no comparable control-estate 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 an estate 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 estate 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 bind actions and artifacts directly. Explicit models expand the semantic reach of that authority.

Part 3 developed Alignment in five moves: locate the boundary where authority can act; 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 estate 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 authority, 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