2.1 From Context to Engineering Models

A foundation model knows programming languages, frameworks, databases, distributed systems, cloud infrastructure, testing practices, security concepts, and common architectural patterns. It does not arrive knowing the particular system in front of it: its boundaries, history, conventions, ownership, or current engineering state. That knowledge is distributed across source, configuration, documentation, registries, history, and the people who maintain the system. An agent can reconstruct what a task needs from those artifacts, but reconstruction consumes reasoning and is easily repeated across tasks and reasoning states.

AGENT HARNESS

Inset — Skills and Project Instructions

MAGE's emphasis on externalizing engineering knowledge appears in today's agent harnesses in mechanisms such as project instructions and skills. Project instructions give an agent persistent repository-specific guidance: architectural conventions, commands, constraints, or procedures that should apply across tasks. Skills package reusable guidance and resources for a recurring class of work and make them available when that work arises. Both reduce the amount of engineering knowledge that must be supplied by a person or reconstructed by an agent in each new reasoning episode.

These mechanisms differ in scope and structure, and neither exhausts the ways engineering knowledge can be externalized. Project instructions can keep relatively small amounts of cross-cutting knowledge persistently available. Skills can package larger procedures and load them when relevant rather than consuming working context continuously. Retrieval can select knowledge from a larger external store. Models can represent knowledge in structures that support queries, transformations, validation, or deterministic execution rather than relying on prose interpretation. As the representation becomes more structured, the environment can do more with the knowledge than simply show it to the agent.

This is why MAGE focuses on what knowledge must persist and how it should be represented, rather than prescribing skills or instruction files. Those mechanisms are useful contemporary carriers, but the engineering requirement survives changes in harness design: consequential knowledge that would otherwise be tacit or repeatedly reconstructed should be externalized in a form suited to how it will be used.

The first Modeling move is therefore to make reusable engineering knowledge explicit. Instead of asking each reasoner to recover the relevant structure from raw artifacts, preserve the entities and relationships that recurring engineering questions depend on. A task can then retrieve the connected slice it needs rather than reconstructing that slice anew.

The Modeling Principle: externalize engineering knowledge and intent into explicit, structured models that both engineers and agents can reason through. In other words: once a system exceeds what a reasoner can usefully hold in view, give recurring engineering questions purposeful representations.

Software engineering has long treated the externalization of intent as an engineering problem. Requirements engineering, for example, distinguishes stakeholder goals and environmental assumptions from specifications used to constrain a realization, and develops representations through which those claims can be analyzed, refined, and traced.¹1. Pamela Zave and Michael Jackson, “Four Dark Corners of Requirements Engineering,” ACM Transactions on Software Engineering and Methodology 6, no. 1 (1997): 1–30, https://doi.org/10.1145/237432.237434. ²2. Bashar Nuseibeh and Steve Easterbrook, “Requirements Engineering: A Roadmap,” in “Proceedings of the Conference on the Future of Software Engineering,” special issue, Proceedings of the Conference on the Future of Software Engineering (New York), 2000, 35–46, https://doi.org/10.1145/336512.336523. ³3. Axel van Lamsweerde, Requirements Engineering: From System Goals to UML Models to Software Specifications (Wiley, 2009). Important requirements may remain qualitative, incomplete, or dependent on assumptions about the environment. The inheritance MAGE takes from this tradition is the more basic move: make consequential engineering knowledge into an explicit object through which engineering can reason. Part III takes up the separate question of which obligations the engineered environment should enforce.

This Part begins with externalized context and proceeds toward representations with richer semantics, explicit properties, and maintained correspondence to the system. This chapter establishes the underlying modeling move: what counts as a model, what makes one useful, and how an engineering question determines the representation worth carrying.

2.1.1 Modeling Is a Classical Engineering Move

Modeling is not new. Engineering disciplines have long used representations that suppress irrelevant detail so that particular properties of a system can be reasoned about directly. Software engineering inherited and developed the same practice. Architectural descriptions expose components and relations; schemas expose permitted data structures; state machines expose states and transitions; interface specifications expose contracts across boundaries; formal models expose properties precisely enough for mathematical or mechanical reasoning. Model-based systems engineering makes this commitment particularly explicit: engineering knowledge is organized around models that support analysis, communication, design, and assurance across the system lifecycle.⁴4. International Council on Systems Engineering, Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, 5th ed. (Wiley, 2023). ⁵5. ISO/IEC/IEEE, ISO/IEC/IEEE 42010:2022, Software, Systems and Enterprise — Architecture Description, technical report (Geneva, 2022).

