Model
Represent entities, state, boundaries, dependencies, time, and failure modes explicitly enough to reason about them.
Identification
Diagnostic questions
- What are the system's authoritative objects and states?
- Where are its trust and control boundaries?
- How does state change over time?
- What can fail, and what follows from that failure?
In practice
MachineIQ models equipment and loss scenarios as explicit records, because a judgement about how a machine fails is only reusable if the failure is written down as an object rather than held as an opinion. Star Trek: Alter Course models a world whose transitions are named, which is what makes a run reproducible. Project Standards models conventions as schemas, which is what makes them checkable.
A useful model is usually smaller than expected and more explicit about boundaries than feels comfortable. The hard part is naming what the system is not responsible for.
Background threads
A plant diagram is a model with consequences. It shows what is connected to what, which valve isolates which section, and therefore what is still energised after a given action. The habit that transfers is treating boundaries as first-class: the drawing exists so somebody can answer “what does this affect” before acting, not after.
Common failure
A model that only describes the working case. Failure is left implicit, so the first abnormal condition has no defined representation and the system has to guess.