# 4 · Grant is not mandate *Part two — The vocabulary, and why each word is load-bearing* --- Two quantities. One is what an environment can actually do. The other is what somebody decided it should do. They are almost never the same, the difference is usually large, and in most organisations neither has ever been written down. The estate calls the first a **grant** and the second a **mandate**. This chapter is about why those two words are worth defending, and why the most common way of describing the pair — *permissions* and *policy* — loses the thing that matters. ## Grant: what the environment can actually do The lexicon, at `https://pki.sgit.ai/packs/grant-and-mandate/concepts.html`, defines a grant by its edges rather than its label: > **What the environment can actually do**, as installed and configured. A tree of capability nodes, each carrying what it reaches, the control standing in the way (or nothing), the tier of that control, an evidence class, and a date. Generated by **measurement**, never authored. *Stated.* Four things in that definition are doing work, and it is worth taking them one at a time because each is a rejection of a common practice. **A tree, not a list.** Because the interesting relationships are containment ones, and because blast radius is a path through a tree rather than an item in a list. A list of what an agent can reach tells you the surface. It does not tell you that reaching A is what gets you to B, which is what you actually need when you are deciding what to fix. **Each node carries what stands in the way, or nothing.** The `reaches` line and the `stands in the way` line are separate fields on purpose. Document 09 is blunt about which one misleads: the `reaches` line is the one that does the work, because *a list of what is reachable without what stands in the way is the part people already have and the part that misleads.* Every permissions screen you have ever seen is that list. **A date, per node.** Not per tree. A grant is a claim about somebody else's product, and it ages on their release schedule, so a tree dated as a whole is wrong in one place while looking current. **Generated by measurement, never authored.** This is the load-bearing one, and it has its own correction. ## The grant is discovered, not authored The pack's change control records this as GM1, its first correction and the one it calls load-bearing: > a hand-written grant file is a wish; it records what somebody believed on the day they typed it, which is the thing a grant is not. *Stated.* A permissions file written by a human is a statement of intent wearing the clothes of a statement of fact. It records a belief, on a date, by somebody who may have been wrong then and is certainly out of date now. So the grant document is generated by running a measurement inside the environment, it carries provenance per node, and a node with no evidence is marked rather than dropped. Chapter 9 is the measurement method and the two entries it produced. The consequence is the part people miss: **drift becomes mechanical.** If a grant is measured, then the question *has this changed?* is answered by re-running the measurement and diffing, not by asking anyone to remember. And the diff has a direction that matters more than the others — a node moving from `setting` to `expectation` means a control was removed while nothing broke. Nothing failed. No alarm fired. The containment simply stopped existing, silently, and the only thing that would ever notice is a second measurement. Chapter 9 records that detector firing for real, one commit after the change it detected. It fired in the harmless direction. The mechanism is the same either way. ## Mandate: what the environment is expected to do The other side, from the same lexicon: > **What the environment is expected to do.** Authored by a person, signed by an **issuer**, naming a **subject**, carrying an **interval** — *without one it is a grant under another name.* *Stated.* Note the inversion. The grant must never be authored; the mandate must be. That is not a stylistic preference — the two documents answer different kinds of question. *What can this thing do* is a question about the world, and you answer it by looking. *What should this thing do* is a question about a decision, and there is nobody to look at: if no one has decided, the answer does not exist, and a measurement will not produce it. Four fields, each of which a real system usually lacks: **An issuer.** Somebody whose authority this is. Not a config file, not a repository, not a team — a signing identity that can be resolved and checked, and that could be held to it. **A subject.** Bound, so the mandate is about one agent rather than about a role that anyone can wear. Chapter 8 shows what happens when the subject is a role and its key is published: the register can say what the role may do and can never say who wore it. **An interval.** The clause in the lexicon is the sharpest test in the vocabulary — *without one it is a grant under another name.* A permission with no expiry is a permanent capability, and a permanent capability is a property of the environment rather than a decision about it. Every token you have that does not expire has already crossed back over into being a grant. **A signature**, so a third party can check all of the above without asking the issuer. ## Allow-list stored, prohibitions rendered One structural rule, and it is the kind of detail that turns out to be load-bearing in a user interface. A mandate is **stored** as an allow-list, because that is the enforceable form: an evaluator needs to know what is permitted, and default-deny requires an explicit set. **Prohibitions** — *will not push to any branch outside `claude/**`* — are a generated rendering of the allow-list's complement, and they carry their own date and the version of the capability set they were rendered over. Both halves exist because they have different audiences. Document 09 states the rule for the interface, and it is the trap in the pack's screen four: > **Prohibitions shown, allow-list stored and not displayed.** Screen four's trap: an allow-list presented for approval produces consent without comprehension. *Stated.* Show a person a list of forty permitted operations and ask them to approve it and they will approve it, because reading forty items and imagining their complement is not something people do. Show them three sentences beginning *will not* and they can tell you whether that is what they meant. The rendering carries its own date for a reason that is easy to miss and unpleasant when it bites: the complement of a fixed allow-list *changes when the capability set grows*. Add a new capability to the vocabulary and yesterday's mandate silently prohibits something new. A regenerated view must not retroactively change what was agreed, so the rendering records what it was rendered over. You can see the field in the real mandate: `prohibitions_rendered_over: "capability set v0"`. *Drawn.* The packs do not say this, but the field is an admission with a sharper edge than its placement suggests. If the complement moves when the vocabulary moves, then a mandate's meaning depends on a capability vocabulary — and Chapter 15 records that this estate does not have one. `capabilities.json` in the register is explicitly a fixture, and the question *what is a capability name* is one of the three blocking questions still open. Which means the prohibitions in the real mandate are rendered over a vocabulary that is acknowledged not to exist yet. That does not make the demonstration invalid. It does mean the phrase *capability set v0* is doing more work in this estate than anything currently behind it can support. ## Apparent authority, and why the gap is an exposure Chapter 1 introduced the doctrine; here is where it earns its place in the vocabulary. The grant is authority nobody decided. The mandate is authorisation somebody did. If those were merely two descriptions of the same thing at different resolutions, the gap between them would be a tidiness problem — an inventory exercise, worth doing when there is time. It is not, because the outside world binds you to the grant. If your agent's credential reaches forty-one repositories and it writes to one nobody considered, no system asks whether you meant it. The write lands. Under apparent authority the consequence is the principal's, and the principal is you. So the difference between the two quantities is not slack. It is **exposure that nobody accepted**, and the register publishes it as exactly that. The view at `https://pki.sgit.ai/registry/views/excess-authority.json` carries one row for one subject, and the row reads: grant `repo.contents.write` over 41 resources; mandate `repo.pull-request.create` over 1; excess 40 resources; **acceptor: `null`**. Forty resources of exposure with nobody's name on it. That is the countable object, and Chapter 5 is about the arithmetic that produces it. ## What this vocabulary refuses Two things, and the refusals are as informative as the definitions. **It refuses "implicit authorisation."** Covered in Chapter 1: the word smuggles in a decider who does not exist. There is no implicit authoriser; there is an absence where one would be. **It refuses `wallet`.** The pack ran naming checks and recorded the result. `card` and `pack` were kept. `passport` was tested before and misfit. `wallet` was avoided deliberately — it is taken by the payments work, and it would import the expectation of held verifiable credentials presented by the subject, which is a model this design does not use. Grants and mandates here are artefacts signed by an issuer, not credentials held by a principal. The distinction decides where the object lives, who can revoke it, and what a verifier fetches. *Drawn.* I would put the general rule this way, and the packs do not: **a vocabulary that blurs the distinction between what was decided and what merely exists does not read badly — it reintroduces the confusion it was written to remove.** Every term in Part two is defensible only in proportion to how well it holds that line, and the two chapters that follow are about the two places it is hardest to hold: in arithmetic, where a stored answer goes stale, and in a control label, where something inside the thing it constrains gets called a boundary.