6.3 Scope Conditions

MAGE has scope conditions because it costs something: models have to be built and maintained; controls consume compute and attention; synchronization can fail; every new mechanism adds to what the environment must carry. Those costs are justified only where the resulting structure buys something back.

The right unit of analysis is usually an obligation or engineering surface, not an industry label. The same scientific system may have highly governable build and reproducibility machinery around a kernel whose scientific validity remains a matter of expert judgment. A startup may have little reason to model its architecture comprehensively while still needing a hard security boundary around payments. MAGE therefore applies unevenly even within one repository.

6.3.1 Return, Governability, and Authority

Whether MAGE applies to a given engineering surface comes down to three questions:

1. Will it earn a return? Is there enough recurrence or consequence to repay the investment?
2. Can the obligation be governed adequately? Can the property be represented, evidenced, and evaluated well enough?
3. Can the organization act on what it learns? Is there authority to change the shared environment?

Does the investment earn a return? Recurrence is the usual source of return. If the same architectural knowledge, review judgment, or failure class will be encountered hundreds of times, making it explicit once can avoid paying for the same reasoning repeatedly. But recurrence is not the only justification. A rare obligation with catastrophic consequences may warrant extensive modeling and assurance because preventing a single failure can repay the investment. The economic question is therefore broader: does the expected reduction in future reasoning, risk, or recovery cost justify the construction and carrying cost of the asset?

Can the obligation be governed adequately? Some properties can be represented precisely and settled mechanically: a schema conforms, a dependency is permitted, an invariant holds. Others admit statistical evidence but not a definitive predicate. Still others depend substantially on aesthetic, scientific, organizational, or social judgment. Governability is the degree to which an important obligation can be made explicit, supplied with relevant evidence, and evaluated with adequate reliability and acceptable cost. Deterministic checking is its strongest region, not its definition.

The residual probabilistic surface is therefore not necessarily technical debt. Some judgment belongs there. The objective is not to minimize it blindly, but to avoid repeatedly purchasing expensive probabilistic reasoning or residual risk where a cheaper, adequate, and trustworthy representation or mechanism can do better.

One organizational condition determines whether lessons become shared assets: authority to change the shared environment. Someone who discovers a structural problem must have a functioning path to the architecture, models, controls, or shared infrastructure that could address it. Authority need not reside in one person. It has to connect diagnosis to the environment. Without that path, the organization can understand a failure perfectly and still patch it locally forever.

These are theoretical scope conditions informed by Part V, not population estimates.

6.3.2 The Expanding Frontier of Explicit Engineering

MAGE's scope is not fixed because explicit engineering is becoming cheaper and, in some cases, more feasible. Two questions determine where investment pays. The first is economic: how much future reasoning, risk, or recovery cost can an explicit engineering asset avoid relative to its construction and carrying cost? The second is governability: how much of the obligation can be represented, supported with evidence, and evaluated reliably enough to enforce? These questions interact, but neither determines the other.

The distinction matters because consequence does not imply governability. Some consequential obligations admit precise models and strong evaluation: structural loads, resource bounds, protocol states, or dependency relations may eventually support calculation, exhaustive analysis, or proof. Other obligations remain substantially qualitative even when an organization has strong reason — or a legal duty — to evaluate them carefully. Aesthetic quality, scientific validity, organizational fitness, and social acceptability can justify substantial engineering investment without ever becoming completely reducible to predicates.

Part IV gave the practical version of this distinction. A writing style guide can preserve knowledge about good writing even though good writing has no definitive predicate. Some narrower obligations, such as spelling or paragraph length, can be checked deterministically; others, such as whether an introduction prepares the reader for what follows, may admit useful probabilistic evaluation. The DocAble residency model showed the boundary moving in the other direction: repeated empirical judgment about memory behavior became a quantitative invariant once a better representation exposed the relevant relation. Modeling can therefore improve judgment without eliminating it, and it can sometimes make stronger enforcement feasible.

ENGINEERING PRACTICE

Inset — Hard Obligations, Judgment Calls

An obligation does not have to be mechanically checkable to be a real engineering obligation. Consider a historic building. The Secretary of the Interior's Standards for Rehabilitation require certified projects to preserve historic character, and new work must be compatible with the historic building in its massing, size, scale, and architectural features. Replacement features may need to match the original design, color, texture, and other visual qualities.¹1. U.S. Department of the Interior, National Park Service, “The Secretary of the Interior's Standards for Rehabilitation,” 2024. These are real requirements that can determine whether a project is approved, but there is no complete test for compatible with the historic character. Engineers and architects can measure dimensions, identify materials, record features that must be preserved, compare photographs and drawings, and use precedent and design rules. These make the judgment better informed and more consistent. They do not remove the judgment.

