Part 3 — Alignment  ::  Chapter 16

3.4 Growing the Governed Environment

No engineered environment begins with every obligation it will eventually need already represented and mechanized. Some obligations are known in advance: an API must require authentication, a state transition is forbidden, a format mutation must cross a particular seam. Others become visible only when the work exposes a failure nobody represented or controlled. A governed environment acquires durable structure in two ways: ex ante from obligations already known, and ex post from failures and surprises.

The ex post route is governance conversion. A failure occurs; engineering judgment identifies the recurring class behind it; the environment then represents what was missing, states the obligation, exposes the evidence, strengthens the evaluation, or gives the verdict consequence. Later work inherits the result. The repair fixes this instance. Conversion changes the environment.

ENGINEERING

Inset — Failure modes before and after failure

Engineering need not wait for a failure to learn how a system can fail. Techniques such as Failure Modes and Effects Analysis (FMEA) work ex ante: engineers identify possible failure modes, consider their effects, and use that analysis to decide where prevention, detection, mitigation, or other controls are warranted. Known obligations can therefore produce durable engineering structure before experience forces the issue.

Governance conversion works in the complementary direction. A failure or consequential surprise supplies evidence that something was missing. Engineering identifies the failure mode behind the instance and asks what durable structure should address the class: a model, obligation, sensor, validator, constraint, gate, or other mechanism. The repair fixes the instance; conversion changes what future work inherits.

The distinction is about how the need became known, not about the resulting mechanism. Ex-ante analysis and ex-post learning may lead to the same control. Governance conversion names the ex-post route; it does not imply that engineers should wait for failures they can reasonably anticipate.

3.4.1 Ex Ante: Encode What You Already Know

Start with obligations you can state before the work begins and that are consequential, recurrent, or reusable enough to make durable. A required output shape may become a schema; a forbidden dependency may become an architectural relation plus a validator; a service boundary may become a permission or narrow API; a legal lifecycle may become a closed transition table. Encode recurring obligations when the environment can carry them more cheaply and reliably than repeated judgment.

Part IV turns this into a method for starting and migrating systems; here the distinction is simply that these obligations are known before failure forces the issue.

3.4.2 Ex Post: Convert What the Work Teaches

The harder half begins when the system surprises you. A failure may reveal a recurring failure mode: the environment lacks a representation, an obligation was never stated, the relevant evidence is not observable, a validator is too weak, or a judgment exists but carries no authority. Do not assume every failure calls for another gate. Diagnose what was missing.

The conversion can therefore land in several places:

  1. Missing representation / semantics → improve the model. Make the fact or relation durable at the abstraction where the question becomes answerable.
  2. Missing obligation or tolerance → state the governing boundary. A failure may show that variation treated as free was not actually acceptable. Make the invariant, policy, bound, or permitted set explicit enough for future work to reason against it.
  3. Missing evidence → add a sensor or trace. Make the relevant state observable.
  4. Missing evaluation → strengthen the validator. Turn evidence into a repeatable judgment.
  5. Missing consequence → add or strengthen a constraint or gate. Make the verdict matter.

This is why Modeling and Alignment form a feedback loop in practice. A failure can expose knowledge that remained implicit, or reveal that a choice treated as a degree of freedom actually carried a tacit obligation or tolerance. Modeling can make that distinction explicit; Alignment can then give the resulting obligation appropriate evidence and authority. The environment improves when recurring reconstruction or judgment moves into durable structure that later work can inherit. Figure 3.4-1 draws the diagnosis.

Governance conversion: a failure is diagnosed for what was missing, and the missing piece is encoded as durable structure that future work benefits from inheriting as engineering capital A failure or surprise flows down into one question — what was missing — which fans into five branches: missing representation/semantics, obligation, evidence, evaluation, or consequence. Each branch encodes a durable answer: a model, an invariant, a sensor, a validator, or a constraint or gate. The five converge into durable engineering structure, which future work benefits from inheriting, accumulating as engineering capital. The figure's point: a recurring failure is not automatically a request for another gate — you diagnose what the environment lacked and encode that. FAILURE / SURPRISE What was missing? representation obligation evidence evaluation consequence model invariant sensor validator constraint / gate DURABLE ENGINEERING STRUCTURE FUTURE WORK BENEFITS FROM INHERITING IT ENGINEERING CAPITAL a failure is not a request for another gate — diagnose what was missing, then encode it
Figure 3.4-1. Governance conversion. When a failure exposes a recurring failure mode rooted in missing representation, obligation, evidence, evaluation, or consequence, encode the missing structure at the appropriate layer. Future work inherits the result as engineering capital when that durable structure continues to lower future cost or uncertainty.