The representations differ substantially in purpose and rigor, but they share a basic engineering move: choose a form in which the property of interest becomes easier to express, inspect, or analyze than it is in the realized artifact itself. The value lies in the reduction. A useful model preserves the distinctions required by its question and leaves the rest behind.

MAGE applies this classical move under different economic conditions. Commodity intelligence makes structured representations cheaper to construct, maintain, translate, and consume. Generative implementation simultaneously increases their leverage. As realization accelerates, engineering knowledge about what should be built, how the system is organized, and which properties matter must remain available across an increasing volume of autonomous work.

For readers familiar with model-based systems and software engineering (MBSE), much of the repertoire in this Part will therefore be familiar. MAGE's concern is what happens when these established representations become part of the engineered environment surrounding autonomous realization: agents can reason through them, engineering knowledge can persist across reasoning episodes, and selected properties can later become objects of Alignment.^** Readers with a background in model-based systems engineering may find portions of Part II review. The distinctive concerns for MAGE are the use of models to bound consequential properties while deliberately preserving realization degrees of freedom; the separate Enforcement problem created when realization is delegated to a probabilistic reasoner that does not itself bear engineering responsibility; and the economic question of when explicit representations, their maintained correspondences, and the mechanisms built over them repay their carrying cost. Parts III and VI develop the latter two concerns in detail.

Models also participate in architectural reasoning. They expose relationships and make selected consequences available for analysis; engineers decide the decomposition, boundaries, interactions, allocations, and tradeoffs the system should embody. A model may record an architectural decision already made or reveal that the architecture should change.

SOFTWARE ARCHITECTURE

Inset — Models, views, and software architecture

MAGE follows Fairbanks's definition of software architecture as the set of structures needed to reason about a system, comprising software elements, relations among them, and properties of both.⁶6. George Fairbanks, Just Enough Software Architecture: A Risk-Driven Approach (Marshall & Brainerd, 2010). Engineers therefore reason about one system through multiple views: a component view may expose decomposition, a behavioral view legal transitions, a deployment view allocation, and a quantitative view a resource bound. No one view need contain everything another does.

Architecture consequently cuts across the model classes in MAGE. An architectural decision may depend on structural, behavioral, ownership, decision, measurement, or provenance relationships together. The useful views follow from the engineering questions that must be answered.

Software makes the relationship between model and realization unusually fluid because both are made of information. A schema can generate code; a state machine can drive behavior; a policy model can generate configuration; a dependency graph can become an execution plan. Such a representation can participate directly in the system while remaining selective about what it represents.

When structured views are cheap to derive, maintain, connect, query, analyze, and sometimes execute, more of the knowledge required for architectural reasoning can remain explicit rather than being repeatedly reconstructed from implementation. Modeling names that MAGE activity.

A useful model need not be elaborate. Sometimes it is three states and two legal transitions; sometimes a list of permitted service edges; sometimes a schema joined on stable identifiers. The question is never how much can we model? It is what representation makes this recurring engineering question easier to answer?

2.1.2 A Model Is a Purposeful Reduction

A model is a purposeful reduction of a system. It preserves the information one engineering question needs and suppresses the detail that question does not. Its value is not completeness but selective omission. A reduction an engineer or agent can reason through is more useful than a faithful copy too large to hold in view.

Purposeful reduction is therefore not only compression. It can change the difficulty and character of reasoning. A property that requires semantic reconstruction over thousands of implementation details may become a relation over a small graph, a transition over a finite state space, or a bound over a measured quantity. The representation does not make the answer true. It can make the question tractable. Nor does it make the design decision: it makes selected consequences of that decision easier to reason about.

This is the connection Modeling shares with representation learning: what a reasoner can infer efficiently depends partly on the form in which the problem is presented. MAGE begins from representations engineering has already developed for consequential system questions rather than asking a learned reasoner to rediscover those abstractions on every task.

Tolerance and degrees of freedom

The suppressed detail has a realization-side consequence. Engineering obligations rarely determine a single acceptable realization. They constrain some variation and leave other choices open. This book uses two engineering terms for that distinction. A tolerance bounds the variation that an obligation permits; a degree of freedom is a realization choice left open because the governing obligations do not distinguish among its acceptable alternatives. Purposeful reduction therefore does two things at once: it represents the distinctions the engineering question requires while declining to settle choices that do not matter to that question. MAGE does not seek to close those degrees of freedom merely because they could be specified.