Software has the same problem. The Department of Justice's 2024 accessibility rule generally requires state and local governments to make their web and mobile content conform to WCAG 2.1 Level AA, including conventional electronic documents where the criteria apply.²2. U.S. Department of Justice, “Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities,” 2024. Many resulting requirements can be checked mechanically, but the rule also permits an alternative technique when it provides "substantially equivalent or greater accessibility and usability." Whether it does so can depend on the information and functionality preserved, the users and tasks involved, and the barriers the alternative introduces. DocAble sits on this boundary. It can mechanically check many properties that its document models make observable and use probabilistic models for semantic work such as interpreting figures and generating descriptions. But neither proves that every blind student will receive a substantially equivalent experience from every remediated document. Some judgment remains.

The historic-building and accessibility examples make the same point. An obligation can be important, explicit, and legally binding without having a complete formal test. Engineering can still make the judgment better: make the obligation explicit, mechanize the parts that can be checked, and gather good evidence for the rest. The boundary can also move. Better models and measurements can turn judgments that once required an expert into properties the environment can check; better GenAI may make us willing to entrust increasingly difficult judgments to an artificial expert. Here, expert does not necessarily mean human: it means a reasoner capable of making the judgment well enough for the consequence at stake. The goal is therefore not to eliminate judgment, but to give each obligation the strongest form of evaluation and enforcement the available evidence can support.

These examples show why explicit engineering is not a ladder ending in full formalization. Formal methods occupy an important region of the design space: obligations represented with semantics precise enough for machines to derive, search, transform, or verify solutions. Program synthesis, compiler optimization, model-driven engineering, configuration tuning, and formal methods all exploit such representations. Their historical reach has also been limited by cost, because specifications, models, proofs, generators, correspondence machinery, and verification infrastructure cost engineering effort. Commodity intelligence can lower those costs by assisting with specification, invariant discovery, model construction, proof construction, and translation between engineering intent and formal artifacts.

But full formalization is a region of the design space, not its endpoint. Where governability remains limited, greater consequence can justify more investment without making complete formalization feasible. A design organization may invest heavily in models, precedent, examples, structured critique, evaluation procedures, and expert review. An accessibility system may mechanize dozens of standards-derived obligations while retaining semantic and user-experience judgments that no checker can settle. Greater consequence can justify more engineering in either case; it does not make the underlying obligation more governable. A scientific organization may enforce provenance, units, workflow, and reproducibility while leaving scientific interpretation to expert judgment. A bridge project may formally analyze structural obligations while using substantially different evidence and review for its aesthetic relationship to a historic or scenic setting. The right unit remains the obligation or engineering surface, not the industry or artifact.

Two questions therefore guide the investment: how much explicit engineering is worth doing, and how much of the obligation can actually be governed. The value of explicit engineering asks how much explicit structure the obligation warrants: repeated reasoning cost, consequence, recurrence, and recovery cost can all raise it. Feasible governability asks how much enforcement is achievable: whether the obligation can be represented, observed, and evaluated with adequate reliability and acceptable cost. High value does not imply high governability. Where both are high, strong formalization and enforcement mechanisms may pay. Where value is high but governability remains limited, substantial investment can instead improve the representations, knowledge, procedures, evidence, and evaluation through which judgment occurs. Figure 6.3-1 shows the two dimensions together.

Commodity intelligence can change where work falls in this design space in two ways. First, it lowers the cost of constructing and maintaining explicit structure. Models, skills, specifications, validators, proofs, and other engineering assets can therefore repay their cost at lower levels of recurrence or consequence. This makes explicit engineering worthwhile for more obligations without changing the obligations themselves.

Second, better representation, instrumentation, and evaluation can increase governability. An obligation initially expressed only as expert judgment may yield narrower properties that can be evaluated reliably; a property reconstructed semantically from implementation may become a predicate once an appropriate model exposes it directly. Part IV described the practical version: make obligations enforceable where feasible. The determinization frontier describes its strongest case: Modeling changes the representation until a previously reconstructed judgment becomes mechanically decidable, after which Alignment can carry the decision repeatably.

These two changes need not end in the same place. Some questions resist enforcement because the necessary representation or evidence remains unavailable. Others admit probabilistic evaluation adequate for one consequence but not another. Still others are intrinsically plural or contextual: no amount of cheaper implementation turns good writing, scientific importance, or compatible with the historic character into a single definitive predicate. Explicit engineering still pays when it makes those judgments better represented, better informed, more repeatable, or easier to review.

MAGE therefore concerns the whole design space, not progress toward ever greater formalization. It asks which consequential knowledge should be made explicit, which obligations should be enforced where feasible, and which remaining degrees of freedom should stay with probabilistic or expert judgment. At one limit, sufficiently complete and governable realization models may make synthesis, proof-directed realization, or deterministic generation preferable to an agent. Elsewhere, the appropriate governed engineering environment may combine explicit models, reusable skills, probabilistic evaluation, deterministic controls, and expert review. The objective is not maximum formalization. It is the economical division of work among the reasoner, the engineered environment, and expert judgment.

