standards.sgit.ai / vaults

The vaults — the delivery surface

The vaults are the substrate; this site is a projection of them. They hold the source bytes, the transformations, the graph JSON, the SQLite builds, the apps and the tools. This page states plainly how one reaches a reader, prints the read keys, and is honest about the two things that are not built.

Nothing exists only in the vault that a reader would need in order to check a claim.

How a vault actually reaches you

Readers of a standards site will want to know what they are trusting, so here it is, established by survey rather than assumed:

Step	What happens
Ciphertext origin	`dev.send.sgraph.ai` — an API that serves encrypted objects and has no UI
Viewer	`dev.vault.sgraph.ai` — the browser application that decrypts and renders
Decryption	Client-side, in your browser, with the read key printed on the host page. The server never holds the key
Credential format	`<readkey>:<vaultid>`
Embedding	A sandboxed iframe — `sandbox="allow-scripts"`, opaque origin. The host page hands the key over a validated `postMessage` handshake rather than a URL fragment, so the key never appears in any URL and is never written to the frame's storage; it lives in the frame's memory for the session
What the key grants	Read only. A published read key cannot be turned back into a write key. That is a property of the scheme, not a policy

The two prefixes

Read keys yes, write keys never. sgit_rk1_ is a read key — a capability handed out on purpose, and every one on this page is published deliberately. The write prefix is a different thing entirely: it grants read and write, and publishing one hands the vault to anybody.

This site's CI enforces the distinction rather than trusting it. Every push is checked for the write prefix anywhere in the tree, and every read key must be exactly 64 hex characters or the build fails. Key discipline, and the incident that motivated the check →

The published estate — twelve vaults

Surveyed 23 August 2026. Exactly one is an instrument vault. The rest are the estate this site's own vaults will join; the catalogue on sgit.ai stays canonical for the estate-wide index.

Vault	Files	Size	Commits	Presentation	PUBLIC.md
Field Notes `4bshby5n` · application	4	11 KB	2	HTML app (index.html)	no	open →
Strategy Maps `ookq4mn4` · structured analysis	33	830 KB	3	2 HTML apps	no	open →
Deploy Docs `fyofmkvr` · record-keeping	17	25 KB	2	Markdown, no app	no	open →
The Vault Catalogue `kc67yhgw` · record-keeping	9	11 KB	2	Markdown, no app	no	open →
Algarve May 2026 `3d04e6b9ca98` · gallery	71	29 MB	36	HTML app	no	open →
Supplement Stack `r7zes477` · record-keeping	23	2.3 MB	5	HTML app	no	open →
Risk Mandate `4zf6pf2z` · application	124	1.9 MB	98	8 HTML app entries	no	open →
Agentic Browser Isolation `0610gsp9` · structured analysis	104	2.4 MB	4	17 app entries	no	open →
Risk Graph Explorer `3simlnqe` · application	33	428 KB	7	1 HTML app (tool)	yes	open →
Private Health Score `zc6abngv` · application	35	1.2 MB	3	HTML app (tool)	no	open →
VoiceDebrief `k6xy9z4d` · structured analysis	92	1.2 MB	18	4 apps	no	open →
Regulation Graph instrument `73heuprz` · reference data	207	14.9 MB	2	11 app views	yes	open →

Read keys for all twelve are published in /agents/vaults.json — prefix-validated before rendering, as the catalogue does.

The instrument vault

Regulation Graph (73heuprz) — the EU AI Act. 207 files, 14.9 MB, 1,523 nodes, 1,944 edges, eleven app views. Parsed from official Formex XML retrieved from CELLAR, hash-verified, with a SHA-256 of the retrieved bytes on every node.

sgit_rk1_c004daae386e8d17fa648884acc527018bd4ea1116ad673fb2f1b068011695c9:73heuprz

Open it → · the instrument folder →

What is in an instrument vault

The same shape for every instrument, so a tool written once works everywhere:

standards__<instrument-slug>/
├── PUBLIC.md        what is in here · what the read key grants · what was audited
├── MANIFEST.json    id, version, amendments composed, build date, source URLs,
│                    hash of every source file, node/edge counts, contract_version
├── source/          the retrieved bytes, UNMODIFIED, + .sha256 + RETRIEVAL.md
├── structure/       the TAXONOMY — the paragraph-as-folder tree
├── graph/           the ONTOLOGY — nodes.json, edges.json, graph.sqlite, graph.ttl
├── concepts/        defined terms; one identifier, many labels
├── crosswalk/       FrameworkReference bridge nodes to other instruments
├── app/             index.html, _page.json, the views
└── dist/            <instrument>-v<n>.zip · <instrument>-v<n>.sqlite

For ISO, source/ is empty and the page says why. The paragraph-as-folder design →

Distribution — specified, and not built

Net-new

Not one of the twelve published vaults offers a zip or a file export. Two things resemble it and are not it: Regulation Graph's RDF/Turtle export is an in-app graph serialisation, and pki.sgit.ai's briefing-pack zip is a static site pack. Vault-level export is net-new work across the entire estate.

What is specified, and what each is for:

<instrument>-v<n>.zip — the whole vault as plain folders and files. Offline, greppable, archivable by a third party, no key needed once downloaded. This is the answer to the verification objection and the delivery mechanism at the same time.

<instrument>-v<n>.sqlite — the graph as a queryable file. Loads in DuckDB, in sql.js in a browser, in Python, in anything.

Versioned. Never overwritten. A standards corpus that silently changes under a fixed filename is worse than no corpus — and the amendment history is the product.

The architectural fork, published unresolved

The commissioning memo said the vaults hold everything and the website is a projection. A later internal brief changed position — “vault authors, repo publishes” — on one ground:

Clear text is what enables verification.

That objection is real and it cuts. Ciphertext that decrypts in a browser with a published key is readable, but it is not greppable, diffable, archivable by a third party, or citable by a URL that will resolve in ten years. A standards site's entire value is that a claim can be checked.

	Vault	Repo / static site
Holds	Everything — source bytes, transformations, model outputs, JSON, SQLite, apps, tools	The projection: rendered pages, the raw markdown of this site's own writing, the graph as plain files
Is the	Working substrate and distribution unit	Verification surface and citable address
Optimised for	Delivery, versioning, coherence, handing somebody one credential	Being read, indexed, diffed, forked and cited
Authority	Canonical for data	Canonical for URLs

Both, with a stated division of labour, and the governing rule at the top of this page. Q2 — published as a fork rather than settled →

Durability risk

Both hosts are dev.-prefixed. The viewer and the ciphertext API. For a site whose proposition is durable citation, depending on infrastructure named dev is worth naming now rather than discovering later — and the dist/ exports that would let a third party archive an instrument independently do not exist yet. What the citation scheme does not fix →

← Agentic access Key discipline →