In software engineering, a tolerance can be numeric but is often qualitative. A latency budget may set a numerical bound: a response must complete within 200 ms. Coupling admits an intermediate form: an architecture may tolerate dependencies up to a measured threshold while also distinguishing kinds of coupling that are acceptable or prohibited. Other architectural tolerances are primarily qualitative: one component may depend on another through a declared interface but not reach directly into its implementation. The difference partly follows from the medium. Physical engineering often concerns continuous quantities such as length, voltage, pressure, or temperature, so tolerances naturally take numerical form. Software structures and behaviors are largely discrete—types, sets, relations, graphs, states, and transitions—so tolerances often define sets of acceptable realizations instead.

Software's medium compounds this: because programs are constrained less by physical material than by the information they must accept, produce, and preserve, different implementations can satisfy the same obligations, so the space of acceptable realizations is often large.⁷7. Frederick P. Brooks, “No Silver Bullet: Essence and Accidents of Software Engineering,” Computer 20, no. 4 (1987): 10–19. Engineering need not choose one point in that space merely because it could. It can instead specify the properties that distinguish acceptable from unacceptable realizations and leave the remaining choices open. Commodity intelligence changes the economics of exercising that freedom: once realization becomes cheap, an autonomous reasoner can construct and revise implementations inside a space that would previously have been expensive for human engineers to explore. Modeling identifies the consequential distinctions; Alignment can enforce selected boundaries. The rest remains available to realization.

Figure 2.1-1 draws the relationship: obligations bound a region without selecting a point inside it.

Not every unmodeled choice is free

This also distinguishes tacit obligations from genuinely free choices. An unmodeled choice can look open even when engineers would reject some realizations of it. Then the choice was never wholly free. Human judgment was already imposing a boundary. What was missing was an explicit representation of the obligation or its tolerance. A genuinely free choice is different. Once the governing obligations are accounted for, engineering has no reason to distinguish among the remaining alternatives. A useful diagnostic follows: if a realization would provoke not that, some consequential boundary remains, whether or not anyone has written it down.

An unmodeled choice can therefore mean several things. The consequence may not yet be understood; an obligation may remain tacit; the obligation may be explicit but not represented; or the choice may genuinely be free. These states can change as engineers learn from the system. A region initially treated as free may expose recurring costs or interactions that reveal an obligation; another may be investigated and turn out to contain no consequential distinction at all.

ENGINEERING

Inset — Uncertainty and unknown unknowns

Engineering distinguishes a choice deliberately left open from one whose consequences are not yet understood. The first is a degree of freedom. The second is uncertainty. In the harder case—sometimes called an unknown unknown—engineering has not yet recognized the consequential property, interaction, or failure well enough to ask the right question about it. An unmodeled region therefore should not be assumed to be free merely because no obligation has been stated.

A model cannot directly represent what engineering has not yet recognized. It can, however, make uncertainty more inspectable. By reducing a complicated system to selected entities, relations, states, quantities, or alternatives, a model can make variation and interaction easier to compare and trace. Unexpected behavior can then expose distinctions that were difficult to see in the realized system directly. A degree of freedom is known freedom; uncertainty is not.

This is one reason modeling can precede specification. Sometimes engineers construct a model because they know which property must hold. Sometimes they construct one to discover which properties matter.

Modeling does not require complete specification. Engineers can model what is known while leaving uncertainty visible and genuine freedom unconstrained. As understanding improves, the model can change with it.

The question is the design input. Ask whether two workers can process the same job at once, and the color of the web interface falls away; you need who can own work, how ownership is acquired, when it expires, and what happens after a crash. Ask instead whether one service may bypass another, and the ownership details fall away; now you need components, communication edges, and the seams a call must pass through. The system did not change. The question did. The useful reduction is not always obvious at first. Sometimes you have to look at the problem differently to see which relationships matter.

Hold the system constant. Change the engineering question. Watch the model change.

There is no single "model of the system," only reductions built to expose particular properties. A model earns its place by the question it settles, not by how much of the system it represents.

This idea also has a long history in artificial intelligence. Knowledge-representation research treats a representation as more than stored information: its form embodies commitments about what distinctions matter and affects what kinds of inference are convenient or possible.⁸8. Randall Davis et al., “What Is a Knowledge Representation?,” AI Magazine 14, no. 1 (1993): 17–33, https://doi.org/10.1609/aimag.v14i1.1029. MAGE applies the same principle to engineering representations. A dependency graph, state machine, contract, or measurement model is useful not because it records more of the system, but because its chosen structure makes a particular engineering question cheaper to answer.

A representation remains a purposeful reduction even when it is executable. Some models in this Part participate directly in execution or analysis: machines query them, derive artifacts from them, generate from them, or check properties over them. Software can therefore make the distance between architectural representation and realization unusually small. Executability changes what a model can do; it does not make the model a complete representation of the system. That is why the examples ahead are drawn as reductions before their implementations are discussed: the abstraction should remain visible apart from its encoding.