MAGE also applies at different engineering scales. An individual engineer can model the part of a system under active change and govern its realization. A team can connect those local models to shared architecture, ownership, and operational knowledge. A product can connect models and obligations across engineering surfaces, and an organization can carry selected policies, assurance obligations, and engineering knowledge across products.^** This interacts with Conway's law, which relates system structure to organizational communication structure ³3. Melvin E. Conway, “How Do Committees Invent?,” Datamation 14, no. 4 (1968): 28–31.. MAGE does not remove that coupling, but explicit models provide additional surfaces—such as architectural relations, security obligations, or assurance claims—around which responsibility can be organized across implementation boundaries. Purposeful models and explicit correspondence let these scales remain distinct while still informing and constraining one another, so the consequential judgment can stay at the level where it belongs rather than requiring either complete local autonomy or one organization-wide model.

Scale and assurance strength are separate choices. One engineer may use formal verification for a consequential protocol while a large organization relies mostly on design documents, tests, runtime evidence, and human judgment. Organization-wide adoption does not imply maximal formalization, nor does strong assurance require organization-wide adoption.

The frontier is not a destination

Neither change should be mistaken for a destination for software engineering as a whole. Search works when we know enough about what counts as success. Many consequential engineering questions remain open because the correct shape of the system is itself being discovered: which abstraction matters, which tradeoff users will accept, which failure will dominate in operation, or which requirement the organization actually intends. In those cases implementation is not merely realization; it is an experiment that produces information about the specification. And even a question that is closed today may reopen as users, dependencies, organizations, regulations, workloads, or adversaries change. Software evolution therefore remains an outer loop around increasingly powerful episodes of automated realization ⁴4. M. M. Lehman and J. F. Ramil, “Software Evolution—Background, Theory, Practice,” Information Processing Letters 88 (2003): 33–44.. MAGE can turn sufficiently closed engineering questions into search problems when their consequential shape is knowable; it should not get there by pretending that unresolved uncertainty has disappeared.

The main failure mode is premature closure. Explicit does not mean correct. A small probabilistic surface is therefore not itself evidence of good engineering: the environment can determinize the wrong problem. If the organization does not yet know what users need or which tradeoff is acceptable, formalizing one conjecture merely makes the wrong target easier to optimize, and commodity intelligence can make the failure more consequential because it can elaborate the mistaken premise cheaply and at scale.

Engineering capital can also enlarge what can safely be delegated within one system. A model built for today's migration can make tomorrow's change searchable; a differential harness can turn a future rewrite into cheap comparison; a validator can convert repeated judgment into repeatable evaluation. Engineering capital can therefore enlarge the region of work that can later be delegated safely to search.

MAGE therefore predicts a moving economic boundary, not convergence toward complete specification. Requirements emerge through use, organizations change, adversaries adapt, and systems alter the environments that generate their next requirements. Commodity intelligence can move work through this design space; it does not eliminate the world beyond it. Which engineering surfaces become worth representing and governing more strongly—and how that choice changes with consequence, organizational context, model capability, and carrying cost—is an empirical question for the research agenda.

The implication is that scope should be judged surface by surface, according to recurrence, consequence, representability, and carrying cost—not assigned once to an entire project or domain.

6.3.3 Typical Profiles

The two dimensions produce different profiles even within one organization or artifact. Table 6.3-1 gives representative cases. These are not maturity levels: movement toward the upper right is neither inevitable nor always desirable. The appropriate profile depends on the return available from explicit engineering and the governability of the particular obligations at issue.

The pattern is economic rather than categorical. Long-lived systems offer repeated opportunities to amortize representation and assurance. High-consequence systems can justify the same investment even at lower recurrence. Mixed domains divide by engineering surface: scientific software may support strong governance around reproducibility and deployment while leaving scientific validity with domain experts; ML systems can govern pipelines and serving infrastructure much more strongly than they can govern the question, "Is this learned model good?"

At the opposite extreme, do not build elaborate governance around work whose relevant reasoning will not recur and whose consequences do not justify the investment. Use the cheapest adequate mechanism. A prototype may need only tests around one dangerous boundary. If it becomes a long-lived system, the economics change before the label does.

6.3.4 Two Ways an Investment Fails

MAGE becomes a bad bargain in two broad ways. First, the asset never earns a return: the knowledge is not reused, the risk is too small, or the machinery costs more to maintain than the judgment it replaces. Second, the important property cannot be governed adequately: it cannot be represented, evidenced, or evaluated strongly enough to justify moving the decision out of expert judgment.

Most real systems contain both kinds of surfaces. The practical question is therefore not whether a project "uses MAGE," but which properties deserve durable representation or enforcement, how strong the evidence should be, and which decisions should remain with experts.

The next chapter turns the theory, predictions, and boundaries into a research agenda.