Appendix D — Mechanism Stacks
Packages of mechanisms that travel together
A single pattern in the preceding appendices kills one failure class. In practice, though, mechanisms arrive in packages — a concept you want to adopt (model-based engineering, a self-operating orchestrator, an auditable format seam) is not one mechanism but a cluster 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.
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.
‹ PreviousAppendix C - 20. Typed `ViolationCategory` / `FailureCategory` enumsContentsNext ›Appendix D - 1. The MBSE stack
© James C. Davis, 2026–present