Appendix C — Model Reference

Parts II–IV introduce only the model detail needed for the engineering argument. This appendix collects the principal schemas, invariants, derivation directions, and correspondence machinery for those models.

Each model begins with an engineering question and uses the smallest representation that makes the relevant property explicit. The forms here are reference patterns, not a required inventory.

The appendix serves as both a reference and a pattern book: the representations are specific enough to expose their engineering properties but general enough to adapt to other systems. Each section also separates what the model represents from the machinery that may later give selected declarations authority.

Each section answers the same four questions:

Correspondence alone does not establish correctness. A descriptive model can accurately describe an undesirable system; a normative model supplies authored intent against which the implementation can be checked. Part III supplies the mechanisms that can give selected declarations authority.

Figure C-1 establishes the pattern specialized by the later figures.

The executable-model pattern — the spine every later reference figure specializes An engineering question selects a representation. A model box is fed from the left by authored intent along a solid arrow, and from the right by derived facts along a dashed arrow. The model declares or generates code, config, runtime, and artifacts, shown along a solid arrow. Those artifacts are observed or re-derived back into a correspondence check, shown along a dashed arrow. The check asks whether the authored and derived facts disagree. A no leaves the model advisory and report-only. A yes flows along a heavy bordered authority arrow, crossed by a gate glyph, into a finding or gate where warranted. A shared legend below fixes the vocabulary for every G figure: solid arrows are declared relations, dashed arrows are derived or observed correspondence, and a heavy boundary with a gate glyph marks the only place real authority sits. Not every model traverses every edge; a useful representation may remain advisory. ENGINEERING QUESTION MODEL entities · relations · properties AUTHORED intent DERIVED facts declares / generates CODE · CONFIG · RUNTIME · ARTIFACTS observe / re-derive OBSERVED CORRESPONDENCE / INVARIANT CHECK disagreement? no advisory · report-only informs the engineer yes finding / gate CHECKED — where warranted Not every model traverses every edge — a useful representation may stay advisory. Legend — notation used throughout Appendix C AUTHORED solid arrow = a declared relation (authored intent) DERIVED · OBSERVED dashed arrow = derived / observed correspondence CHECKED heavy boundary + gate glyph = real authority (can block) Boxes denote representations. Meaning is encoded by line style, weight, and glyph — not color.
Figure C-1. The executable-model pattern. An engineering question selects a representation containing authored, derived, or observed facts. Correspondence machinery compares represented facts with implementation or runtime evidence. Disagreement may remain advisory or, where the obligation has authority, feed a deterministic gate.
© James C. Davis, 2026–present