Tools outside the vault
Tools that live outside a vault and read its materials at runtime. This was raised as something worth exploring; it is better than that — the pattern already exists on this estate, it works, and there are three shipped precedents. What is missing is not the technique. It is a contract, so that every tool does not end up coupled to one vault's internals.
The precedent, and it is nearly exact
zc6abngv, 35 files) loads “a versioned JSON standard — five dimensions, five bands, eight scoring rules — from the vault at runtime” and computes deterministic results, separating rule-derived numbers from model-generated prose.
Read that again with standard meaning ISO rather than health. The standard is data in the vault; the tool is code that reads it. That is precisely the shape a conformance tool needs, and it is already built and working.
Two more:
| Precedent | What it demonstrates |
|---|---|
Risk Graph Explorer (3simlnqe) | Vault data as live computation. Answering questions recomputes seven views simultaneously; the same questions answered differently yield different graphs. Amber edges are exposure, green is assurance, ghosted is unanswered. Zero network calls, empty permissions |
| Regulation Graph's SQL and RDF views | An instrument queried as a database via sql.js, and as a triple store with Turtle export. The graph is already addressable by two query languages |
Three working precedents. This is established practice waiting to be pointed at standards.
The contract between a tool and a vault
Read this and only this. A tool that reaches past it is coupled to one vault's internals and will break on the next one:
MANIFEST.json instrument id, version, amendments, build date, counts graph/nodes.json stable node ids (positional hashes) graph/edges.json typed edges from the published grammar graph/graph.sqlite the same graph, queryable concepts/*.json defined terms; one identifier, many labels crosswalk/*.json FrameworkReference bridges
The five rules
- Version the contract, not just the data.
MANIFEST.jsoncarries acontract_version. A tool declares which version it speaks and refuses politely rather than silently misreading a newer shape. - Address by positional hash, never by array index or display label. Labels are translations; array positions are an accident of parsing. Both failure modes are silent, which is why this is a rule.
- A tool never holds a write key. A read key, or a downloaded zip. Key discipline →
- A tool that computes must say what it computed from. Every number carries the provision it derives from and the hash of that provision's text. Computed, not claimed.
- A tool that cannot answer must say so visibly. Both shipped precedents ghost unanswered nodes rather than defaulting them. An unanswered question is an output →
Five tools, ranked by value over effort
T1 — The crosswalk browser · build first
Pick a provision in instrument A; see every provision in B, C and D that bridges to it, with each bridge's basis and strength. Reads crosswalk/*.json across every instrument vault.
Why first: it is the thing a multi-standard site sells, it is the only tool that gets more valuable with each instrument added, and it makes the compounding argument visible rather than asserted.
Zero crosswalks exist, so T1 would currently render an empty screen. It cannot be faked, which is a virtue. T1 is the reason to write the first bridge. Five preconditions, one met →
T2 — The conformance calculator
Answer questions about your situation; get findings that each point at a named provision. A direct descendant of Private Health Score and Risk Graph Explorer.
The model is the worked example's V1 — thirty days against six months is arithmetic, not judgement — published alongside its own caveat, “most obligations are not that crisp, and the graph must not imply they are.” A tool that reported a percentage would be asserting exactly what this site exists to stop being asserted. Why →
T3 — The amendment differ
Two versions of an instrument in, changed provisions out — by content hash, so it is exact rather than textual. This is the tool that makes the site a living resource rather than a snapshot, and it directly fixes the flagship vault's two-commits-no-history gap.
Blocked on data, not code: it needs two versions of an instrument in the vault to compare, and the AI Act vault composes its amendment in rather than storing the pre-amendment text as its own version.
T4 — The provision citation resolver shipped
A stable URL per provision that resolves to the text, the hashes, the retrieval record and every crosswalk touching it. Small, and it unblocks everything else — every bridge is a pair of citations, so nothing else can be built without it.
Open the resolver → · the scheme it implements →
T5 — Cross-vault search
Each vault is currently an island; the catalogue indexes them and does not search inside them. A prebuilt search index per vault plus a federated client-side query. Hardest of the five, and the one most likely to want a real backend. Defer until instrument four.
Where a tool lives
| Thing | Where | Why |
|---|---|---|
| The tool's code | In this repository, rendered on this site | It is small, it must be inspectable, and that is the clear text enables verification argument applied to the tools rather than only to the data |
| The data it reads | In the vault | Bulky, versioned, and the delivery unit |
| A vault-internal copy of the tool | Yes, for flagship instruments | So a downloaded zip is self-sufficient offline. Accept the duplication; build both from one source |
That split gives three delivery modes from one build — a page on this site, an app inside the vault, and a zip that works with no network. Which is the delivery-mechanism claim actually delivered, rather than described.