Appendix A — MAGE Engineering Stacks

Stacks: mechanisms that travel together

A single pattern in the preceding appendices kills one failure class. In practice, though, mechanisms arrive in clusters — a concept you want to adopt (model-based engineering, a self-operating orchestrator, an auditable format seam) is not one mechanism but several that reinforce each other. This appendix names those clusters. Each stack attaches to a concept, lists the mechanisms that make it up, and says which of them you can leave out.

A stack composes at a different grain than a package move. A package is composition inside one mechanism — a constraint shipped already welded to its own dedicated sensors, still one catalogue entry. A stack is composition across several distinct mechanisms — many entries that together make one governed capability. Both travel together; the package is the intra-mechanism weld, the stack the inter-mechanism cluster.

Every stack sorts its members into two kinds:

• Mandatory — the stack fails without this member. Model-based engineering needs both the typed models AND the drift control that keeps them equal to the code; adopt the models alone and you ship a map the fleet will trust while it quietly lies. A self-operating orchestrator needs its work-templates. These are the members you cannot skip without breaking the concept.
• Complementary — layers on top for extra value, not required for correctness. Dynamic context-injection can sit on top of a semantic-lint stack to prevent the violation the lint already catches; heartbeats sharpen an observability stack that already sees and responds. Worth adopting, but the stack stands without them.

Each member links to its own pattern page in the earlier appendices. Read a stack to see which mechanisms you must adopt as a set, and which you can add later.

Where every mechanism sits

One idea sits above the pattern set rather than beside it: enforce at the right semantic level. A control must fire at the level where the property actually lives (structural → deterministic check; semantic → model/judge) and be as legible as the failure it prevents — the placement judgment that explains WHERE every other mechanism sits.

It earns that place because it is a choice, not a pattern you reach for. Aim a check one level too low and it passes the violation it should catch while firing on the legal case it should allow — present, but wrong. Read the pages that follow with this lens: each pattern is as much a decision about level as about shape.

The nine capabilities

The mechanisms answer to nine capabilities a governed engineering environment needs. Each names a job the fleet must do; the patterns grouped under it are the shapes that do it. Nine peers are hard to hold, so they hang on the book's own triad of what governance acts on — the models-bridge the fleet reasons through, the product it ships, and the agent fleet that does the work. The stacks below and the reference that closes this appendix both sort into these nine.

Models-bridge — the map the fleet reasons through, held equal to reality.

• Maintain authoritative system knowledge. Represent intent + structure in typed models the fleet reasons through.
• Keep representations equal to reality. Reconcile model ↔ code/system; catch drift mechanically.

Product — the shipped artifact: constrained, complete, preserved, attributed.

• Constrain where and how agents act. Sanctioned mutation surfaces + closed action vocabularies + semantic policy.
• Establish completion on re-derived evidence. Recompute completion; derive assurance obligations from the model.
• Preserve product semantics. Guarantee the product's meaning survives mutation + conforms to spec.
• Track provenance and trace causes. Durable, complete, checkable attribution of every mutation and cause.

Agent — the fleet that produces work: admitted, managed, self-governed.

• Admit or reject changes. Gate the work order and the path to production.
• Manage work, state, and resources. Lifecycle records, resource mediation, and fleet observation.
• Govern the control estate itself. Model, cover, and encode the governance system as its own subject.

A note on vendor features

The mechanisms in this book are described against one concrete substrate — a coding agent and its harness — because a real system is what makes them legible. The mechanism is never the vendor feature, though; the vendor feature is one instance of it. A harness's lifecycle hooks, for example, realize a general idea: enforcement points on the agent's runtime lifecycle, where a deterministic step fires whether or not the agent cooperates. Your framework may expose that idea differently — a middleware layer, a git hook, a CI stage, a wrapper process — and the concept carries across intact.

Read every "the agent does X" in these appendices as here is one way to realize the MAGE concept X. The concept is the portable part, and it is what you are meant to take with you.