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.
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
- 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.
- 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.
- 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.
- Leveson, Nancy G. Engineering a Safer World: Systems Thinking Applied to Safety. MIT Press, 2011.