Appendix A: Failure Modes and Limits
A governed loop offers conditional guarantees, not universal correctness. Under its stated trust assumptions, it can establish that effects stayed within declared bounds, required checks ran, transitions followed policy, terminal evidence was sealed, and admission used the required authority. It cannot establish that the Map was wise, that the Validators covered every relevant property, that hidden dependencies did not correlate two evaluators, or that the governance cost was justified.
The following failure modes mark that boundary. Some identify conditions under which the architectural guarantees fail; others identify limits the architecture cannot remove or cases in which the governed path is not worth its cost.
Mis-scoped Context
A Context Packet can be too small to contain a necessary contract or too large to preserve relevance. In the first case, the generator works without a fact needed to satisfy the Mission. In the second, unrelated material competes with the active constraints and enlarges the surface on which plausible but unauthorized structure can appear.
Deterministic extraction does not make a bad slice sufficient. It makes the slice reproducible. The evidence must therefore distinguish omitted authority, irrelevant inclusion, and unauthorized effects rather than collapsing all three into “the model failed.”
A protected effect boundary can reject an overbroad candidate. It cannot recover an omitted truth. If the active authority cannot support a sufficient Context Packet, the run must fail or stop for separately authorized correction; it cannot silently widen its own scope.
Non-convergence
Refinement does not guarantee convergence. Findings may repeat, alternate, or disappear without a meaningful improvement. Constraints may conflict. A requested state may be unreachable under the active budgets and effect envelope. A probabilistic evaluator may also vary enough to create the appearance of progress where none exists.
The relevant evidence spans attempts: candidate identities,
normalized findings, state signatures, evaluator protocol identities,
and progress measures. A finite loop responds to absent progress by
stopping. Ordinary exhaustion, oscillation, or repeated failure ends as
failed_with_evidence. blocked is reserved for
a named external condition such as missing authority, an unavailable
trustworthy oracle, contradictory Mission terms, or an environment
repair that the run cannot perform.
Finite failure is part of reliability. A loop that cannot establish progress but closes with evidence reconstructable under the protected-sink and trust-root assumptions stated later in this appendix has behaved more reliably than one that continues until a favorable answer appears.
Map Contamination
Map Contamination occurs when generated structure is mistaken for observed or adopted structure. A model invents a route, signature, schema field, dependency, or policy statement; a later step records that invention as if a Sensor had extracted it from Terrain or an authorized process had adopted it. Subsequent runs then optimize against a self-confirming fiction.
The Skeleton-First rule prevents one common form of this failure: Sensors extract structural facts, while models may propose bounded content around them. The deeper invariant is authority direction. A Terrain-to-Map workflow may report observed structure but may not make that structure intended policy. A Map-to-Terrain workflow may propose implementation from adopted intent but may not rewrite the intent that judges it.
Post-processing cannot erase an authority violation. If a candidate attempted undeclared effects, the complete attempted footprint remains evidence even when a deterministic cleanup could produce an apparently compliant diff. The candidate is rejected as attempted; a new candidate may be generated under corrected authority and context.
Validator Error and False Confidence
A Validator can be wrong. It can reject an acceptable candidate, accept a defective one, encode a stale rule, or test a property too weakly. Completing every required check therefore means only that the declared evidence requirements were satisfied. It does not mean that every important property was declared or that the resulting software is good in every relevant sense.
Probabilistic evaluation adds instability and correlation risk. Shared models, prompts, retrieval, fixtures, or context can make generator and evaluator agree on the same wrong answer. Chapter 3’s protected protocol makes that uncertainty more visible; it does not abolish it.
For a protected high-consequence property, a probabilistic evaluator cannot be the sole oracle unless adopted policy explicitly accepts its measured error characteristics for that Mission class. Repeated false-positive or false-negative evidence may justify a Validator-change proposal. The active candidate cannot soften the rule that evaluates it.
Completion Without Admission
Chapter 10’s boundary remains decisive: complete closes
a proposal; it does not make the candidate Terrain. Admission
revalidates the current base, policy, identity, approvals, and protected
evidence. Any changed or missing predicate can deny the proposal without
reopening its sealed Run Record.
Automatically applying every complete candidate would
collapse validation into authorization. The same rule applies to Maps
and policy: history may support a proposal, but only separate adoption
changes authority.
Trust-Root Failure
The Ledger is contradiction-resistant only under a protected sink and trust root. Hash chains, independent storage, integrity checkpoints, and access control can expose missing, reordered, or conflicting evidence. They cannot prevent a sufficiently privileged actor from replacing both the evidence and the mechanism used to verify it.
Likewise, a Scope Guard is meaningful only when the runtime, credentials, execution isolation, and admission path are outside candidate control. If an ordinary Mission can rewrite its own Validator, conceal network effects, replace its evidence, or bypass the Mission Gate, the governed-loop claim no longer applies. The architecture makes the trust boundary explicit; it does not make that boundary invulnerable.
Economic Failure
A governed loop can cost more than it saves. Validator maintenance, false-positive handling, evidence retention, protected execution, and review all consume engineering capacity. For low-risk or infrequent work, ownership may cost more than the recurring work justifies.
The architecture does not guarantee productivity or strategic advantage. A workflow that is reliable but uneconomic should remain narrow, run with less autonomy, or not exist.
The Claim That Remains
Software Development as Code does not promise perfect specifications, complete oracles, inevitable convergence, tamper-proof history, or cheaper delivery everywhere. Its narrower claim is stronger because it is testable: under declared authority and trust assumptions, selected effects, evidence requirements, transitions, and admission decisions can be made explicit and enforceable.
That changes the shape of failure. Missing evidence stops the run. Scope violations remain visible. Non-convergence ends finitely. Completed proposals remain separate from adopted reality. History may inform future authority but cannot install it. The system can still be wrong, but it becomes harder for uncertainty to masquerade as permission.