2.1.3 Structure Makes Representations Machine-Operable

AGENT HARNESS

Inset — Tools

MAGE seeks to move suitable work out of probabilistic reasoning and into engineered mechanisms. Today's agent harnesses do this partly through tools. A tool gives the agent an engineered capability it can invoke: querying repository state, parsing a file format, running a compiler, inspecting a dependency graph, applying a transformation, or executing some other operation whose mechanics need not be reconstructed through model reasoning each time.

Tools change the division of labor inside the engineered system. Suppose an agent needs to determine which component owns a file. It might infer ownership from directory names, nearby code, and documentation. Or the environment might maintain an ownership model and expose a query over it. In the second case, the agent still has to decide why ownership matters and what to do with the answer, but it no longer has to infer the answer from indirect evidence. The same move applies to parsing, dependency analysis, schema validation, code transformation, and many other operations: suitable work can move from probabilistic reconstruction into mechanisms whose behavior is engineered directly. Merely exposing a tool does not guarantee that the agent will invoke it when appropriate, so consequential uses may need to be built into the surrounding workflow or checked at an enforcement boundary.

This is why MAGE's concern is broader than tool use. A tool is one contemporary interface through which an engineered environment can expose knowledge or capability. The deeper design question is what the probabilistic implementor should actually have to realize. As more knowledge and suitable operations move into models, queries, transformations, validators, and other engineered mechanisms, reasoning can be concentrated on the decisions that still require it.

Externalizing knowledge saves reconstruction only if a machine can read it back. Machines can read externalized knowledge more reliably when its important entities and relations are structured — given a declared shape — rather than recoverable only from prose. Schemas, registries, graphs, and typed records expose entities and relations that tools can traverse, validate, and join reliably.

A common useful form is a graph of engineering entities and relations. Its nodes are engineering entities: services, modules, endpoints, queues, databases, requirements, tests, owners. Its edges name the relations: calls, depends on, deployed to, owned by, verified by. The graph need not live in a graph database. YAML, registries, and schemas joined on stable identifiers can represent the same structure. The word graph names the structure, not the storage. Relevance then follows relationships: start at the entity a task names, and its neighbors come with it, so the agent reasons over a connected slice instead of a document dump.

Many of these representations can be interpreted as graphs of entities and relations. Their shape is not what distinguishes them; their semantics are. A dependency edge, a transition, an ownership claim, and a permission can all be drawn as arrows while answering different engineering questions. The representation becomes useful through what those entities and relations mean.

Externalizing knowledge this way is the lightest form of Modeling, and much of current practice already stands on it. Spotify's public account describes a retrievable service catalog. Cloudflare's describes standards externalized under stable identifiers. Shopify's describes a different form, in which agent sessions are mined into reusable skills. DocAble assembles its graph from registries, schemas, and YAML joined on stable identifiers. Each makes selected engineering knowledge durable outside a single reasoning episode, allowing later agents to retrieve rather than reconstruct it.

2.1.4 Representations Support Accumulating Capabilities

Structured representations support different capabilities: externalized knowledge, typed relationships, explicit semantics, stated properties, derivation, generation, traceability, and checking. A representation may acquire additional capabilities as engineers ask more of it, but these are not a required sequence or maturity model.

The practical rule is selective modeling. Model facts that are repeatedly reconstructed and properties that are repeatedly adjudicated. A service catalogue may end repeated ownership discovery; an invariant may retire a recurring class of judgment. Add structure when the resulting reduction in recurring engineering work justifies carrying it.

Enforcement remains separate. A rich model may remain advisory, while permissions, sandboxes, compilers, or tests may enforce obligations with little explicit system-level modeling. Modeling expands the set of properties that can be stated and evaluated; Part III asks which the engineered environment should enforce (Figure 2.1-2).

2.1.5 Six Classes of Engineering Question

MAGE uses six model classes as a working classification. The classes are organized by the engineering question a model helps answer, not by notation or implementation form. They are useful rather than exhaustive, and they can overlap: one represented object may participate in several classes. The classification is a working engineering repertoire, not a claim that these six classes form a minimal basis for engineering reasoning; Part VI reopens that question.

The six classes ahead differ less in shape than in semantics. At an abstract level, each can be understood as a graph: a set of things and relationships among them. A structural model might use nodes for components and edges for dependencies. A behavioral model can use nodes for states and edges for transitions. An ownership model relates work, owners, and claims; a decision model relates alternatives through permitted choices; measurement and provenance models likewise connect quantities or events through meaningful relations. The important difference is not that one is a graph and another is not. It is what the nodes and edges mean, and therefore what questions the representation can answer.

