12 — The grant tree and control labels
Summary
The grant side, which the pack had specified least and needed most once C1 made the gap between grant and mandate the product. A grant is a tree of subgrants, so blast radius is a path through it rather than an item in a list — and the load-bearing part is the label on each node, above all who enforces the thing standing in the way. The general test needs no vendor claim: a control bounds a grant only when it is enforced by something the grant does not include, giving boundary, setting and expectation, and placing most of what people currently rely on in the middle tier that reads like a boundary and behaves like a setting. Plus the shortfall, the region C1 never named; the two populations with one hosted tree measured rather than described; prohibitions as a generated presentation layer over a stored allow-list; and the correction that counting acceptances is the one metric that inverts under pressure.
Key concepts
- The three-tier control test — C16: enforced from outside the grant, from inside it, or by nothing at all
- Excess authority, and the shortfall — grant minus mandate hurts security; mandate minus grant hurts operations and is harder to detect
- A hundred percent acceptance — means the risks are trivial or the process is theatre — so declines are instrumented first
- Two populations, neither winning — locally the containment is available and unused; hosted it may be excellent and is unverifiable
Key ideas
- A safe inside a house you handed the keys to is a delay, not a boundary — and so is a folder restriction enforced by a tool running as you.
- A permission prompt disableable by a flag the agent can write is an expectation wearing a setting's clothes.
- Each node carries its own date: a vendor changing one default invalidates one row, and a tree dated as a whole is quietly wrong while looking current.
- The fourth list of absences in this pack — risks that could not be stated is the most informative number in the set.