3.4 Growing the Governed Environment

No engineered environment begins with every future obligation 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 exposes a recurring class, engineering identifies what was missing, and the environment encodes the lesson as durable structure. 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 important 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 is not enforced. 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 enforcement → add or strengthen a constraint or gate. Make the verdict control the relevant action or admission.

Viewed from Part I, these interventions do different things to the probabilistic surface. Better representation can make a satisfactory realization cheaper to find by reducing reconstruction or exposing the property more directly. Better evidence can make the realized state more legible. A repeatable validator can carry an evaluation independently of the producer, and a constraint or gate can enforce that verdict. Governance conversion is therefore not simply the accumulation of checks; it is the selective transfer of recurring engineering judgment from per-instance reasoning into durable structure.

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 enforcement. The environment improves when recurring reconstruction or judgment moves into durable structure that later work can inherit. Figure 3.4-1 draws the diagnosis.

3.4.3 Correct Judgment Without Enforcement

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.

The failure was not missing evidence. The system had evidence. Nor was evaluation missing: the audit correctly identified the danger. What it lacked was enforcement. 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 enforced, 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 costs on future change. Engineering capital is durable engineering structure that lowers the future cost or uncertainty of change.

The capital must be something future work can actually inherit. A model can eliminate repeated reconstruction; a constraint can prevent a recurring failure; a sensor can expose previously hidden state; a validator can make repeated evaluation mechanical; a gate can enforce that evaluation; a skill or runbook can package judgment for reuse. These assets change the starting conditions of future work. They earn a return when future work requires less reconstruction, repeated judgment, failure, or rework because the structure exists.

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 ¹1. 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 Enforcement Stops

Not every quality goal should end in enforcement. A consequential concern may remain unrepresented, require expert judgment, be evaluated without enforcement, or be governed. Figure 3.4-3 shows the four possible stopping 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 does not enforce the resulting judgment.

Governed. The environment enforces the obligation in a form appropriate to the engineering decision: an action may be constrained, a violation refused, or admission made dependent 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 enforcement of 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 not enforced 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 enforces it. 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 enforcement. 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.