Key discipline
A site about normative instruments that is careless with its own credentials has argued against itself before a reader reaches the second page. This page states the rules, the reason each exists, what this repository's CI enforces, and the one open question that should be answered before another vault publishes.
Two prefixes, and only one of them is ever published
| Read key | Write key | |
|---|---|---|
| Prefix | sgit_rk1_ | sgit_vk1_ |
| Grants | Read | Read and write |
| Published? | Yes, on purpose. Every one on the vaults page is a capability handed out deliberately | Never. Anywhere. Ever. Publishing one hands the vault to anybody |
| Reversible? | A published read key cannot be turned back into a write key — a property of the scheme, not a policy | — |
| Shape | Exactly 64 hex characters after the prefix | — |
What this repository's CI enforces
Every push to dev runs admin/build/validate.js before anything is tagged or deployed. Three of its checks are about keys, and a failure stops the release — no tag, no publish. The rule they enforce is not never mention the write prefix; it is the prefix may be discussed, key material may not exist:
No write-key material, anywhere
The prefix may appear in prose — this page could not exist otherwise, and a check that fired on every mention would be switched off within a week. What may not appear is key material after it: eight or more key-shaped characters following the write prefix fails the build, in any file, always.
Read keys must be well formed
Key material after sgit_rk1_ must be exactly 64 hex characters. A published read key is deliberate and safe; a malformed one usually means somebody pasted the wrong thing, and the wrong thing is what you want CI to notice.
The generic credential shape
A long passphrase joined by a colon to a UUID-shaped identifier — inherited from pki.sgit.ai, whose pipeline this one is ported from. Two sites, one class of mistake.
The check is deliberately in the pre-release gate rather than a post-publish scan, for the reason in the next section.
Audit before the key, not after
Revocation cannot retroactively protect ciphertext somebody already fetched.
This is the rule that determines when every other check runs. Once a read key is published and the ciphertext has been served, rotating the key does not un-serve it. Anybody who fetched the encrypted objects while the key was public holds a permanent copy they can still decrypt. So the audit happens before publication, not after an incident — and a scan of the working tree is not enough, because the one disclosed incident on this estate was a key in history.
Escrow is a precondition of publishing, not good practice
For a standards site that is the worst possible outcome. Instruments get amended — the amendment is the entire business argument — and an instrument vault that cannot be updated is a permanently wrong copy of the law with your name on it, readable by everyone, forever. There is no key recovery in this system, so a lost write key is final.
Which makes escrowing the write key a precondition of publishing a read key, and the keys vault the escrow. Below →
The keys vault — the private vault over the vaults
Its existence and its policy are published here. Nothing else about it is, and that is the point of the page.
| Keys vault (private) | The Vault Catalogue (public) | |
|---|---|---|
| Holds | Write keys, read keys, and the pre-publication audits | Read keys only — an index of published vaults, rendered live from a vault that indexes vaults, including itself |
| Read key | Never issued. There is no legitimate reason for one to exist | Published |
| Answers | How do I update this? | How do I read this? |
| Failure mode | Catastrophic and estate-wide | None — it is already public |
Five rules it operates under
- It is a standalone top-level vault, never nested. A sub-vault split is an organisational boundary — lifecycle, sharing, history — and explicitly not a confidentiality boundary from the parent's own readers. Nesting the keys vault under anything published would expose it to that parent's readers.
- No agent ever receives it. An agent that publishes a vault receives one write key, for one vault, scoped to that task. The register is not a credential anybody hands to a session.
- No CI job receives it either. Same rule, and for the same reason.
- Its own recovery lives outside the system it protects. Printed and physical as primary, a hardware-backed password manager as secondary. Not in another vault — that is the recursion with extra steps.
- A write key observed outside it is burned. In a repo, a log, a transcript, a chat, a screenshot — it does not matter which. Create a new vault, migrate the content, republish under a new read key, record both with a rotation date. Do not attempt to un-publish.
The recursion, which must be answered before the vault is created
So the recovery document lives outside the vault it protects, the choice of method is stated and dated so that future-you knows which one was actually done rather than which was intended, and the answer is written down before the vault exists rather than after.
No metered capability behind a published read key
A published read key is handed to everybody, so anything it can spend, everybody can spend. The estate's own example is the right one: the Regulation Graph vault's Article 9 Lab requires a bring-your-own OpenRouter key for its graph REPL, deliberately, so that inference is billed to whoever asked for it rather than to whoever published the vault. Any tool this site ships follows the same rule. The tool contract →
The open question
Was the exposed vault key rotated, or only removed from history?
The Regulation Graph vault's PUBLIC.md carries visible <VAULT-KEY-REMOVED> and <READ-KEY-REMOVED> markers. A pre-publication audit found its own original write key and another vault's plaintext credential committed in history. Both were redacted, the history rebuilt, and a re-audit from a read-key clone reported 205 files and zero findings.
That was handled correctly and disclosed openly, which is to the project's credit. But the published pages do not say whether the exposed key was rotated or only removed — and by this estate's own doctrine, removal alone does not undo distribution of ciphertext somebody already fetched. This is a question, not a claim of a vulnerability. It should be answered before another vault publishes, and the answer should be the first entry in the keys vault's audit log. On the comms page as an ask →
The publishing checklist
- Audit before the key. Scan history, not just the working tree.
- Escrow the write key into the keys vault. No read key goes on a page until its write key is in the register.
- Write
PUBLIC.md— what is in here, what the read key grants, what was audited. Currently on 2 of 12 vaults, which is not a convention yet. - Validate the prefix before rendering any credential on any page.
- No metered capability behind the published key.