You are setting one estate-wide rule for minted credentials; which downstream systems do you exempt, and on what test?

## The test is mechanical, not moral The instinct when writing an estate-wide rule is to grade by importance: mint per consumer for the crown jewels, leave the rest alone. That grading is backwards, because it does not describe anything you can check and it does not describe what actually stops generation working. The workable test asks two questions, both about the **accepting system**, and both answerable yes or no by an engineer in ten minutes: 1. **Can an account be created and dropped there without a person in the loop?** 2. **Can it hold one identity per consumer, at the number of consumers you have and the rate they turn over?** A system that answers no to either is exempt. Not "deprioritised" — exempt, because the rule is unachievable there and a rule everybody quietly fails is worse than a narrower one everybody meets. ## Four shapes that fail the test - **Human-in-the-loop issuance.** A supplier that mints keys only through its own portal, where a person signs in, clicks, and copies a value out. There is nothing to call. This is the permanent exemption: it does not become generated because the value is afterwards kept in a store, and it does not become generated because a script drives a browser at it. - **A hard ceiling or a per-account price.** Where identities are counted against a limit or charged for individually, one per consumer is either impossible or a budget decision rather than a security one. Say which, out loud, with the number. - **Creation behind an approval.** If making an account requires somebody to approve it, minting on request is not minting; it is a ticket queue on the critical path of a consumer starting up. - **Accounts that own state.** Where an identity owns objects, quotas, or history, a per-consumer identity that disappears next week strands whatever it owned. This one is the subtlest and is usually discovered after the migration. ## What the exempt set gets instead Exemption is not permission to stop managing the credential; it changes which controls apply. For a credential that must stay static, the rule reads: - **One named holder per value.** If four consumers need it, that is four reasons to ask whether the supplier will issue four values. - **A stated copy count.** Somebody must be able to say how many copies exist and where, and be wrong in a way that can be corrected. - **An owner of record.** A named person or team answerable for it, carried in the inventory rather than in somebody's memory. - **Monitoring of its use**, because separation is not available to you here and noticing is the remaining control. ## The cost of the rule itself A lead writing this standard is also buying its consequences, and should say so when proposing it: - The create-and-drop path becomes **production infrastructure**. When it is unavailable, new consumers cannot start. - The estate acquires a **population of identities** to name, count, reconcile and prune — an ongoing operational commitment rather than a project. - The privileged account that mints is now among the most valuable credentials you hold, and deserves handling to match. These are the reasons the rule should be as narrow as it can be while still meaning something. A standard that mandates per-consumer credentials everywhere will be met by exception requests within a month; one that mandates them wherever the two-question test passes will be met. ## Keeping the exemption list honest The failure mode of any exemption is that it becomes the path of least resistance. Three habits prevent it: 1. **Enumerate.** The exemptions are a list of named systems with the reason each one failed the test, not a principle teams apply to themselves under deadline. 2. **Re-test on a fixed cadence.** The far side changes. A supplier that only had a portal last year may have gained an interface, and the exemption should expire rather than persist by default. 3. **Put the cost next to the entry.** Each exempt system carries the compensating controls it owes. An exemption with nothing written beside it is indistinguishable from an oversight. ## The judgement being demonstrated What an interviewer is listening for here is whether you can write a rule that survives contact with an estate. That means a test somebody else can apply without you, an exempt set that is visibly finite, a statement of what exemption costs and what it buys, and an honest account of the new infrastructure the rule creates. "Generate everything" is not a standard; it is an aspiration with an exception queue behind it.