09 — The building blocks
Summary
The brief the project lead called #3, derived from the two v0.33.62 briefs rather than supplied: the reusable primitives the six screens are assembled from, specified as components with rendering rules rather than drawn as pictures, because a mockup is thrown away and a block is used. Nine primitives, each a rendering of a field that already exists in a grant or mandate document. The load-bearing rule came from the build rather than from design: a tier is a property of a node's relationship to the tree, not of the node, so a tier badge must be able to show what defeats it, and a defeated control never renders as a boundary — the register's own escalation-is-an-edge finding arriving one layer down. It also adds the one block that exists because building the thing taught the pack something it did not know: the authority/enforcement split, two indicators and never one, because the enforcement is real and the authority is a fixture and averaging them is how a demonstration gets mistaken for a control. Ships as a stylesheet and a gallery rendering the actual documents, not as images.
Key concepts
- The defeat-path rule — a defeated control renders as setting, with the path reachable from the badge
- The authority/enforcement split — two indicators, never one — merging them is the failure
- Prohibitions shown, allow-list stored — screen four's trap, enforced by the component
Key ideas
- A block is a rendering of a field: if it needs data no schema carries, the block is wrong, not the schema.
- Two channels minimum and the word is always one — colour alone re-collapses five states into two.
- `unknown` renders as `unknown`: the gaps are part of the map, and a blank reads as a to-do.
- The gallery renders real documents, so a schema change breaks the build rather than the integration.