3.4.3 Correct Judgment Without Consequence

A merge automation drained a backlog of agent worktrees into the mainline each tick. Most rebased cleanly; a fraction conflicted, and a single convenience option resolved those conflicts by taking one side automatically. On overlapping edits it silently dropped content. An audit already understood the danger: a guard detected when a conflict touched substrate-class files, judged the resolution unsafe, and logged it correctly — as a warning only. The operation proceeded, and the tree lost content. Figure 3.4-2 traces the cascade.

Correct judgment without consequence: the audit detected the danger and judged it unsafe, but the link from verdict to consequence was severed, so the operation proceeded and content was lost A vertical cascade. A dangerous auto-resolution fallback exists. A sensor detects it and a validator judges it unsafe — sensing and evaluation both work. But the link from that verdict to any authoritative consequence is severed; the only thing emitted at the break is a warning. So the operation proceeds anyway and content is lost. Evidence existed and the judgment was correct; no authoritative mechanism acted on the verdict. The durable repair removed the capability rather than making the warning louder. dangerous fallback exists auto-resolve conflicts by taking one side sensor / audit detects condition a guard sees the substrate-class conflict validator: UNSAFE the verdict — correctly identified as dangerous Evidence existed; the judgment was correct. WARNING ONLY logged — no consequence no authoritative consequence the verdict never reaches a consequence operation proceeds anyway content lost the tree silently loses content Durable repair — remove the unsafe capability; escalate an ambiguous merge to a human. The fix removed a capability the environment should never have offered — not a louder warning.
Figure 3.4-2. Correct judgment without consequence. The system observed the dangerous condition and evaluated it correctly, but no authoritative mechanism acted on the verdict. The durable repair removed the unsafe capability rather than making the warning louder.

The failure was not principally missing evidence. The system had evidence. Nor was it missing evaluation: the audit correctly identified the dangerous condition. What it lacked was consequence. The warning described a condition the environment still permitted.

The durable repair did not make the warning louder. It removed the dangerous auto-resolution fallback and escalated ambiguous merges to a human instead. Governance conversion can add a mechanism. It can also delete a capability the environment should never have offered. Where a warning marks a known-dangerous condition intended to become binding, its temporary status should be explicit, with an owner and resolution condition.

3.4.4 Engineering Capital

Governance conversion motivates a useful accounting concept: engineering capital. The field has a mature metaphor for the opposite condition. Technical debt is a liability carried forward: an expedient decision today imposes interest on future change. Engineering capital is the stock of durable engineering assets that lowers the future cost or uncertainty of change.

The asset is not an abstract claim that "the team learned." It is something you can point to. Engineering capital is concrete: a model removes repeated reconstruction; a constraint prevents a failure mode; a sensor makes hidden state observable; a validator turns repeated judgment into a repeatable decision; a gate gives the decision consequence; traceability preserves correspondence; a skill or runbook packages judgment for reuse. Each changes the starting conditions inherited by future work. Engineering capital is therefore broader than "more gates": the conversion of a recurring failure mode can land in a model, in a packaged procedure, or in an authoritative mechanism, and each can contribute to the same stock of reusable engineering capacity.

Engineering capital earns a return by lowering the marginal cost of future work: fewer facts must be rediscovered, fewer failures recur, fewer reviews are spent on mechanically decidable questions, and less rework follows violations. Governance conversion turns an episode of engineering judgment into durable structure; when that structure continues to lower future cost or uncertainty, it earns a return as engineering capital.

