Home / Vaults / Risk Graph Explorer
Risk Graph Explorer
The graph explorer from the risk-mandate work, refactored out into a vault of its own — and the first vault published here that was designed to be public from the start, with its own publication rules enforced by its own build.
Read key:
sgit_rk1_1c1b95f5903e35850a9bc0541ffa09c6b5d4017cbf18817d2ad6f894127e5638:3simlnqeIn the official UI: open it read-only in a new tab · From the CLI:
sgit clone sgit_rk1_1c1b95f5903e35850a9bc0541ffa09c6b5d4017cbf18817d2ad6f894127e5638:3simlnqePublished deliberately, and derived: the owner supplied a vault key, our intake check refused it for publication, and only this one-way derivation appears here.
See it live, here
Both surfaces open automatically below. You can also open the app in its own window ↗ — try the presets, then change one answer and watch the register move.
What is going on here, step by step
An empty register is a correct answer
It opens at zero: 0 facts, 0 risks, 0 provisions, and a prompt to answer the first question. Nothing is assumed about your estate until you say something about it.
That is the claim the whole app is built to make, and its README states it plainly: "the technical answers can be as bad as you like — if nothing is at stake behind them, the register is short, and that is the correct answer." A tool that produces the same output for a scratch service and a payments platform is a checklist, not a risk register.
Answer differently and the graph changes shape
Load the Exposed preset and the same questions produce 18 facts, 37 risks and 14 provisions, with a header that reads decides about a person · in production · at stake. Seven views recompute together: the estate graph, context, a role risk map, risk chains, the register, acceptance, and what happens next.
Look at the graph itself — amber edges are exposure facts, green are assurance, and ghosted means nobody has said either way. Recording that absence as information, rather than as an implicit pass, is the detail that makes this a graph rather than a form.
A vault that carries its own publication rules
Most vaults here were audited by us before their key went out. This one arrived with the audit already written into it: PUBLIC.md states that every byte committed is already public, and its build refuses if any of three rules is broken — nothing private committed (the gate scans every file, not just the built artefact), no write token, and no metered capability.
That third rule is the one worth borrowing, and we had not written it down: "a published read key in front of an LLM config is an open tab on somebody else's budget, and a spend cap is a rate limiter on the fun, not a control." It sent us back to re-check a vault we had already published — see the note below.
permissions: {}
An empty permissions object. Not a scoped write, not a withheld credential — nothing requested at all. The app answers questions in the page: no network call, no storage, no account, as its README says.
The catalogue now spans the full range, each declared in the vault rather than configured on a server: Risk Mandate uses an LLM without holding its key, Supplement Stack writes to one folder, Agentic Browser Isolation declares write: [], and this one asks for nothing.
Extraction as a pattern
This vault began as a section of a larger one. Pulling it out gave it a smaller audience surface, a shorter history, its own release cadence and — decisively — its own permission posture: the parent could plausibly want a model; this one may never have one, and says so.
That is worth naming as a technique. Vault boundaries are permission boundaries, so the question "should this be its own vault?" is usually the question "should this have a different key, a different audience, or a different set of capabilities?" Here the answer was all three, and the split made the public version safe to publish in a way the parent could not have been.
The audit, honestly
Clean: zero hits across every text file — no credentials, no personal data, no operational bookkeeping, and the vault's own key absent from its content. The tidiest audit of any vault published here, which is what you would expect of one built to be public.
It also caused us to re-audit ourselves. Its third rule — no metered capability behind a published read key — applies to Risk Mandate, which does carry an LLM config. So we checked rather than assumed: taking the sealed credential from that vault and attempting to open it with the read key we published, AES-GCM refuses (InvalidTag). The seal is under a key a read-key holder does not hold, so publishing that read key did not expose anybody's budget. Rule satisfied there by sealing; satisfied here, more conservatively, by absence.
As always: revocation is not retroactive. Anyone who fetches these objects keeps them.
Derived facts
33 files · 428 KB · 7 commits · one app entry · last updated 2026-08-10 — derived from the read key alone by admin/build/catalogue_derive.py, the same derivation that populates the catalogue.