Modeling
Software engineering has always relied on abstraction. Large systems exceed what any engineer can reason about directly, so engineers understand them through purposeful views. A dependency graph exposes relationships among components; a state machine exposes legal behavior; a schema exposes permitted structure; a quantitative model exposes a resource bound. Each representation preserves what an engineering question needs and suppresses what it does not.
Explicit models have nevertheless remained secondary in much code-centric software practice because another representation costs work to create, maintain, and reconcile with a changing system. Commodity intelligence changes that economics. Agents can increasingly derive, regenerate, reconcile, and query structured representations cheaply. At the same time, rapid autonomous implementation increases their value: engineering knowledge that once needed to be reconstructed occasionally may otherwise be reconstructed across many tasks and fresh reasoning states.
Modeling principle
Externalize engineering knowledge and intent into explicit, structured models that both engineers and agents can reason through.
Appropriate representations make broader engineering questions tractable and make additional properties available for Alignment.
MAGE therefore treats Modeling as an engineering activity in its own right:
What should I model, and what will the model let me know?
Which model is useful depends on what the engineer needs to know. A concurrency question may require ownership and lifecycle; an architectural-boundary question may require components and permitted communication edges. Different questions about the same system therefore call for different reductions.
Engineering questions recur in several broad forms. Structural questions ask what exists and what is connected; behavioral questions ask what may happen; ownership questions ask who controls work; decision questions ask what is allowed; measurement questions ask how much and against what bound; provenance questions ask what happened and what evidence records it. These are useful views into the modeling repertoire, not a partition of engineering models. The same worker may appear as a component in one model, an actor in a lifecycle in another, and the owner of work in a third. This chapter develops three of these views in detail, then connects several models to answer questions that cross individual views.
DocAble is the running example—the production accessibility service introduced in Chapter 1. A document enters, remediation is distributed across workers and services, the result is validated, and a corrected document returns with a record of what changed. The real system is far more complicated than any single representation ahead. That is the point. Each model keeps only the relationships its question needs. The DocAble specifics ahead — models, mechanisms, and counts — describe the repository revision examined at the time of writing; the live system moves, and exact quantities belong to figures regenerated from it.
Each worked section begins with a familiar engineering representation, the properties it makes expressible, and the analyses it supports, then specializes that representation to DocAble. Four terms stay distinct throughout the chapter. A property is a claim that can be expressed over a model. An invariant is a property required to hold over a declared domain. An analysis or check produces evidence about a property. Whether the engineered environment enforces the resulting obligation is a separate question of enforcement, taken up in Chapter 3.
Four questions for every model
Every model section ahead opens on the same four lines:
- Engineering question — what am I trying to know or decide?
- Model — what representation makes the question tractable?
- Property — what can I now state precisely?
- Quality attribute — what engineering concern does that property serve?
Chapter 3 adds a fifth question: what enforces the property? Modeling makes properties explicit; Alignment makes selected obligations enforceable.