This is why MAGE classifies models by engineering question rather than notation. The same graph-shaped representation can answer different questions depending on its semantics, and one system fact can participate in several views. Architectural reasoning likewise crosses the classes: one design decision may require several views because it affects several engineering concerns.

Figure 2.1-3 sets out a portion of that repertoire: nine familiar representations, read as a set of moves rather than a taxonomy of all modeling. MAGE prescribes no new notation, and the repertoire is larger than the six classes the rest of this Part organizes.

ENGINEERING

Inset — Reuse the engineering repertoire

This Part does not attempt to enumerate every useful model or every consequential engineering question. Its purpose is to draw attention to the fact that your system has consequential questions, and that models provide a means of articulating those questions in representations that let engineers reason about those properties and give agents a succinct form in which to reason about them. The examples ahead illustrate that practice rather than exhaust it.

But you are an engineer. Take this not as an invitation to invent a new modeling technique for every problem, but as a reminder to study the models, patterns, and analyses your field has already developed. Once the engineering question is known, start with the established repertoire. State machines capture legal transitions; dependency and data-flow graphs support reachability questions; schemas capture entities and relations; queueing and resource models expose capacity and contention; decision tables and constraint systems expose permitted combinations. Each comes with known semantics, applicable analyses, strengths, and tradeoffs.

This is much of what it means to be an engineer. An engineer who needs to sort data does not ordinarily invent a sorting algorithm from first principles. The wise engineer recognizes the problem, knows the established algorithms, and selects among them according to the properties and tradeoffs that matter. Modeling should work the same way. The important judgment is often recognizing the engineering question and selecting a representation that preserves the properties needed to answer it. Occasionally the established repertoire is inadequate and invention is required. Recognizing when that is true, and devising the new abstraction, is precisely the kind of judgment for which engineers are valuable.

There are books full of this accumulated knowledge. Software architecture, model-based systems engineering, formal methods, databases, distributed systems, operations research, performance engineering, and other fields document modeling techniques and the conditions under which they work. MAGE does not reproduce those catalogs. It provides a framework for deciding when such knowledge should become an explicit part of the engineered environment. A governed engineering environment can then make the relevant repertoire—or an approved subset of it—available directly to agents. Appendix E shows one realization: DocAble's self-governance skill packages the MAGE engineering method for agents, including a modeling repertoire and modeling moves. The agent can recognize a situation, choose an appropriate Modeling or Alignment move, act through the environment, and learn from the resulting evidence rather than inventing its engineering method afresh on each task. The repertoire is reusable engineering knowledge; choosing from it remains engineering judgment.

The six classes (Figure 2.1-4) name the questions the rest of the Part is built around:

• Structural — what exists, and how the parts relate?
• Behavioral — what may happen, and in what order?
• Ownership — who controls what, and for how long?
• Decision — what is allowed, or which alternative should be selected?
• Measurement — how much, and against what envelope?
• Provenance — what happened, and what evidence records it?

These are views, not boxes. The in-flight lease we reach in the ownership chapter supports Ownership, Behavioral, and Measurement models at once. The classification tells us which question we are asking, not where the representation belongs. A class suggests the questions to ask and the relationships worth preserving; it does not prescribe one notation, and a useful model may cross class boundaries.

System knowledge is not a seventh class. It is the connected substrate in which the six meet — where a service named in a structural model is the same service a decision model references, and a work item in an ownership model resolves to the measurements associated with it. Architectural reasoning can traverse that substrate without requiring one universal model of the architecture. The final chapter of the Part treats the substrate directly.

The classes expose different kinds of acceptable variation. A behavioral model can distinguish legal from illegal executions; a decision model can delimit a set of permitted alternatives; a measurement model can place a quantity against an envelope. Structural, ownership, and provenance models can likewise expose obligations that constrain some realizations while leaving others open. Tolerance names the permitted variation under an obligation; it is not a seventh class of model.

The model class names the engineering question; the representation form is a separate choice. Structural, behavioral, or ownership questions might all be represented as graphs, tables, schemas, or other structured forms. Purpose comes first; representation follows. The question determines which entities, relations, and properties the model must preserve — so represent shared facts once where practical, then project or join the view the question requires.

The chapters ahead apply this repertoire to six production models from DocAble: its document-processing architecture, recovery ordering, in-flight ownership, service-flow policy, cost-and-capacity model, and attribution record. The final chapter then asks how such representations connect through shared identity without collapsing into one universal graph.

A model does not govern the system merely by existing. Modeling makes an engineering property explicit; Alignment makes selected properties enforceable.