The engineered environment evolves with the system it governs.** Lehman's work on software evolution made the analogous observation about software itself: software used in a changing real-world environment must continually adapt, and its complexity tends to increase unless effort is spent maintaining or reducing it. MAGE extends that caution to the engineered environment surrounding the software. Models, validators, constraints, and procedures evolve too — and can become liabilities when they no longer fit what they govern. See Lehman & Ramil 2003 11. M. M. Lehman and J. F. Ramil, “Software Evolution—Background, Theory, Practice,” Information Processing Letters 88 (2003): 33–44.. Capital also depreciates. A model can drift from the system it represents. A validator can encode an assumption the architecture has outgrown. A sensor can become noisy; a gate can impose more delay than the failure it prevents; a once-important control can survive long after its obligation disappears. Maintenance preserves useful capital; reconciliation repairs assets that no longer match the system; retirement removes assets whose carrying cost now exceeds their return. This is why accumulation cannot be the objective. A governed environment with more mechanisms is not necessarily richer than one with fewer. What matters is the future engineering value those mechanisms continue to produce.

Debt makes future work pay again for today's expedience; capital lets future work inherit today's judgment. Governance conversion is one way engineering effort stops being consumed once and becomes reusable structure.

3.4.5 Where Authority Stops

Not every quality goal should end in authoritative enforcement. A consequential concern may remain unrepresented, require human judgment, be evaluated without authoritative consequence, or be governed. Figure 3.4-3 shows the four possible stopping points.

Where authority stops: three questions place any obligation in one of four states — residual, judgment required, evaluated only, or governed A staircase of three questions. First: is the obligation explicit in a form the environment can use? No leads to RESIDUAL — a human or agent must reconstruct it. Yes leads to the second question: can it be evaluated adequately? No leads to JUDGMENT REQUIRED. Yes leads to the third: does authority act on the result? No leads to EVALUATED ONLY — evidence produced and evaluated, but un-gated. Yes leads to GOVERNED. The progression is a design space, not a maturity ladder; different obligations stop in different places. Is the obligation explicit in a form the environment can use? no RESIDUAL human must reconstruct it yes Can it be evaluated adequately? no JUDGMENT REQUIRED no adequate evaluator available yes Does authority act on the result? no EVALUATED ONLY evaluated, yet un-gated yes GOVERNED authoritative consequence design choices, not maturity levels — different obligations stop in different places
Figure 3.4-3. Where authority stops. A concern may remain unrepresented, require judgment, be evaluated without authoritative consequence, or be governed. These are design choices, not maturity levels; different obligations should stop at different points.

Residual. The obligation is not explicit enough for the environment to use, so an engineer or agent must reconstruct the missing meaning.

Judgment required. The obligation is explicit, but available mechanisms cannot evaluate it adequately. Architecture may be represented while a design trade-off still requires expert judgment.

Evaluated only. The environment can produce and evaluate relevant evidence, but no authoritative consequence follows.

Governed. The obligation carries an authoritative consequence appropriate to the engineering decision: the action is constrained, the violation is refused, or admission depends on the verdict.

The same restraint applies to tolerance. Making an acceptable boundary explicit does not imply that the environment should tighten it, or even enforce it mechanically. A broad tolerance may be the correct engineering decision, and variation inside it remains legitimate realization freedom. Stronger Alignment means more dependable authority over the obligation engineering actually chose, not progressively narrowing the acceptable realization space.

DocAble contains examples of each non-governed stopping point, each for a different reason. Some cost controls are deliberately non-binding because imposing a hard daily budget remains a policy choice. DocAble measures governance conversion but does not target a required rate, because doing so would invite gaming. Some accessibility judgments remain outside deterministic enforcement because the available representation does not contain enough semantics to evaluate them reliably. Non-enforcement is sometimes the engineered result.

The mechanism that discovers an obligation need not be the mechanism that ultimately carries its authority. DocAble's primitive-density lint remained an audit signal because high density was only a smell. The migration it provoked produced more specific types, boundaries, and drift controls whose predicates could justify stronger consequences. Part IV follows that migration in detail.

Different obligations should stop in different places. Governance conversion closes recurring gaps when doing so is worth the cost. It also creates the next problem: the environment now contains an expanding portfolio of controls, and those controls can themselves become inconsistent, redundant, or orphaned.

Works Cited

  1. Lehman, M. M., and J. F. Ramil. “Software Evolution—Background, Theory, Practice.” Information Processing Letters 88 (2003): 33–44.
© James C. Davis, 2026–present