Alignment

Engineering systems differ in how they carry their obligations. Some remain in human expertise, documentation, or practice and must be interpreted when the relevant decision arises. Others are encoded into the engineered environment so that compliance can be evaluated or required mechanically. Software architecture provides one example: an architecture can state permitted dependencies and interactions, while conformance checks determine whether an implementation respects them.11. Gail C. Murphy et al., “Software Reflexion Models: Bridging the Gap between Source and High-Level Models,” in “Proceedings of the 3rd ACM SIGSOFT Symposium on Foundations of Software Engineering,” special issue, Proceedings of the 3rd ACM SIGSOFT Symposium on Foundations of Software Engineering (New York), 1995, 18–28, https://doi.org/10.1145/222124.222136. 22. Neeraj Sangal et al., “Using Dependency Models to Manage Complex Software Architecture,” in “Proceedings of the 20th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, And Applications,” special issue, Proceedings of the 20th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, And Applications (New York), 2005, 167–76, https://doi.org/10.1145/1094811.1094824. 33. Leonardo Passos et al., “Static Architecture-Conformance Checking: An Illustrative Overview,” IEEE Software 27, no. 5 (2010): 82–89, https://doi.org/10.1109/MS.2009.117. System-safety engineering provides a broader precedent, identifying hazards and constraints over the larger system and designing controls, feedback, and operating processes to keep those constraints satisfied.44. Nancy G. Leveson, Engineering a Safer World: Systems Thinking Applied to Safety (MIT Press, 2011). Software engineering uses mechanisms ranging from types and access controls to validators and deployment gates for the same purpose.

MAGE calls this move Alignment and treats it as the companion to Modeling. Modeling makes engineering knowledge and intent explicit. Alignment makes selected obligations enforceable by connecting them to mechanisms in the engineered environment that can constrain work, evaluate its results, or determine whether those results are accepted. An obligation with no such mechanism may still matter greatly, but satisfying it continues to depend on human or agent judgment at the point of use.

Commodity intelligence makes this longstanding problem newly important. A generative implementer can produce plausible realizations rapidly and explore degrees of freedom that human implementers might never have considered. Instructions alone do not determine which realization will appear. If an architectural relation, behavioral invariant, ownership rule, measurement requirement, or policy matters to the system, relying on every future realization to reconstruct and voluntarily preserve it leaves that obligation on the probabilistic surface.

Selected obligations can instead be encoded into the engineered environment. Some can be enforced directly through interfaces, permissions, types, or other constraints; others require evidence produced as work proceeds and evaluated before the result is accepted. The appropriate mechanism depends on the obligation and on where the evidence needed to evaluate it becomes available.

Alignment principle

Make engineering obligations enforceable by encoding them into mechanisms that constrain actions, produce evidence, evaluate that evidence, and control admission.

Not every preference warrants mechanical enforcement, and not every important property can support it. Some obligations remain dependent on expert judgment; others would cost more to mechanize than doing so is worth. Part II's tolerances and degrees of freedom also distinguish obligations from variation that engineering deliberately leaves open. The chapters ahead develop how to choose among these possibilities.

Figure 3.0-1 traces the progression from engineering intent to a governed environment.

Alignment: how engineering intent becomes enforced, across the five chapters of Part III Five engineering moves descend a vertical spine, each a chapter of Part III. Locate, 3.1, asks where enforcement can act. Justify, 3.2, asks what it may legitimately enforce. Mechanize, 3.3, asks how a mechanism enforces an obligation. Learn, 3.4, asks how the environment acquires new obligations and controls. Govern, 3.5, asks how accumulated controls are governed as a system. The arc runs from locating where enforcement can act down to governing the controls that result. ALIGNMENT: HOW INTENT BECOMES ENFORCED From engineering intent to governed environment 3.1 LOCATE Where can enforcement occur? 3.1 · Where Obligations Can Be Enforced 3.2 JUSTIFY What may it legitimately enforce? 3.2 · From Intent to Obligation 3.3 MECHANIZE How does a mechanism enforce an obligation? 3.3 · The Four Mechanism Roles 3.4 LEARN How does the environment acquire new obligations and controls? 3.4 · Growing the Governed Environment 3.5 GOVERN How are accumulated controls governed as a system? 3.5 · When Controls Become a System
Figure 3.0-1. How intent becomes enforceable. Enforcement begins by placing a mechanism at a boundary where the obligation can be evaluated or constrained. Mechanisms enforce selected obligations; experience reveals additional opportunities for governance; accumulated controls eventually require governance of their own.

Some mechanisms can be designed before work begins. Others emerge when a failure exposes something the environment did not represent, observe, evaluate, or control. When those lessons become durable engineering structure, later work can inherit them as engineering capital. As the mechanisms accumulate, the control machinery itself becomes an engineering object.

Works Cited

  1. Murphy, Gail C., David Notkin, and Kevin J. Sullivan. “Software Reflexion Models: Bridging the Gap between Source and High-Level Models.” In “Proceedings of the 3rd ACM SIGSOFT Symposium on Foundations of Software Engineering.” Special issue, Proceedings of the 3rd ACM SIGSOFT Symposium on Foundations of Software Engineering (New York), 1995, 18–28. https://doi.org/10.1145/222124.222136.
  2. Sangal, Neeraj, Ev Jordan, Vineet Sinha, and Daniel Jackson. “Using Dependency Models to Manage Complex Software Architecture.” In “Proceedings of the 20th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, And Applications.” Special issue, Proceedings of the 20th Annual ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, And Applications (New York), 2005, 167–76. https://doi.org/10.1145/1094811.1094824.
  3. Passos, Leonardo, Ricardo Terra, Renato Diniz, Marco Tulio Valente, and Nabor C. Mendonça. “Static Architecture-Conformance Checking: An Illustrative Overview.” IEEE Software 27, no. 5 (2010): 82–89. https://doi.org/10.1109/MS.2009.117.
  4. Leveson, Nancy G. Engineering a Safer World: Systems Thinking Applied to Safety. MIT Press, 2011.
© James C. Davis, 2026–present