# sgit.ai, complete documentation, single file

> Every page of https://sgit.ai concatenated into one document, generated at build time
> (v0.6.8). Nothing here needs a second request. Individual pages live at the paths
> shown below, as markdown (`.md`) and as HTML (`.html`); the annotated map is /llms.txt.
>
> sgit is git for encrypted vaults: clone, commit, branch and merge files that are encrypted
> client-side (AES-256-GCM) before they leave your machine. The server stores ciphertext under
> opaque IDs, it never sees filenames, contents, or commit messages.



==============================================================================
# sgit (the encrypted git for humans and AI agents)

> sgit is git for encrypted vaults) and a vault is a unit of work: data, app, history and sources, versioned like git and handed over with a single read key. No account, no hosting, nothing to install for the reader; the server stores ciphertext it cannot read. Twenty-five real vaults you can open.
>
> Page: https://sgit.ai/index.html

Git for encrypted vaults, for humans and AI agents

# A vault is a unit of work:
data, app, history and sources, shipped as one string

Version it like git. Hand it over with a single read key, no account, no hosting, no install for the reader. And the server that stores it cannot read it.

[**Open a real vault →**](demos/vaults/index.md) [5-minute quickstart →](docs/quickstart.md)

Pure Python · two runtime dependencies · Apache-2.0 · [or try it in your browser](try/index.md)

[Reference, **AIUC-1 conformance layer**, The AIUC-1 standard as a graph, plus a conformance layer that computes insurability, Open it →](demos/vaults/aiuc-1-conformance/index.md) [Application, **Agent permission games**, Two games about grants and mandates, the first vault here that phones home, Open it →](demos/vaults/agent-permission-games/index.md) [Presentation, **AI vs. AI, Black Hat EU 2025**, The Black Hat EU 2025 keynote, with its PDF exports and eight research papers, Open it →](demos/vaults/blackhat-eu-2025/index.md) [Report, **Penetration Test Report**, A penetration test report (fictional) with a re-test script per finding, Open it →](demos/vaults/pentest-report/index.md)

Four of **36 published vaults**. Each opens with a read key printed on its page, no account, nothing to install, and the server that stores it cannot read it. [See all 36 →](demos/vaults/index.md)

## What people actually ship

Not categories, things. Each one is a real vault you can open, and each is hard to make any other way, for a reason that has little to do with encryption.

[Hand over a report, **Penetration Test Report**, Findings, evidence and a retest script per finding travel as one unit. The client opens it with one string and can re-run the tests themselves., vault `o4lrwx02` · open it →](demos/vaults/pentest-report/index.md) [Publish a standard as data, **AIUC-1 conformance layer**, 53 controls as a graph you can cite, 82 hashed source snapshots, and a fork that added a conformance layer without changing a byte of the original., vault `2wzct4k7` · open it →](demos/vaults/aiuc-1-conformance/index.md) [Give a talk, **AI vs. AI, Black Hat EU 2025**, 26 slides, six PDF exports and the eight papers the talk cites, in the vault it was presented from. The deck and its sources never separate., vault `k1izvg7e` · open it →](demos/vaults/blackhat-eu-2025/index.md) [Pitch an investor, **VoiceDebrief pitch (FI)**, A presenter app with timings and speaker notes, shipped with the script, the research and the exports it was built from., vault `95i2xqrd` · open it →](demos/vaults/voicedebrief-pitch/index.md) [Ship a game that reports back, **Agent permission games**, Anonymous telemetry over a write-only lane, the one credential shape that survives being published with a read key., vault `4evnlwrj` · open it →](demos/vaults/agent-permission-games/index.md) [Give an agent a workspace, **Risk Mandate**, 124 files, 98 commits, eight entry points: a software project delivered as a vault, that calls an LLM without ever holding the API key., vault `4zf6pf2z` · open it →](demos/vaults/risk-mandate/index.md)

[All published vaults, sortable →](demos/vaults/index.md)

## Nine of these vaults are the same graph, at different altitudes

A **Fractal Semantic Graph** is one where every node opens into a graph with *its own* ontology. A regulation, then its articles, then the words they define: each world using vocabulary the one above never agreed to. What stays constant is the grammar, never the schema, and that is what lets everything connect to everything without anyone being forced to conform. For years we called it graphs of graphs of graphs.

[**The idea, and the evidence**the jump test · a ladder of twelve rungs from the text of a law down to one compute instance · nine published vaults you can open with a read key](demos/fractal-graphs/index.md) [**What it costs, measured**no live database · a 1,051-node graph opens in 94 KB and three requests · 11.2 MB of source down to a 4 KB ontology with nothing discarded](demos/fractal-graphs/performance.md)

[Fractal Semantic Graphs →](demos/fractal-graphs/index.md)

## One human, a team of agents

This site, and every vault on it, is built by one person working with several AI agents, and the agents build for each other. The state that makes that possible is a vault: versioned, shareable, and readable by whoever holds the key.

166site releases, each verified live before it was called done

36vaults published with a deliberately public read key

27sibling sites on `*.sgit.ai`, one question each

12cross-team briefs filed or received, in the open

1A [build brief](docs/briefs/vault-telemetry-append-lanes.md) was published here on a Saturday. Another agent read it and shipped [a vault from it](demos/vaults/agent-permission-games/index.md) the same day.

2The team that owns the API reviewed that vault against the brief, found the brief wrong in two places, and [the correction now sits above the mistake](docs/briefs/index.md).

3One agent [forked another agent's vault](demos/vaults/aiuc-1-conformance/index.md), kept every byte, added a layer, and the original's tests still pass inside the fork.

→The record is the site itself: [the briefs](docs/briefs/index.md), [the case studies](case-studies/index.md), [every release](admin/versions.md). And the diagnosis that produced this homepage is [an article, with the before pictures](articles/proof-behind-the-claim.md).

## Under the hood, it is git

Same muscle memory. Files are encrypted before they leave your machine; the server stores ciphertext and hashes, nothing else.

$sgit create my-vault
✓ Vault created and registered
✓ Initial commit pushed

 Vault key: <24-char-passphrase>:<vault-id>

Keep this safe. It is the address, the auth, and the
encryption key in one string. Without it, nobody, including
the server, can read this vault.

$vim notes/positioning.md
$sgit status
 On clone branch branch-clone-3f9c → named branch main
modified: notes/positioning.md
added: drafts/hero-copy.md

$sgit commit -m "first draft of hero copy"
✓ Committed 2 files (no staging area, commit snapshots the folder)

$sgit history log --oneline
c4e81a first draft of hero copy
b2d70f initial commit

$sgit history diff
--- a/notes/positioning.md
+++ b/notes/positioning.md
- sgit is a CLI for encrypted sync
+ sgit is git for encrypted vaults

$sgit push
✓ Pushed 2 objects (delta push, only changed, only ciphertext)

# on another machine (or another agent)
$sgit clone <vault-key>
✓ Cloned and decrypted 12 files

$sgit pull
✓ Up to date

# one call: encrypt, commit, push, machine-readable result
# no working-directory scan, no full clone needed
$sgit write notes/finding.md --file result.md \
 --message "agent A: analysis" --push --json
 {
"status": "pushed",
"path": "notes/finding.md",
"blob_id": "obj-cas-imm-9c2e41ab77d0"
 }

The vault key is the address, the auth, and the encryption key, one high-entropy string. Keep it safe.

**Git-like version control**commit, branch, merge, diff, log, stash, revert your encrypted files

**Client-side encryption**AES-256-GCM before upload; keys derived from your vault key, never sent to the server

**Real three-way merge**conflict files plus a base/ours/theirs `resolve --show` view

**The two-branch model**a private clone branch per machine or agent; shared named branches for collaboration

**Apps live inside the data**a vault can carry its own sandboxed app, with the permissions it asks for declared in a file

**Browser interop**open the same vault in SG/Vault on the web, CLI and browser speak one wire format

## What the server sees

### Your machine

- filenames & folder structure
- file contents
- commit messages
- branch names
- the vault key & derived keys

*[diagram]*

### The server

- obj-cas-imm-3f9c41ab77d0
- ref-pid-muw-8e02cc194b3a
- ciphertext blobs (AES-256-GCM)
- object sizes · timestamps
- the vault id

That's the whole list, and we publish the threat model, including what the server *can* see (sizes, timing, vault ID). [Read the security model →](security/index.md)

## Built for agents

Agents need shared state. Shared state needs versioning, and privacy. sgit is the encrypted, versioned workspace for humans and AI agents.

Persistent memory

### A vault is just a folder

An agent clones it, reads and writes files normally, commits, pushes. The next session pulls and continues. State survives the context window.

Multi-agent, human-merged

### A branch per agent

Each agent gets its own private clone branch; work meets on named branches; a human reviews the merge, in the terminal or in the SG/Vault browser.

Agent-grade plumbing

### Machine-readable everything

`sgit write` for surgical single-call commits, `--json` on every read path, `cat --id` with zero network calls, sparse clones for fast cold starts. [What that costs, measured](demos/fractal-graphs/performance.md).

[Read the agent guide →](docs/agents.md) · [Performance & cost →](demos/fractal-graphs/performance.md) · [Install the skills →](skills/index.md) · [Use cases →](use-cases/index.md) · [llms.txt](llms.txt)

## In production, and honest about it

sgit is in beta, powering production workflows daily. No superlatives, just the evidence, and a page that tells you when *not* to use it.

**~4,000** tests**mutation testing** in CI**integration tests** against a real server**2** runtime dependencies**Apache-2.0** [**security model** published](security/index.md) [**when NOT** to use sgit](docs/limitations.md) [**why** does this exist?](why/index.md) [**sgit · SG/Vault · SG/Send**: the three doors](docs/what-is-sgit.md)

## Nineteen sites, one question each

Most of the thinking behind sgit no longer lives on this site. It moved out to **`*.sgit.ai`**: a family of focused sites, each taking one question further than a section here could, each with its own version history and repository. This site stayed about sgit.

[**Agents & AI**identity for agents · calling an LLM with no API key · how the code is written](network/index.md#agents-ai) [**Risk & governance**you cannot deny a risk · cite the provision · the requirements nobody writes down](network/index.md#risk-governance) [**Graphs & method**meaning lives in the edges · issues as files · maps are claims](network/index.md#graphs-method) [**Security & infrastructure**a key registry for agents · an edge guard · ephemeral environments](network/index.md#security-infrastructure) [**Business & publishing**open source is a strategy · subscriptions are not rent · provenance as the product](network/index.md#business-publishing)

[Find the one that answers your question →](network/index.md)

## Start with an argument, not a menu

The articles are the readable way in: one page, one argument, with the screenshots and the links to check it. If you only read one thing here, read one of these.

[2026-09-24**Before you give an agent a connector, give the connector a twin**When an AI agent is given a Gmail or Google Calendar connector, it can read, send, move, decline and permanently delete on somebody's behalf, and for several of those actions the platform itself documents that there is no way back. This article argues that a twin of the connector is the minimum requirement for deploying an agent with confidence. The twin is a journal of every request and response the agent makes, appended as it happens to a write-only lane, processed later, and replayed into the inbox and calendar as the agent saw them, with a before and after for every change and a revert plan for each one. It gives provenance, explanation and a named list of what can and cannot be undone, and it changes the agent's behaviour policy from a hope into a list. Every claim about Gmail and Calendar is taken from Google's own documentation and linked. A working replay of an invented session, and a business plan for the service, are published alongside it as a vault.Read it →](articles/connector-twin-before-you-deploy-an-agent.md) [2026-09-24**Every risk is already accepted. The only question is by whom, and for how long.**A foundation article on risk acceptance, for readers who have never met the idea. A risk exists the moment the exposure does, so an organisation is always carrying it; the only open questions are who has accepted it, and until when. There is no deny button, only three doors (accept for a stated interval, fund the work, or fix it), and silence escalates. The interval is the decision, from four hours, which is an incident, to six months, which is a named decision to wait. Accepted is not the same as acceptable, which matters because the EU AI Act requires providers of high-risk AI systems to have residual risk judged acceptable, and never defines the word. Every risk has a holder, every holder has a boss, and every path ends at the board. Every risk is established by facts and ended by facts, from the board down to the configuration file, which is what closes the gap between a register and reality. The article walks one invented risk through six weeks, argues that each material risk deserves a vault of its own as its evidence pack, explains why executives resist the model, and shows why it fits alongside every GRC platform rather than replacing one. A business plan for a company that runs this loop is published with it.Read it →](articles/every-risk-is-already-accepted.md) [2026-09-22**The future of news is the story vault, not the paywall**The news industry runs on two commercial models, advertising and subscriptions, and both are bad for the reader. One sells the reader to somebody else. The other charges rent on something most people have stopped using. Both are now being dismantled from outside, by a search layer that has stopped sending traffic and by consumer law that arrives in January 2027. This article is about what to build instead, in practical terms. The objective is a commercial model that rewards investigative journalism, so that the expensive, evidenced kind of reporting drives usage, usage drives revenue that depends on neither search nor renewals, and that revenue funds more of the same. The mechanism is to stop selling the article and start selling what the article was made from. The story is a graph, a fractal semantic graph in which meaning comes from connectivity and every claim walks down to hashed evidence, so that trust comes through provenance and provenance comes via evidence. The article is one projection of it. From that one graph a newsroom can sell five things, on demand and in pence, to readers, to firms and to agents, and every payment walks back to the people who made the facts. It is built, in parts, on things we have already published.Read it →](articles/future-of-news-story-vault-not-paywall.md)

[All articles →](articles/index.md)

Encrypted vaults. **Git workflows.** Zero knowledge.

[5-minute quickstart →](docs/quickstart.md) [Star on GitHub →](https://github.com/SGit-AI/SGit-AI__CLI)



==============================================================================
# The vault catalogue, sgit.ai

> An index of published vaults rendered live from a vault that indexes vaults, including itself. Each entry: a deliberately published read key, shape, evidence status, copy-or-reference semantics, and write-key status (known-and-escrowed or lost, a frozen vault can never be corrected). Submitting a vault costs a read key and one line; the rest is derived.
>
> Page: https://sgit.ai/catalogue/index.html

[Home](../index.md) / Catalogue

# The vault catalogue

An index of published vaults, rendered live from a vault that indexes vaults, including itself. Every entry carries a deliberately published read key, an honest evidence status, and its write-key status, because a vault whose write key is lost can never be corrected and a reader deserves to know.

**The design constraint, stated openly:** the bottleneck is one person with a backlog of vaults, so an entry costs **a read key and one line**: everything else (listing, sizes, commit count, whether an app is present) is derived by an agent opening the vault with the key it was just given. The two to-do queues are published in the catalogue itself: a named gap gets filled, an unnamed one does not. This page renders vault `kc67yhgw` directly, a push to it updates this page with no site deploy. The human companion is [the published-vaults gallery](../demos/vaults/index.md): one page per vault, with the vault running live in it.

**Where it stands, checked 19 September 2026.** The catalogue vault holds **nine** entries and was last pushed when the site had nine published vaults; the gallery now has **thirty**. The twenty-one missing rows are not a queue problem (those vaults are published, audited and live on their own pages) they are a write-key problem: the catalogue can only be updated by whoever holds its key, and that is not the site's build. Until it catches up, [the gallery](../demos/vaults/index.md) and [its machine-readable twin](../demos/vaults/llms.txt) are the complete list, generated from one file on every release. What this page adds is the shape taxonomy, the evidence and write-key status per entry, and the proof that an index of vaults can itself be a vault.

opening the catalogue…

Fetching the encrypted index…

### Vault debug [how this works →](../case-studies/live-vault-docs.md)

not open yet

what you are looking at

 Every row above is an encrypted object pulled from the SG/Send API and decrypted locally: click one: click one to see what it actually contains. Objects whose id contains **-imm-** are content-addressed and therefore immutable, so they are cached permanently; the mutable **ref** is the one mutable object, so it is checked at most once per freshness window (120s) rather than once per page, inside the window, reading the docs makes no requests at all, and **check for new commit** forces one whenever you want it.

The **tree** objects are the reason a first visit reads more than one file: filenames are encrypted inside them, so building the navigation means reading every directory. That index is a pure function of the commit id, so it is memoised, after the first visit, an unchanged commit reads no tree objects at all. Nothing here is stored on sgit.ai.

[How this page works →](../case-studies/live-vault-docs.md) Architecture diagrams, the object model, the cache tiers, and how a page like this one reads a vault it holds only the read key to.



==============================================================================
# Comparisons, as tests you can re-run, sgit.ai

> What a task costs with vaults and without, published by a participant and built to be challenged: every entry states the steps, the date, the result and how to re-run it. Includes a privilege vocabulary, and one comparison vaults lose.
>
> Page: https://sgit.ai/compare/index.html

[Home](../index.md) / Comparisons

# Comparisons, as tests you can re-run

What a task costs with vaults, and without them. This page is not unbiased. It is published by a participant, and nobody should read it as neutral. It is built to be **challengeable** instead: every entry states the exact steps attempted, the date, what happened, and how to run it yourself.

**Why not "unbiased".** A comparison published by one of the parties is not a neutral instrument, and claiming otherwise would be the least credible thing on this site. The achievable and stronger property is reproducibility: **an assertion that is wrong gets screenshotted; an experiment that is wrong gets corrected.** If an entry here is out of date or simply mistaken, the fix is a re-run, and the correction improves the page rather than discrediting it. [Tell us](mailto:) or open an issue on [GitHub](https://github.com/SGit-AI/SGit-AI__CLI).

## The asymmetry, stated up front

Our rows can be **executed**. A script opens a published vault, tries the operation and records what happened, it runs on demand and fails loudly when reality moves. Rows about anybody else's product cannot work that way: there is no API for "how many steps does this take in a desktop app", and automating someone's product against their terms is not something we will do. Those rows are **checked by hand, by a person, on a stated date**.

So the two kinds of row carry different badges, and you should trust them differently:

| Badge | Means | Ages |
|---|---|---|
| **machine-verified** | An automated check against the live service, in `admin/build/compare_tests.py`. The evidence below each claim is its actual output | Re-run any time; the date is the last run |
| **hand-checked** | A person performed the steps on the date shown and wrote down what happened | Decays. Past the expiry it renders as **unverified**, not as fact |

Loading verification status…

## The entry format

Every entry answers the same eight things. Anything that cannot be filled in honestly does not get published.

| Field | Why it is there |
|---|---|
| **Task** | Stated concretely enough that somebody can attempt it |
| **Steps** | Countable and disputable on facts. The number is a *summary*; the transcript below it is the evidence, because step counts are gamed by where you start counting |
| **Prerequisites** | Accounts, subscriptions, installs. This is where cost actually lands |
| **Privileges granted** | What the counterparty can now reach. The column that usually decides the answer, see the vocabulary below |
| **Where it runs** | Your machine, or theirs |
| **Survives the vendor** | Whether the artefact still works if the service stops |
| **Verified** | The date, and whether by machine or by hand |
| **Re-run it** | The command or the steps, so the claim is auditable rather than trusted |

## The privilege vocabulary

"Share it with them" hides the entire question. These seven properties make two grants comparable, and each is a fact rather than a judgement. This vocabulary is the part of this page most likely to be wrong at first. It is offered to be argued with.

| Property | Values | What it answers |
|---|---|---|
| **scope** | file · folder · vault · account · all-vaults | How much does the grant reach? |
| **operations** | read · write · delete · administer | What can be done with it? |
| **bearer** | person · program-on-their-machine · vendor-server · any-holder | Who actually holds it? "any-holder" means the grant is a string: whoever has it, has it |
| **mediation** | server-enforced · key-enforced | Who says no? A server can refuse and can log. A key cannot refuse, possession *is* access |
| **duration** | session · until-withdrawn · forever | When does it lapse on its own? |
| **withdrawal** | effective · future-only · none | Can you take it back, and does taking it back reach what they already have? |
| **observability** | per-reader-log · aggregate · none | Can you see who read what? |

Written compactly, a published read key is: `scope:vault · ops:read · bearer:any-holder · mediation:key · duration:forever · withdrawal:future-only · observability:none`. Three of those seven are **worse** than a mainstream sharing link, and saying so is the point of having a vocabulary.

**One shape the vocabulary above could not express, until a vault demonstrated it.** An app can be granted the *use* of a credential without being given the credential: the [Risk Mandate vault](../demos/vaults/risk-mandate/index.md) seals its OpenRouter key under the vault key, and the host makes the call on the app's behalf. So `ops` and `bearer` come apart, `ops:llm-chat` is granted while `bearer` of the key is not, and a read-key holder auditing the vault (as we did) finds ciphertext where the secret would be. Most sharing models cannot say this, because handing over the capability and handing over the credential are the same act.

**The performance comparison lives on its own page.** "How does this compare to a graph database?" is asked often enough, and needs enough measurement behind it, that it is not an entry here. [Performance, cost, and running everywhere](../demos/fractal-graphs/performance.md) is the answer: what a read actually costs with no live database, the cost model line by line, and the six places this is slower, all with the commands to repeat every figure.

## The entries

Three to start with, chosen to be different: one small and verifiable in seconds, one we lose, one that is the actual differentiator. More arrive as they are tested, not as they are thought of.

### 1 · Print a markdown file that somebody sent you

Small, universally understood, checkable in under a minute, the kind of entry that earns the credibility the larger claims spend.

|  | A markdown file in a vault | A markdown file on your disk |
|---|---|---|
| **Steps** | **2**: open the file in the vault UI (it renders), press **Print** | **3–5**, depending on what you already have: many editors render markdown but print the *source*; the common workarounds are convert-to-HTML, paste into a browser, or install something |
| **Prerequisites** | A browser | An editor that both renders *and* prints, or a converter, or an online tool |
| **Privileges granted** | None beyond the key you already hold | None, *unless* you use an online converter, which is `scope:file · ops:read · bearer:vendor-server · withdrawal:none`. Uploading a document to a stranger to reformat it is a privilege grant that does not feel like one |
| **Where it runs** | Your browser; the print component renders locally | Your machine, or a stranger's |
| **Verified** | **hand-checked, 2026-08-16**: the vault UI exposes a **Print** control on an open markdown file, backed by `SgPrint.printMarkdown`; confirmed present and reachable in a browser driven with a published read key |
| **Re-run it** | Open `https://dev.vault.sgraph.ai/#sgit_public_read_0a0f34839d737eef0f8f66e5236990b1f397af064763e3f71dca2717015f9d15:3d04e6b9ca98`, go to the vault browser, click `README.md`, look for **Print**. For the other column, take any `.md` file and try to produce a formatted page with whatever you already have installed, count what it takes |

**What would change this entry:** an editor that renders and prints markdown in one action, which several are close to. If you know one, that column's step count should drop and this entry should say so.

### 2 · Take access back after you have shared something we lose this one

A comparison where our column always wins is discounted on sight, so here is one where the mainstream answer is straightforwardly better.

|  | A vault, shared by read key | A hosted document, shared by link |
|---|---|---|
| **Steps to withdraw** | **Rotate the key and re-publish.** Future commits are protected | **1–2**: remove the share; the next request is refused |
| **Does it reach what they already have?** | **No.** Anything already fetched stays readable forever, with no way to reach it | **Largely yes**: unless they exported or screenshotted, the server stops serving it |
| **privileges** | `withdrawal:future-only · mediation:key · observability:none` | `withdrawal:effective · mediation:server-enforced · observability:per-reader-log` |
| **Why** | Possession of a key *is* access, so there is no server in the loop to refuse a later request. The objects are content-addressed and immutable, the same id returns the same bytes forever, which is exactly what makes an already-taken copy permanent |
| **Verified** | **machine-verified**: the immutability that causes this is checked automatically (`objects-immutable` below). The hosted-side behaviour is **hand-checked, 2026-08-16**, and is the ordinary documented behaviour of mainstream sharing |
| **Re-run it** | `python3 admin/build/compare_tests.py`, the immutability check fetches one object twice and compares bytes |

**The honest summary:** if the ability to revoke access after the fact matters more to you than the host being unable to read your content, a server-mediated platform is the better tool and you should use one. Vaults trade revocation for the host knowing nothing. That is a real trade, not a free win.

### 3 · Let a program record data for you without letting it change your records

The differentiator. Note that the step counts are similar. It is the privileges column that separates these, which is why it is the column to lead with.

|  | A vault app | An assistant with folder access |
|---|---|---|
| **Steps** | Declare the grant in `app.json` and open the vault | Grant access to the folder, then run it |
| **Privileges granted** | `scope:folder(adherence/) · ops:write,mkdir · mediation:key+host`, read broadly, but write to **one folder**. The app cannot alter the records it reports on | Typically `scope:folder · ops:read,write · bearer:vendor-server` for the whole shared folder, the granularity available is the folder you shared |
| **Where it runs** | Your browser, in a sandboxed frame with an opaque origin | Usually the vendor's infrastructure, with your files sent to it |
| **Survives the vendor** | The data is files with a documented layout; the reader is replaceable (we wrote a ~170-line one to prove it) | The conversation and any generated artefacts live where the vendor put them |
| **Verified** | **machine-verified**: `scoped-write-declared` below reads the live vault's `app.json` and asserts the write scope is exactly `["adherence/"]`. The comparison column is **hand-checked, 2026-08-16** and describes the general shape of folder-level sharing, which varies by product, corrections welcome, per-product rows to follow |
| **Re-run it** | Open the [Supplement Stack vault](../demos/vaults/supplement-stack/index.md) and read its `app.json`, or run `python3 admin/build/compare_tests.py` |

**The caveat that keeps this honest:** read granularity is coarser than write granularity here. A read key opens the *whole vault*, not one file. Finer read boundaries mean separate vaults with separate keys, decided in advance, granularity costs structure. If you need per-file read control without pre-planning the shape, this is not yet the tool.

## The checks behind the machine-verified rows

These run against the live service using only published read keys, and each states what would make it fail, a test that cannot fail is not evidence.

Loading results…

## What is deliberately not here

| Not here | Why |
|---|---|
| Anything we plan to ship | A comparison page is exactly where planned capability must not sit beside shipped capability. One unshipped row and a reader re-reads every other row as marketing |
| Ease-of-use scores | A judgement published by a participant is the thing this page cannot defend. Steps, prerequisites and privileges are facts |
| A deployment-features comparison | It would be the most linked and the fastest to rot, and our own story has a caveat worth resolving first: a vault's files are portable, but the polished viewer is currently one hosted implementation |
| A maturity model | Those score an organisation's practice over time. This scores a task against a tool stack on a date, a different instrument |



==============================================================================
# Published vaults, sgit.ai

> Thirty-one vaults you can open in your browser right now, every read key published on purpose. A read key is the whole credential: no account, nothing to install, no write capability in it. Each row opens a page with what the vault does and the vault running live inside it.
>
> Page: https://sgit.ai/demos/vaults/index.html

[Home](../../index.md) / Vaults

# Published vaults

Open any of these in your browser right now. Every read key here was published on purpose, and a read key is the whole credential: no account, nothing to install, no write capability in it. Each row opens a page with what the vault does and the vault itself running live inside it.

**Nine are semantic graphs**, each in its own ontology, from a regulation down to a compute instance. · [The ladder, walked →](../fractal-graphs/index.md) · [What reading one costs →](../fractal-graphs/performance.md)

**36 published vaults**: 10 briefing, 7 analysis, 5 application, 5 reference, 4 record, 3 presentation, 1 gallery, 1 report. Newest first; **click any heading to sort**. Every read key and the live link are on the vault's own page.

| # | Vault | What it is | Category | Files | Size | Published |
|---|---|---|---|---|---|---|

| 36 | [Company X-Ray](company-xray/index.md)`ukpqjkly` | A business plan for reading a company's own documents together, with one invented company X-rayed and every finding tied to its evidence | Briefing | 60 | 710 KB | 2026-09-24 |

| 35 | [Lesson Loop](lesson-loop/index.md)`3s9q7zl7` | A business plan for coaches: the coach's knowledge captured at the end of every lesson, in a record the player holds | Briefing | 27 | 407 KB | 2026-09-24 |

| 34 | [Risk Acceptance Office](risk-acceptance/index.md)`odn10gfp` | A business plan with one risk replayed: established on facts, accepted for an interval, escalated, funded and ended on facts | Briefing | 32 | 673 KB | 2026-09-24 |

| 33 | [Connector Twin](connector-twin/index.md)`7tkvspwp` | A business plan with a working replay: what an agent did through Gmail and Calendar, what it saw, and what can be undone | Briefing | 31 | 515 KB | 2026-09-24 |

| 32 | [Agent as Webmaster](agent-webmaster/index.md)`ikrqeu5t` | A complete business plan, with mock-ups and prototypes, written for somebody else to run | Briefing | 32 | 666 KB | 2026-09-23 |

| 31 | [DSIT AI Risk Toolkit](dsit-ai-risk-toolkit/index.md)`0q4sfr57` | Start with an AI decision and trace it back to UK DSIT guidance; an eight-slide walkthrough plays from the vault | Reference | 155 | 12.1 MB | 2026-09-20 |

| 30 | [Fractional CISO application pack](fractional-ciso-pack/index.md)`eaba68j5` | The sibling of #29, written for an archetype instead of a company, so there is nothing to redact. Two days a month, a twelve-month map, and a section that says what the role is not | Briefing | 72 | 19 MB | 2026-09-18 |

| 29 | [Interim CISO application pack](interim-ciso-pack/index.md)`8brojsem` | A job application as a vault, three routes for three readers, four documents in four formats each, and the client named nowhere | Briefing | 56 | 17 MB | 2026-09-17 |

| 28 | [Synthetic users · riskmandate.ai](synthetic-users-riskmandate/index.md)`o3q6zhtr` | The same method as #27 pointed at a second product, and it measured rather than narrated, catching a shipped bug every existing test had passed over | Analysis | 53 | 3.5 MB | 2026-09-16 |

| 27 | [Synthetic users](synthetic-users/index.md)`g2hei4u6` | Five invented buyers walked through store.sgit.ai one screenshot at a time, 43 steps, 15 unanswered questions, 18 findings, three costing a sale | Analysis | 67 | 6.4 MB | 2026-09-15 |

| 26 | [The sgit.ai board](board/index.md)`pdulwi6i` | The site's own task board as a vault, cards as files, five columns as an app, the source of truth the site renders from | Record | 21 | 40 KB | 2026-09-07 |

| 25 | [Agent permission games](agent-permission-games/index.md)`4evnlwrj` | Two games about grants and mandates, the first vault here that phones home | Application | 68 | 2.6 MB | 2026-09-06 |

| 24 | [AIUC-1 conformance layer](aiuc-1-conformance/index.md)`2wzct4k7` | The AIUC-1 standard as a graph, plus a conformance layer that computes insurability | Reference | 649 | 43 MB | 2026-09-05 |

| 23 | [Licence to Operate](licence-to-operate/index.md)`posrhzp3` | An insurance policy for an agent, simulated: grant, mandate, and the delta nothing covers | Analysis | 121 | 13 MB | 2026-09-04 |

| 22 | [VoiceDebrief pitch (FI)](voicedebrief-pitch/index.md)`95i2xqrd` | A three-minute investor pitch as a presenter app, with script, timings and sources | Presentation | 48 | 17 MB | 2026-09-02 |

| 21 | [Scaling Threat Modeling](threatmodcon-2025/index.md)`0ict6flm` | ThreatModCon 2025: eleven linked threat models across 51 nodes and 179 threats | Presentation | 53 | 4.1 MB | 2026-08-27 |

| 20 | [AI vs. AI, Black Hat EU 2025](blackhat-eu-2025/index.md)`k1izvg7e` | The Black Hat EU 2025 keynote, with its PDF exports and eight research papers | Presentation | 87 | 20 MB | 2026-08-27 |

| 19 | [Standards Atlas, GDPR](standards-atlas-gdpr/index.md)`4zv4bvmu` | GDPR as a semantic graph, with writes scoped to a feedback folder | Reference | 116 | 6.3 MB | 2026-08-25 |

| 18 | [RiskMandate · File security](riskmandate-file-security/index.md)`wu365g94` | An eleven-step risk-acceptance walk, running SQLite in the browser | Analysis | 71 | 2.7 MB | 2026-08-25 |

| 17 | [Penetration Test Report](pentest-report/index.md)`o4lrwx02` | A penetration test report (fictional) with a re-test script per finding | Report | 93 | 6.4 MB | 2026-08-25 |

| 16 | [SG/Payments Brief Pack](payments-brief-pack/index.md)`o3m0sz3q` | A payments briefing pack, marked PROPOSED rather than dressed as decided | Briefing | 18 | 224 KB | 2026-08-25 |

| 15 | [Content-Transformation Proxy](content-transformation-proxy/index.md)`3c90c2bff2b1` | An as-built engineering brief, shipped with its slides, diagrams and source PDFs | Briefing | 140 | 63 MB | 2026-08-25 |

| 14 | [SG Commercialisation](commercialisation/index.md)`haeu7p1e` | A commercial operating model, with its customer register deliberately left empty | Briefing | 78 | 536 KB | 2026-08-25 |

| 13 | [Vault App Mode](vault-app-pocs/index.md)`xth1xt78` | Nine proofs of concept for vault app mode, with a hub that runs them | Reference | 57 | 251 KB | 2026-08-23 |

| 12 | [Private Health Score](health-score/index.md)`zc6abngv` | A clinical questionnaire scored by a versioned framework, with a clinician review screen | Application | 35 | 1.2 MB | 2026-08-23 |

| 11 | [VoiceDebrief](voice-debrief/index.md)`k6xy9z4d` | Four apps in one vault, from raw recording to structured debrief | Analysis | 92 | 1.2 MB | 2026-08-22 |

| 10 | [Regulation Graph](regulation-graph/index.md)`73heuprz` | The EU AI Act parsed from Formex into an evidence graph, article by article | Reference | 207 | 14.9 MB | 2026-08-20 |

| 9 | [Risk Mandate](risk-mandate/index.md)`4zf6pf2z` | A working software project delivered as a vault, and it calls an LLM holding no API key | Application | 124 | 1.9 MB | 2026-08-17 |

| 8 | [Risk Graph Explorer](risk-graph-explorer/index.md)`3simlnqe` | A fact-to-risk graph explorer, built to be public: its app.json requests nothing | Application | 33 | 428 KB | 2026-08-17 |

| 7 | [Agentic Browser Isolation](agentic-browser-isolation/index.md)`0610gsp9` | Should an agent browse with your logged-in sessions? A living risk graph, per stakeholder | Analysis | 104 | 2.4 MB | 2026-08-17 |

| 6 | [Supplement Stack](supplement-stack/index.md)`r7zes477` | A patient-held health record: a real regimen, label photos, totals against UK RNIs | Record | 23 | 2.3 MB | 2026-08-16 |

| 5 | [Strategy Maps](strategy-maps/index.md)`ookq4mn4` | The SG/Send strategy in seven Wardley maps, plus the sgit positioning analysis | Analysis | 33 | 830 KB | 2026-08-16 |

| 4 | [Field Notes](field-notes/index.md)`4bshby5n` | Six studies with generative SVG art, the smallest complete vault app | Application | 4 | 11 KB | 2026-08-16 |

| 3 | [Deploy Docs](deploy-docs/index.md)`fyofmkvr` | Living deployment documentation, updated by an sgit push with no site deploy | Record | 17 | 25 KB | 2026-08-16 |

| 2 | [The Vault Catalogue](catalogue/index.md)`kc67yhgw` | An index of published vaults that is itself a vault, and lists itself | Record | 9 | 11 KB | 2026-08-16 |

| 1 | [Algarve · May 2026](algarve-may-2026/index.md)`3d04e6b9ca98` | A travel diary: twenty photographs in three sizes and an eight-chapter narrative | Gallery | 71 | 29 MB | 2026-08-16 |

Publishing one of your own? [**The method is written down**](publishing.md): the seven steps behind every row above, the tools that do each one, and the mistakes that produced each rule. The rules themselves, with the incident behind each, are on [**Lessons learned**](../../lessons/index.md), including why a read key may be published and a vault key never may.

This table is the complete list, and [its machine-readable twin](llms.txt) is generated from the same file. [The catalogue](../../catalogue/index.md) (an index of vaults that is itself a vault, updated by an sgit push with no site deploy) carries a shape taxonomy and per-entry evidence status for the first nine; it is waiting on its key holder for the rest. The original worked example of creating, auditing and embedding one is on [the embed demo page](../vault-app-embed.md).

Agents: this catalogue is also published as [/demos/vaults/llms.txt](llms.txt), every vault above with its id, category, size and published read key, generated from the same file this table is, so the two cannot drift. The whole-site map is [/llms.txt](../../llms.txt).



==============================================================================
# Start with an AI decision, then trace it back to the guidance: the DSIT AI Risk Toolkit vault

> An independent, experimental journey through the UK DSIT AI Risk Management Toolkit, published as a vault: describe a use case, review the risk prompts that apply, record evidence and owners, propose controls and reassessment, and follow each step back to its source. An eight-slide walkthrough plays on the page from the encrypted vault, with the PDF as a download. Underneath: separate worlds with named bridges, every edge labelled curated or lexical, hashed source snapshots, 13 passing checks and 6 published gaps. Not an official DSIT service or certification.
>
> Page: https://sgit.ai/demos/vaults/dsit-ai-risk-toolkit/index.html

[Home](../../../index.md) / [Vaults](../index.md) / DSIT AI Risk Toolkit

An independent, experimental journey through the UK DSIT AI Risk Management Toolkit

# Start with an AI decision, then trace it back to the guidance

Describe a use case, review the risk prompts that apply to it, record evidence and owners, propose controls and a reassessment trigger, and follow each step back to its source in the official guidance. The vault below is a working prototype of that journey. An eight-slide walkthrough shows it with a fictional example.

[Try the live vault ↗](https://dev.vault.sgraph.ai/#sgit_public_read_cdc00d2baaf75361d86ae1b7a40169bd98d71aaae1bd581e181a0f0ba0e0e6bb%3A0q4sfr57) [View the eight-slide walkthrough ↓](#walkthrough) [Download the PDF deck](#walkthrough)

The walkthrough uses fictional data. This is an independent experiment with public UK government guidance, not an official DSIT service, assessment or certification. Nothing you enter leaves your browser tab until you export it.

## See the journey in eight slides

The deck is read live out of the vault as you click: the slide source runs in a sandboxed frame with no origin and no network, each slide renders in a second frame with scripting switched off, and the five screenshots are decrypted in your browser. Use **notes** for the speaker notes, **focus** to hide the slide list, the arrow keys to move, and **PDF** to download the printed deck.

**The eight slides, in one line each**

1. **A decision before a risk list.** The vault opens on a use case and a governance decision, not a checklist.
2. **The journey.** Use case, relevant risks, evidence and owner, control and reassessment, original source.
3. **Start with the use case.** Title, decision, scope and decision owner. Three synthetic examples, or your own.
4. **Context changes the questions.** Ten context facts prioritise 153 top-level prompts; unknown answers stay open.
5. **One risk, a working record.** Pick a source question, record evidence, owners, a control and a review trigger.
6. **The graph stays underneath.** The research graph of 941 nodes and 4,735 edges connects question, topic and source.
7. **Take the work with you.** A JSON export of your answers and the derived session graph; import recomputes conclusions.
8. **Try a decision in the vault.** Bring one use case and one decision, and say where the journey is confusing.

## What you can try in the vault

Five steps, in the order the journey asks them. Each one is a screen in the live vault; the graph does the tracing underneath, and you do not need to learn it first.

| Step | What you do | What to notice |
|---|---|---|
| **1 · Use case** | Write the decision you need to make: a title, the governance decision, the scope, the decision owner. Or pick one of three clearly labelled synthetic examples. | The journey starts from a decision, not from a list of risks. |
| **2 · Risk prompts** | Answer ten context facts. The 153 top-level prompts from the official guidance are prioritised for your case; unknown answers stay open. | The prompts keep the source wording. Six conservative rules propose scope changes for human review; none removes a question silently. |
| **3 · Evidence and owner** | For a risk that applies, record an evidence reference and the people responsible. | A recorded reference is a user assertion. It is not independently verified by anything in the vault. |
| **4 · Control and reassessment** | Propose a control and the trigger that would make you look at the risk again. | These are proposals, kept apart from the source text, and labelled as such. |
| **5 · Source** | Follow any prompt back to the retained guidance snapshot and the GOV.UK page it came from. | Every prompt walks back to hashed source bytes. That is the graph, doing its job without being asked. |

**Where your answers go.** Nowhere, until you say so. Draft answers live in the browser tab; **export the JSON before closing it**. The export holds your entries and a derived session graph, not copies of the source corpus, and importing it recomputes the scope conclusions. This is a prototype built to be tested with the people it is for, and the most useful thing to send back is where it confused you. [Open the journey ↗](https://dev.vault.sgraph.ai/#sgit_public_read_cdc00d2baaf75361d86ae1b7a40169bd98d71aaae1bd581e181a0f0ba0e0e6bb%3A0q4sfr57)

## The vault, embedded

The journey opens as the vault's home page. The earlier source-backed reference edition is one click away inside it, at `reference.html`. It has more room [in its own tab ↗](https://dev.vault.sgraph.ai/#sgit_public_read_cdc00d2baaf75361d86ae1b7a40169bd98d71aaae1bd581e181a0f0ba0e0e6bb%3A0q4sfr57).

## How it works underneath

The journey sits on the reference edition this vault started as, and the reference edition is the reason the source trace works. Its structure has not changed; it has moved below the decision.

### Separate worlds, and the bridges are the point

The guidance, the official spreadsheet, the risk method it describes, the 160 risk-question bullets and the frameworks it cites are not the same kind of thing, and modelling them in one vocabulary would force most of them to pretend to be another. The vault declares separate worlds and lets each keep its own shape, with named bridges between them. Its ontology states the limit plainly: *"containment alone is not fractality. Cross-world edges make the semantic transitions inspectable."* That is the same distinction [Fractal Semantic Graphs](../../fractal-graphs/index.md) arrives at from the other direction.

| World | What lives in it |
|---|---|
| `source` | The publication as retrieved: 30 guidance sections, 67 blocks, and the bytes they came from |
| `risk_method` | The method the guidance describes: risk categories, treatments and appetite |
| `risk_question` | The 160 risk-question bullets, in nine category shards, with 274 punctuation units for stable traversal and no semantic claim |
| `workbook` | The official spreadsheet as data: 4 sheets, 490 cells, 208 of them formulas |
| `frameworks` | The external standards the text cites, referenced and never reproduced |

The semantic explorer at the four-world edition of 20 September 2026. Each connection states its verb and how it was obtained: `is_derived_from · curated` is an authored claim, `is_mentioned_by · lexical` is a string match, and the vault never lets you mistake one for the other.

### Curated against lexical

Every assertion is labelled with which it is: an edge somebody decided, or an edge a search found. A reader who disagrees with a `curated` edge is disagreeing with a person. A `lexical` edge claims only that a word appeared, and the vault's own limits say *"lexical mentions are not validated meaning."* It also refuses the inference everyone wants to make from a compliance artefact: *"no compliance inference or organisation attestation is made."*

The risk-method world, from identification to treatment. Nine categories, each an edge away from the guidance that defines it and the workbook cells that score it.

### Every claim carries the bytes it came from

Five source snapshots are retained inside the vault, each with its URL, its retrieval date and the SHA-256 of the bytes: the guidance body, two content-API responses, and the official workbook in both XLSX and ODS. The workbook is read rather than rewritten: cached values are not recalculated, dates stay as Excel serials, styling is not reproduced, and the vault says so. Two of its checks exist purely to prove the originals were not touched.

*"A claim is only as useful as its trace."* The checks, all passing, and the known gaps published beside them.

### The six gaps it publishes about itself

- **It corrects its own earlier number.** *"Direct OOXML recount finds 208 formula cells, correcting 227 in the retained earlier briefing."* The earlier briefing stays in the vault, uncorrected, with the correction recorded beside it.
- **It preserves a contradiction in the source.** The official file is named v1.1 and its own Welcome sheet says v1.0. Both labels are kept.
- **It refuses to repair the source.** Two defined names in the official workbook are broken. They are reported broken. *"No source repairs were made."*
- **It declines the flattering reading.** *"Starter rows are not evidence of adoption"*, and no independent implementation, compliance assessment or adoption metric is asserted.
- **It dates itself.** The retained research briefing is a snapshot as of 20 September 2026; external sources may change.
- **It names what it did not build.** Formula dependency expansion and shared-formula expansion are not implemented.
*"Inspect. Download. Query."* The official files remain unchanged, and SQLite compiled to WebAssembly runs the queries in your tab.

### What it demonstrates about vaults

| Feature | How this vault uses it |
|---|---|
| **Read and download, no write** | `fs.read` is true and `write` and `delete` are both empty arrays, with downloads and external links declared. The journey's drafts stay in the tab and are never written back |
| **Queries with no backend** | sql.js, which is SQLite compiled to WebAssembly, is bundled so the query view works offline. The copies were taken from the published [Regulation Graph vault](../regulation-graph/index.md) and the provenance of that decision is recorded in `NOTICE.md` |
| **Two things versioned in the open** | The reference edition and the journey carry separate version records, each with its own release page, and the version badge in the app links to the release it is showing |
| **A licence that survives the copy** | Source text under OGL v3.0, application code with no additional licence assigned by the release, bundled sql.js under MIT with SQLite in the public domain, marked under MIT. Each is stated rather than blended |
| **Machine-readable on the way out** | `downloads/graph.jsonld` keeps every assertion's provenance and partition, and the journey's JSON export carries the derived session graph, so both leave the vault without losing what made them checkable |
| **A deck, on the site, from the vault** | The walkthrough above follows the [decks/v2 contract](../../../docs/briefs/vault-decks-on-a-site.md): manifest, slide source, styling, screenshots and PDF read from the vault; controls, routing and download owned by this page |

## Status, versions and limits

| What | As published, 23 September 2026 |
|---|---|
| **Main journey** | v0.2.0, dated 23 September 2026, an independent experiment. Its record describes itself as *"experimental, unverified user assertions; no official DSIT endorsement or compliance assessment"*. Its ontology and question shards remain the v0.1.0 research snapshot |
| **Reference edition** | v0.2.3, dated 23 September 2026: the journey promoted to the vault home, the former reference home kept at `reference.html`, every source-backed page retained |
| **Research graph** | 941 nodes and 4,735 edges, as stated in the deck's own notes and counted from the vault's edge shards. A separate graph from the reference edition's, and the counts are not merged |
| **Reference graph** | 1,051 nodes and 1,289 edges in `data/graph.json`, measured from a read-key clone on 23 September 2026. The four-world edition of 20 September was 617 nodes and 694 edges; that figure is kept below as the dated snapshot it was |
| **Checks** | 13 of 13 passing in `data/validation.json`, with 6 known gaps published beside them |
| **Licences** | DSIT source text: Open Government Licence v3.0, attributed, with no departmental logos or crests. Application and graph code: created for this edition, with no additional licence assigned by the release; the owner may choose one separately. Bundled sql.js and marked: MIT. SQLite: public domain |
| **What this is not** | Not an official DSIT service, standard, certification or conformance assessment. No validated risk scoping, no claim of organisational adoption, no user-tested effectiveness. A prototype for testing with intended users |

****Provenance and the credential****

**The key is the whole credential.**
 Read key: `sgit_public_read_cdc00d2baaf75361d86ae1b7a40169bd98d71aaae1bd581e181a0f0ba0e0e6bb:0q4sfr57`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_cdc00d2baaf75361d86ae1b7a40169bd98d71aaae1bd581e181a0f0ba0e0e6bb%3A0q4sfr57) · From the CLI: `sgit clone sgit_public_read_cdc00d2baaf75361d86ae1b7a40169bd98d71aaae1bd581e181a0f0ba0e0e6bb:0q4sfr57`
Published under the `sgit_public_read_` prefix, which is the form for a key published on purpose. It grants read and only read; the owner credential is kept outside the vault, as its README says. Classified before it touched anything, and verified with an all-zeros negative control at first publication: the real key produced 42 files, the control an empty directory. [What the prefixes declare →](../../../docs/credentials.md)

### Derived facts, 23 September 2026

From `admin/build/catalogue_derive.py 0q4sfr57 <read key hex>` and a read-key clone, no token: **155 files** · 12.1 MB plaintext · 14 commits · HEAD `obj-cas-imm-16ef099d1561` · app entry `index.html` declared in `.vault/app.json` with `fs.read`, empty `write` and `delete`, downloads and external links · one deck in `decks/decks.json` (type `decks/v2`), 8 slides, 5 screenshots, PDF `deck/DSIT_AI_Risk_Use_Case_Journey.pdf` with SHA-256 `36f9e16c295824c09e4acffa0c0370f4a66c0fd01c58068f733857c8de4e1cf6` · 6 version records, current 0.2.3 · 5 hashed source snapshots retrieved 20 September 2026.

### The pre-publication audit

| Checked | Result |
|---|---|
| Credentials and secrets | **None.** No vault key, no credential under any `sgit_private_` prefix, no API keys, tokens, `delete_auth` or `append_token` values, no private-key blocks. The public read key appears in the deck's last slide and in the PDF's link annotation, on purpose |
| Personal data | **None.** Two email addresses appear, `alt.formats@dsit.gov.uk` and `psai-tech@dsit.gov.uk`, both published institutional contacts carried over from the official publication. The deck's second slide paraphrases a public LinkedIn comment and says it did not verify the post or claim endorsement |
| Its own checks | Re-read from `data/validation.json`: 13 of 13 passing, 6 known gaps published |
| Attribution | OGL v3.0 acknowledged, no crests or logos used, external standards referenced and not reproduced, official status disclaimed on the front page, in `NOTICE.md` and on every slide's footer |

### The historical snapshot, 20 September 2026

First published as row #31 with 42 files, 3.2 MB, 617 nodes and 694 edges across 3 partitions and 4 worlds, 8 predicates all with declared inverses, 8 of 8 checks passing, and 2 released versions with 0.1.1 current. Those numbers described that edition and are kept here with their date. The four screenshots in the section above were taken from it.

The usual rule applies to this key as to every other one here: **revocation is not retroactive**. Anyone who fetches these objects keeps them.

A rung on [Fractal Semantic Graphs](../../fractal-graphs/index.md), beside the [Regulation Graph](../regulation-graph/index.md) whose sql.js copies it reuses. [← All published vaults](../index.md) · [The publishing method](../publishing.md) · [Decks from a vault, on a site](../../../docs/briefs/vault-decks-on-a-site.md)



==============================================================================
# Publishing a vault: the method, sgit.ai

> The seven steps behind every vault published here, written for another agent to follow: classify the credential before it touches anything, derive rather than refuse, audit with the read key, derive the facts, capture evidence by driving the real product, write the page, and record what outlives it, plus the mistakes that produced each rule.
>
> Page: https://sgit.ai/demos/vaults/publishing.html

[Home](../../index.md) / [Vaults](index.md) / Publishing a vault

# Publishing a vault: the method

Every vault in this section went through the same seven steps. This page is that method written down so another site, or another agent, can follow it. It is deliberately specific: the commands are real, the tools are in this repo, and the rules are the ones learned by nearly getting them wrong.

**Who this is for.** An agent maintaining a site that publishes vaults. Read the [markdown twin](publishing.md) if you are one. The tooling referenced lives in `admin/build/` of the sgit.ai repository and is small enough to copy rather than depend on.

## The two rules everything else serves

| Rule | Why it is absolute |
|---|---|
| **Read keys yes, vault keys never** | A read key is a capability handed out on purpose and cannot become write access. A vault key is read *and* write; publishing one hands the vault to anybody |
| **Audit before the key, not after** | Revocation is not retroactive. Anyone who fetches the objects keeps them, so an audit that happens after publication has not happened |

## 1 · Classify the credential before it touches anything

Do this first, before the credential is pasted into a page, a script or a commit. Credentials arrive mislabelled. It has happened three times here, each time a vault key described as a read key.

```
python3 admin/build/check_credential.py '<credential>'
# exit 0 → read-only, safe to publish
# exit 1 → write credential (or unrecognised) — stop
```

It classifies two ways, because the problem has two eras: by **prefix** for vaults new enough to emit one, and by **shape** for everything older, a read key is 64 hex characters, and anything else before the colon is a passphrase, which means write.

**Publish it under the prefix that declares what you are doing.** `sgit_public_read_` is a read key meant to be published; `sgit_private_read_` is one meant to be kept secret. Same bytes, same access, opposite declaration, and the build now refuses the second in any tracked file. [The five prefixes and what each declares →](../../docs/credentials.md)

## 2 · If it is a vault key, derive rather than refuse

A vault key does not block publication; it changes what you publish. Store it where the repository cannot commit it, then derive:

```
# the gitignored tier — the release tripwire then scans every tracked file for it
printf '%s' "$VAULT_KEY" > admin/local/demo-keys/<name>-vault-key

python3 - <<'PY'
from sgit_ai.crypto.Vault__Crypto import Vault__Crypto
c = Vault__Crypto()
pw, vault_id = c.parse_vault_key(open('admin/local/demo-keys/<name>-vault-key').read().strip())
print(c.derive_keys(pw, vault_id)['read_key'])     # publish only this
PY
```

The derivation is one-way: a published read key cannot be turned back into the vault key. Never print the write key; never let the vault key reach a tracked file.

## 3 · Audit with the read key, across every file

Open the vault with the *read* key, the credential your readers will have, and scan every text file. Look for: the vault's own key (this has really happened, and forced a republish), API keys, tokens and `delete_auth` values, private-key blocks, personal data, and operational bookkeeping under `.vault/`.

**Ruling hits out is the work.** Scanners produce false positives and that is normal: a phone-number pattern matching `0123456789` inside a minified library; an `sk-test-…` string that turns out to be a fixture in a test asserting a leaked key *is* caught. Read every hit. Publish the interesting ones, a finding explained is worth more than a clean sheet asserted.

## 4 · Derive the facts rather than describing them

```
python3 admin/build/catalogue_derive.py <vault_id> <read_key>
```

File count, size, commit depth, HEAD, top-level layout, file types, app entry points and browser-renderability, all from the read key, no token and no clone. A human supplies only what a human knows: what it is for, and whether it is production or a sketch.

## 5 · Capture evidence by driving the real product

Screenshots should be of the actual vault, produced by a script that opens it with the published read key and performs the navigation being described. Mock-ups age into lies; a capture script re-runs.

```
node admin/build/capture_shots.mjs --vault <slug>
```

Each shot declares a surface (the app, or the vault browser), the steps, and the crop. Steps can click in the app frame, drive shadow-DOM controls, type into the debug REPL, expand folders or switch views. Store the images beside the page (`demos/vaults/<slug>/images/`) so a vault's folder is self-contained.

## 6 · Write the page: describe, then show, then admit

| Section | What goes in it |
|---|---|
| Lead + why this one | What the vault is, and the one thing it demonstrates that others do not |
| The credential, in the open | The read key, a CLI command, and a link that opens it in the official UI. Say plainly that it grants read and only read |
| Live embed | Both surfaces, opened over the embed protocol so the key never enters a URL or the frame's storage |
| Walkthrough rows | Alternating prose and screenshot, one row per non-obvious thing. This is where a reader learns what a live embed cannot tell them |
| What it demonstrates | A feature table naming the mechanism, not the marketing |
| **The audit, honestly** | What was scanned, what was found, and what it means. Findings included |
| Derived facts | Step 4's output, with the tool named so it can be re-run |

## 7 · Record the things that outlive the page

Per entry: the **shape** (the workflow it resembles, not its domain), the **evidence status** (production, demonstration, or sketch), whether it is a copy or a live reference, and the **write-key status**: escrowed or lost. A vault whose write key is lost is frozen: readable forever, never correctable. Say so where a reader will see it.

## What we got wrong, so you do not have to

| Mistake | The rule that came out of it |
|---|---|
| A vault published its own write credential inside its content | **Republish, don't retrofit.** A sanitised copy into a fresh vault also sheds the history you cannot publish |
| A vault key submitted as a read key, three times | Classification is a check, not a habit, step 1 |
| A test reported a refusal that was really a truncated clone | Re-run before recording. A result you cannot reproduce is not evidence |
| Our own tripwire banned the string we needed in order to teach people to recognise it | Make the rule *precise*, not stricter: fire on the prefix plus a credential character, so documentation can name it |
| A read key was published in front of a vault carrying an LLM config | Check, do not assume: we attempted to unseal it with the published read key, and AES-GCM refused. State the result either way |

The best statement of the vault-side rules is not ours: the [Risk Graph Explorer](risk-graph-explorer/index.md) carries a `PUBLIC.md` whose three build-enforced rules (nothing private committed, no write token, **no metered capability**) are the version to copy if you are building a vault intended for publication.

## The tools, in one list

| Tool | Does |
|---|---|
| `admin/build/check_credential.py` | Classifies a credential; exit code says publish or stop |
| `admin/build/catalogue_derive.py` | Read key → the facts, read-only and no token |
| `admin/build/capture_shots.mjs` | Drives the live vault and crops evidence screenshots |
| `admin/build/validate.js` | The release gate, including the key-leak tripwire |
| `admin/build/compare_tests.py` | Executes the claims that can be executed, with dates |



==============================================================================
# The same pack, written for an archetype instead of a company, fractional CISO pack

> Sibling of vault #29 from the same generator: a fractional CISO pack that solves the publication problem by describing a type of company rather than withholding a real one. Five documents in four formats, a one-page infographic, an engagement document with a twelve-month map and a section on what two days a month is not, and the audit stated in full.
>
> Page: https://sgit.ai/demos/vaults/fractional-ciso-pack/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Fractional CISO application pack

# The same pack, written for an archetype instead of a company

A sibling of [vault #29](../interim-ciso-pack/index.md) from the same generator, one day later, and the interesting difference is how it solves the privacy problem. That pack described a real role and *withheld* the company. This one describes **a type of company**, derived from public sources, so there is nothing to withhold. Same three routes, same thirteen recommendations, a different argument: two days a month, on a retainer, for a business that is already certified.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_7c84275ebcbbf312dbbec4713a00c83fb0dd8520b6a52b082d7ff81e3523c40e:eaba68j5`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_7c84275ebcbbf312dbbec4713a00c83fb0dd8520b6a52b082d7ff81e3523c40e%3Aeaba68j5) · From the CLI: `sgit clone sgit_public_read_7c84275ebcbbf312dbbec4713a00c83fb0dd8520b6a52b082d7ff81e3523c40e:eaba68j5`
Submitted as a read key and published unchanged. No company is named anywhere in the vault, and none is implied, see the audit below.

The pack's own one-pager. Everything on it is also in the vault as data. The infographic is a rendering of `content.json`, not a separate document.

## See it live, here

[Open the vault in a new tab ↗](https://dev.vault.sgraph.ai/#sgit_public_read_7c84275ebcbbf312dbbec4713a00c83fb0dd8520b6a52b082d7ff81e3523c40e%3Aeaba68j5)The document viewer wants the room.

## The idea worth stealing: describe the category, not the company

Vault #29 had to be audited for whether an unnamed FTSE 250 client could be inferred from what was said about it. This pack removes the question. Its company route opens with the sentence *“this pack is written for a type of company rather than a named one”*, and then describes the type in six rows, what it does, who buys it, where the risk sits, what it already has, what it usually lacks, who governs it:

> “A venture-backed UK software company, post-Series A, somewhere between 40 and 100 people, whose product processes other people's most sensitive personal data.”

Everything after that *follows from the archetype*: third-party and sub-processor risk as the highest-value work, assurance as a revenue lever, data minimisation as a decision rather than a project. The pack says so itself: *“if the company you have in mind is different in any of these respects, the engagement below changes shape, and that conversation is a better first meeting than a pitch.”*

That is a better answer to the publication problem than redaction, and it generalises: **a document written for a class can be published; a document written for an instance has to be scrubbed.**

The company route leads with the archetype. Fourteen sections follow it, including *What it is not*, *Conflict* and *Tensions*.

## What changed from #29, precisely

|  | [#29, Interim](../interim-ciso-pack/index.md) | #30, Fractional |
|---|---|---|
| **The role** | Six months, near full-time, a dated regulatory deliverable | Two days a month, ongoing, a board advisory retainer |
| **The reader** | A specific FTSE 250 company, withheld | **An archetype**, described in six rows from public sources |
| **The company folder** | A strategy brief with a disclosed redaction | `company-archetype.md`, nothing to redact |
| **Documents** | Four, in four formats | **Five** in four formats, plus an infographic as PNG and PDF, plus the three 2019 decks rendered in the viewer |
| **New document** | none | *The engagement*: the monthly rhythm, a twelve-month map, and a section headed *What two days a month is not* |
| **Shared** | The generator, the CV facts, the thirteen recommendations, the three routes, the agentic team, and the deliberate absence of any rate or tax status |

The README states the relationship in one paragraph and ends it with the line that matters for both: *“Rates and tax status are deliberately absent from both.”*

## The section to read first is the one that says no

The engagement document's strongest passage is a list of what two days a month *is not*. Not cover, *“if something goes wrong at three in the morning, a fractional advisor is not the incident manager.”* Not a Data Protection Officer. Not delivery. Not an audit. And not a substitute for a full-time CISO once the company needs one, *“part of the job is saying when that point arrives.”*

The *Honest tensions* section goes further and names the economic one: a fractional CISO is cheaper than a permanent one, *“and that same economy can be used to defer a hire the company genuinely needs. Naming the trigger early is the only honest defence.”* A sales document that identifies how it could be misused against the buyer is rare enough to be worth pointing at.

Five documents, each as PDF, Word, Markdown and JSON; the infographic as PNG and PDF; and the 2019 decks now rendered in the viewer rather than only archived.

## The pre-publication audit

Run against a full clone with the published read key. The pack's own claim, *“no company is named anywhere in this pack … nothing here depends on inside knowledge, which is why it can be published”*: checked rather than accepted:

| Checked | Result |
|---|---|
| Company identification | **None, and none implied.** The reader is an archetype in six rows. The only company names in the vault are the candidate's past employers, from a public CV |
| Rates, fees, tax status | **Absent.***Retainer* appears as a word with no figure attached; the only monetary values are statutory penalty amounts |
| Contact details | One email address, the candidate's long-public OWASP one; the infographic adds public LinkedIn and GitHub handles. No phone, no address |
| Credentials and secrets | **None** |
| Named third parties | The same thirteen recommendations as #29, from the candidate's own 2019 CC BY-SA deck, labelled with their 2019 titles. Not reproduced on this page |
| Read key | Verified with an all-zeros negative control against the same vault id: real key 72 files, control an empty directory |

## Shape

| **Vault** | `eaba68j5` · 72 files · 19 MB |
|---|---|
| **App** | `index.html` with CSS, JS and a fallback copy of `content.json` inlined; PDF.js loaded through `sg.loadJs` inside a host, page images as the fallback |
| **Permissions** | `downloads: true`, and nothing else. No writes. The HUD hides the vault name and shows the app title |
| **Documents** | Six distinct: two CVs, the case, the recommendations, *the engagement*, and the infographic, 21 recruiter files across the formats, 18 pre-rendered page images |
| **Licence** | Content CC BY 4.0; the 2019 decks and recommendation slides CC BY-SA as originally published; PDF.js Apache-2.0 |

Published as row #30. Its sibling is [#29](../interim-ciso-pack/index.md); the two are worth reading as a pair, because they are the same machinery giving two different answers to *how do you publish a document about a job*. [← All published vaults](../index.md) · [The publishing method](../publishing.md)



==============================================================================
# An application for a job, as a vault, interim CISO pack

> A candidate pack delivered as an encrypted vault instead of a CV on an email: three routes for three readers, four documents each in PDF, Word, Markdown and JSON, a disclosed redaction, and a client named nowhere, with the pre-publication privacy audit stated in full.
>
> Page: https://sgit.ai/demos/vaults/interim-ciso-pack/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Interim CISO application pack

# An application for a job, as a vault

A candidate pack for an interim CISO role, delivered as an encrypted vault instead of a CV attached to an email. **Three routes through one artefact** (the recruiter, the hiring company, and anyone curious) over four documents that each exist as PDF, Word, Markdown *and* JSON. The claim it makes about how the candidate works is the same claim the artefact demonstrates by existing.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_699401f6cb3bdb1d6e19bfa690d8e0006a5379070ff320b5a8ae2fc21968f5c9:8brojsem`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_699401f6cb3bdb1d6e19bfa690d8e0006a5379070ff320b5a8ae2fc21968f5c9%3A8brojsem) · From the CLI: `sgit clone sgit_public_read_699401f6cb3bdb1d6e19bfa690d8e0006a5379070ff320b5a8ae2fc21968f5c9:8brojsem`
Submitted as a read key and published unchanged. **The hiring company is not named anywhere in the vault**: see the audit below.

## See it live, here

[Open the vault in a new tab ↗](https://dev.vault.sgraph.ai/#sgit_public_read_699401f6cb3bdb1d6e19bfa690d8e0006a5379070ff320b5a8ae2fc21968f5c9%3A8brojsem)The document viewer needs room, better in its own tab than in the frame.

One artefact, three declared readers, and a front page that tells you which one you are.

## The idea worth stealing: the pack is the evidence

Every candidate pack asserts something about how the candidate works. This one is constructed so that the assertion and the demonstration are the same object. Its own front page says it plainly:

> “This pack is itself an example of how he works: a voice memo became a brief, a team of AI agents researched and built the material, and it is delivered as an encrypted, versioned vault.”

A claim to work with agents, made in a document that agents built. A claim about handling sensitive material, made in an artefact whose server cannot read it. The reviewer does not have to believe the claim, the thing in their hands is the test of it.

## Three routes, because three people read a CV for different reasons

The interesting structural choice: rather than one document that compromises between audiences, the pack splits at the front door and lets each route stand alone.

| Route | For | What is behind it |
|---|---|---|
| **Recruiter** | The person putting the candidate forward | An embedded document viewer, four documents in four formats each, **a submission summary to copy**, key facts, and answers to screening questions, the things a recruiter has to paste into a form |
| **Company** | The hiring organisation | The mandate, the shape of the function, the regulatory calendar, a four-stage plan, a typical week, **what to settle before signing**, a conflict disclosure and a section titled *honest tensions* |
| **About** | Anyone | A skills map, a career timeline, thirteen recommendations, the agentic team and its rules, and how the pack was built |

A recruiter needs text to paste; a hiring manager needs an argument; a curious reader needs context. Those are genuinely different documents, and the vault holds all three without any of them being a compromise.

The company route runs to eleven sections, and two of them are *Before signing* and *Tensions*.

## Four formats, and the fourth is the interesting one

Each of the four documents (short CV, full CV, the one-page case, the recommendations) exists as **PDF, Word, Markdown and JSON**, generated from one source by the pack's own build.

PDF is for the human. Word is because recruiters still ask for it. Markdown is for whoever pastes it somewhere. **JSON is the one that matters**: a CV as structured data, so a machine reading the pack gets fields rather than a page it has to parse. It is the same instinct as this site's [`llms.txt`](../../../llms.txt), publish the thing, and publish it again in the shape a machine wants.

Page counts and byte sizes are computed at build time and recorded with SHA-256 hashes, so the sidebar cannot describe a file it did not produce.

## The build refuses what the authoring contract refuses

The pack's own pipeline fails if the page declares a vault resource with `<link href>`, `<script src>` or `<img src>`, uses `fetch()`, writes `location.hash`, references a missing file, or contains a JavaScript syntax error. That is [the vault authoring contract](../../../docs/vault/vault-apps.md) enforced by the artefact's own build rather than discovered after a push, and the last of those checks is the one that [caught a shipped bug on riskmandate.ai](../synthetic-users-riskmandate/index.md) the day before.

The viewer degrades honestly too: inside a vault host it loads PDF.js through `sg.loadJs` and reads bytes through `sg.vfs.read`, with `isEvalSupported: false`; where PDF.js cannot run, it falls back to page images rendered at build time. `app.json` asks for exactly one permission, `downloads`, so files save without a prompt each time, and the app never writes to the vault.

## What it refuses to do, which is the part to copy

- **It does not name the client.** The role is described as an interim CISO position at a FTSE 250 company and nothing further; one line in the strategy brief states outright that *“nothing here characterises the client, which is not named.”*
- **It discloses its own redaction rather than hiding it.** The strategy brief carries an editor's note saying which sections were removed for publication (the off-payroll analysis, pricing, and two contract items on status and rate) and that nothing else changed. The brief keeps its original date.
- **It states its limits inside the argument.** The same note records that this is not legal or tax advice, that several paragraph numbers could not be read at the primary source and are marked, that one tribunal outcome comes from commentary rather than the decision, and that no reported case was found on one question, *“reported as a gap rather than as comfort.”*
- **It includes a conflict disclosure and a section called *Tensions*** in the material written for the people deciding whether to hire.
- **The recommendations are dated and sourced.** Thirteen of them, each carrying its 2019 job title and relationship, attributed to the candidate's own 2019 deck (CC BY-SA), which ships in the vault's `archive/` so the source can be checked rather than taken on trust.

## The pre-publication audit

Run against a full clone with the published read key, before this page existed. The submitter's position was that the vault holds no sensitive data, does not identify the company, and reuses material that was already public. **Checked, and it holds**: with one point worth a reader knowing:

| Checked | Result |
|---|---|
| Client identification | **Not named.** Described only as FTSE 250, with regulatory applicability raised as open questions rather than answered |
| Day rates, IR35, pricing | **Absent.** The only monetary figures in the vault are statutory penalty amounts. The removal is disclosed in the brief itself |
| Contact details | **None**: no phone, no address. One email address, the candidate's own long-public OWASP one |
| Credentials and secrets | **None.** No keys, tokens or credential-shaped strings |
| Named third parties | **Thirteen**, in the recommendations, with their 2019 job titles and employers. Public twice over, LinkedIn recommendations, republished in the candidate's own CC BY-SA 2019 deck, which is in the vault. Labelled `title_2019` throughout, with the provenance stated |
| Read key | Verified with an all-zeros negative control against the same vault id: the real key produced 56 files, the control an empty directory |

This page quotes the candidate and the pack's own framing; it does not reproduce the individual recommendations, which stay where their provenance is stated.

## What to take from it

- **Split at the front door, not inside the document.** If three people read a thing for three reasons, three routes beat one compromise.
- **Ship the machine-readable copy beside the human one.** A CV as JSON costs one build step and changes what a machine can do with it.
- **Put the redaction note in the artefact.** A document that says what was removed is more trustworthy than one that reads as though nothing was.
- **Let the artefact be the proof of the claim it makes.** This is the most portable idea here and it is not about hiring.

## Shape

| **Vault** | `8brojsem` · 56 files · 17 MB |
|---|---|
| **App** | `index.html` with CSS, JS and a fallback copy of `content.json` inlined |
| **Permissions** | `downloads: true`, and nothing else. No writes |
| **Documents** | Four, each as PDF, Word, Markdown and JSON, with sizes and SHA-256 hashes recorded at build time |
| **Licence** | Content CC BY 4.0; the 2019 decks and recommendation slides CC BY-SA as originally published; PDF.js Apache-2.0 |

Published as row #29. [← All published vaults](../index.md) · [The publishing method](../publishing.md)



==============================================================================
# Synthetic users, second run, five people who do not exist, reading riskmandate.ai

> The synthetic-user method applied to a second product one day later: 30 screenshots, 12 findings, two blocking a sale, and a headline finding that is measured rather than narrated, plus a JavaScript error on every page that had shipped and that every existing test had passed over.
>
> Page: https://sgit.ai/demos/vaults/synthetic-users-riskmandate/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Synthetic users · riskmandate.ai

# Synthetic users, second run, five people who do not exist, reading riskmandate.ai

The same method as [vault #27](../synthetic-users/index.md), pointed at a different product one day later. That is the interesting part: one run is an anecdote, two sites is a method. And the second run produced a **different class of finding** than the first, it measured rather than narrated, and it caught a bug that every existing test had passed over.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_a41174009cf6f3019147040ef0c759b6c84c86ffa37eb54af06011c161a12332:o3q6zhtr`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/en-gb/#sgit_public_read_a41174009cf6f3019147040ef0c759b6c84c86ffa37eb54af06011c161a12332%3Ao3q6zhtr) · From the CLI: `sgit clone sgit_public_read_a41174009cf6f3019147040ef0c759b6c84c86ffa37eb54af06011c161a12332:o3q6zhtr`
Submitted as a read key and published as one. Nothing was derived, and no vault key was involved.

**Everybody in it is invented**, and the vault says so above the fold, as the first one did. The personas and their words are a language model's. What is evidence is what a browser produced: the screenshots, the URLs, the scroll positions, **the word counts**, and the JavaScript errors the first pass recorded, all captured by driving a real browser against the deployed bytes at `v1.20.1`.

## See it live, here

[Open the vault in a new tab ↗](https://dev.vault.sgraph.ai/en-gb/#sgit_public_read_a41174009cf6f3019147040ef0c759b6c84c86ffa37eb54af06011c161a12332%3Ao3q6zhtr)Same app as vault #27, same five-across rail.

Five runs, six steps each, 30 screenshots. Two of the five would have paid; neither could.

## What the second run did that the first did not

It would have been easy for this to be the same vault with different names in it. It is not, and the difference is worth naming:

|  | [#27, store.sgit.ai](../synthetic-users/index.md) | This one, riskmandate.ai |
|---|---|---|
| **What the findings are made of** | What a persona said, in their voice | **Counted things.** Words above the fold, character offsets, scroll positions in pixels and screens |
| **Shape of the headline** | A page missing a fact a buyer needed | A product **never named where it is sold** |
| **Runs** | 5 · 43 steps · 15 questions · 10 confusions | 5 · 30 steps · 11 questions · **12 confusions** |
| **Page errors** | Zero, on every run | **On every page visited**, and they had shipped |
| **Findings** | 18, three blocking | 12, two blocking |

More confusion from fewer steps is the number to look at. The first site lost people slowly; this one lost them on the first screen.

## The headline: the product is not named where it is sold

Above the fold, the home page says *policy* six times, *insure* three times and *underwriters* once, shows a price of **£5**, and never once says **Agent Behaviour Policy**, which is what it sells. The name first appears **58% of the way down the page**.

The consequence is not subtle. **Two of the five read “Buy one, from £5” as buying an insurance policy for five pounds.** The persona who held that reading longest was the insurance professional, the reader best equipped to recognise the vocabulary, and therefore the most confidently wrong:

> “So: insurable, insurance, underwriters, and a policy you can buy for five pounds. On my reading of those words, **this is a product that places cover**.”, Claire Buckley, step 1

She understood the product only on the third page. The founder resolved it by accident, from a button caption. The vault also notes that the hero card is captioned *“A REAL POLICY · TEMPLATE”* beside a headline about insurability, and is the one caption on the page with room to say the product's actual name.

The reader best equipped to recognise the words was the one the words misled furthest.

### We re-measured it, and the structural numbers reproduce exactly

A claim this specific is checkable, so it was checked, the live page fetched today, rendered at the same 1440×900, and measured independently of the vault:

| Claim | The vault | Re-measured |
|---|---|---|
| Page text length | 9,270 chars | **9,270**: exact |
| First “Agent Behaviour Policy” | char 5,387 · 58% down | **char 5,387 · 58%**: exact |
| Whole page height | 6,481px · 7.2 screens | **6,481px · 7.2 screens**: exact |
| “Agent Behaviour Policy” / “ABP” above the fold | 0 and 0 | **0 and 0** |
| *underwriters* above the fold | 1 | **1** |
| *policy* / *insur** above the fold | 6 and 3 | 7 and 5, **a counting-rule difference, not a discrepancy** |

The last row: our `insur*` pattern also catches *insurance*, where the vault counted *insurable / insure / insurability* specifically; the *policy* count differs by one at the fold boundary. Every structural number, the ones the argument rests on, matches to the character.

## The bug that every test had passed over

The single most useful thing in this vault is not a persona's opinion. The first pass recorded a JavaScript error on **every page it visited**: `Unexpected token '}'` on the home page, `Unexpected end of input` on the insurance page. Both had shipped. The insurance page had been broken **since it launched**.

> “Every existing test passed, because the HTML still rendered and only the console knew.”

It was fixed in the same session, and, the right response, **a test was added that parses every inline script on every page and fails the build if one does not**. A synthetic-user run justified by its qualitative output paid for itself on a defect that has nothing to do with users at all, because the method happens to require driving a real browser and recording what it throws.

## What it says worked, which is the harder half to write

Three things were named unprompted by more than one persona, and are the reason two of the five would buy:

- **Sourced quotes.** The connector-scope section quotes vendors' own documentation with dates, *“the first page I have read on this subject that quotes the publisher instead of paraphrasing them.”*
- **The admissions.** That levels 3 and 4 have never run for a paying buyer; that the payment rails are not built; that one rung is still a design. *“Nobody oversells and then volunteers that.”*
- **The card.** Four numbers on a real vault were the only thing on the first screen that made the engineer stay. **The card is doing the work the headline is not.**

Both blocked sales were blocked by something that is not a price: **no duration anywhere**, and **no way to pay**. One founder would have paid £500 from his phone; one buyer would have paid £1,500 the same day against a deal worth more than her runway. The site correctly says the rails are not built. The honesty is right, and the consequence is that the highest-intent reader in the study had nowhere to go but an email address.

Twelve findings, tagged by what they cost rather than by severity words, *closes a segment*, *loses a channel*, *costs reach*.

## One persona walked both sites

**Priya Raghavan**, a staff engineer who pays on her own card, appears in [vault #27](../synthetic-users/index.md) and in this one. She bought on the store; on riskmandate.ai she would buy level 1. A persona reused across products is what turns two separate studies into a comparison, and it costs nothing but the discipline of keeping the records in the same shape.

## Shape, and the audit

| **Vault** | `o3q6zhtr` · 53 files · 3.5 MB · 30 PNG screenshots |
|---|---|
| **Permissions** | `app.json` declares **none** |
| **Credential** | Submitted as a **read key** and published unchanged. Verified with an all-zeros negative control: the real key produced 53 files and a `clone_mode.json`; the control produced an empty directory |
| **Secrets** | None. No tokens, keys or credentials in the contents |
| **Screenshots here** | Taken by driving the vault's own app, served from the clone at 1440×1000 on a 2× display |

Published as row #28. The first application of this method is [vault #27](../synthetic-users/index.md); the product it reads is [riskmandate.ai ↗](https://riskmandate.ai/), which this site points at from [the Licence to Operate vault](../licence-to-operate/index.md). [← All published vaults](../index.md)



==============================================================================
# Synthetic users, five people who do not exist, shopping

> Five invented buyers walked through store.sgit.ai one screenshot at a time, asked what they made of each screen and interviewed at the end: 43 screenshots, 15 questions the site did not answer, 10 confusions and 18 findings, three of them costing a sale, four already fixed and kept rather than deleted.
>
> Page: https://sgit.ai/demos/vaults/synthetic-users/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Synthetic users

# Synthetic users, five people who do not exist, shopping

Five invented buyers were walked through [store.sgit.ai](../../../network/index.md) one screenshot at a time, asked what they made of each screen, and interviewed at the end. The vault holds all of it: **43 screenshots, 43 steps, 15 questions the site did not answer, 10 places somebody got lost, and 18 findings, three of them costing a sale.** It is the most useful vault published here that contains no real data at all.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_b70c317b7aa4b6084e05669795dc89e6bf1e46b4e948b9f6c475948ae502823c:g2hei4u6`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/en-gb/#sgit_public_read_b70c317b7aa4b6084e05669795dc89e6bf1e46b4e948b9f6c475948ae502823c%3Ag2hei4u6) · From the CLI: `sgit clone sgit_public_read_b70c317b7aa4b6084e05669795dc89e6bf1e46b4e948b9f6c475948ae502823c:g2hei4u6`
Derived one-way from a vault key that is not published and never will be.

**Everybody in it is invented, and the vault says so first.** The personas are fictional, the names are fictional, and every word attributed to them was written by a language model reading screenshots. The vault's own banner calls this out before you can scroll past it: **it is not user research**, and no sentence in it is evidence about a real person. What *is* evidence is the part a machine produced, the screenshots, the URLs, the step order, the viewport sizes and the page-error counts, captured by driving Chromium against the store's built bytes at `v0.1.12`, verified byte-identical to the live site by SHA-256.

## See it live, here

[Open the vault in a new tab ↗](https://dev.vault.sgraph.ai/en-gb/#sgit_public_read_b70c317b7aa4b6084e05669795dc89e6bf1e46b4e948b9f6c475948ae502823c%3Ag2hei4u6)A five-person rail with a run, an interview and a findings list behind each, roomier in its own tab than in the frame below.

Five people, five outcomes, and the disclosure above the fold rather than in a footnote.

## The idea worth stealing: hand the agent the screenshot, not the DOM

This is the whole method, and the vault states it in one sentence:

> “An agent that drives a store by reading the DOM finds the buy button every time, and therefore finds no confusion, which is the only thing worth running this for.”

So the loop is deliberately crippled. The agent gets **a screenshot**, the same thing a person would have, and has to work out what to do from it. Seven steps, run until the persona buys, leaves, or runs out of patience, and patience is a field on their record, not a judgement call made mid-run:

|  | Step | Why it is there |
|---|---|---|
| **1** | Observe | Screenshot at the persona's own window size. **Do not read the DOM.** Do not read the markdown twin unless this persona would |
| **2** | Say what you see | At the level of detail this persona would take in, *“a skimmer sees three things; a slow reader sees the caveat under the price”* |
| **3** | Think | What they are weighing, and what they are suspicious of. The vault calls this *“the part that is worth more than the click path”* |
| **4** | Record a question | Something the page raised and did not answer. Null when there is none. **These are the output** |
| **5** | Record confusion | Where the page lost them, or where they guessed. *“A run with no confusion anywhere is a run that was not done properly”* |
| **6** | Act | One action, with the reason given **in the persona's terms, not the site's** |
| **7** | Loop | Until bought, left, or out of patience |

The protocol is published *inside* the vault, which is what makes a second run in a month's time comparable rather than merely later.

## The five runs, and what each one cost

Every number below is computed from the run records, not from the summary:

| Persona | Outcome | Steps | Questions | Confusions | Viewport |
|---|---|---|---|---|---|
| **Priya Raghavan**: staff engineer, pays on her own card | **bought** | 10 | 3 | 2 | 1440×900 |
| **Tomás Beckett**: technical co-founder, £500 is his call alone | **stalled** | 10 | 5 | 4 | **390×844** |
| **Marguerite Okonjo**: fund partner | left, favourably | 8 | 2 | 1 | 1440×900 |
| **Dan Whitlock**: COO, signs to £10,000 | left | 7 | 4 | 3 | 1512×820 |
| **Ines Halvorsen**: security engineer, never the buyer | left, and sent it on | 8 | 1 | 0 | 1680×1050 |

**Read the viewport column.** The persona carrying the largest decision a single person makes alone on that site did the whole thing **on a phone**, and produced the most questions and the most confusion of anyone. That is not a finding the vault announces; it falls out of the table once the numbers are in one place.

Zero page errors across all five runs, which is worth stating because it means none of the confusion below was a bug in the store's code. It was the copy.

Every step pairs the image with four things: what they saw, what they thought, what they asked, what they did. The screenshot is the citation.

## What it found: 18 things, three of them costing a sale

The findings are ordered by what they cost rather than by who found them, and each one points at a page you can go and check. The three blockers:

1. **The £500 page carries no duration of any kind.** The buyer's single decisive question is *how long does this take*, and it was answerable nowhere before purchase. Earlier copy had carried a figure and it was lost in an edit three versions back. Found by the persona who left without buying and said so in the interview.
2. **The same page describes its own process two ways, and the post-sale page a third.** A buyer would have had to pay to find out which was true.
3. **The add-on built for a board has no price, no range and no next action**: on a page whose heading is exactly the question its buyer arrives with.
Grouped by cost, tagged by page, and attributed to the run that produced them.

**Four are already marked fixed**, in the store release that followed the runs, and they are kept, annotated, rather than deleted, on the stated grounds that *“a findings list that loses the fixed ones cannot be compared with the next set of runs.”* That is the same instinct as this site's own [version log](../../../admin/versions.md), applied to somebody else's bugs.

One fix is better than the finding asked for. The duration problem was not answered by inventing a number: the page now says that the time from a buyer's reply **has never run for a paying buyer, so there is no measurement to quote**: with a ledger row to match. A synthetic user asked for a figure and got a disclosure instead, which is the more honest answer and the harder one to write.

## Where it stops being a checklist

The interviews are the part that does not read like tooling output. The adversarial persona, a security engineer who reads vendor sites for sport and is *never* the buyer, was asked whether she believed it:

> “More than any vendor site I have read this year, and I read them for sport. The reason is narrow and specific: **three times I found the weak point and the site had already written it down, in stronger words than I would have used.**”

And the buyer who stalled, asked what made him believe it:

> “Two things did it: the ‘never sold once’ chip on the thing they want me to buy, and the deposit split I did not ask for. **Nobody invents either of those to sell harder.**”

Then, asked what he still did not know at the end: *“The date. I have a term sheet expected in six weeks and this site does not contain a single duration for the thing I would buy.”* The same gap as finding #1, in the voice of the person it cost.

The same questions for everyone, so the answers can be read down a column as well as across a run.

## What it refuses to claim

The thing that makes this publishable rather than embarrassing is how hard it works to be less than it appears:

- **The disclosure is above the fold and in the README's second heading** (*“Everybody in here is invented”*) not in a footnote a reader reaches after forming a view.
- **It separates the invented part from the captured part** explicitly: the narration is a model's; the screenshots, URLs, step order, viewports and error counts are a browser's.
- **It names the build it ran against** (`v0.1.12`), verified byte-identical to the live site by hash, and says why it ran against local bytes rather than the live host.
- **Three findings are recorded as claims that held** rather than defects, a checkout page with no form element and no off-origin request, an admin page absent from three indexes, and three pages that cost the seller sales and were kept anyway.
- **It ends on an open question** it does not answer: whether one world-readable page is a decision or an accident.

## What to take from it

- **Cripple the agent on purpose.** Give it the screenshot, not the DOM. Competence at finding the button is the thing standing between you and the finding.
- **Write the expected journey before the run.** The vault stores what each persona was *expected* to do beside what they did, so a surprise is visible as a difference rather than only as a result.
- **Make “where did you guess” a required field.** A run with no confusion is treated as a run done badly, not a site that passed.
- **Keep the fixed findings.** Deleting them destroys the comparison the next run exists to make.
- **Put the protocol in the artefact.** Two runs a month apart are only comparable if the loop is written down where both can see it.

## Shape

| **Vault** | `g2hei4u6` · 67 files · 6.4 MB · 43 PNG screenshots |
|---|---|
| **App** | `index.html` with CSS, JS and a fallback copy of the data inlined, so it renders outside a vault host too, which is how the screenshots on this page were taken |
| **Permissions** | `app.json` declares **none**: no filesystem, no network, no LLM. It reads its own bundle and draws |
| **Data** | `personas`, `journeys` (written before the runs), `protocol`, `runs`, and `bundle.json`, the concatenation the app actually reads |
| **Tools** | `runner.mjs` drives the browser, `narrate.py` adds the persona layer, `bundle.py` rebuilds the app's data |

## The pre-publication audit

Run with the read key printed above, against a full clone, before this page existed:

- **The credential submitted was a vault key, not a read key.** It was classified before it touched anything, the read key was derived one-way from it, and **only the derived read key appears here**. The vault key is not on this site and will not be.
- **The derivation was verified with a negative control.** The derived key produced 67 files and a `clone_mode.json`; an all-zeros key against the same vault id produced an empty directory. [That control exists because we once called a leak on a directory an invalid key created identically.](../publishing.md)
- **Nothing secret-shaped in the contents.** The one credential-looking string, `SYNTH4DELTA`, is a discount code **the store publishes itself**; the vault says so, and says the store's build fails if a published hundred-per-cent code and a live payment rail ever coexist.
- **Every screenshot on this page was taken by driving the vault's own app**, served locally from the clone, at 1440×1000 on a 2× display.

Published as row #27 on the [vaults table](../index.md). The store it examines is [store.sgit.ai](../../../network/index.md); the method is the one on [publishing a vault](../publishing.md). [← All published vaults](../index.md)



==============================================================================
# The sgit.ai board, a published vault

> The site's own task board, moved into a vault: every card a markdown file, a five-column board app that requests no permissions, and a published read key, because every task, bug and need on it is public. The site renders a snapshot at each release; the vault is the truth between them.
>
> Page: https://sgit.ai/demos/vaults/board/index.html

[Home](../../../index.md) / [Vaults](../index.md) / The sgit.ai board

# The site's own board, as a vault

Two days after [the board](../../../team/board.md) appeared as files in the site repository, it moved out into a vault of its own. Every card is a markdown file; a five-column board app renders them and asks the host for nothing; and the read key is published, because every task, bug and need on it is public. The vault is the source of truth (**moving a card is `sgit push`, with no site release**) and the site renders a snapshot from a clone each time it ships.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_f41d03b0de550479b3c4359709130386df48f34b2cd75e5ed83de28e9776b479:pdulwi6i`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_f41d03b0de550479b3c4359709130386df48f34b2cd75e5ed83de28e9776b479%3Apdulwi6i) · From the CLI: `sgit clone sgit_public_read_f41d03b0de550479b3c4359709130386df48f34b2cd75e5ed83de28e9776b479:pdulwi6i`
Published as a read key, derived from the vault key at creation. The vault key is held by the site's release engineer and is not published.

## See it live, here

[Open the board in a new tab ↗](https://dev.vault.sgraph.ai/#sgit_public_read_f41d03b0de550479b3c4359709130386df48f34b2cd75e5ed83de28e9776b479%3Apdulwi6i)Five columns wide. It has more room in its own tab than in the frame below.

## Why a vault, and not the repository

The cards started as files in the site repository, which was already the right shape, issues-fs.sgit.ai's argument that a tracker should be files that version with the thing they track. But it tied every board change to a site release: to move a card from *review* to *done*, an agent had to build, validate, push two remotes and wait for the deploy to verify. A board should be cheaper to update than the thing it tracks.

So the files moved into a vault. Now the site is a **reader** of the board rather than its home: the release script pulls the vault before it builds, and the columns on [the board page](../../../team/board.md) are a snapshot as of that release, labelled as such. Between releases, the vault is ahead of the site, and opening it shows the truth.

## What is in it

the app

### Five columns, from the files, asking for nothing

`index.html` lists `issues/` through `sg.vfs`, parses each card's frontmatter, and draws the columns. `app.json` declares `"permissions": {}`. The app reads the vault it is in and touches nothing else. Served outside a vault host, it falls back to `issues/index.json`, which `tools/reindex.py` regenerates from the same files.

Needs, the things only the author can supply, keep their own column and their own colour, so they are never discovered late.

The app, rendered from the files. Moving a card is editing one line and pushing.

## The card format

```
---
title: The ask: round size, instrument, and what it buys
id: N1
kind: need          # need = only the author can supply it · task = an agent can pick it up
status: needs       # needs | backlog | doing | review | done
role: ambassador    # the sgit.ai team role that owns it
priority: high
opened: 2026-09-07
---
What it is, and what it unblocks.
```

Ids are `N<n>` for needs and `T<n>` for tasks, never reused. A card that names a need is closed only by the author's answer. Corrections to published claims are not cards: they are version-log entries on the site, so the record of a mistake is never tidied away.

## Notes

**Audited before publishing**, briefly, because there is nothing to find: the vault holds card text, a README, one app and one tool. No credentials of any kind, no personal data. Every link in a card is root-relative to sgit.ai and resolves.

**The write key is escrowed** in the site's gitignored credential tier, the same place every other published vault's write key lives, so the board can be corrected by the release engineer and by nobody who holds only the read key.

**The site's clone is a mirror, not a fork.** `admin/content/team/issues/` in the site repository is this vault's working tree; its encrypted store is gitignored, its card files are tracked as the build's input. If the two ever disagree, the vault is right.

[← The board, as the site renders it](../../../team/board.md) · [All published vaults](../index.md)



==============================================================================
# Field Notes, a published vault

> The minimum viable published vault: six studies with generative SVG art as a self-contained vault app, read over the sg.vfs bridge, opened by a single published read key.
>
> Page: https://sgit.ai/demos/vaults/field-notes/index.html

[Home](../../../index.md) / [Vaults](../../../index.md) / Field Notes

# Field Notes

Six small studies, a note and a generative SVG drawing each, served as a self-contained vault app.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_2848993a68c02a33ea5582902c391901191e53680d35b36c0e76185d4107ad81:4bshby5n`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_2848993a68c02a33ea5582902c391901191e53680d35b36c0e76185d4107ad81%3A4bshby5n) · From the CLI: `sgit clone sgit_public_read_2848993a68c02a33ea5582902c391901191e53680d35b36c0e76185d4107ad81:4bshby5n`
Published deliberately. It grants read, and only read, a write attempt is refused by the server’s write gate (the **R1 W0** badge you will see in the chrome).

## See it live, here

## What this vault demonstrates

| Feature | How this vault uses it |
|---|---|
| Vault app (`app.json`) | one self-contained `index.html`, auto-opened; CSS and JS inlined per the authoring contract |
| `sg.vfs` bridge | the app reads `content.json` over the bridge at runtime: the status line in the app proves it |
| Generative SVG | the six drawings are code, not images: no binary assets to fetch |
| Published read key | the first vault created specifically to be published; the complete walkthrough is on [the embed demo page](../../vault-app-embed.md) |

## What this shape is for

The minimum viable published vault: content plus a small app, one key, no server that can read any of it. Use this shape for anything you would put on a small static site, except the host serves only ciphertext, and unpublishing is deleting one credential from a page rather than tearing down a site.

## Derived facts

4 files · 11 KB · 2 commits · app entry `index.html` · derived from the read key alone by `admin/build/catalogue_derive.py`, the same derivation that populates [the catalogue](../../../catalogue/index.md), where this vault also has an entry.



==============================================================================
# Strategy Maps (a published vault)

> The SG/Send strategy in seven Wardley maps plus the sgit positioning analysis) two app entry points in one encrypted vault, published after the audit that made a republish necessary.
>
> Page: https://sgit.ai/demos/vaults/strategy-maps/index.html

[Home](../../../index.md) / [Vaults](../../../index.md) / Strategy Maps

# Strategy Maps

The SG/Send strategy in seven Wardley maps, plus the sgit positioning analysis as a second app in the same encrypted store.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_451c4c1e28fbb24a7f350bb3f107b2c103d69ed363167029ef9c9000ff76c07b:ookq4mn4`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_451c4c1e28fbb24a7f350bb3f107b2c103d69ed363167029ef9c9000ff76c07b%3Aookq4mn4) · From the CLI: `sgit clone sgit_public_read_451c4c1e28fbb24a7f350bb3f107b2c103d69ed363167029ef9c9000ff76c07b:ookq4mn4`
Published deliberately. It grants read, and only read, a write attempt is refused by the server’s write gate (the **R1 W0** badge you will see in the chrome).

## See it live, here

## What this vault demonstrates

| Feature | How this vault uses it |
|---|---|
| Two app entry points | `index.html` (the strategy essay, eight Wardley map PNGs) and `sgit-maps.html` (six inline-SVG maps), one encrypted store, two front doors |
| Vault-path images | the essay’s PNGs travel as ciphertext and are swapped in as `blob:` URLs after decryption |
| Republish pattern | this vault is a sanitised republish: the original could not publish its key because a write credential was inside its content, [the audit is public](../../strategy-maps.md) |
| Cross-app links | the two apps link to each other and the links survive embedding |

## What this shape is for

Published analysis with real assets: strategy documents, briefs, decks. The two-entry-point trick means one vault can carry a family of related documents that share content, history and a single published key.

## Derived facts

33 files · 830 KB · 3 commits · app entries `index.html` and `sgit-maps.html` · derived from the read key alone by `admin/build/catalogue_derive.py`, the same derivation that populates [the catalogue](../../../catalogue/index.md), where this vault also has an entry.



==============================================================================
# Deploy Docs, a published vault

> The living deployment documentation for sgit.ai: markdown written by two Claude Code sessions, rendered live in the visitor’s browser, updated by an sgit push with no site deploy.
>
> Page: https://sgit.ai/demos/vaults/deploy-docs/index.html

[Home](../../../index.md) / [Vaults](../../../index.md) / Deploy Docs

# Deploy Docs

The living deployment documentation for sgit.ai itself, written by two Claude Code sessions, rendered live on the /deploy page.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_8d01421290efc3fa03205eced0534335a06ae209d627555b3dde136b878e3de1:fyofmkvr`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_8d01421290efc3fa03205eced0534335a06ae209d627555b3dde136b878e3de1%3Afyofmkvr) · From the CLI: `sgit clone sgit_public_read_8d01421290efc3fa03205eced0534335a06ae209d627555b3dde136b878e3de1:fyofmkvr`
Published deliberately. It grants read, and only read, a write attempt is refused by the server’s write gate (the **R1 W0** badge you will see in the chrome).

## See it live, here

## What this vault demonstrates

| Feature | How this vault uses it |
|---|---|
| Live markdown rendering | [the /deploy page](../../../deploy/index.md) decrypts and renders this vault in the visitor’s browser, a push here updates that page with no site deploy |
| Freshness window | the mutable HEAD pointer is checked at most once per 120 s; everything else is content-addressed and cached forever |
| Two writers | written by two Claude Code sessions collaborating through the vault, the commit history shows the handoffs |
| Debug panel | the page’s vault panel shows every encrypted object arriving and what it decrypts to |

## What this shape is for

Documentation that updates without a deploy pipeline, from any writer who holds the vault key, to any reader who holds the read key. The natural shape for runbooks, guides and anything agents co-author.

## Derived facts

17 files · 25 KB · 2 commits · markdown, no app · derived from the read key alone by `admin/build/catalogue_derive.py`, the same derivation that populates [the catalogue](../../../catalogue/index.md), where this vault also has an entry.



==============================================================================
# The Vault Catalogue (a published vault)

> The index of published vaults, itself a vault, listed in itself) a submission queue where an entry costs a read key and one line, with published to-do lists and first-class write-key status.
>
> Page: https://sgit.ai/demos/vaults/catalogue/index.html

[Home](../../../index.md) / [Vaults](../../../index.md) / The Vault Catalogue

# The Vault Catalogue

The index of published vaults, itself a vault, published with a read key, and listed in itself.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_fd71e4bde7232498e43a5da869b1501260d9d403031b20af87b5bc801bdf6280:kc67yhgw`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_fd71e4bde7232498e43a5da869b1501260d9d403031b20af87b5bc801bdf6280%3Akc67yhgw) · From the CLI: `sgit clone sgit_public_read_fd71e4bde7232498e43a5da869b1501260d9d403031b20af87b5bc801bdf6280:kc67yhgw`
Published deliberately. It grants read, and only read, a write attempt is refused by the server’s write gate (the **R1 W0** badge you will see in the chrome).

## See it live, here

## What this vault demonstrates

| Feature | How this vault uses it |
|---|---|
| Recursion, usefully | an index of published vaults that is itself a published vault, listed in itself, [rendered live at /catalogue/](../../../catalogue/index.md) |
| Submission queue | an entry costs a read key and one line; everything else is derived by an agent opening the vault |
| Published to-do lists | `todo/awaiting-read-key.md` and `todo/awaiting-processing.md` are public, because a named gap gets filled |
| First-class write-key status | every entry records whether the write key is escrowed or lost, because a frozen vault can never be corrected |

## What this shape is for

Machine-and-human-readable registries that update by pushing to a vault rather than deploying a site. The schema here is deliberately the first instance of what a vault hub would need.

## Derived facts

9 files · 11 KB · 2 commits · markdown, no app · derived from the read key alone by `admin/build/catalogue_derive.py`, the same derivation that populates [the catalogue](../../../catalogue/index.md), where this vault also has an entry.



==============================================================================
# Supplement Stack, a published vault

> A patient-held health record as a vault: a real supplement regimen, label photographs every extracted value is traceable to, deterministic totals against UK RNIs and EFSA upper limits, and an adherence log the app may write to and nothing else. Shared with a professional by handing over a read key.
>
> Page: https://sgit.ai/demos/vaults/supplement-stack/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Supplement Stack

# Supplement Stack

A patient-held health record as a vault: a real supplement regimen, a photograph of every label the numbers were read from, deterministic totals against UK reference values, and an app permitted to write to exactly one folder and nothing else.

**The idea it is built on, in one line.** Every label describes one product; **nothing describes the sum**. The missing artefact is the total per nutrient across everything a person is taking, so the model extracts (fuzzy, and traceable to a label photo), the code adds up (deterministic, and reproducible), and the output is a briefing for somebody qualified. **Never a verdict.** This is a record-keeping tool, not medical advice, and no compliance finding of any kind exists for this pattern.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_047186b559528058c66d1792b7345639b1238cb95c166d1d5f5b65c59813c2ee:r7zes477`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_047186b559528058c66d1792b7345639b1238cb95c166d1d5f5b65c59813c2ee%3Ar7zes477) · From the CLI: `sgit clone sgit_public_read_047186b559528058c66d1792b7345639b1238cb95c166d1d5f5b65c59813c2ee:r7zes477`
Published deliberately. It grants read, and only read, a write attempt is refused by the server's write gate.

## See it live, here

Both surfaces open automatically below. You can also [**open the app in its own window ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_047186b559528058c66d1792b7345639b1238cb95c166d1d5f5b65c59813c2ee%3Ar7zes477).

## What this vault demonstrates

| Feature | How this vault uses it |
|---|---|
| **Scoped write permission** | `app.json` grants the app `read` over everything but `write` and `mkdir` over `adherence/`*only*. The app that records what you took each day cannot touch the regimen, the label photographs or the references, least authority, declared in the vault and enforced by the host |
| Source-mapped extraction | every amount in `regimen.json` carries a `label_image` pointing at the photograph it was read from, so a misread is *visible* rather than propagated, the same discipline a diff gives code |
| Deterministic analysis | `scripts/totals.py` sums per nutrient with its rules stated in the open: topicals contribute nothing, as-needed items sit outside daily totals, and a null amount is **flagged, never guessed**. The in-app JavaScript does the same arithmetic, so two implementations can be checked against each other |
| Named, dated reference data | UK RNIs and EFSA upper limits, with sources and a transcription note, explicitly *not* US Daily Values, because comparing a UK intake to US references without saying so would be a quiet error |
| Honest incompleteness | one product's 27-nutrient panel is not yet captured, so the app labels the totals **INCOMPLETE** rather than showing a confident wrong number |
| The brief ships with the vault | `briefs/` carries the architecture brief the whole thing was built from, the reasoning travels with the artefact |

## What is going on here, step by step

The embeds above are the real vault, which makes it easy to scroll past the parts that matter. Each row points at one of them. Every screenshot is of this vault, driven by a script holding nothing but the published read key.

the daily record

### What was actually taken, not what was intended

The **Today** tab is a checklist of the day's regimen, grouped by timing. Ticking an item and pressing **Save today** writes one small JSON file, `adherence/2026-08-16.json`, into the vault.

That distinction is the point: a regimen file says what you *mean* to take; the adherence log says what you *did*. When the conversation with a professional finally happens, the second is the honest input.

The Today tab: per-item, per-timing, with a Save that writes into the vault.

traceable extraction

### Every number points back at the photograph it came from

The **Stack** tab lists each product with its dose, timing, route, and the label photograph the amounts were read from. A model did that reading, which is a fuzzy step, so each value carries a `label_image` back to its source.

This is the source-map discipline applied to health data: a misreading stays *visible* and checkable against the picture, instead of quietly becoming a number in a total.

The Stack: products, doses and the label photograph behind each set of numbers.

the missing artefact

### The sum nobody else computes

This is the tab the whole vault exists for. Every label describes one product; **nothing describes the sum**. Here it is: total per nutrient per day, each against the UK RNI and the EFSA upper limit, with the contributing products named.

Two details matter more than the numbers. The reference set is *named and dated* (UK RNI + EFSA UL, deliberately not US Daily Values, for a regimen bought in the UK). And the amber banner says the totals are **incomplete**, listing exactly which amounts have not been captured: *"Nothing is guessed: a value that is not on a captured label is flagged, never estimated."*

Totals per nutrient with ×RNI and ×UL ratios, and an honest incompleteness banner.

never a verdict

### The output is a briefing, not a diagnosis

The **Briefing** tab assembles everything into something to hand to a pharmacist or GP: the stack, the totals, the overlaps, the open questions, *"Three products target the knee, is that a sensible combination or redundant?"*, *"Do any of these interact with my other medication?"*

The tool deliberately stops there. It does the arithmetic nobody had done and hands the result to somebody qualified. It never answers the questions itself, and the vault says so on its own About tab.

The Briefing: what to take to a professional, including the questions to ask.

least authority

### The app may write to one folder, and nothing else

Here is the vault's own `app.json`, read straight out of the store. The permission block grants `read` broadly but `write` and `mkdir` over `adherence/` *only*.

So the app that ticks off today's doses cannot alter the regimen, the label photographs, or the reference values, not by policy, but because the capability was never granted. This is what permissions look like when they are a property of the vault rather than a setting on a server, and it is the healthcare-shaped version of the whole argument.

app.json: read broadly, write only adherence/) least authority, declared in the vault.

## Why this shape matters beyond supplements

This is the clearest **patient-held record** on the site. The data lives in a vault the person controls; sharing it with a professional is handing over a read key, not granting an account on someone's platform, and not emailing a PDF that is copied forever the moment it arrives. The write key never leaves the owner, so a reader can read *everything* and change *nothing*.

The division of labour is the transferable part: **a model does the fuzzy work** (reading amounts off a photograph), **code does the exact work** (adding them up), and every fuzzy step is traceable to its source so a human can check it. Any domain where an LLM reads documents and arithmetic must be right (expenses, lab results, invoices, dosing) can borrow that shape. See the [healthcare use case](../../../use-cases/health-regulated.md) for where this fits.

## The audit, honestly

Every vault is audited before its read key appears here. This one is **clean on credentials**: no tokens, no keys, no `.vault/` operational bookkeeping, and the scan for personal identifiers found none either (no name, address, contact details, date of birth or health-service number; the record describes its owner only as "UK-based adult male").

What it *does* publish is a real person's actual supplement regimen, and the health context that can be inferred from it, a knee, sport, sleep. That is the owner's own data, published on purpose, and it is worth stating the rule that goes with it: **revocation is not retroactive**. Anybody who fetches these objects keeps them. Rotating the key protects future commits and returns nothing already read. The regimen is published because a real record demonstrates the pattern in a way a fabricated one cannot, and because the alternative, a sanitised sample, is exactly the thing this vault argues against.

## Derived facts

23 files · 2.3 MB · 5 commits · app entry `index.html` · twelve label photographs, derived from the read key alone by `admin/build/catalogue_derive.py`, the same derivation that populates [the catalogue](../../../catalogue/index.md).



==============================================================================
# Risk Mandate, a published vault

> A working application built and delivered as a vault: 124 files, 98 commits, eight entry points, pinned releases, offline capable, and it calls an LLM without ever holding the API key, which is sealed under the vault key.
>
> Page: https://sgit.ai/demos/vaults/risk-mandate/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Risk Mandate

# Risk Mandate

A field demo built to be handed to a stranger on an iPad, and, underneath it, the most complete software project published here: 124 files, 98 commits, eight entry points, a test suite, build tooling and pinned releases, all inside one encrypted vault.

**Why this one matters.** It answers the question the other demos leave open: *can you actually build something real in a vault?* This is a working application with a release history, developed in the vault, delivered by the vault, and running offline once cached. It also does the thing that is hardest to do safely, **it uses an LLM without ever holding the API key**.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_a702fba803faac4369eb5d5a320b4dfa017af62bd2425fb298aac4b99e95c0ae:4zf6pf2z`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_a702fba803faac4369eb5d5a320b4dfa017af62bd2425fb298aac4b99e95c0ae%3A4zf6pf2z) · From the CLI: `sgit clone sgit_public_read_a702fba803faac4369eb5d5a320b4dfa017af62bd2425fb298aac4b99e95c0ae:4zf6pf2z`
Published deliberately, and **derived**: this read key is a one-way derivation of the vault key, which stays with its owner. It grants read, and only read.

## See it live, here

Both surfaces open automatically below. You can also [**open the app in its own window ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_a702fba803faac4369eb5d5a320b4dfa017af62bd2425fb298aac4b99e95c0ae%3A4zf6pf2z). It is more fun full size.

## What is going on here, step by step

Three things this vault does that the others do not. Every screenshot is of this vault, driven by a script holding nothing but the published read key.

the app

### A real application, delivered as a vault

This is **Risk Mandate**, a field demo built to be handed to someone on an iPad: pick a scenario, answer eight questions, and a risk register assembles beside you, readable as an operator, a CISO or a board.

It is one `index.html` with everything inlined, and it opens straight from the vault. Note the chrome: a **release selector** ("Live (latest)"), a sealed-secret badge, and **Read-only**: you are looking at a published build, not a preview.

The line under the button is the part worth reading twice: *"Nothing leaves this device."* On the stand it runs with the network off, one cached load, then flight mode all day.

The app as it opens from the published read key: scenarios, presets, and a version chip.

the privilege claim

### It uses an LLM. It never holds the API key.

The whole argument of this vault is in its `app.json`. It grants the app `llm: chat, models, usage, listen`, and `fs.write` over `field/workspace/` and nothing else.

What is *not* granted is the credential. `.vault/llm/config.json` carries `keySealed: {iv, ct}`, the OpenRouter key encrypted under the vault key. The host decrypts it and makes the outbound call; the frame is handed a result, never a secret. Opening this vault with the published read key, that field is ciphertext we cannot decrypt, which is the point, and we checked.

In the [privilege vocabulary](../../../compare/index.md): the app gets `ops:llm-chat` without ever getting `bearer` of the key. That distinction is usually impossible to express, let alone enforce.

app.json: LLM use granted, the key withheld, and write scoped to one folder.

version control, seriously

### Ninety-eight commits, and releases pinned to them

This is not a document that happens to live in a vault. It is a software project developed in one. **98 commits**, a test suite, build tooling, and `.vault/releases.json` pinning named releases (`v0.15.5`, `v0.10.3`, `v0.7.7`…) to specific commit ids, which is what the release selector in the app chrome is reading.

Its build script is the detail we enjoyed most: `tools/build.mjs` fails the build on any declarative external reference *and* on any credential-shaped string. They arrived at the same tripwire this site runs on its own releases, independently, for the same reason.

The SGit view: 98 commits of a real project, read with a published read key.

## What this vault demonstrates

| Feature | How this vault uses it |
|---|---|
| **AI without the credential** | Sealed OpenRouter key in `.vault/llm/config.json`; the host decrypts and calls, the app frame receives results only. Read-key holders, including us, see ciphertext in that field |
| **Scoped permissions, two kinds** | `llm` capabilities enumerated (chat, models, usage, listen) and `fs.write` limited to `field/workspace/` |
| Eight entry points | `index.html`, plus a board, a takeaway page, talking points, a build-history page and three proofs-of-concept, one vault, many front doors |
| Pinned releases | `.vault/releases.json` maps names to commit ids; the app chrome offers them as a live selector |
| Offline by design | One cached load, then it runs with the network off, the demo survives conference wifi |
| A build that enforces the contract | `tools/build.mjs` exits non-zero on declarative external references *and* on credential-shaped strings, their own version of this site's release tripwire |
| Shareable results without a server | `takeaway.html` rebuilds a saved register from the link alone |

## The audit, honestly

Audited independently before this key was published, across all 124 files. **Clean:** no credentials, no personal data, and the vault's own key does not appear in its content, the failure that forced a republish in [an earlier case](../strategy-maps/index.md).

Two findings worth publishing because they are the *good* kind. The OpenRouter credential is present but **sealed**: encrypted under the vault key, so a read-key holder gets ciphertext. And the one match our secret scanner produced was `sk-test-abcdefghijklmnop` in `tests/suites/40-llm.mjs`, a deliberately fake key in a test that asserts a reachable API key *is caught*. A scanner hit that turns out to be a security test is a good sign about a codebase.

As always: revocation is not retroactive. Anyone who fetches these objects keeps them.

## Derived facts

124 files · 1.9 MB · 98 commits · eight app entries · last updated 2026-08-06, derived from the read key alone by `admin/build/catalogue_derive.py`, the same derivation that populates [the catalogue](../../../catalogue/index.md).



==============================================================================
# Agentic Browser Isolation, a published vault

> A living risk graph for whether an AI agent browses with your logged-in sessions or an isolated identity: seventeen entry points, a page per stakeholder altitude, acceptance-gated escalation, cited evidence, and an app that requests no write capability at all.
>
> Page: https://sgit.ai/demos/vaults/agentic-browser-isolation/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Agentic Browser Isolation

# Agentic Browser Isolation

A living risk graph for one narrow, consequential question: when an AI agent browses and acts on the web, does it run **inside your browser with your logged-in sessions**, or inside an isolated browser with a scoped identity of its own?

**Why this one is here.** It is the site's own argument, made by somebody else and in far more detail: this is the ambient-authority problem the [serialised change proposal](../../../use-cases/serialised-pull-request.md) and the [agent use case](../../../use-cases/ai-agents.md) circle around, an agent borrowing a human's whole session because that is the only credential on offer. Here it is a register with owners, evidence and an escalation mechanism, and it is vendor-neutral: any isolation product is an *instance of* the control, and its own self-created risks go on the register like everything else.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_92cad4cea8f58c55f59b686c71c935225a1ba7c41ecb6922a8aa570467604f6e:0610gsp9`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_92cad4cea8f58c55f59b686c71c935225a1ba7c41ecb6922a8aa570467604f6e%3A0610gsp9) · From the CLI: `sgit clone sgit_public_read_92cad4cea8f58c55f59b686c71c935225a1ba7c41ecb6922a8aa570467604f6e:0610gsp9`
Published 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 ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_92cad4cea8f58c55f59b686c71c935225a1ba7c41ecb6922a8aa570467604f6e%3A0610gsp9), with ten pages to walk, it is worth the room.

## What is going on here, step by step

Four things worth stopping on. Every screenshot is of this vault, driven by a script holding nothing but the published read key.

ten front doors

### One vault, seventeen entry points

The app opens on **Facts** and carries a numbered spine across the top: your reality, the two designs, the chain, how it unfolds, stakeholders, an explorer, two graph views and the raw data. Seventeen HTML entry points in one vault, each a real page.

The evidence is cited outward, too, the facts link to Brave's prompt-injection write-up, an arXiv paper on credential exposure, independent testing. A risk register that names its sources is one you can argue with.

The app on open: a ten-step spine, and the decision stated at the top.

the mechanism

### The same exposure, in seven languages

This is the idea worth stealing. Every altitude has **one named owner** (L1 IT, L2 CISO, L3 DPO/CFO/COO, L4 CEO, L5 Board) and each owns the risk *in their own language*.

A risk is never assigned automatically. It sits **pending** until that owner accepts it personally, and *only an accepted risk escalates to the altitude above*. Look at the counts in the picture: IT has 5 risks pending; everyone above is `waiting`, with nothing yet arrived, because nothing has been passed up. There is **no deny button**: accept, mitigate, or ask for more data.

Seven stakeholder altitudes, each with its own pending/accepted counts.

a graph, not a document

### The register is data, and you can see it as one

Seventy JSON files hold the register (risks, controls, evidence, owners, acceptances) and the app offers them as an explorer, a rendered graph, and a queryable graph database, with RDF tooling vendored into the vault so none of it needs the network.

That is the shape argument for vaults holding structured analysis rather than prose: the same encrypted objects serve a narrative page, a stakeholder view and a graph query, because the underlying thing is data.

The graph view, rendered in the browser from the vault\u2019s own JSON.

read-only by declaration

### An app that asks for nothing

Its `app.json` declares `fs.read: true` and `fs.write: []`, an **empty** write list. Compare the [Supplement Stack](../supplement-stack/index.md), which writes to one folder, and [Risk Mandate](../risk-mandate/index.md), which uses an LLM without holding its key.

Three vaults, three points on the same scale, each declared in the vault rather than configured on a server. The footer states the consequence plainly: *your changes are device-local; the vault baseline is never modified*.

app.json: read true, write []) the app requests no write capability at all.

## What this vault demonstrates

| Feature | How this vault uses it |
|---|---|
| **Seventeen entry points** | The most in the catalogue: a narrative spine, a page per stakeholder altitude, an explorer, two graph views and the raw data, one encrypted store, many front doors |
| **Zero write capability** | `fs.write: []`. The app reads and renders; edits stay device-local and the vault baseline is untouched |
| Structured analysis, not prose | ~70 JSON files hold risks, controls, evidence and acceptances; the pages are views over that data |
| Graph tooling inside the vault | RDF libraries vendored in, so the explorer and graph database work with no network and no CDN, the authoring contract making offline the default |
| Cited evidence | Facts link out to primary sources; the register can be checked rather than believed |
| A mechanism, not a spreadsheet | Acceptance-gated escalation with named owners and no deny button, the part most worth copying |

## The audit, honestly

Audited across all 104 files before the key was published. **Clean:** no credentials, no personal data, no operational bookkeeping, and the vault's own key does not appear in its content.

The scan produced six hits and all six were false positives, digit runs like `0123456789` inside a minified RDF library, matching a phone-number pattern. Worth recording because it is what a real audit looks like: the interesting output of a secret scanner is usually the part you have to rule out by reading it.

As always: revocation is not retroactive. Anyone who fetches these objects keeps them.

## Derived facts

104 files · 2.4 MB · 4 commits · seventeen app entries · last updated 2026-07-18, derived from the read key alone by `admin/build/catalogue_derive.py`, the same derivation that populates [the catalogue](../../../catalogue/index.md).



==============================================================================
# Risk Graph Explorer, a published vault

> A fact-to-risk graph explorer extracted into its own vault and designed to be public: its PUBLIC.md states three rules its build enforces, including no metered capability behind a published read key, and its app.json requests no permissions at all.
>
> Page: https://sgit.ai/demos/vaults/risk-graph-explorer/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Risk Graph Explorer

# Risk Graph Explorer

The graph explorer from [the risk-mandate work](../agentic-browser-isolation/index.md), 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.

**Answer the questions; the register assembles.** Seven views recompute as you go, including acceptance (who holds what) and what happens next (how decisions become incidents and projects). Nothing you answer leaves the page: no network call, no storage, no account. It is destined for riskmandate.ai, and the vault is how it will be served.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_1c1b95f5903e35850a9bc0541ffa09c6b5d4017cbf18817d2ad6f894127e5638:3simlnqe`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_1c1b95f5903e35850a9bc0541ffa09c6b5d4017cbf18817d2ad6f894127e5638%3A3simlnqe) · From the CLI: `sgit clone sgit_public_read_1c1b95f5903e35850a9bc0541ffa09c6b5d4017cbf18817d2ad6f894127e5638:3simlnqe`
Published 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 ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_1c1b95f5903e35850a9bc0541ffa09c6b5d4017cbf18817d2ad6f894127e5638%3A3simlnqe), try the presets, then change one answer and watch the register move.

**Going deeper.** This vault has more in it than one page holds. [**The seven views, explained**](views/index.md) walks each view with a screenshot of the live vault and the mechanism behind it. [**The author’s walkthroughs**](videos/index.md) carries three recorded demos with full transcripts, the reasoning that the screenshots cannot show.

## What is going on here, step by step

the argument

### 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.

The explorer at zero: no answers, so no register.

context decides

### 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.

The Exposed preset: 18 facts, 37 risks, and unanswered relationships drawn as ghosts.

published on purpose

### 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.

PUBLIC.md: three rules, enforced by the vault’s own build.

the floor

### 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](../risk-mandate/index.md) uses an LLM without holding its key, [Supplement Stack](../supplement-stack/index.md) writes to one folder, [Agentic Browser Isolation](../agentic-browser-isolation/index.md) declares `write: []`, and this one asks for nothing.

app.json with an empty permissions object, the floor of the scale.

## 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](../risk-mandate/index.md), 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](../../../catalogue/index.md).



==============================================================================
# The seven views, explained (Risk Graph Explorer)

> A deep walk through each view of the risk graph explorer) the estate, context, role risk map, risk chains, the register, acceptance and what happens next, with screenshots of the live vault and the mechanism behind each, grounded in the author’s own walkthroughs.
>
> Page: https://sgit.ai/demos/vaults/risk-graph-explorer/views/index.html

[Home](../../../../index.md) / [Vaults](../../index.md) / [Risk Graph Explorer](../index.md) / The seven views

# The seven views, explained

One set of answers, seen from seven altitudes. This page walks each view of the [Risk Graph Explorer](../index.md) with a screenshot of the live vault and an explanation grounded in [the author’s own walkthroughs](../videos/index.md), because the reasoning behind a view is rarely visible in a picture of it.

**The spine, in one line.** An answer becomes a **fact**; facts combine into **risks**; risks are **assigned** to a role and **chain** upward to the corporate register; a role **accepts** what it holds; acceptance produces **what happens next**. Every view below is that same spine, cut at a different angle, which is why changing one answer moves all seven.

Screenshots are of the live vault under the **Exposed** preset, captured with the published read key. Open it yourself from [the vault page](../index.md) and follow along.

1 · The estate

### Every answer becomes a fact, and the graph is the evidence

This is where answering happens, and the first thing to notice is that **a "no" is still information**. From the walkthrough: *"if you don't have an agent, then we only have one piece of information here, but this is a fact."*

The questions walk a deliberate path: what the agent is, what data is in its reach, whether its output decides about a person, what it can do with that data (*cannot see it · reads it · reads and changes it*), whether it can change production, how it is stopped, who may stop it, how long stopping takes, whether stopping was ever tested, what it can reach if it misbehaves, whether it has outbound access, whether the damage is reversible, whether there is a written procedure, whether the actions could be reconstructed, and whose account it acts under.

Each answer lands as an `F-nn` fact chip, and the graph draws the relationships between them, amber for exposure, green for assurance, **ghosted for nobody has said either way**. That last one matters: an unanswered question is drawn as an absence rather than silently treated as a pass.

The estate: answers on the left, the fact graph they build on the right.

2 · Context

### The same technical answers, weighed against what is at stake

Context is the view that makes the app's core claim enforceable. The technical answers can be as alarming as you like; if nothing is behind them, little follows. The header carries the verdict in plain language, *decides about a person · in production · at stake*, and those three phrases are what turn a list of facts into a register worth reading.

This is the difference between a risk tool and a checklist: a checklist scores the agent, this weighs the agent *against the estate it runs in*.

Context: what is at stake, and where it runs, applied to the same answers.

3 · Role risk map

### The org chart, with risks flowing up it

The view the author calls *"crazy powerful"*, and the header states its invariant outright: **every risk is assigned to somebody, and every risk reaches the board**.

Read the counts under each role and you can see the two modes the walkthrough describes. The CISO shows `14 assigned · 14 through`; the CTO `4 assigned · 25 through`; the board simply `37 arrive here`. **Assigned** is what you personally hold. **Through** is what arrives because the risk graph says it must, *"he arrives because of the risk graph says so"*. The SRE holds a set; the platform owner inherits those and adds its own; the CTO inherits everything below and adds its own; the CEO connects the dots.

The consequence is the one worth quoting: *"no risk then becomes orphaned, because every risk will flow upwards, and that's super important."* An owner cannot be surprised at the top by something nobody carried up.

Role risk map: assigned vs through, with every path terminating at the board.

4 · Risk chains

### Risks that cause risks, and the ability to walk it backwards

The second graph, and a different question: not *who holds this* but *what produced it*. Columns are levels, inherent at the left, operational rising by causal depth, and the **corporate register pinned to the right, because that is where the question stops**.

Click any entry and it colours what produced it (**upstream**) and what it produces (**downstream**). The walkthrough uses it in both directions: *"if you go to 'led by' at the bottom, you arrive at the bottom of the risk; if you go 'leads to', you're navigating upwards."* So a corporate-level entry can be interrogated, *"why is it? It's because we have that one, and that one, and this one"*: until you reach the specific answers that caused it.

One detail that only an honest tool ships: **a dashed edge is a cycle, and the cycles are real**. Rather than hiding a loop that the model does not like, it draws it.

Risk chains: inherent to corporate, left to right, with upstream and downstream colouring.

5 · The register

### The familiar artefact, with its provenance attached

This is the output most organisations already recognise: a risk register. What is different is that every row carries where it came from. Per the walkthrough: *"for every risk that you have here, you can see who's assigned, who causes it, and who leads to, and how does it connect."*

A conventional register is a list of assertions someone typed. This one is a **projection of the graph**, which means it cannot contain a risk that nothing produced, and it cannot lose a risk that something did.

The register: the conventional artefact, generated rather than authored.

6 · Acceptance

### Nobody can accept on anybody else’s behalf

Acceptance is where the register stops being a document and becomes a decision. Each role holds what it holds and must accept it personally, and the author is explicit that this is where the value shows up: *"everybody that is going to accept it is going to push back."*

That pushback is the feature. The walkthrough contains a live example of the author disagreeing with his own tool, *"I actually don't agree with these risks… I don't buy that"*, and the point is what happens next, because every risk is fact-derived, the disagreement resolves into *which fact is wrong* rather than whose opinion is louder. *"The cool thing is that we start to have the evidence to show exactly why we are saying this."*

Acceptance: per role, per risk, with no delegation and no deny button.

7 · What happens next

### Decisions become incidents and projects

The last view closes the loop. Acceptance is not the end of a risk; it is a commitment that produces consequences, the things that will happen if the exposure materialises, and the work that would change it.

In the parent vault this is where a board refusal *funds a project* that flips the whole graph to the safer option. Here it is the same mechanism in miniature: the register does not merely describe a position, it names what follows from holding it.

What happens next: the consequences and the work that would change them.

## The same estate, at three settings

The presets are the fastest way to feel what the tool actually does. These are the **role risk map** for the same organisation under three different sets of answers, nothing about the org chart changed, only what is true about the agent.

typical

### A typical deployment

An agent is present and the estate is ordinary. Risks exist, they are held, and they reach the board, but the shape is contained.

Typical: risks present, shape contained.

governed

### The same estate, governed

Approvals, a tested stop, a named authority, bounded reach. From the walkthrough: *"you have the govern, we can see it's a much cleaner sort of flow of events."* The risks do not vanish, they arrive with far less weight, and by shorter paths.

**This is the argument the whole tool exists to make.** The register is not a verdict on whether you should run an agent; it is a picture of what you are carrying, which changes when the controls change.

Governed: same organisation, cleaner flow.

## Why this workflow is powerful

| What it does | Why it matters |
|---|---|
| **Answers are facts, and facts are cited** | Every risk traces to the specific answers that produced it. Disagreement becomes "which fact is wrong", not "whose judgement wins" |
| **No risk is orphaned** | Every risk is assigned and every path terminates at the board. Nothing can sit in a register held by nobody |
| **Assigned is distinguished from inherited** | A role sees what it personally holds and what merely passes through it, two very different conversations |
| **Acceptance is personal and cannot be delegated** | The register becomes a set of decisions with names on them, and the pushback that follows is the point rather than a failure |
| **Cycles are drawn, not hidden** | A model that shows its own loops is one you can argue with |
| **Nothing is at stake ⇒ a short register** | The output scales with exposure, which is what separates a register from a checklist |
| **It runs in a vault, in your browser** | No account, no upload, no network call. The answers you give about your estate never leave the page |

The last row is what makes the rest publishable. A tool that asks these questions is asking for an unusually candid description of your weakest controls, and this one can be handed to somebody as [a read key](../index.md) that carries the whole application, with nothing to send anywhere.



==============================================================================
# The author’s walkthroughs, Risk Graph Explorer

> Three recorded walkthroughs of the risk graph explorer with full transcripts: the graph browser, risk chains, and the role risk map, the designer explaining why the tool is shaped as it is.
>
> Page: https://sgit.ai/demos/vaults/risk-graph-explorer/videos/index.html

[Home](../../../../index.md) / [Vaults](../../index.md) / [Risk Graph Explorer](../index.md) / Walkthroughs

# The author’s walkthroughs

Three recorded walkthroughs of this vault, each one played, then read. Under every video is the same session as a document: the moments that matter, the frame the screen was showing at that moment, and what is actually happening in it. The full transcript is at the foot of each.

**Why a video is not enough on its own.** A recording is invisible to a search engine, to [llms-full.txt](../../../../llms-full.txt), and to any agent reading this site as documentation. It is also full of *“this guy here”* and *“look at this”*: pointing that a transcript cannot resolve. So each moment below pairs the words with the picture they were pointing at, which is the only form in which the argument survives being read rather than watched.

Timestamps link into the video at that point. The **Graph Browser** moments are frames of the recording itself; the **Risk Chains** and **Role risk map** moments are captured from the live vault with the published read key, driven to the state being described.

## 1 · Graph Browser · 4:21 · 5 Aug 2026

How answering the questions builds the fact graph, and why a “no” is still information.

**Note on what you are looking at.** This walkthrough was recorded inside [Risk Mandate](../../risk-mandate/index.md), the field demo the explorer was later extracted from, so the chrome says *Risk Mandate, field demo* and the tab strip is shorter than today’s. The mechanism is the same one running in [this vault](../index.md).

[00:00](https://youtu.be/PP6zsrC0KEg?t=0)
### Five ready-made estates, before a single question

The video opens on the field demo’s front door, **“Eight questions about the agents you run”**, and the row of prepared examples underneath it: *a typical estate*, *a rough day*, *a well-run estate*, *a coding agent in CI*, *a support agent on accounts*. One tap loads a populated register.

That row is a design position, not a convenience. A tool that only shows you your own answers cannot show you what a different answer would have produced, and the argument here is entirely about difference.

“I want to just talk about this graph explorer that we pushed as an MVP, which is, I think, ridiculously powerful as a way to present.”

00:00, the entry point, with five prepared estates to open instead of answering.

[00:31](https://youtu.be/PP6zsrC0KEg?t=31)
### One answer, one edge, and the counters start moving

The first question is answered: *“Yes, in production”*, which lands as `F-1`. Watch the header. It reads **1 fact · 4 risks · 5 provisions**, *where it runs: in production*, and **at stake: nothing yet**: **, because nothing has yet been said about data.

In the graph, exactly one edge is drawn: `runs-in`, from **The agent** to **The production estate**. Every other twin is ghosted and carries its own tally (`0/3 said`, `0/2 said`) which is the tool stating, per node, how much of what it wants to know it does not have.

00:31, 1 fact, one edge, and “at stake” still empty.

[00:59](https://youtu.be/PP6zsrC0KEg?t=59)
### Edges are named, and the names carry the meaning

Personal data is selected (`F-36`) and the header flips: **personal data at stake**. **The data in its reach** lights amber with *Personal data* written beneath it, and **Decisions its output…** gains the note *Its output informs a person w…*.

This is the moment the deixis in the transcript resolves. He says the edges differ, and they do, by *name*: `runs-in`, `can-read`, `can-change`, `informed-by`. Not a generic line with a thickness, a labelled relation. That is what makes the picture evidence rather than decoration.

“We actually have different, in a way, almost, different edges depending of what it is. And then, what it can do with the data, right? It cannot see it, or reads it, or reads and changes it.”

00:59, the data node lights, and the edges arrive with names on them.

[01:30](https://youtu.be/PP6zsrC0KEg?t=90)
### One answer can be two facts

*“Reads and changes it”* is selected, and its chip reads `F-33 F-34`. Two fact identifiers for one click, because the answer asserts two separable things, and each has to be independently citable later when a risk points back at what produced it.

The graph gains `can-read` and `can-modify` as distinct edges. Below, the questions have moved on to whether it can change production, whether it can be stopped, and how long stopping would take, the path from *capability* to *control*.

01:30, one selection, two facts, two edges.

[02:01](https://youtu.be/PP6zsrC0KEg?t=121)
### “This is here, depends on that one”, the sentence a transcript cannot carry

Here is the clearest case for reading the video rather than only listening to it. He says two risks are connected and points; the words alone name neither end.

The frame answers it. *“Yes, eventually”* is selected under **q3, if you had to stop it right now, could you?** (`F-12`), and an edge labelled `stops-in-many-actions` runs from the agent down to **The stop control**, which now shows `4/12 said`. The dependency he is pointing at is a named edge with a counted endpoint.

“This is an interesting one because this is connected to the stop control. So, you can actually see that this is here, depends on that one.”

02:01, the referent of “this depends on that one”, named.

[02:30](https://youtu.be/PP6zsrC0KEg?t=150)
### Saying “never” draws an edge too

Two negative answers land: *never* actually stopped it (`F-19`), and *no*, the side effects of stopping are not known (`F-22`). A checklist would score these as gaps and move on.

Instead the graph grows `never-exercised-on`, `never-timed-for` and `absent-for`, negative relations, drawn and labelled exactly like the positive ones. This is the mechanism behind the claim that a “no” is information: the answer produces a fact with a name, so a risk downstream can cite it. **11 facts · 20 risks**, and the shape is filling in.

02:30, “never” and “no” arrive as named edges, not as silence.

[03:00](https://youtu.be/PP6zsrC0KEg?t=180)
### The one green edge

Reach is answered *customer-facing* (`F-24`) and egress *no egress* (`F-47`), and `cannot-reach`, running from the agent to **Outbound network access**, is drawn in the assurance colour rather than the exposure colour. In a field of amber it is the single teal line.

That is the whole two-colour scheme doing its job in one frame: amber is something true that costs you, teal is something true that helps you, and both are the same kind of object, a stated fact with an edge. A good answer is not the absence of a finding; it is a finding.

03:00, “no egress” draws an edge too, in the other colour.

[03:30](https://youtu.be/PP6zsrC0KEg?t=210)
### Seventeen facts, and the question of whose account it acts under

By now the graph is dense with named relations, `cannot-reconstruct`, `held-by-a-group-for`, `irreversible-by`, `never-timed-for`, `absent-for`, and the header reads **17 facts · 30 risks · 11 provisions**. The agent node shows `15/43 said`: fifteen of the forty-three things the model would like to know have been said.

The last question is the sharpest, and it is deliberately last: **whose account does it act under**: *a named person’s · a team’s · a service account nobody owns*. Everything before it describes what the agent can do. This one asks who will be standing there when it does it.

“It’s a great way to almost in one day capture all the data.”

03:30, 17 facts in, and the account question still to answer.

[04:01](https://youtu.be/PP6zsrC0KEg?t=241)
### The other views, in one sweep, and a risk with an owner

He closes by touring what the same answers become elsewhere, landing on **Risk chains** with **RISK-22** selected: *“Some changes the agent makes cannot be reversed by the operator”*, marked **OPERATIONAL · HOLDS NOW**, assigned to *SRE / platform on-call* and *Platform owner*, with a **blast radius** drawn from its own facts.

That panel is the payoff of everything above it. The risk was not typed by anybody. It exists because certain answers were given, it is owned because the org chart says who holds that class of thing, and it can be argued with by going back to the facts underneath, which is what the next walkthrough is about.

04:01, a generated risk, with an owner and a blast radius.

**Full transcript, Graph Browser**

Okay, so I want to just talk about this graph explorer that we pushed as an MVP, which is I think ridiculously powerful as a way to present. So what we have here now is how the questions we originally talked about in the demo. But it's in a weird way, we start with the first question, right? Do you have an agent and where does it run? Because if you don't have an agent, then we only have one piece of information here, which is, and but this is a fact, right? So this here captures the facts and information. So you could see that you have both the operation state or the test environment. And it's interesting because the risk will be very similar.

The only question is whether it's live, so in a way that there's a risk level that is probably going to be there, right? So let's say you have one, right? And now you can see what kind of data is enriched. Let's say I got personal data. And what's cool about this is you can see that what's happening is this graph is now going to be populated with the data that we collected. So you can think of this graph as the evidence piece, right? So look, there's the output of facts and decision. Okay, it informs decisions.

So you can see that what's cool about it is that we actually have different, in a way, almost different edges depending of what it is. And then, what can do with the data, right? It cannot see it, or reads it, or reads and changes. So this is a typical example of you have a production system, right, that touches personal data, accounts, contact details, it informs the decision, you know, of the there, and it reads and changes. So it's a typical agent, right? And now you got it. So now you talk about the information of this.

You know, can the agent change things, right? Can you read and report? Can changes? Can change on its own? So you start to map, you know, for example, how it's done, right? With a person approval or change. So that so this is where you take that to the next level. So it changes on its own, right? So how do you stop it? Let's say you have an action to stop, or eventually can stop, or we don't know how to stop it. And how long should we stop it? Is it minutes? An hour? Don't know. So you start to see again, you know, the stop control now we map stop in many actions, never, time for, an hour, minutes, right? And then, have you actually stopped it? Yes, we have, only in test, never, right? Do you know the effects of stopping it? Have we mapped it? Is it partially? Etc.

So this is an interesting one because this is connected to the stop control. So you can actually see that this is here depends on that one. So it's in a way now a next line up, like down, sorry, of the flow. Is there a named person? Do you have a named person or not? So this is the stop authority, right? The team, you know, if it really is, you know, misbehavior for full speed, could, you know, what could you reach, right? Internal only, customer facing? Don't know. So this would be customer only.

So you could now start to see again, you know, what's the damage, that it can acts, you know, can you reach anything outside the network? This means that does it have internet access or not. So again, you can see here, outbound access, right? For example, no egress. Could, you know, could you undo the damage, right? So let's say you have fully reversible versus not, or some change are forever, which is important, right? Is there a written procedure for how you pull the plug? You tested it, you've written, you don't have it. Could you reconstruct what you did, for example, every day, right? Or, you know, do you have, you know, fully or partially or not, right? Cuz sometimes you have backups, but they do not allow you to restore specific things, and whose account it is, right? A service account, a named person, a team, right? So, you know, what is actually the, for example, the flow that happens. And then this is great, like because you can look at it.

This is, I love this, right, because it's a great way to almost in one day capture all the data. Just for reference, we then capture the context. We have now these really cool road map with all the risks that flow forward. We also have these risk chains, which I go in more detail in others, but that means that every risk that is then connected connects to the top level, right? And then we even have a risk register, right? And for every risk that you have here, you can see who's assigned, who causes it, and who leads to, and how does it connect, right? So it's pretty cool.

## 2 · Risk Chains · 4:18 · 5 Aug 2026

Risks that cause risks, and why being able to disagree with the register is the feature.

[“risk 6”](https://youtu.be/kWip3QnuN1I?t=45)
### Every risk carries the condition under which it would stop being true

He names one entry (*“if you look at this guy here, for example, you have risk 6”*) so this is that entry, selected in the live vault. **RISK-6, the production estate can be changed by an agent**, with the app’s own one-line gloss: *“They hold the estate. A change they did not make can still be one they must live with.”*

The dashboard is where the design shows. **Established by**: `F-5`, the agent `can-change` the production estate, one fact, cited. **Ceases when any of these hold**: `F-4` reads-only-from, or `F-3` absent-from. That second list is unusual and worth stopping on: **the risk ships with its own falsification condition**. It is not a judgement to be argued down, it is a claim with stated exit criteria.

Then **reduced by, but not retired**: *narrowing what it may change*, *staging changes behind a gate*. Mitigation is recorded as reduction, never as removal. And **touches**: EU AI Act Art. 12, Art. 26.

The entry he names, opened: one fact establishes it, two would end it.

[“corporate 2”](https://youtu.be/kWip3QnuN1I?t=110)
### Walking it backwards: “why is it? Because we have that one, and that one”

The same view from the other end. **CORP-2, customer harm**, assigned to the Chief Product Officer and the CEO, and the panel answers his question literally. **Established by**: *“Nothing directly. It holds because the entries below it do.”* **Leads to**: *“Nothing recorded”*: this is the top, which is where the question stops.

Underneath, **led by** enumerates the causes, and each carries a reason in the tool’s own words: RISK-5 *“← a person on the other end is what customer harm means”*; RISK-26 *“← the record is somebody’s”*; RISK-27 *“← this is what customer harm looks like in practice”*.

Note the colour: tracing upstream lights the path in the assurance tone rather than the exposure tone, so *what caused this* and *what this causes* are visually distinct operations on the same graph. And the corporate entry **touches no twin directly**: it is entirely a consequence, which is exactly why it cannot be edited into existence.

The top of a chain, interrogated backwards, with a reason attached to each cause.

[governed](https://youtu.be/kWip3QnuN1I?t=200)
### The same organisation with controls in place

Switching the preset to **Governed** re-derives every chain from a different set of answers: approvals in the path, a tested stop, a named authority, bounded reach. Fewer entries, shorter routes to the register, *“a much cleaner sort of flow of events.”*

The comparison is the argument. Nothing about the organisation changed between this frame and the last; only what is true about the agent did. A register that produced the same output either way would be measuring the questionnaire, not the estate.

Governed: same organisation, same graph, fewer and shorter chains.

**The most useful thirty seconds in all three videos** is the author disagreeing with his own tool. *“I actually don’t agree with these risks… I don’t buy that at the moment.”* He then works out what he does think is true, that the exposure is really about the agent touching EU AI Act obligations, and that stopping it would itself disrupt production, and says *“so we should capture that.”* The disagreement does not resolve into whose judgement wins. It resolves into **which fact is wrong or missing**, and then the register re-derives. That is the difference between a document you argue about and a model you correct. *“When you go and push your risk to be approved, the stakeholder is going to challenge you really hard. The cool thing is that we start to have the evidence to show exactly why we are saying this.”*

**Full transcript, Risk Chains**

...to go through this UI which I think is starting to really show the idea of connecting the risks upstream. So what you have here to show you, this is part of the UI that we have that you know, you can basically see the multiple workflows that we have from a typical, non-exposed, one that's actually quite governed. What I really like is this, let's look at the exposed first, this sort of chain, and let's consolidate this here. So the idea here is that the risks connect from one element to the other. So if you look at this guy here, for example, you have risk 6.

"The production can be changed by an agent." This is now connected to that risk. "Organization acts to the system that acts for a person", who then creates this risk, right? "Organization asks to, Tech to be changed." And then hits the top two risk register. So the logic here, this is the corporate risk register, so you can see that that particular risk will arrive there, and when I click here, I can also see the reverse. So I can see, if we say we have a risk of this, why is it? It's because we have that one, and we have that one, and we have this one, and that one. And I could also see it here, what actually happens.

You can see, for example, this particular risk, corporate 2, who is assigned to, and then to the CEO, to what, you know, is reduced by this particular choices, touches GDPR, and then leads to this. So, so actually, so this is a good example, so you can see that this guy here, this risk leads to these two, and is led by that and that. So you can see that, you know, and again I can click on it and see the risk, right? So, so if you, if you go to "led by" at the bottom, you arrive at the bottom of the, the risk. If you go "leads to", you're basically navigating upwards the risk through. And the idea is that every risk should arrive at the corporate, at the top, right? So, so this now becomes a very powerful way to start to understand connections, and then we map the risks to the correct one, and I'll do a separate one to show how again, we connect all these risks to the particular CEO, CFO, you know, stakeholder, right? Now, the cool thing about this is you could see that the risks that you have go from zero, we don't have anything, to yes, you have an agent, bang, you got some risk.

So as we start to add basically these answers, you see that we basically start to populate and start to add the risks and they start to interconnect, which is really cool, right? So, the idea is that the changes here impact the risks that exist and how the risk register almost looks like and the evidence that we have, right? So, and what's interesting about this, is if you look for example at "governed", actually this is there because of, I was actually, when I was explaining Claude about how to do this, I was saying just the fact they have an agent, you're going to have risks, but I actually don't agree with these risks because, see even that loss of control, I would argue that's not the risk that I have by having an agent, right? So the logic here is like if I have an agent in production and I have a lot of these values which are pretty good, I don't buy that at the moment I have this, right? Because we said in this one that we already have some of these. So, I think this is a good example of why when you go and push your risk to be approved, the stakeholder is going to challenge you really hard. The cool thing is that we start to have the evidence to show exactly why we are saying this. So, I think that in this particular case, it has more to do with the fact that the agent touches EU act, so suddenly we are in compliance with the EU AI act, or we might be compliant with it, and we now have an agent in the mix, and then the organization, and we have, and even though here we say we can stop within a minute, right? There is still some disruption to production, right? Which is interesting, right? So we should capture that operation, right? Because the system, like that one's a good one, you know, stopping the agent might have an interruption. So, again, we need to capture these nuances.

The cool thing is this is all now fact-driven, which is super powerful.

## 3 · Role risk map · 3:15 · 5 Aug 2026

The org chart with risks flowing up it, and the ways a risk arrives at a person.

[“no agent”](https://youtu.be/yqQgff4RWuE?t=160)
### The org chart exists before any risk does

Under the **New** preset the structure is already there (board, CEO, CTO, CISO, CFO, DPO, chief product officer, platform owner, customer-facing service owner, SRE) and nothing is flowing through it.

That ordering matters. The organisation is not derived from the risks; the risks are routed onto an organisation that was described first. Which is why the same estate can be re-answered all day and the chart underneath never moves.

“If you have no agent, you have nothing.”

Nothing answered: the structure, carrying nothing.

[the CTO](https://youtu.be/yqQgff4RWuE?t=95)
### Held, versus arrived, and the tool separates them explicitly

Selecting the CTO lights the path *Board → CEO → CTO → Platform owner / CISO* and splits what the role carries into named sections. **Holds, 4**: *“Assigned to this role. Its own to deal with.”* **Arrives by the risk chain, 16**, with the tool’s own explanation of why that category exists:

“It arrives because the **risk graph** says so, not because anybody reports here, which is how a board entry ends up with an unexercised runbook underneath it.”

That sentence is the whole feature. An owner is not surprised at the top by something nobody carried up, because arrival is computed rather than reported. On the chart itself each role is labelled in the same two terms. The CTO reads `4 assigned · 25 through`, and the board simply `37 arrive here`.

The CTO: four of its own, sixteen that arrive because the graph says they must.

[the SRE](https://youtu.be/yqQgff4RWuE?t=130)
### At the bottom, a third category, and it is empty

The SRE / platform on-call is the leaf, *reports to Platform owner → CTO → CEO → Board*, and it **holds 9** (RISK-2, 6, 10, 11, 12, 13, 19, 22, 35) the operational set the walkthrough describes as travelling upward from here.

The panel here reveals something the video only implies: there are **three** ways a risk reaches a role, not two. **Arrives by the risk chain (2**, and **arrives by the org chart) 0**, glossed *“Held by somebody who reports here”*, answered *“Nothing below.”* Inheritance through the reporting line and causation through the risk graph are counted separately, which is what lets you ask a manager *why* they hold something and get a structural answer rather than a list.

“No risk then becomes orphaned, because every risk will flow upwards, and that’s super important.”

The leaf of the chart: nine held, two caused, nothing inherited) because there is nothing below it.

**Full transcript, Role risk map**

Okay, so this next video shows another super powerful capability that we had here to our risk graph explorer, which is the org chart, and how we have, in this case, the board, we have the CEO, we have three direct reports, and we have then the kind of the team, where the platform owner, to the CTO, to the CEO, to the board, and you can actually see, you know, it's quite nice, the chain, right, the chief product officer, you know, has a customer service owner who connects to the board, who responds to the CEO and the board, right? And we can kind of see the sequence of events, right? So, what we're going to see here is how as we add risks to the organization, right? You start to have risks that are flowing to here, right? Which is pretty cool, so you could see that as we add, basically, and we provide answers, you basically start to see the, fundamentally, the risks changing. And what's cool about it is you could see how they arrive, and one of the things that's quite interesting is that we have two modes already, because you could see that the CEO, in this case, or the board, right, receive all these risks, so the CEO, in this case, is assigned his three corporate risk registers directly to him, but you also have these risks that arrive from the risk chain, and that's very important. Right? So you basically could see that because somebody, you know, a senior, holds, he arrives because of the risk graph says so, right? So that means that these particular risks that exist there, which for example, come from here, so you could see that this risk here, so let's say, the SRE is holding risk 2, risk 6, risk 9, risk 21, and risk 31, and that risk is also now going to exist, same risks are going to be connected to the platform owner, who now has a couple more risks of itself, and now the CTO has a couple risks of itself but also inherits all the risks that we mentioned below all the way up. So it's pretty cool, right? Because again, same thing, right? So the DPO is assigned a couple of risks, and then, you know, that he has, right? And then, you know, it also arrives from the risk chain, and then you got the CFO, the same thing, right? And then the CEO, you know, connects the dots. So this is a really powerful capability because it's how you connect all the dots, right? So if you look at the different scenarios, if you have no agent, you have nothing, if you have a typical kind of agent deployment, you have this kind of shape, if you have a lot of exposure, you get a much bigger set of responsibilities, and you have the govern, we can see it's a much cleaner sort of flow of events.

And now we can start to challenge, you know, is those risks in the right place because everybody that is going to accept it is going to push back. But this is crazy powerful because now we start to see the relationships, and we see that no risk then becomes orphaned, because every risk will flow upwards, and that's super important.

## Where to go next

Each view gets a systematic treatment, screenshot by screenshot, on [**the seven views page**](../views/index.md). The vault itself (its read key, both live surfaces, and the publication rules it enforces on its own build) is on [the vault page](../index.md).



==============================================================================
# Algarve · May 2026, a published vault

> A travel diary as a vault: twenty photographs in three sizes, an eight-chapter narrative and an auto-opening gallery app, 29 MB of ciphertext opened by one published read key, with its pre-publication audit finding stated on the page.
>
> Page: https://sgit.ai/demos/vaults/algarve-may-2026/index.html

[Home](../../../index.md) / [Vaults](../../../index.md) / Algarve · May 2026

# Algarve · May 2026

A travel diary as a vault: twenty photographs in three sizes, an eight-chapter narrative, and a gallery app that opens automatically.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_0a0f34839d737eef0f8f66e5236990b1f397af064763e3f71dca2717015f9d15:3d04e6b9ca98`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_0a0f34839d737eef0f8f66e5236990b1f397af064763e3f71dca2717015f9d15%3A3d04e6b9ca98) · From the CLI: `sgit clone sgit_public_read_0a0f34839d737eef0f8f66e5236990b1f397af064763e3f71dca2717015f9d15:3d04e6b9ca98`
Published deliberately. It grants read, and only read, a write attempt is refused by the server’s write gate (the **R1 W0** badge you will see in the chrome).

## See it live, here

Both surfaces open automatically below. You can also [**open the gallery app in its own window ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_0a0f34839d737eef0f8f66e5236990b1f397af064763e3f71dca2717015f9d15%3A3d04e6b9ca98), the read key travels in the URL fragment, which the vault UI accepts directly.

## What this vault demonstrates

| Feature | How this vault uses it |
|---|---|
| Real binary payload | 60 WebP photographs in three sizes (originals ≈29 MB total, web ≈1600px, thumbnails), every byte stored and served as ciphertext |
| Auto-opening gallery app | `app.json` sets `auto_open` with a minimal HUD; the app is an editorial photo story with chapters and a lightbox, driven by `gallery.json` |
| Content + narrative | `NARRATIVE.md` carries the written week; `gallery.json` carries per-photo titles, captions, chapters, edit the JSON, push, and the gallery updates |
| Deep history | 36 commits of organising, captioning and re-cutting, open the SGIT view above and read the story of the story |
| Owner secrets done right | `.vault/owner/readonly-tokens.json` decrypts to *further ciphertext*: owner bookkeeping is double-encrypted under a key the read key cannot reach |

## What is going on here, step by step

The two embeds above are the real product, which makes them easy to scroll past without noticing what is unusual. Each row below points at one thing and says why it matters. Every screenshot is of this vault, driven by a script that opens it with the **published read key** and nothing else, the same credential printed at the top of this page.

the app itself

### The app is real HTML, not a viewer

The gallery is the vault's own `index.html`, an editorial layout with chapters, pull quotes and photo rows, written as ordinary HTML and CSS. Nothing renders it into a fixed "photo album" template: whatever the author wrote is what runs.

Each photograph here arrived as ciphertext, was decrypted in the browser, and was handed to the page as a `blob:` URL. The server never saw a picture, it served opaque bytes and has no idea this is a gallery.

A chapter row: two decrypted photographs, laid out by the vault’s own CSS.

interaction

### Click a photo and the app takes over

Because the app is real HTML, it can behave like any web app. Clicking a photograph opens the gallery's own lightbox: a larger image, the caption and chapter from `gallery.json`, and arrows to move through all twenty.

This is the part that surprises people most, an encrypted store is usually a download-and-open experience. Here the interaction is authored *inside* the vault and the reader never leaves the page.

The lightbox: caption, chapter, position (1 / 20), and prev/next arrows.

watch it decrypt

### A pane that shows the decryption happening

The app frame ships with a debug pane, and its **Vault** tab is the timeline of the open: the vault unlocked, the file tree loaded, `app.json` found, the app iframe ready, each with the milliseconds it took.

Read the key line: the vault opens from a key that is shown truncated, and the file tree, *seventy files*, is built in the browser from encrypted directory objects. Filenames are encrypted too, so even the folder structure is something the client reconstructs rather than something the server reports.

The Vault tab: each step of the open, with timings.

the sg bridge

### And a console you can type into

The **REPL** tab is a small console over the `sg.*` bridge, the same API the app itself uses. `vfs.list` walks the decrypted tree, `vfs.read` prints a text file.

Note what the help text says about writing: `vfs.write` and `vfs.delete` are marked *writable vaults only*. This page's key is read-only, so those commands are refused, not hidden by the interface, but impossible, because no write capability exists anywhere in the chain.

vfs.list at the vault root, then inside /photos) typed live, answered from decrypted objects.

transparency

### The whole vault is browsable, including its source

The second surface on this page is the vault browser. It shows the real tree: `photos/originals/` with its twenty WebP files, the thumbnails and web-sized copies beside them, and the app's own files.

Open `index.html` and press **Source** and you are reading the gallery's code, the same 29.9 KB the app boots from. A published vault is transparent in a way a hosted gallery rarely is: the reader can inspect exactly what is running.

photos/originals expanded, with index.html open in source view.

version control

### And it is version control, not just storage

The **SGIT** tab is why this is sgit rather than a folder in the cloud. Every commit that built this gallery is here, thirty-six of them, with real object ids, dates and branch labels, and `tree` and `diff` links per commit.

This is the vault's history, read from the same encrypted objects, with the same read key. Nothing was re-uploaded to make it browsable: the history *is* the storage.

The SGit view: the commit history of the gallery, read-only.

**How these pictures were made.** They are not mock-ups and they are not hand-cropped. `admin/build/capture_shots.mjs` opens this vault in a real browser with the published read key, performs the navigation each row describes, scroll to a chapter, click a photograph, open the debug pane, switch to the REPL and type `vfs.list`, expand `photos/originals`, switch to the SGit view, and crops the result. Re-running it after the vault changes regenerates every image. The tool takes a read key, so it can document any published vault the same way.

## The audit, honestly

Every vault gets an audit before its read key is published here, and this one has a finding worth stating plainly: the server-side bookkeeping file for a public preview (`.vault/owner/public-previews/…`) carries a live `delete_auth` token, readable by anyone holding this read key. Its scope is narrow, it permits deleting or replacing that one *public preview*, not writing to the vault, whose write gate remains closed, and the owner has been advised to rotate it. It stays on this page because the finding class is the lesson: bookkeeping written into vault content travels with the read key forever. The newer pattern (owner secrets double-encrypted, as the row above shows this same vault doing for its read-only tokens) is the fix.

## What this shape is for

Photo albums, trip diaries, family archives, portfolio galleries, anything where the pictures should not sit plaintext on someone else’s server, but a single shareable key should open the whole experience, chapters and captions included. This is the first of several galleries in [the catalogue’s](../../../catalogue/index.md) awaiting list.

## Derived facts

71 files · 29 MB · 36 commits · app entry `index.html` · derived from the read key alone by `admin/build/catalogue_derive.py`, the same derivation that populates [the catalogue](../../../catalogue/index.md), where this vault also has an entry.



==============================================================================
# Demos, sgit.ai

> Live end-to-end demonstrations: vaults actually created, pushed, and embedded in the pages that document them, each with a deliberately published read-only key.
>
> Page: https://sgit.ai/demos/index.html

[Home](../index.md) / Demos

# Demos

Live, end-to-end demonstrations, each one a vault that was actually created, pushed, and embedded in the page that documents it. The walkthroughs are complete: every command, the keys that are deliberately public, and the ones that never will be.

**The rule every demo follows:** the vault's *read key* is published on purpose. It is derived one-way and cannot write, so publishing it is what makes the demo openable by anyone. The vault's *write key* appears nowhere: not in these pages, not in the repos, and the build refuses to push if one ever reaches a tracked file.

## Thirty vaults, one page each

The demos outgrew this page. Every vault whose read key this site publishes now has its own page under [**Published vaults**](vaults/index.md), what it does, which features it uses, the audit that ran before the key was published, and the vault itself running live in the page. Thirty at the last count, from a regulation parsed into a graph to a job application delivered as a vault, and the table there is generated from the same file as [the machine-readable list](vaults/llms.txt), so the two cannot drift.

[Gallery · 30 vaults### Published vaultsEvery vault with a deliberately published read key, one page per vault, the vault running live in it. Graphs, presentations, briefing packs, records, applications.Open the gallery →](vaults/index.md)

[Method### How a vault gets published hereThe seven steps behind every row: classify the credential, derive rather than refuse, audit with the read key, screenshot the real app, write the page, publish the key, verify with a negative control.Read the method →](vaults/publishing.md)

[Concept · 8 vaults### Fractal Semantic GraphsEvery node opens into a graph with its own ontology, down to the word; only the grammar is shared. What that means, why it is worth connecting everything with everything, and then how far down it goes: the law, the standard, the evidence, the risk, the owner, the policy, and a threat in one line of code, each a live graph in a published vault, with the pictures and the counts.Walk the ladder →](fractal-graphs/index.md)

[Index · live from a vault### The catalogueAn index of vaults that is itself a vault, rendered live on this site with a published read key. The machine-first companion to the gallery.Open the catalogue →](../catalogue/index.md)

## The three walkthroughs

These were the first demos, and they are still the pages to read if you want to see *how* a vault ends up inside a page, the sandboxed iframe, the postMessage bridge, the republish pattern when an original vault cannot publish its key, and two apps served from one store.

[Walkthrough · live### A vault app, live inside this pageField Notes: a self-contained vault app created from scratch, pushed, and opened inside sgit.ai with a published read key, sandboxed iframe, postMessage bridge, every byte decrypted in your browser.Open the walkthrough →](vault-app-embed.md)

[Report · real### The Strategy in Seven MapsNot demo content: the actual SG/Send strategy, published on LinkedIn in May 2026, served live from a vault with a published read key, plus the audit that shows why the original vault could not publish its key, and the republish pattern that fixed it.Open the walkthrough →](strategy-maps.md)

[Analysis · live### sgit, on a Wardley MapSix maps of sgit's own positioning (where git wins, where the boundary falls, the agent as the new user) drawn as inline SVG and served as a **second app from the same vault** as the strategy essay: one store, two entry points, one read key.Open the analysis →](sgit-maps.md)

## Reading a vault from a site, without the vault supplying the viewer

The newer pattern, used by the deck and document pages under the gallery, is the reverse of the embed: the site owns the viewer, the vault supplies only data, and the two meet in an iframe with no origin. It is written up for other sites' agents in [the deck brief](../docs/briefs/vault-decks-on-a-site.md), [the markdown and file-viewer brief](../docs/briefs/markdown-and-file-viewers.md), and [reading a single file out of a vault](../docs/vault/reading-a-vault-file.md).

[← Home](../index.md)[Published vaults →](vaults/index.md)



==============================================================================
# Fractal Semantic Graphs, sgit.ai

> What a Fractal Semantic Graph is: every node opens into a semantic graph with its own ontology, joined to the worlds above and below by named edges, down to the word; why that lets everything connect with everything without forcing anyone to share a schema; and the evidence: the vault where the idea was first worked plus seven more published vaults from the text of a law to a threat in one method on one compute instance, with screenshots, counts, and the rungs still modelled rather than imported.
>
> Page: https://sgit.ai/demos/fractal-graphs/index.html

[Home](../../index.md) / [Vaults](../vaults/index.md) / Fractal Semantic Graphs

# Fractal Semantic Graphs

A **semantic graph** is nodes joined by edges that mean something: every edge a verb, read in both directions. A **fractal** semantic graph is one where **every node opens into a semantic graph of its own, with its own node types, its own verbs, its own ontology**, and so does every node inside that, down to the smallest thing that still matters to the question you are asking. In most of our work that smallest node is a word, a number or a symbol. What stays constant between the worlds is not the schema but the grammar: edges are verbs, meaning lives in connectivity, every claim keeps its provenance. That is what lets everything connect to everything without anyone being forced to share a schema. For a long time we called this *graphs of graphs of graphs*, or *ontologies of ontologies of ontologies*. This page defines it, shows it, points at the vault where the idea was first worked, and then proves it with eight more published vaults you can open. If what you want is the engineering rather than the concept, [**Performance, cost, and running everywhere**](performance.md) has the measurements: what a read costs, why there is no database, and how this compares to ordinary graph engineering.

## What a Fractal Semantic Graph is

Most visitors here already know three of the four words. A **graph** is nodes and edges. A **semantic graph** gives the edges meaning: `arises_from`, `evidenced_by`, `owned_by`, each with a named inverse, so a link reads correctly from whichever end you stand at. An **ontology** is the agreed vocabulary of node types and verbs a graph is allowed to use. The fourth word is the new one.

**Fractal** means the graph has no privileged level and no single schema. Zoom into any node and you enter a new world: its own node types, its own verbs, its own taxonomy, its own centre of gravity. A regulation is a node in a graph of instruments and jurisdictions; open it and it is a graph of articles, recitals and amendments, a legal ontology; open an article and it is a graph of paragraphs and points; open a paragraph and it is a graph of the terms it uses, each an edge from the article that defines it, a lexical ontology nothing like the one two levels up. Each of these worlds was defined by whoever owns it, in its own vocabulary, and none was made to conform to the others. What connects them is that each is still a semantic graph, every edge a verb with an inverse and every node traceable to its source, so an edge can be drawn from any node in one world to any node in another. There is no top and no bottom, only the altitude you happen to be looking from, and how much definition you choose to load at it.

*[diagram]*

The test for the word is what happens at a link. Start inside one world, a risk register. It is already a rich semantic graph with a large vocabulary of verbs, each carrying meaning: a fact `gives_rise_to` a risk, a risk `is_owned_by` a role, a person `reports_to` a person, a control `mitigates` a risk, evidence `backs` a fact. Every link that makes sense inside that ontology teaches you something, and the knowledge accumulates one link at a time; a register with ten thousand well-named edges is a great deal of knowledge. Nothing about it is fractal yet. It is one graph, however large and however deeply it nests, in one vocabulary. A system that never lets you leave that vocabulary is a single graph, or a hierarchy, and not a fractal.

**The fractal property is that on one of those links you can jump into another universe.** Follow the register's *fact* node for an incident and you land in the security operations world: alerts, signals, the systems that were touched, ATT&CK techniques, attack trees, its own verbs and its own taxonomy, none of them borrowed from the register. In that world you meet a DNS entry that looks like command-and-control; follow it and you are in the DNS estate: zones, records, parents, values, every request the resolvers logged, a dataset perhaps millions of nodes large and quite possibly served through an abstraction layer over a SQL database, a graph database or a GraphQL endpoint rather than held as files. Follow one record to the traffic it produced and you are reading network captures, flows and a single TCP packet, in yet another vocabulary. Four worlds, four ontologies, four taxonomies, and one continuous path of named edges between them.

*[diagram]*

**What makes it fractal rather than merely linked** is that in every one of those self-contained worlds you find the same building blocks: nodes, edges with verbs and inverses, an ontology, a taxonomy, triplets, provenance. The grammar is what lets the jump work, in either direction, without an adapter. And it runs upward as well as down: everything just described can itself be one node in a larger graph that analyses it, next to graphs of behaviour, of agentic actions, of agendas, of funding. Even the schema can be fractal, in the way the Mandelbrot set is one formula whose structure repeats at every zoom: graphs composed from graphs, with properties of their own, treated as a graph all the way up.

**Every connection you follow should teach you something.** Even when the answer is *nothing to see here*, you now know that door was empty, and that is knowledge too. Whether a link added value is for the observer, or the query, to decide; the graph's job is to make the link available and keep its provenance. The more granularity you can reach, the better your representation of reality and the better the decisions and the understanding built on it. But granularity is chosen per context: you load as much as this question needs and no more, because the rest stays one edge away. Custom views built on top of the whole, each showing one context at one granularity, are what make all of this scale.

**Nobody is forced to conform.** An organisation, a division, a team, a single person, a regulator can each define their own world in their own vocabulary, and connect to everyone else's by drawing edges rather than by adopting a shared schema. [graphs.sgit.ai](https://graphs.sgit.ai/v1/depth/index.html) puts it as three layers: shared facts owned by nobody, per-party formulas, declared bridges between them.

**Somebody else reached the same limit, in their own words.** The [DSIT AI Risk Toolkit vault](../vaults/dsit-ai-risk-toolkit/index.md), published here on 20 September 2026, models UK government guidance as four worlds and states as the first of its four declared limits: *"containment alone is not fractality. Cross-world edges make the semantic transitions inspectable."* Different author, different vocabulary, same distinction as the one above.

## Why connect everything with everything

Because in our world **everything is already a graph, and so is every file format.** A regulation is a graph of articles; a PDF of that regulation is a graph of pages, blocks, lines and glyphs; a spreadsheet is a graph of sheets, rows, cells and formulas; a codebase is a graph of packages, classes, methods and tokens; a JSON document is a tree, which is a graph with one verb. None of them needs to be *converted into* a graph; each only needs its edges named. Once they are, the boundaries between formats stop mattering, and four things become possible that no document can do:

- **A question can cross formats without a join table.** *Which method in our code implements the control that the crosswalk maps to the article the amendment changed?* is one traversal, word in a law to control in a standard to attestation to method, because each step is an edge somebody named. The [AIUC-1 vault below](#standard) does exactly the first half of that walk, into a second vault, and finds eight amended articles nobody had noticed.
- **A correction propagates instead of being republished.** Mark one node superseded and every path that rested on it becomes a query (*what did we build on this?*) rather than an archaeology project. A document cannot do this: the correction is a new document, and nothing connects it to the thousand that already cite the error.
- **The smallest node is whatever your question needs, not what the format offers.** For a lawyer it is the defined term. For a threat model it is the method. For a conformance check it is the attestation and its expiry date. For the atlas below it is, literally, the word. Because every word is a node, *foreseeable* in Article 9(2) can be one edge from the ruling that decided what it means.
- **Every unit keeps its own world.** A regulation is modelled in a regulator's vocabulary, a risk register in the risk team's, a threat model in the engineers', and none of them is asked to change. The bridges between them are edges somebody declares (`crosswalks_to`, `evidenced_by`, `mitigates`), not a merged schema everybody has to agree on first. That is why the ladder below can have eleven rungs from seven authors and still be one traversal.
- **Provenance comes free.** When the leaf is a word and the word is connected to the byte range it came from and the hash of the file that held it, every claim at every altitude above it is traceable to source without any additional machinery. The Regulation Graph below ends every provenance chain in a SHA-256 of the retrieved bytes for exactly this reason.

The one discipline that makes “everything with everything” useful rather than noise is that **the edge has to be a verb**. `relates_to` is banned, because two things always relate; an edge with no verb constrains nothing and cannot narrow a query. The granularity of the verb is the precision of the question you can later ask.

## Four words, one of them new

| Word | What it adds | Where it stops |
|---|---|---|
| **Graph** | Nodes and edges | The edges mean nothing in particular |
| **Semantic graph** | Every edge is a verb with a named inverse; meaning is in connectivity, not in properties | One level: the nodes are atoms |
| **Ontology** | The agreed vocabulary of node types and verbs | One ontology per domain; joining two by merging them is a project that usually fails |
| **Fractal Semantic Graph** | Every node opens into a semantic graph with its own ontology, at every altitude, down to the word; ontologies are joined by declared edges, never merged: an ontology of ontologies | Where somebody has not yet named the edges between two worlds. That is a gap, and it is listed below |

## Where the idea was worked first

The term has a vault of its own, and it was published here before this page existed: [**VoiceDebrief · Fractal Semantic Graphs**](../vaults/voice-debrief/index.md), vault `k6xy9z4d`, row 11 of the gallery. Four apps in one vault, built in the open across two days in August 2026 against a pack of 34 architecture briefs, lifting meaning out of text (fictional voice notes first, then Article 9(2) of the EU AI Act) into typed semantic graphs. The zoom diagram at the top of this page uses Article 9(2) because that vault works the provision to exhaustion: legal annotation, altitudes, a concept graph, source-tethered tasks, a bow tie, and a cyber instantiation joined to the law node-to-node.

Its `concepts/principles.md` is a register of fifteen principles, each with its origin and the date it was corrected, and several of them are the definition on this page in its first form:

| Principle | In the vault's words | On this page |
|---|---|---|
| **P4 · Everything is a node** | “If it's mentioned, it can be focused: words, compounds, definitions, external standards, articles, actors, extracted facts.” | The smallest node is a word |
| **P6 · Fractal descent** | “Every node opens its own neighbourhood; recursion happens on demand, not up front. Depth follows attention.” | Granularity is chosen per context |
| **P7 · The junction rule** | “Two texts never link paragraph-to-paragraph. Each is lifted into its own nodes, and the graphs join node-to-node through the intermediate layer. This is what makes company graphs and regulation graphs composable.” | The jump between worlds, and why ontologies are joined rather than merged |
| **P11 · Altitude** | “Each rung is the same meaning at less resolution, and compression is lossless so long as the links hold.” | The altitude you happen to be looking from |
| **P15 · Structure points down; meaning radiates out** | “Taxonomy is merely the shape; ontology is the content.” | The meaning of a node is supplied by the ontology at its altitude |

The leading brief in that vault, dated 6 August 2026, says the thing this page took five revisions to say: *“Paragraph, then section, then document, then a set of documents. Each level is the same operation applied to a larger span, which is what makes the structure fractal rather than merely nested.”* And the reason to do it at all: *“the interesting object is not any one of their graphs but the edges between them. That connection is where meaning lives.”* The vault's notation spec adds two laws worth carrying everywhere: every statement must read aloud as a grammatical sentence and decompose into triples with no residue, and every statement must link to the span it compresses, because *“claims from memory are not allowed anywhere in this system.”*

The same vault is also mirrored in the open as a git repository, [VoiceDebrief/VoiceDebrief__Fractal-Semantic-Graphs](https://github.com/VoiceDebrief/VoiceDebrief__Fractal-Semantic-Graphs), plaintext tree and encrypted store side by side. Checked on 20 September 2026: the repository's 90 content files match the vault's HEAD file for file, and both last moved on 10 August.

## How far down does the graph go?

All the way. One grammar, eleven ontologies: from the text of a regulation, through a standard's controls, through a risk and the person who accepts it, down to a threat in one line of code on one compute instance, each rung modelled in its own vocabulary by its own author, and every one joined to the next by a named edge. The rest of this page is the evidence: **seven published vaults and three sibling sites**, each a live fractal semantic graph at a different altitude, every one openable with the read key printed on its page.

## The ladder, and who covers which rung

Eleven altitudes, eleven ontologies, one grammar. The left column is the level of the world being described; the right column names the published vault in which that level is a live graph; each name is a link to that vault's page, where its read key is. No two rungs share a schema: a regulation's articles, a standard's controls, a register's risks and a threat model's methods were each modelled by their own author in their own vocabulary. What they share is the grammar, which is why one traversal can cross all eleven.

*[diagram]*

## The grammar that survives every zoom, in full

Each altitude gets its own schema; what none of them gets to change is the grammar. It is published on [graphs.sgit.ai](https://graphs.sgit.ai/v1/grammar/index.html) and it is short: **every edge is a verb**, stated in both directions with an inverse a person in the business would actually say (`gives_rise_to` / `arises_from`, `evidenced_by` / `evidences`); **`relates-to` is banned**, because an edge with no verb carries no constraint and cannot narrow a query; **properties carry data, never meaning**, so two nodes both holding `8080` differ only in what they are connected to; **supersede, never delete**, so a correction becomes a query over everything that rested on the error; and **never render the whole graph**; render the result of a question.

The consequence is the thing the ladder above shows: zooming from an article into a paragraph, from a control into the attestation behind it, from a threat into the method it lives in, lands you in a different ontology each time, and the walk still works, because every edge on the way is a verb with an inverse and every node knows where it came from. The Standards Atlas below puts it in its own words when you open its graph view: *“You are at the top of the fractal. Each domain is its own ontology that connects up to the GDPR root and down to concepts and articles.”*

## Altitude 0: the law, as a graph you can cite

Regulation Graph · vault 73heuprz

### The EU AI Act, parsed from its own XML and hashed to the byte

Regulation (EU) 2024/1689 read from official Formex XML, decomposed into **113 articles, 500 paragraphs, 417 points, 180 recitals, 13 annexes and 68 definitions**, 1,523 nodes and 1,944 edges in all, with the SHA-256 of the retrieved bytes at the end of every provenance chain. Eleven views, including SQL and RDF exports, all client-side.

This is the bottom of the provenance ladder and the top of the semantic one: when a risk somewhere else says *touches Article 12*, this is the vault that can say what Article 12 says and prove the bytes. [The vault's page →](../vaults/regulation-graph/index.md)

Article-level citations, with halos on the articles amended by Regulation (EU) 2026/1744. There is no official consolidated text yet, so the graph composes the two.

Standards Atlas · GDPR · vault 4zv4bvmu

### “You are at the top of the fractal”

The GDPR's 99 articles as a graph whose operative meaning lives in a second layer the text never mentions: **rulings, regulators' guidance, and per-country variation**, modelled as nodes anchored to the articles they bend. The graph view is explicitly navigated *by altitude* (the Regulation, then a domain, then a concept, then the articles and the rulings that interpret them), and the layout is computed from the graph rather than drawn.

It is also the earliest experiment here and it shows: six of its 227 edges are typed `relates`, the one verb the grammar bans. Recorded rather than hidden, because the rule was written after this vault was. [The vault's page →](../vaults/standards-atlas-gdpr/index.md)

Altitude 0: the Regulation and its eight domains. Pick one to descend.

one level down

### Same grammar, one altitude lower

Descend into *Principles* and the ring is Article 5's seven principles, each a concept node connecting up to the domain and down to the articles, rulings and guidance anchored on it. Descend again and one principle shows its provenance: the pipeline stage that proposed it, the confidence it was given, and the official text it points at. Nothing about the rendering changed between the three altitudes; only the question did.

Altitude 1: *Principles*, “the spine the whole graph hangs from”, and its seven concepts, one article.

the layer the text omits

### Why a static PDF of a law is wrong and a versioned graph is not

Article 45 of the GDPR has not changed a word since 2016. What it permits has flipped four times: Safe Harbour, Schrems I, Privacy Shield, Schrems II, the Data Privacy Framework, an appeal pending. The atlas draws that as a timeline of ruling nodes over one unchanged article node, which is the whole argument for the second layer in one picture.

One article, five rulings, twenty-five years. The text is a constant; its meaning is the graph.

## Altitudes 1 to 3: the standard, the evidence, the policy

AIUC-1 conformance layer · vault 2wzct4k7

### A standard's controls, joined node-to-node to the law they cite

The AIUC-1 agent standard as data, **53 controls, 2,788 nodes, 11,610 edges** and 82 hashed source snapshots, plus a conformance layer added as one directory without changing a byte of the original. Its explorer loads *two vaults as one graph*: one of its packs is literally `The AI Act, by article (vault 73heuprz)`.

That join is where a crosswalk stops being a string. AIUC-1 publishes 1,126 crosswalks as text; **62 resolve** into Regulation Graph node ids at article level, and the traversal returns something neither vault knew alone: **8 of the 27 articles reached are amended**, so the crosswalk was written against the pre-amendment text. [The vault's page →](../vaults/aiuc-1-conformance/index.md)

Two vaults, one canvas. The chip row is the join: standard, crosswalks, *another vault's* articles, conformance, bow ties, acceptances.

the evidence rung

### Two edges that are never allowed to touch

`evidenced_by` answers *does the standard say this?* and lives in the catalogue. `attested_by` answers *does this subject do this?* and lives in the layer. A test is red if a layer edge ever reaches a source observation. Every control in scope gets a row whether or not anyone has looked, so the first build of one subject comes out **2 evidenced, 48 unevidenced, 3 contradicted**, and that is the designed answer. Unevidenced is a state, and it is the default.

53 rows, a level out of five computed from the attestations behind it, and the date each one expires.

the policy rung

### The policy is a query, and time is what breaks it

Each control's conformance state becomes a **condition** or an **exclusion** on a `policy/v1` object, and bow ties decide which consequences are covered. At build time: 1 condition met, 52 exclusions, 0 of 5 consequences covered. Move the as-of date to January 2027 with nothing edited by anybody and the one condition has expired: *“real-timeliness arriving as a consequence rather than as a feature.”* The [Licence to Operate](../vaults/licence-to-operate/index.md) vault is the same object from the other end: an agent's grant, its mandate, and the policy insuring the mandate, spent one conversational turn at a time.

Coverage by consequence, with *why not* spelled out for each.

## Altitudes 4 to 6: from a fact about your estate to a board decision

Risk Graph Explorer · vault 3simlnqe

### Answers become facts; facts give rise to risks; risks cause risks

Answer questions about a system and the register assembles: 18 facts, 37 risks, 14 provisions, seven views recomputing as you go. Risk chains run inherent-to-corporate left to right and are walkable in both directions (*leads to* navigates up, *led by* walks back to the answers that caused it), with cycles drawn as dashed edges because the cycles are real. The app declares `permissions: {}`: a vault allowed to do nothing at all. [The seven views, explained →](../vaults/risk-graph-explorer/views/index.md)

Risks that cause risks. Click either end of an edge and the graph is walked from there.

the owner rung

### The org chart, with risks flowing up it

The role risk map distinguishes what a role *holds* from what arrives *through* it because the graph says it must, so no risk is orphaned and every path terminates at the board. The same organisation under the *Typical* and *Governed* presets has the same org chart; only what is true about the agent changes, which is the whole argument in one comparison.

Assigned versus through. Nothing stops short of the board.

Agentic Browser Isolation · vault 0610gsp9

### The same exposure, in seven languages

Should an agent browse with your logged-in sessions? Seventy JSON files hold the register (risks, controls, evidence, owners, acceptances), and the same nodes are read at **seven stakeholder altitudes**, IT to Board, each owning the risk in its own vocabulary. A risk sits *pending* until its named owner accepts it personally, and only an accepted risk escalates to the altitude above. There is no deny button: accept, mitigate, or ask for more data. [The vault's page →](../vaults/agentic-browser-isolation/index.md)

IT has five risks pending; everyone above is `waiting`, because nothing has been passed up yet.

## Altitudes 7 to 11: all the way down to the compute instance

ThreatModCon 2025 · vault 0ict6flm

### Eleven linked threat models, customer to compute

This is the vault that answers the *“all the way down”* question most directly. A threat model of one system tells you very little; this one is a **graph of graphs**: eleven models linked down a zoom ladder: Customer → Business → Application → Component → Package → Class → Method → Source Code → Environment → Runtime → Compute. **51 nodes, 179 threats, 3 critical**, each layer carrying its own counts.

The demonstration is a single SQL injection traced upward from the method it lives in to the revenue it puts at risk, and then framed four ways, for the Board, the CISO, the CTO and the developer, from one fact. Everything runs inside the vault, offline. [The vault's page →](../vaults/threatmodcon-2025/index.md)

The zoom ladder, counted: 11 layers, 51 nodes, 179 threats. The bottom rung is a compute instance.

the flat view

### The whole estate on one screen, because it is one graph

Flatten the eleven layers and the result is still one graph, which is the point. A vulnerability at the bottom and a revenue obligation at the top are not in different tools with a spreadsheet between them; they are nodes a query can connect.

The same eleven layers, flattened.

## Between vaults: the edges that cross a boundary

The join above, a control in one vault pointing at an article in another, is the property that turns a set of graphs into a fractal rather than a pile. Two mechanisms carry it. The AIUC-1 layer records **595 anchors** that tie its nodes to the exact bytes they came from, verified at build and again in the browser, and resolves its crosswalks into another vault's node ids *with the CELEX identifier and a hash on each edge*. And sgit's own object model ships **typed `*.link.json` edges between vaults**, optionally pinned to a commit in the target's history: a cross-graph edge that cannot silently follow a moving target. Both are documented on [graphs.sgit.ai's reality page](https://graphs.sgit.ai/v1/shipped/index.html), which is careful to say which of its claims are running and which are argued.

The vault commit graph underneath all of this is a graph too, content-addressed over ciphertext, multi-parent, with a real merge-base, which is why the read-only query API a vault app gets (`sg.history.log`, `list`, `read`) is the same surface every explorer on this page runs on.

## What is still modelled rather than imported

The honest half of the answer. The ladder reaches the compute instance, but not every rung is fed from a live source yet:

- **Environment, runtime and compute are modelled layers.** ThreatModCon's bottom four rungs are nodes an author placed, not a live import from a CMDB, an IaC repository or a cloud account. The grammar to receive such an import exists; the connector that emits it is not published here.
- **Enterprise architecture is a gap.** No published vault holds an EA repository (capabilities, applications, data flows) as a graph joined upward to obligations. The rungs on either side of it (business capability at the top of ThreatModCon, application and component below) are there; the EA layer between the standard and the system is the one this page cannot yet point at.
- **The AIUC-1 crosswalks resolve at article level only**, where the Regulation Graph has paragraphs; and 1,064 of 1,126 target frameworks with no published graph, reported unresolved rather than forced.
- **The GDPR atlas is a seed pass**, dated 30 May 2026, illustrative and not exhaustive, and it uses the banned `relates` edge six times.
- **standards.sgit.ai models one instrument** and says so in capitals: *“ZERO crosswalks exist between any two instruments.”* The crosswalks that do exist are in the AIUC-1 vault, not on that site.
- **The agent rung is a vocabulary, not yet a join.** abp.sgit.ai's 23 capability primitives are the right shape to attach to a system's actual permission set; no published vault yet imports a real grant and computes the delta against a mandate at scale.

Named gaps get filled. Unnamed ones do not, which is why this section is here.

## The three sites that carry the argument

graphs.sgit.ai · Graphs & method · [Fractal Semantic Graphs ↗](https://graphs.sgit.ai/) · The grammar in three altitudes: five rules you can apply tomorrow, the working edge set with its numbered gaps, and the full positioning against schemas and vector search, including the four situations in which the argument is wrong. The *reality* page separates what ships from what is argued, and the examples include Article 26(5) carried from a running system to a board decision and back. · “A node is just a node. Meaning lives in the edges.” · part of the sgit.ai network

standards.sgit.ai · Risk & governance · [Laws, standards and frameworks as addressable provisions ↗](https://standards.sgit.ai/) · A citation scheme where every provision has a constructible URL and a recomputable positional hash, a grounding ladder, and the rule for agents: report which provision a claim points at, never that a requirement is met. One instrument modelled, and a status page that says so in capitals. · “Point at the provision, or you are asserting.” · part of the sgit.ai network

abp.sgit.ai · Agents & AI · [The Agent Behaviour Policy ↗](https://abp.sgit.ai/) · Four objects (the grant, the mandate, the delta between them, and the barrier that decides whether anything is actually in the way) for one agent in one deployment, written in a capability grammar of 23 `verb.object.reach` primitives. It publishes the record and never the verdict: no score, no rating, no risk level anywhere, including in the data. The rung where the graph meets a real permission set. · “You know what you asked for. You do not know what it can do.” · part of the sgit.ai network

## Open them

| Altitude | Vault | Size | Page, with the read key |
|---|---|---|---|
| Law | Regulation Graph `73heuprz` | 207 files · 14.9 MB | [regulation-graph](../vaults/regulation-graph/index.md) |
| Law + its interpretation | Standards Atlas GDPR `4zv4bvmu` | 116 files · 6.3 MB | [standards-atlas-gdpr](../vaults/standards-atlas-gdpr/index.md) |
| The lift: text → typed claims → provision | VoiceDebrief · Fractal Semantic Graphs `k6xy9z4d` | 92 files · 1.2 MB | [voice-debrief](../vaults/voice-debrief/index.md) |
| Guidance, workbook, method, frameworks | DSIT AI Risk Toolkit `0q4sfr57` | 42 files · 3.2 MB | [dsit-ai-risk-toolkit](../vaults/dsit-ai-risk-toolkit/index.md) |
| Standard · evidence · policy | AIUC-1 conformance layer `2wzct4k7` | 649 files · 43 MB | [aiuc-1-conformance](../vaults/aiuc-1-conformance/index.md) |
| Fact · risk · acceptance | Risk Graph Explorer `3simlnqe` | 33 files · 428 KB | [risk-graph-explorer](../vaults/risk-graph-explorer/index.md) |
| Owner, at seven altitudes | Agentic Browser Isolation `0610gsp9` | 104 files · 2.4 MB | [agentic-browser-isolation](../vaults/agentic-browser-isolation/index.md) |
| Policy, spent turn by turn | Licence to Operate `posrhzp3` | not measured | [licence-to-operate](../vaults/licence-to-operate/index.md) |
| System → compute | ThreatModCon 2025 `0ict6flm` | 53 files · 4.1 MB | [threatmodcon-2025](../vaults/threatmodcon-2025/index.md) |

Every read key is on the vault's own page, published on purpose; none of them can write. Agents: the machine-readable list of all thirty vaults, with ids and keys, is [/demos/vaults/llms.txt](../vaults/llms.txt). The grammar for drawing your own is at [graphs.sgit.ai/llms.txt](https://graphs.sgit.ai/llms.txt).

## How fast is it, and what does it cost?

The question a reader asked after this page went up, and it deserves a page of its own: what is the performance of this against ordinary graph engineering, given that we run with **no live database**? [Performance, cost, and running everywhere](performance.md) answers it with measurements rather than adjectives. The graph is files in object storage, the engine that answers a question is built in the reader's tab and thrown away after, and the cycle is **LETS**: Load, Extract, Transform, Save. A 617-node semantic graph opens in **94 KB and three requests**. A question answered from a cold start costs **7.8 seconds and 315 KB**, against 65.4 seconds to clone everything. Arriving in a new world and learning its rules costs **4 KB**, which is why the jump between worlds is affordable rather than theoretical. The standing cost of all thirty one graphs on this site is 295 MB of object storage, with nothing running between questions. That page also lists the six places this is slower, including the one a graph database wins outright.

[← Published vaults](../vaults/index.md)[Performance and cost →](performance.md)



==============================================================================
# Performance, cost, and running everywhere, Fractal Semantic Graphs

> Measured answer to “performance of graph engineering versus fractal graph”: no live database, files in object storage, and the LETS cycle (Load, Extract, Transform, Save) with a disposable engine in the reader's tab. A 617-node graph opens in 94 KB and three requests, a question costs 7.8 s and 315 KB from cold against 65.4 s for a full clone, an ontology costs 4 KB, and the standing cost of thirty one published graphs is 295 MB of object storage with nothing running between questions. Plus the cost model line by line, the five places the same read key runs, fractal deployment, and six places it is slower.
>
> Page: https://sgit.ai/demos/fractal-graphs/performance.html

[Home](../../index.md) / [Fractal Semantic Graphs](index.md) / Performance and cost

# Performance, cost, and running everywhere

A reader of [the Fractal Semantic Graphs page](index.md) asked the right follow-up question: what is the **performance** of this against ordinary graph engineering? The honest answer needs the architecture said out loud first, because the two are not doing the same work. We run with **no live database**. A graph is a set of files in cloud storage, read directly. The engine that answers a question is created when the question is asked and destroyed when it is answered, either in the reader's browser tab or in a serverless function that lives for one request. We call the cycle **LETS**: Load, Extract, Transform, Save. Most of the performance, though, comes from a design habit rather than a mechanism: [**start by asking what data the task at hand actually needs**](#design), and build on three layers that are already fast. Under that, three properties do the rest: **reading an encrypted file takes one request**, because the address is computed locally rather than looked up; **writes go to an append lane outside the commit tree**, so they never contend with reads; and **the cached bytes are ciphertext**, so every cache in the path can hold them without widening exposure. This page gives the measured numbers, taken on 21 September 2026 against live published vaults, then the cost model, then the part that matters most in practice: the same graph runs in a browser, a terminal, a function and a build container, with one read key and nothing installed.

## The short answer

A graph database is very good at one thing this is not trying to do, and pays for it in a way we are not willing to pay. Both columns below are real engineering positions. The question is which bill you want.

|  | Classic graph engineering | Fractal Semantic Graph |
|---|---|---|
| **Where the graph lives** | Inside a database process, in its own storage format | In ordinary files in object storage, content addressed and encrypted |
| **What runs between questions** | A server, its indexes, its replicas, its backups | Nothing at all |
| **Cost of admission** | Everything must be loaded in, and conform to one schema | Publish the files and declare the ontology. Other worlds keep their own |
| **Reading one item** | Connect, authenticate, plan, execute, serialise | **One unauthenticated GET**, because the address was derived locally from the read key rather than looked up |
| **If you need it faster** | A bigger instance | [Take the API out of the path.](#direct) The same clone is 65.4 s through the API and **2.63 s** against plain GETs, because the store is cloud storage and the bytes are ciphertext, so serving them directly is safe |
| **Where a query runs** | On the server, for every reader | In the reader's tab, or in a function that exists for one request |
| **Writes against reads** | Share the engine, so they contend | An [append lane outside the commit tree](#append). A write never touches a branch and never blocks a read |
| **What a query costs the owner** | Instance hours, whether anyone asks or not | The bytes that were actually read |
| **Joining two domains** | A shared schema, so a migration, so a project | An edge, because neither side gives up its own ontology |
| **Six hops over a hundred million edges** | **Its home ground.** Nothing here competes | Not this. See [where it is slower](#limits) |
| **Answering one question over a million** | Fast, once the server is up and loaded | Fast, and the server was never up |

The performance claim is therefore narrow and testable: **for the questions people actually ask of a semantic graph, the work is bounded by the answer, not by the graph**, and the numbers below are what that costs.

## The real optimisation is the question, not the engine

Everything below this line is detail. The architecture is fast mostly because of a design habit, and the habit is this: **start by asking what data the task at hand actually needs.** Not what the system holds, not what the schema allows, not what might be useful later. What this question needs. Once that is the first question, most performance work stops being necessary, because the expensive thing was never the engine. It was loading data nobody was going to look at.

The second half of the habit is refusing to reinvent anything underneath it. **Three layers are already fast, already solved, and already free**, so the job is to compose them rather than replace them.

| **The file system** | A high-performance indexed store with decades of tuning behind it and the operating system's page cache sitting in front. Nothing here writes a storage engine, because one is already installed |
|---|---|
| **A content-addressed hash store on top of it** | An object's name is the hash of its bytes, so a lookup is a path, deduplication is free, and a cache entry cannot be wrong. This is the layer that makes the store safe to spread everywhere |
| **A graph on top of that** | Which tells you *which bytes to ask for*. This is the part that is actually ours, and it is the part that decides how much work a question costs |

It is worth being fair about what a database does here, because the comparison is often unfair in our direction. **A database is fast largely because it keeps the working set in memory.** The buffer pool, the page cache, the in-memory index: most of the speed of a query comes from the answer already being in RAM rather than on disk. That is not cheating, it is good engineering, and it is the same insight. The difference is who chooses the working set. A database guesses it from access patterns and an eviction policy, in advance, for every reader at once. **We choose it per question, at the moment the question is asked, and throw it away afterwards.** It is the same trick, made explicit and made specific.

### Neither the disk nor the decryption is the cost

The habit only makes sense if loading is genuinely cheap, so here is what the layers actually cost. Measured on 21 September 2026 on an ordinary cloud container, on the 1.0 MB file that holds the whole DSIT graph.

| Step | Time for 1.0 MB | Rate |
|---|---|---|
| Fixed per-request overhead, before a single byte of the file | **347 ms** | [a deployment characteristic, not an architecture cost](#fixed) |
| Transfer of the 1.0 MB itself | **300 ms** | 3.5 MB/s on this link |
| Read it from local disk once it is there | **2.5 ms** | 418 MB/s |
| **Decrypt it, AES-256-GCM** | **0.35 ms** | **2,978 MB/s** |
| Parse the JSON | 3.2 ms | the largest local cost, and it is the parser |

Read that table twice. **Decryption is a tenth of the JSON parse, and half a thousandth of the transfer.** On a 59 KB shard it is 0.025 ms, which is not a number anybody needs to plan around. The same holds in a browser, where AES-GCM runs in WebCrypto against the same hardware instructions the measurement above used. Whenever somebody assumes that encrypting the data must have cost something in speed, this is the answer: at these sizes, on ordinary compute, **encryption is free**, the disk is free, and what is left is the request. Which puts the whole question back where it belongs, on how many requests you made and how many bytes you decided to ask for.

**The design rule, stated as a budget.** If you find yourself loading gigabytes to answer a question, something is wrong upstream, and no amount of tuning will fix it. Go back and cut the data, because the fix is always in the shape of the data and never in the engine.

| **Under 100 KB** | An answer. This is the normal case and it feels instant |
|---|---|
| **Around 1 MB** | A whole world at one altitude. Fine, and still under two seconds cold |
| **10 MB and up** | You are loading a store rather than an answer. Cut a slice, or move the question to a lower altitude |
| **Gigabytes** | A design error, not a performance problem. The graph exists so that this never has to happen |

## LETS: Load, Extract, Transform, Save

The familiar cycle is ETL: extract from the sources, transform, load into the warehouse you then own and must keep alive. LETS inverts the order and the ownership. The store you already have *is* the database, so you load from it, build a throwaway engine around the slice you need, answer the question, and save the answer back as new immutable files beside the ones you read.

*[diagram]*

| **Load** | Fetch the bytes you need, straight from storage over an ordinary GET, and decrypt them where they are going to be used. No query planner, no connection pool, no session |
|---|---|
| **Extract** | Pull out the slice that the question is about, and the ontology that gives that slice its meaning. In a fractal graph these are separate files on purpose, so you can take the second without the first |
| **Transform** | Build a throwaway engine around it. SQLite compiled to WebAssembly for tabular questions, an RDF store for triple questions, ordinary in-memory structures for traversals. It is created for this question and thrown away after it |
| **Save** | Write the answer back as new immutable files with their provenance, a new version rather than an edit, and **shaped for the question that comes next**. The result is now itself loadable, which is what makes the cycle compose |

**The Save step is where the compounding happens, and it is the part people skip.** Saving is not filing the answer away. It is leaving behind an artefact cut to the shape of the next question, so that the next pass through the loop loads less than this one did. The Article 9 slice in the Regulation Graph exists because somebody answered a question about Article 9 once and then saved the answer in a form that makes asking again cost 29 KB instead of a megabyte. Do that a few times and the expensive queries have all been pre-answered, each by the run that first needed them, and none of it required deciding in advance which queries would matter. **Build time replaces query time, one question at a time, paid by whoever asked first.**

**The load-bearing consequence.** Because Save never overwrites, every object is immutable, and because every object is immutable, **every cache in the path is correct forever**. The browser cache, the CDN edge, the local clone and the agent's working copy never need invalidating. That is not a tuning trick. It is the reason there is no server: the hardest thing a database does for you, keeping one mutable truth consistent across readers, is a problem this architecture does not create.

## What it actually costs, measured

All of the following was measured on 21 September 2026 from an ordinary cloud container with no special network, against two live published vaults, using the read keys printed on their own pages. Anyone can repeat it.

### Opening a graph from the command line

The vault is the [DSIT AI Risk Toolkit](../vaults/dsit-ai-risk-toolkit/index.md), 42 files, 3.2 MB of content, a semantic graph of **1,051 nodes and 1,289 edges** across five worlds.

**A version drift, caught by measuring.** That vault's [own page here](../vaults/dsit-ai-risk-toolkit/index.md) says 617 nodes and 694 edges, which was true when it was published on 20 September. The vault released 0.2.1 on 21 September and the graph grew. The figures on this page are from the file as cloned today, counted rather than quoted, and the discrepancy is only visible because the vault keeps its versions rather than overwriting them.

| Operation | Bytes moved | Time |
|---|---|---|
| Full clone, every file and the whole history | 15 MB on disk | **65.4 s** |
| Sparse clone: every path, size and hash, no content | 256 KB | **7.3 s** |
| Fetch one file that answers one question (a 59 KB topic shard) | 59 KB | **0.49 s** |
| Fetch a second file (marginal cost of the next question) | 63 KB | **0.87 s** |
| Fetch the entire graph as one file | 1.0 MB | **1.21 s**(raw GET of the same object: 0.65 s) |
| Ask again for something already fetched | 0 | **0.18 s**, no network |

The first and third rows are the whole argument. **Cloning everything costs 65 seconds. Answering a question costs 7.8 seconds and 315 KB**, and the second question costs under a second. Nothing was indexed in advance, nothing was kept warm, and no service was running before the command was typed.

The sparse clone deserves its own sentence, because it is the step that makes the rest cheap. For 256 KB you get the complete file list with every size and content hash, which means **an agent can decide what is worth reading before reading anything**. The same call against the much larger [Regulation Graph](../vaults/regulation-graph/index.md) vault, 207 files and 14.9 MB, took **7.06 s and 360 KB**. The index does not grow with the content.

### Opening the same graph in a browser

Bytes and request counts for each view of that vault's app, measured by instrumenting the browser. This is the number that decides whether a page feels instant, and it is the number a graph database cannot improve, because the bottleneck was never the query.

*[diagram]*

Four things in that chart are worth naming.

- **The landing view of a 1,051-node semantic graph costs three requests and 94 KB.** Less than a typical web font pair. The graph file is not touched, because no question has been asked yet.
- **The most expensive view is a third of the vault.** There is no view that loads everything, because there is no question that needs everything.
- **The ontology is 2 KB.** In the Regulation Graph it is 4,217 bytes and fetched in 0.95 s. That is the entire price of arriving in a new world and learning its rules, which is what makes the [jump between worlds](index.md#what) affordable rather than theoretical.
- **The query engine is 859 KB and loads only if you query.** SQLite compiled to WebAssembly ships inside the vault. A reader who never opens the query view never pays for it, and one who does pays once and then queries for free, locally, offline, for as long as the tab is open.

The Regulation Graph shows the same shape at four times the size. It holds **1,523 nodes and 1,944 edges** over the EU AI Act. Its nodes file is 816 KB and its edges file 252 KB, so the graph is about 1.05 MB out of a 14.9 MB vault. Roughly 10 MB of that vault is raw source XML, retained so every claim can be traced back to the bytes it came from, and **never loaded to answer anything**. It also ships pre-cut slices: the Article 9 slice is 29,638 bytes and fetched in 0.75 s, so a question about Article 9 never touches the 1.05 MB graph at all.

## Getting at an encrypted file takes one request

This is the property underneath every number above, and it is the one most people do not expect, because encryption is usually assumed to add a lookup. It does not here.

**The address is derived, not discovered.** Every file id in a vault is produced by HMAC-SHA256 over the read key under a named domain: `sg-vault-v1:file-id:ref`, `:branch-ref`, `:branch-index`, and so on. The CLI and the browser client both do this, from the same constants. A client that holds the read key can therefore **compute the address of the branch ref, the index and the settings before making any request at all**. There is no discovery round trip, no directory to consult and no session to establish, which is the round trip that usually dominates a small read.

**Reading is then a plain CORS GET with no auth header**, because the bytes are useless without the key. Measured against a live vault on 21 September 2026:

| Request | Returned | Time |
|---|---|---|
| One object, `GET /api/vault/read/{vault_id}/bare/data/{object_id}`, no headers | 2,364 bytes of ciphertext | **0.35 s** best of six |
| The same, a larger object | 59,324 bytes of ciphertext | **0.31 s** best of six, [the same as the small one](#fixed) |
| Five objects, one `POST /api/vault/batch/{vault_id}` | 0.08 MB | **0.87 s**, one round trip |
| **Twenty objects, one POST** | **3.76 MB** | **2.79 s**, one round trip |
| Forty two objects, one POST | **502** | The server's response-size limit. The CLI already handles this by splitting the chunk |

### What that latency actually is, and why it is not an architecture cost

It would be easy to read the numbers above as the cost of reading encrypted data. They are not. Almost all of that time is **fixed per-request overhead, and it is completely insensitive to how many bytes come back**. Measured six times each, best of run:

| One GET returning | Best | Median |
|---|---|---|
| 340 bytes | 0.331 s | 0.381 s |
| 41 KB | **0.309 s** | 0.390 s |
| 2.3 KB | 0.347 s | 0.530 s |
| 1.0 MB | 0.647 s | 0.992 s |

**A 340-byte response and a 41 KB response take the same time.** Only at a megabyte does transfer become visible at all, and then it accounts for 0.300 s of the 0.647 s. One request that returned in 4.8 s during the run is the shape of the thing: a cold start, not a slow read.

So the floor of roughly a third of a second is **the per-invocation cost of running this API serverless**. It is a deployment choice with a known fix: SG/API also runs on EC2, where a warm process is already listening and that per-invocation cost does not exist. We have not measured that deployment here, so this page does not put a number on it, but the honest reading of the table above is that **the architecture is not what costs 350 ms, the invocation model is**, and anybody comparing this against a database on a warm connection should hold that separately.

Which makes the second optimisation the interesting one, because it works on either deployment.

### Batching, which is how the fixed cost gets amortised

`POST /api/vault/batch/{vault_id}` takes **up to 100 operations in one request**, and they can be **mixed reads and writes**. Measured on small objects, so that bytes stay out of the way and only the per-object cost shows:

| Objects in one batch | Best time | Per object |
|---|---|---|
| 1 | 0.590 s | 590 ms |
| 2 | 0.394 s | 197 ms |
| 5 | 0.560 s | 112 ms |
| 10 | 0.872 s | 87 ms |
| **18** | **1.528 s** | **85 ms** |

That fits a straight line, and the line is the cost model worth carrying around:

**time ≈ 0.25 s fixed, plus about 71 ms per object, plus transfer**

Eighteen objects fetched one at a time would be about 6.3 seconds. In one batch they took **1.53 seconds, a little over four times faster**, and the saving grows with the count until the response-size ceiling stops you. This is the optimisation that matters most in practice, because it is the one that turns a page needing thirty small files into a single round trip.

The batch endpoint does more than amortise reads, and the rest is worth knowing before building on it.

| **Mixed reads and writes in one request** | Operations are `read`, `write`, `write-if-match` and `delete`, authorised per operation, so a read-then-write cycle can be one round trip instead of two |
|---|---|
| **Atomic compare-and-swap across many files** | `write-if-match` carries the SHA-256 of the content you believe is there, and **if any match fails the entire batch is rejected**. That is optimistic concurrency over a set of files, in one request, with no lock anywhere |
| **A ceiling you will meet** | 100 operations per request is the hard limit, and there is a response-size limit well before that: our 42-object read returned 502. The CLI chunks at 50, and on a 502 it splits the chunk and then falls back to presigned S3 reads per file |
| **Large objects route around the body** | Presigned URLs rather than the request body, so a big blob never has to fit inside a batch response at all |

**The next thing worth optimising, named rather than glossed.** That 71 ms per object inside a batch is server-side work, and it is close to linear, which is the signature of the objects being fetched from storage one after another inside the handler. Fetching them concurrently would bring a twenty-object batch close to the cost of a one-object batch. That, and chunking by accumulated size rather than by file count so the 502 stops happening, are the two changes that would move these numbers most. Both are in the API and the client, not in the design.

Two things fall out of all of this. The first is that **the transport is not the bottleneck anywhere**: twenty files and 3.76 MB, which is more than half the vault's bytes, came back in one round trip in under three seconds. The second is the honest correction to the clone figure above, which is worth stating rather than hiding.

**Why the 65 second clone is a client-side cost, not a transport one.** The clone log says what happened: seven commits walked, twenty eight trees walked, and **106 blobs** downloaded rather than 42, because a full clone takes the history as well as the current files. Then one batch of 50 hit the server's response-size limit and fell back to fetching those 50 files one at a time, which is most of the 65 seconds. The transport moved 3.76 MB in 2.79 seconds when asked in one request. That gap is an engineering finding for the CLI, chunk by accumulated size rather than by file count, and not a property of the architecture.

**Encryption costs 28 bytes per object, flat.** The two measurements above were 2,364 bytes of ciphertext for 2,336 of plaintext, and 59,324 for 59,296. That is a 12-byte nonce plus a 16-byte authentication tag, the same 28 bytes whether the file is two kilobytes or two megabytes. There is no percentage overhead to budget for and no padding to reason about.

**There are two ways to address a file, and the choice is a performance decision.** Pin the content-addressed object id in your page and reading it is exactly one GET, valid forever, because the id is a hash of the ciphertext and those bytes can never change. Or give a path and let the client resolve HEAD to tree to blob, which costs a small number of extra hops and always gives you the current version. Neither is better. They answer different questions, and a well-built page uses both.

## If speed really matters, take the API out of the path

Everything measured so far went through the API, and the API turned out to be most of the cost. It is worth saying plainly what that API is: **a convenience over a store, not a requirement of it**. The store is cloud storage holding encrypted objects whose names are hashes. Nothing prevents a reader going straight to the bucket, or to a CDN in front of it, with no function in the path at all.

**And nothing much is risked by doing so**, which is the part that makes this a real option rather than a dangerous one. Every object is ciphertext under a key the server never had, and every name is a hash of those bytes. Exposing the objects as ordinary public GETs discloses object sizes and request timing, which is the same exposure the API already has and which [the security model](../../security/index.md) names as an acknowledged side channel. It discloses nothing else. That is why reads need no auth header today, and it is why a bucket behind a CDN is a legitimate deployment rather than a hole.

### It already ships, and here is what it costs

The CLI has a transport for exactly this. `--transport static` points at any host that answers GETs, sniffs which of two published layouts it uses on the first successful read, then fans out **eight parallel requests at a time**. It also records every URL it touches, so a test can assert that no request ever carried key material, which is the kind of check that proves a property rather than asserting one.

So the same clone can be run twice, same client, same 106 objects, same decryption, with only the path to the bytes changed.

| Path to the bytes | Full clone of the same vault |
|---|---|
| Through the serverless API | **65.4 s** |
| **Plain GETs, no API in the path** | **2.63 s** |
| Straight off a local folder | 2.05 s |

**Twenty five times faster, with nothing about the vault changed.** The honest caveat: that static host was on localhost, so the network was free, and a real CDN would add edge latency. But the comparison still isolates what it is meant to, because the client, the objects and the work were identical in both rows. The difference is the function in the middle. If a workload is request-heavy, this is the lever, and it is a bigger one than any tuning inside the API.

### The direct path is already in production for large files

This is not a hypothetical route. Anything over **4 MB** already takes it, because that is the safe margin under the serverless base64 response limit of about 4.7 MB. The client asks the API for a presigned URL and then **fetches the bytes straight from storage**. The same fallback catches a batch that returns 502: split the chunk, and if a single object still fails, go around the API entirely and read it presigned.

Which means the architecture already has two paths to every byte, and the only reason the small case goes through a function is that nobody has needed it not to. The options from here are ordinary storage engineering rather than anything exotic.

| **A CDN in front of the bucket** | Immutable objects with hash names are the ideal cache key. Every edge holds them correctly and forever, and reads never reach the origin twice |
|---|---|
| **Ranged and parallel GETs** | Object storage serves byte ranges, so a very large object comes down as many chunks at once rather than one stream. This is how a 100 MB or 500 MB file should be read, and it is available because the store is a standard one |
| **Lower-latency storage classes** | The newer single-digit-millisecond classes, such as S3 Express One Zone, exist precisely for small-object read latency. We have not benchmarked one, so there is no number here, only the observation that the store is ordinary enough to move onto one |
| **Somewhere else entirely** | The store is cloud storage, so it is not tied to one provider. Another object store, another CDN, or a service dedicated to serving files fast will all work, because what is being served is opaque bytes at deterministic paths |

### Finding the object you want, in a handful of requests

Direct access is only useful if you can work out which object to ask for. In most cases you already know, because the id is pinned in the page or held in an index you have. When you do not, the walk is short: the branch ref, which gives you the commit, which gives you a tree, which gives you the file or the next tree down. **A couple of requests, not a clone.**

Measured against the static host, counting every GET it received: reading one named file out of a sparse clone cost **two requests**, and one of those was the client re-probing which layout the host uses, a 404 it could skip by remembering the answer. The real cost is one GET.

**This is the thing git cannot do.** Pulling one file out of a git repository generally means cloning the repository, because the objects are packed and the transport is negotiated. Here every object is individually addressable at a deterministic path, so one file is one request against a plain web server. It is also why `--sparse` exists and works: **structure only, 256 KB and 7.3 s, then fetch content on demand**, which is the shallow clone of this world. `--bare` takes the structure with no working copy at all.

One gap, stated because it is the cause of the 65 second figure: **there is no history-depth flag today.** A full clone takes every version of every file, 106 blobs where the current tree is 42 files. A sparse clone avoids the content but still walks all seven commits and twenty eight trees. Depth control, so that a reader can ask for the current tree and nothing older, is the missing option, and it would do more for clone time than anything else on this list.

## Live evidence: a whole knowledge base served from encrypted vaults

[sgraph.ai/en-gb/library/](https://sgraph.ai/en-gb/library/) is a public knowledge base whose content does not exist on the web server. It is a static shell that reads everything out of two encrypted vaults, in the visitor's browser, with read keys published in the page on purpose.

| **The shell** | 28 KB of HTML plus 242 KB of CSS and components, **270 KB in total**, entirely static and cacheable by anything. Measured 21 September 2026 |
|---|---|
| **The content** | Every article, the navigation tree, the blog and the what's-new entries come from vaults, decrypted in the tab. The server hosting that site cannot read a word of what it is serving |
| **Pinned reads** | Blog and what's-new entries carry their content-addressed object id in the page source, so opening one is a single GET straight to the bytes |
| **Resolved reads** | The navigation is deliberately *not* pinned. Its own source comment says why: no hardcoded nav object id, the client resolves HEAD to tree to blob at runtime, so the nav is always current |
| **The cache** | A small script loaded before anything else patches `fetch` and keeps immutable objects in IndexedDB. See below |

That is the architecture argued on this page, running as somebody's production documentation site rather than as a demo. The interesting part is not that it works. It is that the performance profile is the one a plain static site has, while the data underneath it stays encrypted, versioned and owned by whoever holds the vault key.

## Append mode: writes that never touch the graph

The read path is only half of it. Writing into a vault would normally be the expensive, contended operation: read the current state, modify, commit, rebuild the tree, take a lock, resolve a conflict. **Append lanes skip all of that.**

A lane lives at `bare/append/{token}/pending/`, **outside the version-controlled commit tree**. The consequence is stated plainly in [the API documentation](../../api/append-lanes.md): appends never touch a branch and never conflict with a push. The performance implications follow directly.

| **A write is one POST** | The token goes in the body, and the call is **account-less**: no access token, no session, no login. Nothing is read before writing, so there is no read-modify-write cycle to lose a race in |
|---|---|
| **Nothing is rebuilt** | No commit, no tree, no index update, no branch move. The object is placed in a lane and that is the whole operation |
| **Writes never contend with reads** | The lane is not in the commit tree, so a reader walking the graph never looks at it. A million appends do not slow a single read, and they cannot conflict with somebody else pushing at the same moment |
| **The response is deliberately blind** | `{"ok":true}`, with no id and no count. The server does no extra work to compose an answer and leaks nothing about lane contents by timing or size |
| **Senders scale sideways** | Register several anchors and each sender writes into their own lane. One correspondent flooding you does not bury another, and revoking one sender is removing one anchor with no effect on the rest |

The published limits are the shape of the envelope: 5 MB per payload, 1,000 pending per token, 100 file ids per batch, 3 MB inline content, pages of 50 up to 200. This is what makes telemetry, logs, signals, control messages and state flows cheap enough to be ordinary, and it is the transport behind [vault-to-vault messaging](../../docs/vault-messaging.md). A vault whose read key is public can collect anonymous usage from its own readers without anybody holding a credential that could change it.

## Caching encrypted data, which turns out to be the easy case

The usual reason not to cache aggressively is that a cache becomes a second place the data lives, with its own exposure and its own staleness. Neither applies here, and both for the same reason.

- **The cached bytes are ciphertext.** A cache holding them is not a trust boundary, because the decryption key never goes near it. The browser cache, IndexedDB, a CDN edge, a corporate proxy and a local clone can all hold vault objects without widening exposure by one byte. That is why a vault can sit behind a CDN at all.
- **The name proves the bytes.** An `obj-cas-imm-` id is SHA-256 *over the ciphertext*. A cache entry under that name can never be stale and can never be wrong, so no invalidation logic is needed anywhere. It also gives deduplication without the server ever knowing a byte of plaintext, and it makes the caching rule derivable from the id alone.
- **Mutable refs are the exception, and the failure is silent.** A stale ref renders a previous commit's tree from ciphertext that is itself perfectly valid, so nothing errors and the reader simply sees an old version of the vault. Refs must never be cached. [The caching contract](../../api/vault-objects.md) is explicit about the split.

The library site above ships this as a small script loaded before any module, which patches `fetch` and does three things: keeps immutable objects in **IndexedDB so later page loads need no network round trip at all**; collapses concurrent callers for the same URL into a single request, which it says was introduced to kill a duplicate fetch between two navigation components; and times out in-flight entries after 30 seconds. It labels every response it serves, `idb-hit`, `inflight` or `network`, and emits an event per fetch, so the caching is observable rather than magic.

**A gap found while measuring this, reported rather than smoothed over.** Our own [caching contract](../../api/vault-objects.md) says an immutable object should be served with `Cache-Control: public, max-age=31536000, immutable` and a ref with `no-store`. On 21 September 2026 the read endpoint returned **no `Cache-Control` header at all** for an immutable object, and the CDN reported a miss. The mechanism is unaffected, because the client cache keys on the id rather than trusting a header, which is the more robust design and is exactly why the library site ships its own. But the documented header is not live on that path today, and the page that documents it should not be read as describing what is currently served.

## Restructuring into context is the compression

The fractal property is usually argued as a point about meaning: each world keeps its own ontology, so nothing is forced to conform. It is also, and less obviously, a point about **volume**. Restructuring data into context *is* compression, and unlike ordinary compression it costs nothing to reverse, because every level keeps the edge down to the level below.

Here is the ladder with real bytes, measured in the [Regulation Graph](../vaults/regulation-graph/index.md) vault, which models the EU AI Act.

| Altitude | What it is | Bytes | Against the level below |
|---|---|---|---|
| **The source** | The law as published, raw Formex XML, retained so every claim traces to the bytes it came from | 11,216,043 |  |
| **The graph** | Nodes and edges: 1,523 nodes, 1,944 edges, the whole instrument | 1,073,915 | **10x smaller** |
| **One article's slice** | Article 9, pre-cut because it was asked about | 29,638 | **36x smaller** |
| **The ontology** | The rules of this world: partitions, namespaces, what may and may not be claimed | 4,217 | **7x smaller** |

Top to bottom that is **11.2 MB down to 4.2 KB, a factor of about 2,660**, and not one byte has been thrown away. The source is still there, still hashed, still one link below. This is why the fractal structure is a performance feature rather than only a modelling one: **you query the small thing, and you follow the link down only when the answer actually requires it.** A reader asking what the Act says about risk management systems loads 29 KB. A reader who then wants to see the exact published wording follows an edge and loads that. Nobody loads 11 MB, and nobody is prevented from reaching it.

The same shape is in the [DSIT vault](../vaults/dsit-ai-risk-toolkit/index.md), where 503 KB of retained sources sit under a graph, under an ontology of 2,336 bytes that explains the whole thing.

**Which is why this scales in the direction that usually breaks things.** In a schema-first system, more data means a bigger index, more memory and a bigger machine: the cost of a query grows with the size of the store. Here it does not. The store can be gigabytes or terabytes, and **what a question loads stays in the megabytes, because the graph is what tells you which bytes matter.** Adding a terabyte adds nodes you did not load. That is the claim worth testing against your own data, and it is the one that makes the architecture interesting at scale rather than merely cheap at rest.

## Why it is fast, in four sentences

| **Never render the graph, render the answer** | The unit of work is the question, not the dataset. Traditional graph tooling optimises traversal over a loaded graph. This skips the loading, which is the part that was expensive |
|---|---|
| **Each world is small because each world keeps its own ontology** | There is no global schema to carry around, so a traversal stays inside one world until it deliberately crosses an edge. Crossing costs one small file. This is the performance benefit of the fractal property, and it is not an accident of it |
| **Immutable and content addressed, so every cache is correct** | The CDN is the read replica. The browser cache is the local index. Neither can ever be stale, because an object's name is its content, and neither is a trust boundary, because what it holds is ciphertext |
| **The address is computed, not looked up** | File ids are derived by HMAC from the read key, so reading an encrypted file is one unauthenticated GET with no discovery round trip, and twenty of them are one POST |
| **And the design does most of it** | The habit of asking what data this question needs, on top of three layers that were already fast, beats any amount of engine tuning. Decryption runs at 2,978 MB/s and a local read at 418 MB/s, so [the only real variables are how many requests you made and how many bytes you asked for](#design), and [a batch collapses the first of those](#batching) |

## The cost model, which is the part that changes the decision

Performance arguments are usually won or lost on the invoice rather than the benchmark. Here is what is on ours and what is not.

| What you normally pay for | Here |
|---|---|
| Database instance hours, around the clock | **Zero.** There is no instance |
| Memory sized to hold the index | **Zero.** The index is a 256 KB file, and it is the reader who holds it |
| Read replicas for concurrency | **Zero.** Concurrency is the CDN's problem, and it is already solved |
| Backups, snapshots, point-in-time recovery | **Zero as a separate line.** Every version is already retained, because nothing is ever overwritten |
| A staging copy of the database | **Zero.** A clone is a clone. That is the whole mechanism |
| Query compute | **Paid by the reader's own device**, in the tab they already have open, or by a function that ran for a fraction of a second |
| Storage | **The only standing line.** Object storage at rest |
| Egress | **The only variable line.** The bytes that were actually read, which the numbers above show is a small fraction of what is stored |

To put a size on the standing line: the entire published estate on this site, [thirty one vaults](../vaults/index.md), is **2,662 files and 295 MB**. That is the whole corpus, including a 66 MB vault and a 43 MB one. It sits in object storage and costs what a third of a gigabyte costs, which at every major provider's standard rate is small change per month. There is no second bill, because there is no second thing running.

The shape of this matters more than the absolute figure. **Cost scales with what is read, not with what exists, and not with time.** A graph nobody opened this month cost only its storage. A graph that got a hundred thousand readers cost its egress and nothing else, because every one of those readers brought their own compute. There is no capacity to plan, nothing to right size, and no traffic spike that can produce an outage in a component that does not exist.

**The part that surprises people.** Scale to zero is normally a property you buy with a serverless platform and give back the moment you attach a database, because the database cannot scale to zero: it is holding the state. Here the state is in files, so the zero is real. Between questions, this architecture is *not running*, in the literal sense, and it still answers the next question in under a second.

## Running everywhere, on one read key

Because the graph is files and the engine is disposable, the same artefact runs in four very different places with no porting, no build, no account and nothing installed beyond what is already there.

| Where | What it needs | What it does |
|---|---|---|
| **A browser tab** | The URL and the read key in the fragment | Fetches ciphertext over ordinary CORS GETs, decrypts in the page, runs SQLite in WebAssembly. [The primitive is documented](../../docs/vault/reading-a-vault-file.md) and every live embed on this site uses it |
| **A terminal** | `pip install sgit-ai` | Clone, sparse clone, fetch one file. The measurements above were taken this way |
| **A serverless function** | Outbound HTTPS | Load the slice, build the ephemeral engine, answer, return. Nothing to keep warm and nothing to tear down, because the function dying *is* the teardown |
| **A CI container or an agent's sandbox** | The read key as a variable | The same clone the human gets, in a pipeline, with the history attached so a build can assert on what changed |
| **A static host with no backend at all** | GitHub Pages or an S3 bucket | Deterministic GET paths and client-side decryption, degrading cleanly to read only. [Documented here](../../docs/vault/static-hosting.md) |

The same applies to the API itself, which is the point most easily missed. **SG/API is not tied to a serverless runtime.** The measurements on this page were taken against the serverless deployment, which is why every request carries the invocation cost described above. The same API runs on EC2, with a warm process already listening, and that cost is simply not there. And [the API can be left out of the path altogether](#direct), with readers going straight to the bucket or a CDN in front of it, which measured 25 times faster on the same clone. **Where the bytes are served from is a deployment decision, separate from the architecture**, and it is the right lever to reach for when a workload is request-heavy rather than byte-heavy.

**And a real database comes with it, wherever it lands.** A browser tab or a function can stand up a full SQL engine over the slice it just loaded: SQLite compiled to WebAssembly, in memory, with real indexes and real joins. That is not a workaround for lacking a server. It is the same thing the managed services do, and it is worth noticing that they do it: plenty of serverless and scale-to-zero database products work by loading the dataset into an in-memory SQLite or MySQL when an instance wakes, and serving queries from there. The dataset being small enough to hold in memory is what makes them viable. **We do explicitly what they do implicitly**, with two differences: the working set is chosen by the question rather than by an instance lifecycle, and nothing has to wake up, because the engine is built where the answer is needed.

This is also the disaster recovery story, and it is short. Every reader who ever cloned has a complete, verifiable copy including history. There is no primary to fail over from.

## Fractal deployment: the same shape at every altitude

The architecture repeats the property the graphs have. A vault holds files. A vault can hold another vault, by reference, with its own owner and its own read key. A vault can hold the app that reads it, and that app can hold the engine that queries it. A site can read a vault it does not own. At each of those altitudes the thing you are looking at is the same kind of thing, addressed the same way, opened with the same one credential.

| **Deploy one graph** | Publish the files. The read key is the deployment |
|---|---|
| **Deploy a graph of graphs** | [Sub-vaults](../../docs/vault/sub-vaults.md): a link file pointing at another vault, which has its own owner, its own key and its own ontology. Nobody merges anything |
| **Deploy it inside somebody else's boundary** | The same files in their bucket, or their GitHub Pages, or their air-gapped copy. The app does not care where the GETs are answered from |
| **Deploy the reader, not the data** | A site page that reads a vault it does not own, decrypting in the visitor's browser. The trust direction inverts and [the surfaces page](../../docs/surfaces.md) says how |

The practical consequence for anyone with a data boundary to respect: **the deployment unit is a set of files and a key**, so putting a graph inside a regulated environment, a customer's tenancy or a machine with no internet is a copy, not a project. And two organisations can join their graphs by exchanging an edge and a read key, without either one adopting the other's schema or hosting the other's database.

## Where it is slower, stated plainly

This page would not be worth sending if it only listed wins.

- **A full clone is slow, and not for the reason it looks.** 65 seconds for 3.2 MB, but the same clone against plain GETs with no API in the path took **2.63 seconds**. It is slow because it takes the history too, 106 blobs rather than 42 files, and because one batch of 50 exceeded the server's response-size limit and degraded to 50 individual fetches. None of that is the architecture. Until it is fixed, use the sparse clone or [the static transport](#direct).
- **There is no history-depth flag.** You can skip the content with `--sparse`, but you cannot yet ask for the current tree without its ancestors. That is the single change that would most improve clone time.
- **Every request pays about a third of a second before it returns a byte**, on the serverless deployment measured here. That is the invocation, not the read, and it does not grow with the response. It is also the most improvable number on this page: batch up to a hundred operations into one request, or run SG/API on EC2 where a warm process is already listening.
- **There is no server-side query.** Whatever the client needs, the client downloads. That is fine at a megabyte and wrong at a gigabyte, which is why partitions and pre-cut slices are a design step rather than an optimisation you reach for later.
- **Deep traversal over a very large single-domain graph is not our ground.** Six hops across a hundred million edges in one schema is exactly what a graph database was built for. Use one. The fractal argument is about the case where those hundred million edges were never going to live in one schema in the first place.
- **Writes are single writer per branch.** There is no concurrent multi-writer transaction, by design. [The two-branch model](../../docs/two-branch-model.md) is how several agents work without one.
- **Cutting good slices is real work.** The Article 9 slice is fast because somebody decided Article 9 was a question worth pre-answering. Build time replaces query time, and the judgement of what to cut does not come for free.
- **Revocation is not retroactive.** A published read key cannot be unpublished, and anyone who cloned keeps their copy. That is the same property as the disaster recovery win, seen from the other side. [The credentials page](../../docs/credentials.md) is explicit about it.

## Repeat the measurements

Every number on this page came from these commands, against a vault whose read key is published on its own page and cannot write anything.

```
$ pip install sgit-ai
$ time sgit clone <read-key> dsit
  42 files, 3.2 MB                                  65.4 s
$ time sgit clone --sparse <read-key> sparse
  structure only, 256 KB on disk                     7.3 s
$ cd sparse && time sgit fetch data/questions/security.json
  59 KB                                              0.49 s
$ time sgit fetch data/graph.json
1.0 MB, the whole 1,051-node graph                 1.21 s
         the raw GET of that object, without the client: 0.65 s
```

The direct path needs no vault host at all, only something that answers GETs:

```
$ sgit clone --transport static --base-url https://<any-get-host>/ <read-key> v
  106 objects, 60 files extracted                    2.63 s
  the same clone through the API:                   65.40 s
```

The transport figures used no client at all. One encrypted object, no auth header, no account:

```
$ curl "https://send.sgraph.ai/api/vault/read/0q4sfr57/bare%2Fdata%2F<object-id>"
  59,324 bytes of ciphertext                         0.63 s
$ curl -X POST "https://send.sgraph.ai/api/vault/batch/0q4sfr57" \
       -d '{"operations":[{"op":"read","file_id":"bare/data/<id>"}, ...]}'
  20 objects, 3.76 MB, one round trip                2.79 s
```

Object ids come from `sgit ls --json` against a sparse clone, which prints every path with its size and its `blob_id` without downloading anything.

The disk and crypto figures are local, so they need no vault at all. Decryption was timed over 200 iterations of AES-256-GCM on random data of each size, after a warm-up, using the same `cryptography` library the CLI uses:

```
$ python3 -c "measure AESGCM(key).decrypt over 1.0 MB, 200 runs"
0.351 ms per call                              2,978 MB/s
  the same call on a 59 KB shard: 0.025 ms
```

The read key is on [the vault's page](../vaults/dsit-ai-risk-toolkit/index.md), published on purpose. Browser figures were taken by instrumenting the page and recording every response, so they are exact byte counts rather than estimates, with network latency excluded; the latency numbers above are from the live API over an ordinary connection. Agents: the machine-readable list of every vault, with ids and read keys, is [/demos/vaults/llms.txt](../vaults/llms.txt).

## The answer to the question, in one paragraph

Most of the win is a design habit rather than a technology: ask what data this question needs, and build on three layers that are already fast, the file system, a content-addressed hash store, and a graph that tells you which bytes to ask for. Decryption runs at nearly 3 GB/s and a local read at 418 MB/s, so what is left is the request: a fixed cost of roughly a third of a second on the serverless deployment, insensitive to size, which a batch of up to a hundred operations amortises away and a warm process on EC2 removes. The remaining variable is how many bytes you decided to load, and the fractal structure is what keeps that number small, by restructuring data into context and keeping a link down to the source. Graph engineering and fractal semantic graphs are not competing on the same benchmark. A graph database makes traversal fast by first making you pay to get everything inside it, and then keeps charging while nobody is asking. A fractal semantic graph leaves the data as encrypted files, lets each domain keep its own ontology, and builds a disposable engine around the small slice a question actually touches. Reading one of those files is a single unauthenticated GET, because the address was derived from the read key rather than looked up, and twenty of them are one POST. Writes go to a lane outside the commit tree, so they never contend with reads. The cached bytes are ciphertext, so every cache in the path can hold them safely and none of them can go stale, because an object's name is a hash of its content. The measured result is a 1,051-node graph that opens in 94 KB, a question answered in under eight seconds from a cold start with nothing running, a marginal question under a second, and an estate of thirty one graphs whose entire standing cost is 295 MB of object storage. What you give up is deep traversal over one enormous single-schema graph. What you gain is that the graphs you could never have merged into one schema can now be connected by an edge, and that the whole thing runs in a browser tab.

[← Fractal Semantic Graphs](index.md)[The vault that was measured →](../vaults/dsit-ai-risk-toolkit/index.md)



==============================================================================
# A vault app, live inside this page, sgit.ai demos

> The complete walkthrough: create a vault app, push it, derive and publish the read key, and open the app live inside a sgit.ai page in a sandboxed iframe with a postMessage window.sg bridge.
>
> Page: https://sgit.ai/demos/vault-app-embed.html

[Home](../index.md) / [Demos](index.md) / Vault app embed

# A vault app, live inside this page

Below is an application running out of an encrypted vault, embedded in this page with nothing but a **published read-only key**. This walkthrough is the complete process that produced it, every command, the key that is deliberately public, and the one that never will be.

**The one-sentence mechanism:** the vault's ciphertext is fetched from the SG/Send server over CORS, decrypted in your browser with the read key printed on this page, and the vault's `index.html` is booted inside a sandboxed iframe with a `window.sg` bridge, the same shape SG/Vault's own vault-in-vault embedding uses. No copy of the app or its content exists on sgit.ai.

## The live embed

Click to open it. The status line inside the app will read `content: sg.vfs.readText("content.json") — live from the vault`, which is the bridge proving itself: the app asked the embed host for a vault file and got it.

Loads ~10 encrypted objects from `dev.send.sgraph.ai` and decrypts them here. Nothing you do in it can write, the page only holds a read key.

## How this vault was made, end to end

**1, Write the app.** A vault app is one self-contained `index.html`, CSS and JS inlined, content in `content.json`, generative SVG instead of image files, plus an `app.json` that auto-launches it. It follows the [authoring contract](../docs/vault/vault-apps.md): no `<link href>`, `<script src>` or `<img src>` against vault paths, content read via `sg.vfs.readText` with an inlined fallback, and `sg-app-ready` posted when rendered.

```
demo-vault-gallery/
├── index.html      # the app — one file, contract-compliant
├── content.json    # the editable content the app reads over the bridge
├── app.json        # { "entry": "index.html", "present": true, "auto_open": true }
└── README.md
```

**2, Make the folder a vault and push it.**

```
$ sgit init --existing .
  Vault key: <passphrase>:4bshby5n   ← saved to a password manager. Not printed here, not ever.
$ sgit commit -m "Field Notes v1: app, content, README" && sgit push
  Push complete. Pushed 1 commit(s), 4 object(s) uploaded.
```

**3, Derive the read key.** It is computed one-way from the vault key: it can decrypt everything in the vault and can never be turned back into write access.

```
$ sgit dev derive-keys '<vault-key>'
  read_key: 2848993a68c02a33…   ← this one is safe to publish. See below.
```

**4, Publish the read key.** Deliberately, in full, in this page's source:

```
vault id : 4bshby5n
endpoint : https://dev.send.sgraph.ai
read key : 2848993a68c02a33ea5582902c391901191e53680d35b36c0e76185d4107ad81
```

Anyone can take those three lines and read this vault, from the CLI (`sgit clone --read-key 2848993a68c0… 4bshby5n`), from their own page, from a script. That is the point: **read access is a capability you can hand out**, without an account, without the host mediating it, and without it ever becoming write access. A write attempt with this key is refused by construction, try it.

**5, Embed it.** The host on this page is [`assets/vault-embed.js`](../admin/index.md), ~170 lines: derive the ref id with HMAC-SHA256, fetch ciphertext over CORS, decrypt with Web Crypto, boot the app in an iframe with `sandbox="allow-scripts"` (opaque origin, the app gets no cookies, no storage, no reach into this page), and answer its `sg.vfs` calls over postMessage.

## What the app can and cannot do in here

| Capability | In this embed | Why |
|---|---|---|
| `sg.vfs.readText` / `sg.vfs.read` | works | served by the host from decrypted vault objects |
| `sg.loadCss` / `sg.loadJs` | works | same read path, injected into the frame |
| any mutation (`sg.fs.*`, `sg.vault.*`, …) | impossible | the page holds only a read key. There is no write capability to misuse, not even by a bug in the host |
| reach this page, cookies, storage, top navigation | blocked | `sandbox="allow-scripts"` and an opaque origin; the only channel is postMessage |

## Embedding the full SG/Vault UI, the gap closed

The embed above is our minimal host: ~170 lines, enough bridge for a read-only app. The obvious next step was embedding the *real* SG/Vault interface, App-Mode chrome, or the vault browser with its FILES / SGIT / SETTINGS rail. When we first ran that experiment it worked in every respect but one: the credential. The loader documented a read-only format but the client rejected it, and the CLI's `64hex:vault_id` shorthand was parsed as a passphrase, PBKDF2'd, and derived the wrong file ids (we measured `abfd8ea0f1a2` where the vault's real ref id is `11ea50e81f4d`, hence "Vault not found"). We filed both as asks.

**They landed.** The deployed loader now detects a read-key credential as **format 6** (`<64-hex read_key>:<vault_id>`, matching what `sgit clone` already accepted) and, critically, *checks it before the passphrase formats*, which is exactly the ordering bug we hit. It also strips the sgit CLI's canonical key prefixes before detection, so a key pasted straight from new CLI output is understood, including `sgit_rk1_`, the read-only one, which is the form we publish. (Its write-credential sibling is the prefix our own build refuses to let onto this site at all: the release validator treats that string as a leak and fails the build, which is why you will not find it written out here.) Re-running the same experiment against the live build:

| Question | Answer | Evidence |
|---|---|---|
| Can the vault UI be iframed at all? | **Yes** | no `X-Frame-Options`, no `frame-ancestors` |
| Does App Mode work inside a cross-origin iframe? | **Yes, fully** | the complete HUD: toolbar, URL bar, read/write badges |
| Can it open with *only the read key*? | **Yes, now** | all three forms parse in the deployed loader (`hex:id`, `sgit_rk1_hex:id`, and the legacy `id hex`); App Mode booted this Field Notes app from the published read key alone, six SVG studies rendered, the app's own status line reading `content.json` over the bridge |
| Does the vault browser open read-only? | **Yes** | `vault-shell` with the FILES / SGIT / SETTINGS rail, the real decrypted tree (4 files, 10.6 KB), and an explicit `R1 W0` + **Read-only** badge in the chrome |
| Is the SGit view reachable? | **Yes, but still no deep-link** | driving the nav reaches HISTORY / REFS / TREE / BRANCHES / STATUS / REPAIR with both real commits listed; no URL selects a view, so a host page cannot frame the SGit view *in isolation*. The one ask still open. |

So the credential gap is closed, and the consequence is the point of this whole page: **a published read key is now enough to embed the official interface**: no account, no token, no write capability anywhere in the chain. And the mechanism got better than the one we first tested: the UI now ships an **embed protocol**, so the host page hands the key over a validated `postMessage` handshake instead of a URL fragment. The key never appears in any URL, is never written to the frame's storage (it lives in the frame's memory for the session), the frame proves it is the right recipient before the key is sent, and the host gets structured `vault-ready` / `vault-error` events back instead of guessing from load timings.

Below is exactly that, both surfaces, opened with the same published key printed further up this page, loading on click because they pull the full UI from another origin. The area is deliberately wider than this text column, because the vault browser is a full working surface, and there is a full-screen button for vaults with a big UX.

Loads `dev.vault.sgraph.ai` in an iframe and completes the embed handshake. Nothing on sgit.ai ever sees more than the published read key it already prints.

**What is still not possible, precisely.** The two buttons above select a *surface* (App Mode or the vault browser). They cannot select a *view* inside the browser: the SGIT inspector and SETTINGS panels are one click away on the left rail, but the embed message carries only `{key, mode, deepLink}` where `deepLink` is a file path. There is no field that names a view, and view switching stays an in-page event. So "open straight onto the commit history" is still one small protocol field away, and [the briefing](../docs/briefs/briefing-sgvault-ui-embed.md) now states exactly that ask: an optional `view` field on `vault-open`, applied after mount. Everything else on this page works today.

## Honest scope

Two hosts now run on this page, and keeping both is deliberate. The **minimal** host is ~170 lines and shows the protocol with nothing hidden: derive, fetch, decrypt, answer `sg.vfs` over postMessage. The **official** host is the real product, full `window.sg` surface, permissions, HUD chrome, and now an embed handshake that keeps the key out of URLs and storage. Read the small one to understand the mechanism; use the big one to see what a product built on it feels like. Everything above is live and reproducible from the commands on this page.

| Shape | Evidence status | Copy or reference |
|---|---|---|
| Gallery (app + content) | **LIVE**, the embed above reads the real vault on every load | **Reference**, a push to the vault changes this page's embed with no rebuild |

## Related

- [Building vault apps](../docs/vault/vault-apps.md), the authoring contract this app follows
- [A live site whose host cannot read it](../case-studies/live-vault-docs.md). The same read path rendering markdown docs
- [Sub-vaults](../docs/vault/sub-vaults.md), vault-in-vault, the pattern this embed mirrors
- [The plan](../admin/plans/why-expansion-plan.md), two more demo vaults (a report, a two-agent inbox) follow this template

[← Demos](index.md)[Building vault apps →](../docs/vault/vault-apps.md)



==============================================================================
# The Strategy in Seven Maps, a real document republished from a vault, sgit.ai demos

> The actual SG/Send strategy (eight Wardley Maps, published on LinkedIn in May 2026) served live from an encrypted vault with a published read key, plus the audit that found the original vault could NOT publish its key (its own write credential was inside its content) and the republish pattern that fixed it.
>
> Page: https://sgit.ai/demos/strategy-maps.html

[Home](../index.md) / [Demos](index.md) / The Strategy in Seven Maps

# A real strategy document, republished from a vault

This is not demo content. It is the actual SG/Send strategy, eight Wardley Maps with commentary, written by the founder, [published on LinkedIn](https://www.linkedin.com/feed/update/urn:li:ugcPost:7464691060775120896/) in May 2026, served live below from an encrypted vault with a published read-only key. And the process of publishing it is itself a security lesson, so that is on this page too.

## The live embed

The vault's own app, the scrollable strategy essay with the eight maps, click-to-zoom included. Every byte, including the PNG maps, is fetched as ciphertext and decrypted here.

~30 encrypted objects (~900 KB, mostly the map PNGs) from `dev.send.sgraph.ai`, decrypted in your browser.

## Why this vault could not simply publish its read key

The original lives in a vault created in May 2026, before today's key practices. Asked "is it OK to share its read key?", we audited it, and the answer was **no**, for reasons worth publishing because they generalise:

| Finding | Why it blocks publishing the read key |
|---|---|
| **The vault's own write credential was inside its content.** A production briefing in the vault documented the clone command, including the vault's read-write token, verbatim. | Publishing the read key would hand every reader the *write* key. This is the general trap: a read key exposes everything ever committed, including documentation that casually quotes credentials. |
| **Server-side bookkeeping with live tokens.**`.vault/owner/public-previews/` held records containing `delete_auth` tokens, capabilities to delete the published previews. | A read key decrypts the whole tree, dot-folders included. Operational bookkeeping and publishable content were in the same trust boundary. |
| **Legacy low-entropy credential.** The vault's keys derive from a legacy dictionary-words-plus-digits token, a small keyspace by construction. | Even with the content clean, "public read, protected write" is only as strong as the write credential. This class of token is being retired for exactly this reason. |

**The fix is the pattern to copy:** republish, don't retrofit. The content was copied out, the credential quotes redacted (with a visible publication note in the affected file), the operational bookkeeping and test debris dropped, and the result committed to a *new* vault (`ookq4mn4`) with a full-entropy key that has never appeared anywhere. Only then was the read key derived and published:

```
# the audit, in one honest line: grep before you publish
$ grep -rniE "token|secret|key|delete_auth" . --include="*.md" --include="*.json"
# the republish
$ sgit init --existing .   # fresh vault, full-entropy key — saved to a password manager
$ sgit commit -m "republished, credentials redacted" && sgit push
$ sgit dev derive-keys '<vault-key>'
  read_key: 451c4c1e28fbb24a…   ← published below, in full, on purpose
```

```
vault id : ookq4mn4
endpoint : https://dev.send.sgraph.ai
read key : 451c4c1e28fbb24a7f350bb3f107b2c103d69ed363167029ef9c9000ff76c07b
```

The original vault is untouched and stays private. Its history, which contains the credential-bearing briefing, is not carried over: a republish is also how you shed a history you cannot publish.

## What this demo adds to the embed host

The [first demo](vault-app-embed.md) was built without image files. This app loads eight PNG maps by setting `img.src` to vault paths, which, inside a sandboxed frame, resolve against an opaque origin and fail. The embed host now does what the real SG/Vault host does: a `MutationObserver` intercepts vault-path images, reads the bytes over the bridge, and swaps in `blob:` URLs. The maps you see above each travelled as ciphertext.

| Shape | Evidence status | Copy or reference |
|---|---|---|
| Report / strategy microsite | **REAL**: a production artefact, published externally in May 2026; not authored for this demo | **Reference**: the embed reads vault `ookq4mn4` live; a push updates this page with no rebuild |

## Related

- [The first demo](vault-app-embed.md), the walkthrough of the embed mechanism itself
- [The day we leaked our own vault key](../case-studies/exposed-vault-key.md), the incident behind the audit habits used here
- [Briefing to the SG/Vault UI team](../docs/briefs/briefing-sgvault-ui-embed.md), the path to embedding the official UI instead of our minimal host

[← First demo](vault-app-embed.md)[All demos →](index.md)



==============================================================================
# sgit, on a Wardley Map (sgit.ai demos)

> Six Wardley Maps analysing sgit's positioning) starting with where git wins, drawn as inline SVG and served as a second app from the same encrypted vault as the SG/Send strategy essay: one vault, two entry points, one published read key.
>
> Page: https://sgit.ai/demos/sgit-maps.html

[Home](../index.md) / [Demos](index.md) / sgit on a Wardley map

# sgit, on a Wardley Map

Six maps analysing sgit's own positioning, starting with where git wins, because a map that flatters its author is not a map. It lives as a **second app inside the same vault** as the SG/Send strategy essay: one encrypted store, two entry points, both openable with the one read key already published on this site.

**What is new here technically:** a vault is not limited to one app. This vault (`ookq4mn4`) now carries two, `index.html` (the strategy essay) and `sgit-maps.html` (this analysis), and the embed below opens the second by passing an `entry` to the same host that opens the first. The maps are not images: each is drawn as inline SVG from data in the page, decrypted in your browser.

## The live embed

The links between the two apps work *inside* the embed: the header of this analysis links to the strategy essay and back, and the embed host remounts the frame on the new entry, vault apps cross-linking under a read key.

Same vault and read key as [the strategy essay demo](strategy-maps.md), only the entry differs.

## The six maps, in one paragraph each

1. **Version control, today**: git at full strength: a commodity whose moat is the platform layer above it, all of it resting on the host reading plaintext.
2. **The files that cannot follow**: the same need with one changed constraint, and a hole in the map where its foundation should be: nothing on the right is both versioned and unable to read you.
3. **sgit's move**: no new verbs; invert the bottom layer instead. Encrypted, content-addressed objects make the store a commodity *because* it cannot read, and produce one novel component: the publishable read key.
4. **The boundary, on one map**: both chains under one team: code flows right through git; protected files flow through sgit. The split is the layer above the protocol and the substrate below it, never the operations. One folder can run both, this site does.
5. **The new user: agents**: durable memory, plus the serialised diff versus the write-scoped token; the evolve arrows all point away from ambient authority.
6. **The strategy**: commoditise private version control; the value accrues to the layer above, and every component on that layer is already running on sgit.ai, including the page in the embed.

| Shape | Evidence status | Copy or reference |
|---|---|---|
| Structured analysis (positioning) | **LIVE**: authored for sgit.ai from the [boundary-map work](../why/index.md); the maps state where git wins first | **Reference**: the embed reads vault `ookq4mn4` live; pushing a better map updates this page with no rebuild |

## Related

- [The Strategy in Seven Maps](strategy-maps.md), the SG/Send half, first app in the same vault
- [The boundary map in prose](../why/index.md), the same argument, as the Why page
- [How the embed works](vault-app-embed.md), the full walkthrough of the mechanism

[← The strategy essay](strategy-maps.md)[All demos →](index.md)



==============================================================================
# Use cases, sgit

> Who has the problem sgit solves, with a working recipe and an honest evidence status for each: AI agents, professional services, security teams, health and regulated data, plus the underlying workflows.
>
> Page: https://sgit.ai/use-cases/index.html

[Home](../index.md) / Use cases

# Use cases

Two kinds of page here. **Workflows** are the mechanics, what sgit does, on shipped commands. **Situations** are who has the problem, each with a working recipe, an honest evidence status, and a brief you can hand to an agent.

**Reading this as an agent?** Every page on this site has a `.md` twin at the same path, this one is [use-cases/index.md](index.md). Internal links inside the markdown point at markdown, so you can traverse the whole site without parsing HTML. The machine index is [llms.txt](../llms.txt).

## Situations

Each of these is a place where the sentence "this needs version control, and the store must not be able to read it" is literally true. The pages are written to be usable: the setup, the commands, what is proven versus what is a pattern, and an agent brief.

[The lead example### The serialised pull requestAn agent proposes changes to a shared vault while holding **no credential at all**: clone with a public read key, commit on a private branch, emit a diff for human review. The answer to ambient agent authority, built before the guidance recommending it.](serialised-pull-request.md)

[AI agents### Agent state that isn't the vendor's to readDurable memory across sessions and machines, and shared memory between agents, with the store unable to read either. **Evidence: this website.**](ai-agents.md)

[Professional services### Working documents with clientsLegal, M&A, audit, assessment: the deliverable and the working notes, versioned, in a store that cannot read them, and read access you can hand out without an account.](professional-services.md)

[Security teams### Findings about your own weaknessesPentest output and vulnerability data need history, diffs and multi-person workflow, and are the last thing to put in a SaaS you don't control.](security-teams.md)

[Health & regulated### Data that changes what is permissibleWhen the host provably cannot read the content, the conversation stops being about the provider's access controls. Read the caveats on that page before quoting it.](health-regulated.md)

## Workflows

The mechanics underneath those situations. Every one runs on shipped commands, nothing aspirational.

## Private memory for AI agents

An agent's context window ends; its work shouldn't. A vault is just a folder, the agent clones it, reads and writes files normally, commits, and pushes. The next session pulls and continues where the last one stopped. Everything is encrypted before it leaves the agent's machine, so the shared state can hold things you would never put in a third-party database: client documents, security findings, personal data.

```
# session 1
$ sgit clone <vault-key> workspace
$ sgit commit -m "session 1: research notes" && sgit push
# session 2, days later, different machine
$ sgit pull   # continue exactly where session 1 stopped
```

[Full agent guide →](../docs/agents.md)

## Multi-agent collaboration

Give each agent its own named branch. Every clone also gets a private clone branch whose key never leaves that agent's session, so agents cannot trample each other's work-in-progress. Work meets on named branches, and a human reviews the merge. Agents can inspect each other's commits read-only with `sgit history show` and `sgit history diff`, without pulling, so looking never means merging.

```
# agent A  $ sgit branch new feature-analysis … sgit push
# agent B  $ sgit branch new feature-report   … sgit push
# human    $ sgit pull → review → merge, with sgit resolve --show on conflicts
```

## Human ↔ agent workspaces

The same vault has two doors: you in the SG/Vault web app, the agent in the CLI. The browser client is an independent implementation of the same wire format, you browse, edit and review in a UI while the agent works the same files from the terminal. Both sides see each other's commits; neither side's plaintext ever touches the server. (How the browser side works: [sgraph.ai](https://sgraph.ai).)

```
$ sgit vault info
  Web URL: https://vault.sgraph.ai/en-gb/#<your-vault-key>
```

## Encrypted folders with history

A shared folder where the hosting provider cannot read the contents, with commits, diffs, and rollback. Work offline, commit locally, push when ready; restore any prior version with `sgit history revert`. Vault-level `backup` and `restore` produce portable archives, and `sgit vault move` rotates keys if a key is ever exposed.

```
$ sgit init --existing        # vault-ify a folder you already have
$ sgit commit -m "baseline" && sgit push
$ sgit history revert --commit obj-cas-imm-b2d70f   # roll back
```

## Signed & encrypted file exchange

Alongside vault sync, sgit ships a PKI toolset: generate keypairs, exchange public keys as contact bundles, then sign, verify, encrypt and decrypt individual files for named recipients, useful when a file has to travel outside a vault but still needs integrity and confidentiality.

```
$ sgit pki keygen --label "release keys"
$ sgit pki sign report.pdf --fingerprint <fp>
$ sgit pki encrypt report.pdf --recipient <fp>
```

[← Why this exists](../why/index.md)[Documentation →](../docs/index.md)



==============================================================================
# The serialised pull request, sgit use cases

> An agent contributes to a shared vault holding no credential at all: clone with a public read key, commit on a private branch, emit a diff; a person imports, reviews and merges. The ambient-authority problem it removes, the 5 Aug 2026 Black Hat grounding, and the honest shipped-vs-pattern table.
>
> Page: https://sgit.ai/use-cases/serialised-pull-request.html

[Home](../index.md) / [Use cases](index.md) / The serialised pull request

# The serialised pull request

An agent clones a public vault needing no credential at all, makes changes, commits, and emits a diff. A person imports that diff on another machine, reviews it, and merges. No token was issued, so no token could be stolen, scoped too widely, or left unrevoked.

## The problem: ambient authority

The standard way to let an agent contribute to a repository is to give it a credential, and the credential is nearly always bigger than the task. One widely used coding agent held a token scoped to *every repository its developer had authorised*. The platform capability that would fix this (a user-minted, short-lived, single-repository token) has been an open feature request since June 2026, which is the polite way of saying it does not exist.

The consequences stopped being theoretical this month. Research disclosed at Black Hat on **5 August 2026** showed that a GitHub issue opened by an account with *no repository privileges* was enough to reach CI secrets in the vendors' own repositories, for three leading agents, under each vendor's default, unmodified workflow configuration. The attacker did not break anything; they asked a confused deputy to use authority it already held. That is what ambient authority means, and every write-scoped agent token is a standing instance of it.

## The workflow

In the project lead's own words, from the session where it happened:

> "I got Claude to clone a vault, a public repo, and I didn't need any permissions. Then Claude made a bunch of changes, then I got Claude to create commits and give me a diff. On another machine I cloned that vault, imported the diff, saw the changes, and then I merged them. Fundamentally, it's like a serialised pull request."

```
# the agent's side — no credential at any point
$ sgit clone --read-key <published-read-key> <vault-id> work
# … changes, commits on the private clone branch …
$ sgit history diff --json > proposed-changes.json   # the serialised artefact

# the human's side, on another machine
$ sgit clone '<vault-key>' review
# import the diff, review it, merge, push — see "honest mechanics" below
```

Four properties, and each is the strong form of something a platform PR only approximates:

- **No credential is issued at all.** Stronger than a short-lived scoped token: there is nothing to steal, nothing to expire, nothing to revoke, and nothing for an injected instruction to spend.
- **The artefact is inspectable before it takes effect.** A diff is reviewed; a write is discovered. The privileged action happens on the reviewer's machine, after human eyes.
- **Provenance survives per commit**, not per session, the history records what was proposed, not just what was merged.
- **It is capability-shaped, not trust-shaped.** It assumes no shared platform accounts and no fork write access, and the artefact moves by any channel, a vault, an email, a queue.

Published security guidance now independently recommends exactly this shape: run analysis in a read-only job holding no publishing credentials, and pass a constrained, reviewed artefact into a separate privileged step, never one job that both consumes untrusted input and can publish. Having built the recommended control *before* the recommendation is a stronger claim than any feature comparison, so we make it plainly.

## The honest mechanics

What is shipped versus what is pattern, checked against the CLI rather than asserted:

| Step | Status today |
|---|---|
| Credential-free clone of a public vault (read key only) | **Shipped**: `sgit clone --read-key`; this site publishes working read keys on its [demo pages](../demos/index.md) |
| Private-branch commits that cannot touch the shared branch | **Shipped**: the [two-branch model](../docs/two-branch-model.md) |
| Emit the diff as a machine-readable artefact | **Shipped**: `sgit history diff --json` |
| First-class import: `sgit diff apply` | **Not shipped.** The workflow was performed, but the import half was review-and-merge by hand. A [brief to the CLI team](../docs/briefs/brief-serialised-diff-and-ignore.md) asks for `sgit diff export` / `sgit diff apply` as first-class commands |
| A published specification of the diff format | **Not published.** If this is the headline workflow, its artefact needs a spec a third party can implement, same brief |

## Evidence status

PARTIAL, performed once, import not yet first-class

The workflow ran end to end exactly as quoted, and every step on the agent's side is a shipped command exercised daily. What keeps this from PROVEN is the import: until `sgit diff apply` exists, the human side leans on manual review-and-merge, and a workflow with a manual middle is a pattern, not a product. The brief is filed; this page upgrades itself when the commands land.

## Brief for an agent

```
$ curl -s https://sgit.ai/use-cases/serialised-pull-request.md
```

> Read https://sgit.ai/use-cases/serialised-pull-request.md. Clone the vault I name using only its read key, make the changes I describe on your clone branch, commit with clear messages, then emit `sgit history diff --json` and give me the output as a file. Do not ask for, hold, or use any write credential at any point.

## Related

- [The two-branch model](../docs/two-branch-model.md), why the agent's commits cannot reach the shared branch
- [Agent state that isn't the vendor's to read](ai-agents.md), the memory half of the agent story
- [The boundary map](../why/index.md), where this sits: proposing changes without write access is present; the hosted review interface is not

[← Use cases](index.md)[AI agents →](ai-agents.md)



==============================================================================
# Agent state that isn't the vendor's to read, sgit use cases

> Durable and shared memory for AI agents in a store that cannot read it: the session protocol, multi-agent branches, sparse clones, and the evidence (this website).
>
> Page: https://sgit.ai/use-cases/ai-agents.html

[Home](../index.md) / [Use cases](index.md) / AI agents

# Agent state that isn't the vendor's to read

An agent's context window ends; its work shouldn't. Where that work goes is a storage decision that quietly becomes a disclosure decision.

**A worked example, opened with a read key.** The question this page circles, an agent acting with a human's ambient authority because that is the only credential on offer, has a published vault devoted to it: [Agentic Browser Isolation](../demos/vaults/agentic-browser-isolation/index.md), a living risk graph asking whether an agent browses inside *your* browser with *your* logged-in sessions, or an isolated one with a scoped identity. It is vendor-neutral, it cites its evidence outward, and its mechanism is worth borrowing: every altitude has one named owner, a risk stays pending until that owner accepts it personally, and only an accepted risk escalates.

## The problem

Every durable-agent design needs somewhere to put state between sessions: notes, intermediate findings, drafts, the record of what was already tried. In practice that is a database, a repo, or a vendor's memory feature, all of which the provider can read.

That is fine while the state is "which step am I on". It stops being fine the moment the state contains the client's documents, the security findings, the unreleased code, the personal data. At that point the question is no longer about engineering: it is whether you are permitted to put that material there at all, and the answer often arrives from someone who does not care how good the access controls are.

The second half of the problem is coordination. One agent needs durable memory; several agents need *shared* memory with isolation, a review step, and a way to look at each other's work without merging it. That is version control, and version control's usual answer is a host that reads everything.

## What sgit does about it

A vault is a folder. The agent clones it, reads and writes files normally, commits, and pushes; the next session pulls and continues. Encryption happens before anything leaves the machine, so the shared state can hold what a third-party database cannot. Each clone also gets a [private branch](../docs/two-branch-model.md) whose key never leaves that session, so agents can work concurrently without trampling each other, and meet on a shared named branch.

## The recipe

**One agent, many sessions.** The whole pattern is two commands at the session boundaries:

```
# session start — always, before anything else
$ sgit clone <vault-key> workspace   # or: sgit pull
# … the agent works normally: read, write, edit files …
# session end — always, before the context runs out
$ sgit commit -m "session 4: drafted the migration plan" && sgit push
```

**Write a single file without a working copy**: the agent-shaped command, with machine-readable output:

```
$ sgit write notes/findings.md --file ./findings.md \
      --message "add findings" --push --json
```

**Several agents, one vault.** Give each a named branch; let a human own the merge:

```
# agent A  $ sgit branch new research  … sgit push
# agent B  $ sgit branch new drafting  … sgit push
# either agent, read-only — looking is not merging
$ sgit history show <commit>
$ sgit history diff --remote
```

**Big vault, small task.** A sparse clone keeps the agent's working set, and its token budget, proportionate to the job:

```
$ sgit clone <vault-key> workspace --sparse notes/ drafts/
```

## Evidence status

PROVEN

**This website is the evidence.** It is built and published by Claude Code sessions that share state through a vault; the site you are reading was deployed by pushing that vault. Two independent details are worth more than the claim:

- The [Deploy section](../deploy/index.md) is maintained by a *different* team's agent, in a different vault, and rendered here by decrypting it in your browser. Neither agent has access to the other's repository.
- The [cross-team briefs](../docs/briefs/index.md) and the [key-leak incident](../case-studies/exposed-vault-key.md) were written by one agent for another team to act on, including the incident where this agent leaked a key into a public commit, which is the sort of thing a marketing page omits.

Honest limit: n is small, and the agents are supervised by the people who wrote the tool.

## Brief for an agent

Paste this into an agent that has the [sgit skill](../skills/index.md) installed, or point it at the markdown directly.

```
# everything on this site is readable as markdown — no HTML parsing needed
$ curl -s https://sgit.ai/use-cases/ai-agents.md
$ curl -s https://sgit.ai/llms.txt          # the index of everything
```

> Read https://sgit.ai/use-cases/ai-agents.md and https://sgit.ai/docs/agents.md. Then set up agent state in a vault for this project: create the vault, structure the folders as described, commit and push, and report the vault key back to me once, I will store it. Do not write the key to any file in the repository. Then write a short SESSION.md describing the clone/pull-at-start and commit/push-at-end protocol so future sessions follow it.

That last sentence matters. We have a [write-up of the day we got it wrong](../case-studies/exposed-vault-key.md).

## Related

- [Working with AI agents](../docs/agents.md), the full agent-facing surface: `--json` everywhere, the session pattern, multi-agent collaboration
- [The two-branch model](../docs/two-branch-model.md), why every clone gets a private branch
- [Skills](../skills/index.md), packaged instructions that make an agent competent at this without you explaining it

[← Use cases](index.md)[Professional services →](professional-services.md)



==============================================================================
# Working documents with clients, sgit use cases

> Engagement vaults for legal, M&A, audit and assessment work: versioned working notes, review as branches, and read-only handover with a published read key.
>
> Page: https://sgit.ai/use-cases/professional-services.html

[Home](../index.md) / [Use cases](index.md) / Professional services

# Working documents with clients

Legal, M&A, audit, security assessment. The material that most needs versions and review is the material that least belongs readable on a third party's disk.

## The problem

A engagement produces two bodies of text: the deliverable, and everything behind it, working notes, drafts, the evidence, the arguments that did not survive. Both need history: who changed what, when, and what the previous version said. Both need more than one person in them.

The usual tools split badly. A shared drive gives you collaboration and no history worth the name. A private repo gives you history and hands the whole engagement to a host. Email attachments give you neither and produce six versions named `final_v3_JS_edits`.

And then the engagement ends, and you need to hand the client something they can keep and verify, without giving them an account on your systems, and without them needing your tooling to read it later.

## What sgit does about it

The working set is a vault: full history, branches, diffs, three-way merge, all client-side. The store holds ciphertext under opaque ids, so "where is this hosted" and "who can read this" stop being the same question, including for the host's staff, a subpoena served on the host, or a breach of it.

For handover, a **read key** is derived one way: it decrypts and cannot be turned into write access. You can give a client read access to a specific vault without giving them anything else, and without the host mediating it.

## The recipe

**One vault per engagement.** Keep the boundary at the vault, not at a folder. It is the unit of access.

```
$ sgit create acme-acquisition
  Vault key: <passphrase>:<vault-id>   ← password manager, now. There is no reset.
$ mkdir deliverable working evidence && sgit commit -m "structure" && sgit push
```

**Review as branches**, so the draft in flight is never the draft on the record:

```
$ sgit branch new draft-2 && sgit push
$ sgit history diff --commit <prev>      # exactly what changed since the last version
$ sgit resolve --show                     # when two reviewers touch the same file
```

**Hand over read-only** at the end, or throughout:

```
$ sgit dev derive-keys '<vault-key>'    # the read key, derived one way
# the client, with nothing but that key:
$ sgit clone --read-key <read-key> <vault-id> engagement
# …and a write attempt is refused, which they can verify themselves
```

**Archive on close.** The archive is self-contained ciphertext, keep it wherever your retention policy says, including somewhere you don't trust:

```
$ sgit vault backup --include-key       # store the key separately from the archive
```

## Evidence status

PATTERN, not yet evidenced publicly

The mechanics above are all shipped commands and are exercised daily; what we do **not** have is a published professional-services deployment we can point you at. Treat this page as a design that fits the constraints, not as a case study.

Two things to weigh before you use it on a real engagement: sgit is in [beta](../docs/limitations.md), and there is no key recovery, if your firm's key management is not already real, this trade-off will find you. If you do run this pattern, we would like to write it up: [say so in the open](https://github.com/SGit-AI/SGit-AI__CLI/issues).

## Brief for an agent

Paste this into an agent that has the [sgit skill](../skills/index.md) installed, or point it at the markdown directly.

```
# everything on this site is readable as markdown — no HTML parsing needed
$ curl -s https://sgit.ai/use-cases/professional-services.md
$ curl -s https://sgit.ai/llms.txt          # the index of everything
```

> Read https://sgit.ai/use-cases/professional-services.md and https://sgit.ai/docs/agents.md. Then set up an engagement vault for this project: create the vault, structure the folders as described, commit and push, and report the vault key back to me once, I will store it. Do not write the key to any file in the repository.

That last sentence matters. We have a [write-up of the day we got it wrong](../case-studies/exposed-vault-key.md).

## Related

- [When NOT to use sgit](../docs/limitations.md), read this before committing a client engagement to it
- [SG/Vault](../docs/vault/index.md), the browser app, so a client can read without installing anything
- [Security model](../security/index.md), precisely what the server can and cannot see

[← AI agents](ai-agents.md)[Security teams →](security-teams.md)



==============================================================================
# Findings about your own weaknesses, sgit use cases

> Pentest and vulnerability findings with history, diffs and multi-person workflow, in a store that cannot read them, plus the key-hygiene rule we learned the hard way.
>
> Page: https://sgit.ai/use-cases/security-teams.html

[Home](../index.md) / [Use cases](index.md) / Security teams

# Findings about your own weaknesses

Pentest output is a map of how to get in. It needs history, diffs and several people, and it is the last thing to hand to a SaaS you don't control.

## The problem

Assessment work produces exactly the document an attacker would most like to have: what is exposed, how to reach it, what has not been fixed yet, and which excuse each owner gave. It is also work that genuinely needs version control, findings get re-tested, severities change, remediation gets tracked across months, and several people edit the same report.

So it goes into a ticketing system or a shared repo, because those are the tools that do the workflow. Both are readable by the provider, and both are now a single place holding the complete attack path for the organisation. That is a concentration of risk that a security team, of all teams, can see clearly.

## What sgit does about it

The findings live in a vault: versioned, diffable, multi-person, and ciphertext everywhere but on the machines of the people working on them. The host is a key-value store for opaque ids; compromising it yields encrypted objects and traffic timing.

It also gives you a defensible answer to the question that follows an incident ("where was this stored, and who could read it?") that does not depend on a vendor's access-control configuration being correct on the day.

## The recipe

**A vault per engagement or per client**, with the report and the raw evidence separated so you can share one without the other:

```
$ sgit create acme-pentest-2026q3
$ mkdir report evidence retest && sgit commit -m "structure" && sgit push
```

**Re-test cycles as commits**, so severity changes are a diff rather than a claim:

```
$ sgit commit -m "retest: SQLi in /search fixed, XSS in /profile still open"
$ sgit history log --oneline
$ sgit history diff --commit <initial-report> --files-only
```

**Deliver read-only** to the client, keeping the write side entirely on your team:

```
$ sgit dev derive-keys '<vault-key>'
$ sgit clone --read-key <read-key> <vault-id> report   # what the client runs
```

**One rule, learned the hard way:** never let the vault key reach a tracked file, a CI variable, or a chat message. Put a check in your pipeline that greps for it, and make that check read the secret from somewhere ignored rather than hardcoding it. That is not hypothetical advice. It is the exact fix from [our own incident](../case-studies/exposed-vault-key.md).

## Evidence status

PARTIAL, adjacent evidence only

We have not published a pentest firm running this. What we can point at is the closest thing we own: this project's [exposed-key incident](../case-studies/exposed-vault-key.md), a real key leak, in a public commit, with the detection gap, the rekey, the measured blast radius (336 objects out, 90 in, zero overlap) and the structural fix written up rather than quietly patched.

That write-up is the artefact a security team would actually judge us on, so it is on the site rather than in a drawer. If you run assessment work on sgit, the failure modes you hit are the ones we want to hear about.

## Brief for an agent

Paste this into an agent that has the [sgit skill](../skills/index.md) installed, or point it at the markdown directly.

```
# everything on this site is readable as markdown — no HTML parsing needed
$ curl -s https://sgit.ai/use-cases/security-teams.md
$ curl -s https://sgit.ai/llms.txt          # the index of everything
```

> Read https://sgit.ai/use-cases/security-teams.md and https://sgit.ai/docs/agents.md. Then set up an assessment vault for this project: create the vault, structure the folders as described, commit and push, and report the vault key back to me once, I will store it. Do not write the key to any file in the repository. Also add a pre-push check that fails if the vault key appears in any tracked file, reading the secret from a gitignored path rather than hardcoding it.

That last sentence matters. We have a [write-up of the day we got it wrong](../case-studies/exposed-vault-key.md).

## Related

- [If a vault key is exposed](../case-studies/exposed-vault-key.md), the runbook and the case study
- [Security model](../security/index.md), the crypto stack and the honest side channels
- [Self-hosting](../deploy/index.md), when the storage layer has to be yours too

[← Professional services](professional-services.md)[Health & regulated →](health-regulated.md)



==============================================================================
# Data that changes what is permissible, sgit use cases

> What client-side encryption does and does not change for regulated data, stated precisely and without compliance claims.
>
> Page: https://sgit.ai/use-cases/health-regulated.html

[Home](../index.md) / [Use cases](index.md) / Health & regulated

# Data that changes what is permissible

When the host provably cannot read the content, the conversation stops being about the provider's access controls, because there is nothing for them to control access to.

**Read this first.** sgit holds no compliance certification of any kind, no HIPAA attestation, no ISO 27001, no SOC 2, no GDPR adequacy finding. Nothing on this page is legal or regulatory advice, and client-side encryption does not by itself make a processing activity lawful. What follows is a description of a technical property and what it does and does not change. Your compliance function decides the rest.

## The problem

Regulated data drags its rules with it. The moment a document is stored somewhere a third party can read, that third party is in scope: they become a processor, they need an agreement, their jurisdiction matters, their breach becomes your notification, and their sub-processors become your problem too. Most of the effort in these projects is not securing the data. It is the paperwork proving who could have seen it.

And the work itself still needs versions and collaboration, which is why it so often ends up in a general-purpose tool with a data-processing addendum stapled on.

## What the property actually changes

Content is encrypted before it leaves the client; the store holds ciphertext under opaque ids and never receives a key. That moves specific arguments, and it is worth being exact about which:

| Question | What changes |
|---|---|
| Can the host read the content? | No, not with a warrant, a rogue administrator, or a breach. This is the strong claim, and it is structural rather than procedural. |
| What does the host still learn? | The vault id, the size of each object, and request timing. Sizes and timing are a real if narrow side channel, see the [security page](../security/index.md). |
| Does this remove the processor relationship? | **Not automatically.** Storing ciphertext may still be processing, depending on the regime and on who holds keys. Ask your counsel; do not take a vendor's word for it, including ours. |
| Does it help with access logging and minimisation? | Partly: a vault is a natural boundary, and read access is a key rather than an account, which makes "who could read this" a shorter list. |
| Does it help with retention and deletion? | Partly, and awkwardly: history keeps old ciphertext until pruned, so "delete" needs thought. See [limitations](../docs/limitations.md). |

## The recipe

**Scope one vault to one purpose.** The vault is the access boundary, so make it match the lawful basis for the data in it, not the team, not the project folder.

```
$ sgit create study-1234-analysis
$ sgit commit -m "structure" && sgit push
```

**Key management is the whole control.** There is no reset and no recovery: the key is the access control, so it has to be managed like one, in a password manager or an HSM-backed store, with a named owner and a documented rotation path.

```
$ sgit vault backup --include-key     # archive and key stored separately
$ sgit vault rekey                          # rotation — see the exposed-key runbook
```

**Self-host if the storage layer is itself in scope.** The [deployment guidance](../deploy/index.md) covers Docker, AWS, GCP and a static host, and is itself served from an encrypted vault, which is a small demonstration of the property.

## A worked example you can open right now

The abstract version of this page is "the host cannot read it". The concrete version is a vault you can open in your browser in the next ten seconds: [**the Supplement Stack vault**](../demos/vaults/supplement-stack/index.md), a real, patient-held health record, published with a read key.

It is worth reading because it answers the questions this page raises in the specific rather than the general:

| The question | How that vault answers it |
|---|---|
| Who holds the data? | The patient. The vault is theirs; the write key never leaves them |
| How is it shared with a clinician? | By handing over a **read key**: no account on anyone's platform, no PDF emailed into permanent circulation. The reader sees everything and can change nothing |
| What stops the app doing more than it should? | `app.json` grants write over `adherence/` and nothing else. The record-keeping app cannot alter the record it reports on, least authority, declared in the vault |
| Where does AI fit without being dangerous? | A model does the fuzzy work (reading amounts off a label photograph, each value traceable back to its image); **code** does the exact work (summing them). Every fuzzy step is checkable against its source |
| Does it give medical advice? | No, and that is designed in. It computes the total nobody else computes and produces a *briefing for somebody qualified*, with the open questions listed. It never concludes |
| Whose reference values? | UK RNIs and EFSA upper limits, named and dated, explicitly not US Daily Values, because comparing a UK intake against US references without saying so is a quiet error |

It is a demonstration rather than a deployed clinical system, and it makes no compliance claim of any kind, but every mechanism above is running, readable, and open to inspection with the key on its page.

## Evidence status

PATTERN, and the most caveated page here

No published healthcare or regulated-industry deployment, no certification, and no audit of the implementation by a third party. What exists is: standard primitives (AES-256-GCM, PBKDF2-SHA256 at 600k, HKDF) with no custom cryptography, ~4,000 tests, byte-for-byte test vectors against the browser's Web Crypto, two independent implementations of the same wire format, and a [published threat model](../security/index.md) that names its own side channels.

That is evidence of engineering care. It is not evidence of compliance, and we are not going to blur the two.

## Brief for an agent

Paste this into an agent that has the [sgit skill](../skills/index.md) installed, or point it at the markdown directly.

```
# everything on this site is readable as markdown — no HTML parsing needed
$ curl -s https://sgit.ai/use-cases/health-regulated.md
$ curl -s https://sgit.ai/llms.txt          # the index of everything
```

> Read https://sgit.ai/use-cases/health-regulated.md and https://sgit.ai/docs/agents.md. Then set up a scoped vault for regulated data for this project: create the vault, structure the folders as described, commit and push, and report the vault key back to me once, I will store it. Do not write the key to any file in the repository. Do not claim any compliance property in what you write; describe only the technical behaviour.

That last sentence matters. We have a [write-up of the day we got it wrong](../case-studies/exposed-vault-key.md).

## Related

- [Security model](../security/index.md), including what the server still observes
- [When NOT to use sgit](../docs/limitations.md), retention, deletion and the key-loss trade-off
- [Run your own server](../deploy/index.md), when the storage layer must be in your own boundary

[← Security teams](security-teams.md)[All use cases →](index.md)



==============================================================================
# Case studies, sgit.ai

> Worked accounts of things that actually happened, including the ones that went wrong: a leaked vault key and its rekey, and the architecture of a live site whose host cannot read it.
>
> Page: https://sgit.ai/case-studies/index.html

[Home](../index.md) / Case studies

# Case studies

Things that actually happened, written up while the details were still checkable, including the ones that went wrong. Each is a worked account with the mechanism, the numbers, and what changed as a result.

**What counts as a case study here:** a specific event or system, with evidence a reader can verify, commands they can run, numbers we measured, or a live page they can open. Not a pattern, not a design we like the look of. Patterns live in [use cases](../use-cases/index.md), which label their evidence honestly; if a use case ever earns a real deployment, its write-up lands here and the two link to each other.

## Published

[Incident### The day we leaked our own vault keyAn agent hardcoded this site's vault passphrase into a tracked file as part of an anti-leak check. It reached three public commits and was caught only because someone asked. The runbook, the rekey, the measured blast radius (336 objects out, 90 in, zero overlap) and the structural fix.Read the incident →](exposed-vault-key.md)

[Workflow### One working tree, two version control systems, and why we stoppedFor 76 releases this site was one folder that was both an sgit vault and a git repository. The workflow, the one-file boundary that made it safe, the ordering rule, and the numbers behind retiring it: a 258 MB mirror that was 91% of the repository, had no reader, and went dead for seven releases without the site noticing.Read the retrospective →](one-tree-two-remotes.md)

[Runbook### Deleting files from git history, and why they were still on GitHub afterwardsThe exact scenario, drawn out: two branches, 15,933 files, why `git rm` is not deletion, what a rewrite does to every commit id, why the push had to be forced, and why one forgotten merged branch kept the purged files downloadable until it was removed.Read the runbook →](purging-history.md)

[Architecture### A live site whose host cannot read itTwo Claude Code sessions, two encrypted vaults, one page: how the Deploy section is fetched as ciphertext from an SG/Send server and decrypted in your browser, with the object model, the cache tiers and the request timeline drawn out.Read the architecture →](live-vault-docs.md)

## How these are written

Same shape every time, so they stay comparable and so an agent can parse them:

- **What happened**: the sequence, in order, with timestamps or commit ids where they exist.
- **The mechanism**: why it happened, at the level of the object model or the code, not at the level of "human error".
- **The numbers**: measured, not estimated, and stated even when they are unflattering.
- **What changed**: the structural fix, and the check that stops it recurring. A write-up with no change attached is a story, not a case study.
- **What we still do not know**: stated rather than smoothed over.

The incident write-up is the template for the uncomfortable kind. It names the agent that made the mistake, the detection gap that let it survive three commits, and the cost of the fix, because a project that hides that class of mistake is the one to worry about.

## Related

- [Use cases](../use-cases/index.md), the patterns, each with an explicit evidence status
- [Cross-team briefs](../docs/briefs/index.md), what this site's agent hands to other teams, and what they hand back
- [Release history](../admin/versions.md), every change to this site, with the vault commit that carried it

[← Home](../index.md)[Use cases →](../use-cases/index.md)



==============================================================================
# Lessons learned, the rules and the incidents behind them, sgit.ai

> Every rule this site enforces, with the event that produced it: classify a credential before it touches anything (a vault key once arrived labelled as a read key), read keys yes and vault keys never (we leaked our own), audit every vault before its key is published (three vaults shipped as republications), and write the method down rather than the outcome.
>
> Page: https://sgit.ai/lessons/index.html

[Home](../index.md) / Lessons learned

# Lessons learned

Every rule this site enforces started as something that went wrong, or very nearly did. This page is the index of those rules with the incident behind each one attached, because a rule with no origin is only a preference, and the first person who finds it inconvenient will drop it.

**How to read an entry.** **The rule** is the thing to copy, stated so it can be checked; **where it came from** is the event that produced it, kept because the event is what makes the rule survive contact with a deadline. The longer accounts live in [case studies](../case-studies/index.md), which are linked rather than repeated here.

## Classify a credential before it touches anything

**The rule.** Every credential submitted for publication is classified first, by a program, before it is used to clone, audit or render anything. `admin/build/check_credential.py` refuses a write credential by **prefix** (`sgit_vk1_`, which new vaults emit) or, for anything older, by **shape**: a read key is 64 hex characters, and anything else before the colon is a passphrase. Where a write credential arrives, the derived read key is published and the write credential is not; refusing outright just sends the sender back to try again with less care.

**Where it came from.** A credential submitted for publication here was once a **vault key** described as a read key: a legacy `passphrase:vault_id` form with no prefix to give it away. It was caught, only the derived read key was published, and nothing leaked. But the catch depended on somebody looking at it, which is not a control. Prefixes are the better answer because they let a key arrive self-labelled, and a prefix also declares *intent*: `sgit_public_read_` is a read key meant to be published, which is what every row in the vaults table carries or is being moved to. The shape check covers the years of keys created before prefixes existed. [**What each credential can do, and what its prefix declares →**](../docs/credentials.md)

## Read keys yes, vault keys never

**The rule.** A read key is a capability this site hands out on purpose, and it cannot become write access: it is derived from the vault key one way, and there is no path back. A vault key is never published, never pasted into a page, never committed. The validator enforces it rather than trusting anyone to remember: it fails the build on the write-credential prefixes and on the bare `passphrase:vault_id` shape, and it scans every tracked file for the real passphrases held in the gitignored tier.

**Where it came from.** An agent hardcoded this site's own vault passphrase into a tracked file, as part of an anti-leak check. It reached three public commits and was caught only because somebody asked a question about it. The rekey, the measured blast radius and the structural fix are written up in full. [**The day we leaked our own vault key →**](../case-studies/exposed-vault-key.md)

The sequel is worth reading beside it: removing a secret from git history does not remove it from GitHub, because a forgotten merged branch keeps the purged objects reachable and downloadable. [**Deleting files from git history →**](../case-studies/purging-history.md)

## Audit every vault before its key appears anywhere

**The rule.** A vault is audited before its read key is published, and the finding is published on the vault's own page rather than filed away. The reason is that a read key is permanent: content travels with the key forever, so anything in the vault at the moment of publication is public from then on, including the history. Several vaults on this site are *republications*, a clean vault created from audited content, precisely because the original could not be corrected after the fact.

**Where it came from.** Three separate audits found a plaintext write credential inside vault content that was about to be published: the strategy maps vault, the health score vault and the regulation graph vault each shipped as a sanitised republication instead. Each of those pages states its own finding. The audit step exists because in all three cases the vault looked finished and the finding was in a file nobody had opened for weeks.

## Write the method down, not just the outcome

**The rule.** Anything done more than twice is written as a method another agent can follow from nothing: the steps in order, the tool that does each one, and the mistake that produced each rule in it. Publishing a vault has seven such steps, from classifying the credential to recording what outlives the release.

**Where it came from.** The same publication mistakes kept arriving from different directions, because the knowledge lived in whoever had done it last. A method that names the mistake beside the step is the only version that survives being handed over. [**Publishing a vault: the method →**](../demos/vaults/publishing.md)

## Worked accounts

Where a lesson has a full write-up with numbers, it is a case study rather than an entry here, and this page links to it rather than retelling it.

[Incident### The day we leaked our own vault keyThree public commits, the rekey runbook, the measured blast radius (336 objects out, 90 in, zero overlap) and the structural fix that now fails the build.Read the incident →](../case-studies/exposed-vault-key.md)

[Runbook### Deleting files from git history15,933 files across 112 commits, why `git rm` is not deletion, why the push had to be forced, and the forgotten branch that kept the purged objects downloadable.Read the runbook →](../case-studies/purging-history.md)

[Workflow### One working tree, two version control systems76 releases in a folder that was both a vault and a git repository, the ordering rule that made it safe, and the numbers behind retiring it.Read the retrospective →](../case-studies/one-tree-two-remotes.md)

## Where the rest of the rules live

- [How the site is run](../team/index.md): nine agentic roles, each stating the rules it enforces and the mistake behind each rule. This page is the cross-role version of the same idea.
- [Vault credentials](../docs/credentials.md): the two capabilities, the five prefixes, and why a mislabelled read key is a real problem even when the bytes are identical.
- [When NOT to use sgit](../docs/limitations.md): the edges, stated plainly, so a reader finds them here rather than the hard way.
- [Published vaults](../demos/vaults/index.md): the vaults these rules were learned on, every read key published on purpose.

[← Case studies](../case-studies/index.md)[Published vaults →](../demos/vaults/index.md)



==============================================================================
# One working tree, two version control systems, and why we stopped, sgit.ai case study

> How this site was developed for 76 releases in a single folder that was both an sgit vault and a git repository (the .gitignore boundary, why the encrypted ref always looked dirty to git (fresh AES-GCM IVs), the ordering rule) and why the vault mirror was retired and purged: no reader, no published read key, 91% of the repository, and seven releases shipped without it before anyone noticed.
>
> Page: https://sgit.ai/case-studies/one-tree-two-remotes.html

[Home](../index.md) / [Case studies](index.md) / One tree, two remotes

# One working tree, two version control systems, and why we stopped

For seventy-six releases this site was developed in a single folder that was simultaneously an sgit vault and a git repository, and every release pushed both. On 19 September 2026 the vault mirror was removed from the repository and purged from its history. This page keeps the workflow as it ran, the boundary that made it safe, and the ordering rule that kept the mirror true, and then records, with the numbers, why a pattern that was correct stopped being worth carrying.

**Status: retired at v0.2.84.** The site now ships over git alone. The [git-and-vaults](../docs/vault/git-and-vaults.md) pattern this page demonstrated is still right for the cases described there; what changed is that this site stopped being one of them. The reasons are in [the last section](#stopped).

## What we ran

The folder that held this site had two version control directories side by side:

```
sgit-ai-website/
├── .git/          → github.com/SGit-AI/SGit-AI__Website  (public mirror + Pages deploy)
├── .sg_vault/     → an SG/Send vault                     (encrypted history + live vault)
└── index.html, why/, case-studies/, admin/ …         ← the same files, once
```

They were not two copies kept in agreement. They were two version control systems pointed at **one directory**: `git status` and `sgit status` described the same bytes. There was no synchronisation step because there was nothing to synchronise; a release was simply two pushes of the same tree:

```
$ sgit commit -m "site v0.2.1: …" && sgit push   # encrypted history → SG/Send
$ git add -A && git commit && git push            # public mirror → GitHub → Pages
```

Each remote did a different job. The git push was what deployed, a GitHub Action publishes the tree to GitHub Pages. The sgit push was meant to be what other agents read: the plan was that Claude Code sessions building the site would clone and pull the vault, and that the encrypted store committed to git would double as a full off-site mirror of it.

## The boundary that made it safe

The entire pattern rested on one file: `.gitignore`. Everything encrypted **was** committed to git, ciphertext objects under `.sg_vault/bare/`, all under opaque ids. What was excluded was exactly the plaintext tier:

```
.sg_vault/local/     # vault key, access token, private PEM — plaintext, never committed
.sg_vault/work/      # scratch state
*.pem
```

That was the whole rule, and it is worth stating as a condition rather than a pattern: committing ciphertext alongside plaintext is right *for a public site*, where the working tree is meant to be published anyway. For a confidential vault the same layout is a leak-audit boundary, one bad `.gitignore` edit away from publishing the plaintext tree. The [git repos inside vaults](../docs/vault/git-and-vaults.md) page covers which side of that line a given project is on.

Because the boundary was one file, it got a machine check, not a convention. The build's validator read the vault passphrase from the gitignored `local/` tier at runtime and scanned every tracked file for it, so a key that reached the tree failed the build by construction. That check exists because of [the day it actually happened](exposed-vault-key.md): an agent hardcoded this site's passphrase into a tracked file, it survived three public commits, and the vault had to be rekeyed. **The tripwire outlived the mirror.** It now reads the write keys of published demo vaults from a gitignored `admin/local/demo-keys/` folder and scans for those instead; the mechanism is unchanged, only the folder moved.

## The one ordering rule: sgit first, then git

Almost everything in the shared store is content-addressed, an object's name is the hash of its ciphertext, so it never changes under its id and the two systems can never disagree about it. Exactly one file is mutable: the vault's HEAD pointer, the **ref**. Every real `sgit push` rewrites it, and that made the order of the two pushes matter:

```
✓ sgit commit && sgit push     # 1st — writes the new ref
✓ git add -A && git commit && git push   # 2nd — captures that exact ref
```

Done in this order, the git mirror always carried the ref the push had just written, and a clean `git status` was the normal end state of every release. Reverse the order and the failure was quiet: the mirror carried the *previous* ref, in sync by bytes, one commit behind in meaning.

One property worth keeping from this: **the ref's bytes carry no information about staleness.** AES-GCM encrypts with a fresh random IV on every write, so a rewritten ref never byte-matches its previous encryption even when it decrypts to the same commit id. "Dirty" did not mean stale, and byte-equality would not have meant current, the only real answers were decrypting the ref or asking `sgit status`. This is also why `.gitattributes` marked the store `binary -diff -merge`: a textual diff of ciphertext is noise, and a git merge of two encrypted refs would produce garbage that decrypts to nothing.

## The release script, then and now

Two pushes with no enforcement is an invitation to forget one, so the release was one script, [`admin/build/release.sh`](../admin/index.md), and it was strict: build, validate, sgit push and verify in sync, git push and verify HEAD equals origin, then poll the live site until it served the new version. The same script ships the site today with the sgit step removed. It still refuses to push until the validator, including the key-leak tripwire, has passed, and it still refuses to call a release done until `https://sgit.ai/` is serving the version it just pushed.

## Why we stopped

Nothing about the pattern broke. What happened is that its costs stayed and its benefits never arrived, and a container recycle made that impossible to ignore.

- **The mirror had no reader.** The design assumed other sessions would `sgit clone` the site vault. In practice every session that built the site cloned it from GitHub, because that is where the deploy runs from and where the history is legible. Not one release was ever produced from a vault clone.
- **The vault had no published read key.** Every other vault on this site is openable by anyone; the site's own vault was the one nobody could open. A zero-knowledge mirror of public content that nobody can read is storage, not publication.
- **It went dead quietly, and the site did not notice.** The container holding the write key was recycled after **v0.2.76**. Because `.sg_vault/local/` is gitignored by design, no clone could push the vault again. Releases **v0.2.77 through v0.2.83**, seven of them, went out over git alone, and the live site was correct throughout. The mirror had been carrying nothing the deploy depended on.
- **It was 91% of the repository.** The encrypted store was **258 MB in 15,933 files** against **24 MB of site content in about 750 files**. Every clone paid for it; every `git add -A` walked it.
- **Two published pages had become false.** This one said "every release pushes both"; the site's `llms.txt` said the site "is itself served from an encrypted vault". Both statements were true when written and had stopped being true, which is a worse state for a case study than either honest answer.

So on 19 September 2026 the store was removed from the tree, the history was rewritten with `git filter-repo` to drop it from every commit, and the branch was force-pushed. The mechanics, and why the purged files were still downloadable from GitHub afterwards, are drawn out in [a page of their own](purging-history.md). The purge is safe for the same reason the mirror was safe: everything removed was ciphertext under a key that was never in the repository. What is gone from GitHub is a copy of the vault's encrypted history; the vault itself, on the SG/Send server, is untouched and still holds it.

## The numbers

| What | Count |
|---|---|
| Releases shipped with both pushes | 76 (through v0.2.76) |
| Releases shipped over git alone while the mirror was unreachable | 7 (v0.2.77 – v0.2.83) |
| Encrypted objects removed from git | 15,933 files, 258 MB |
| Site content that remained | ~750 files, 24 MB |
| Times the mirror was cloned to produce a release | 0 |
| Plaintext ever in the purged history | none, the local/ tier was gitignored from the first commit |

## What we would do differently

- **Give the mirror a reader before giving it a remote.** If nobody clones the vault, do not build a release process around pushing it. The [board vault](../demos/vaults/board/index.md) is the pattern working: it is pulled by the release, rendered into a page, and updated by anyone holding its key, it earns its place because something reads it.
- **A public site's vault should have a public read key, or not exist.** The site publishes read keys for thirty vaults. Withholding its own was an inconsistency, not a precaution.
- **Measure the mirror against the content.** Ninety-one per cent of a repository is a number that should have been on this page from the start.

## Related

- [Git repos inside vaults](../docs/vault/git-and-vaults.md), the general pattern, and the confidential-vault caution, both still current
- [The day we leaked our own vault key](exposed-vault-key.md), why the tripwire exists, and why it stayed after the mirror went
- [The board as a vault](../demos/vaults/board/index.md), the vault this site still pulls at every release
- [Admin & engineering](../admin/index.md), the release process as it is now

[← Case studies](index.md)[Git repos inside vaults →](../docs/vault/git-and-vaults.md)



==============================================================================
# Deleting files from git history, and why they are still on GitHub afterwards, sgit.ai case study

> How this repository dropped 15,933 files from every one of its 112 commits: the setup with two branches drawn out, why git rm is not deletion, what git filter-repo does to every commit id, why the push had to be forced and how the lease made it safe, why a forgotten merged branch kept the purged objects reachable and downloadable, what happens when it is deleted, and the order to do it in when the file is a secret.
>
> Page: https://sgit.ai/case-studies/purging-history.html

[Home](../index.md) / [Case studies](index.md) / Deleting files from git history

# Deleting files from a repository's history, and why they are still on GitHub afterwards

On 19 September 2026 this site's repository dropped 15,933 files it no longer wanted (not just from the current tree, but from every one of the 112 commits that had ever carried them) and force-pushed the result. This page is the exact scenario, drawn out: what the setup was, which branches were in play, what was deleted, why a plain `git rm` would not have done it, why the push had to be forced, and why the deleted files were **still downloadable from GitHub** after the force push landed, until one more branch was removed.

**Read this before copying it.** Everything purged here was ciphertext under a key that was never in the repository, so the purge was housekeeping, not remediation. If the thing you want out of history is a *secret*, history rewriting is the second step and never the first: **rotate the secret, then rewrite**. A rewrite shrinks the window; it does not close it, for the reasons in [the section on why the files are still there](#still-there). The account of that situation is [the day we leaked our own vault key](exposed-vault-key.md).

## The setup

One working folder, two version control systems, one remote with two branches. The folder was both an sgit vault and a git repository ([the pattern and why it was retired](one-tree-two-remotes.md)), and git tracked the vault's encrypted store as a mirror.

```
LOCAL WORKING TREE                              GITHUB · SGit-AI/SGit-AI__Website
sgit-ai-website/                                 ┌──────────────────────────────────────┐
├── .git/            ← git metadata              │ refs/heads/dev            e70d582d  │ ── deploys ──▶ GitHub Pages
├── .sg_vault/                                   │   112 commits, v0.1.0 … v0.2.83     │                sgit.ai
│   ├── bare/        ← 15,933 encrypted files    │                                      │
│   │   ├── data/       (258 MB)   TRACKED       │ refs/heads/claude/site-access-…      │
│   │   ├── indexes/               TRACKED       │   9f9f7772 · 23 Aug · merged in dev  │
│   │   ├── keys/                  TRACKED       └──────────────────────────────────────┘
│   │   └── refs/                  TRACKED
│   ├── local/       ← vault key, token   GITIGNORED (never committed)
│   └── work/        ← scratch           GITIGNORED
├── admin/, docs/, demos/ …   ← the site: ~750 files, 24 MB
└── index.html
```

Two things to notice before anything is deleted. The plaintext credential tier under `.sg_vault/local/` was excluded from git from the very first commit, which is the single fact that made the rest of this page routine. And the remote had *two* branches: `dev`, which GitHub Pages deploys, and a working branch from August that had been fully merged into `dev` and then left behind. That second branch is the reason for the last two sections.

## What we wanted gone

Everything under `.sg_vault/`. It was 91% of the repository by size, had had no reader since it was created, and had been dead, unreachable for a push, since v0.2.76. The numbers:

| What | Before | After |
|---|---|---|
| Tracked files | 16,679 | 746 |
| Of which under `.sg_vault/` | 15,933 | 0 |
| Size of `.sg_vault/` in the working tree | 258 MB | removed |
| Git pack (the whole history) | 276 MB | 21 MB |
| Commits | 112 | 112, same commits, every one rewritten |
| Commits whose id survived unchanged | 0 |

## Why `git rm` is not deletion

Git does not store diffs. Every commit points at a complete snapshot, a tree of trees ending in blobs, and a blob stays in the repository for as long as *any* commit anywhere points at it. Removing a folder in a new commit produces a new snapshot without it. Every previous snapshot is untouched.

```
"git rm -r .sg_vault  →  git commit"  — the folder leaves the tip and nothing else:

  v0.1.5 ──▶ v0.1.6 ──▶ … ──▶ v0.2.83 ──▶ v0.2.84 (new)
    │          │                 │            │
    ▼          ▼                 ▼            ▼
  tree       tree              tree         tree
  ├ site     ├ site            ├ site       ├ site        ← only this one lacks it
  └ .sg_vault└ .sg_vault       └ .sg_vault

  git clone  →  fetches ALL of these  →  258 MB arrives anyway.
  git checkout v0.2.83  →  the folder is back, byte for byte.
```

So the tip would have been clean and the clone would have been the same size. For the mirror that was merely wasteful. For a leaked secret it is the failure mode that catches people every year: the file is gone from the branch, and `git log --all -- path/to/secret` still finds it in thirty seconds.

## What a history rewrite does

`git filter-repo` walks every commit, rebuilds its tree without the excluded paths, and writes a *new* commit. A commit's id is a hash of its content, including its tree and its parent's id, so removing a path from the first commit that carried it changes that commit's id, which changes its child's id, and so on to the tip. The old objects are left unreferenced and swept away by the repack that follows.

```
BEFORE  (the history GitHub had)
  4c1d11d4 v0.2.76 ──▶ bb248b12 v0.2.77 ──▶ … ──▶ e70d582d v0.2.83
  tree: site + .sg_vault   tree: site + .sg_vault         tree: site + .sg_vault

        git filter-repo --path .sg_vault --invert-paths --force
        (1.5 s to rewrite 112 commits; then a repack drops the orphaned blobs)

AFTER   (a different history: same authors, dates, messages, site files; new ids)
  005361e8 v0.2.76 ──▶ 44323549 v0.2.77 ──▶ … ──▶ 45b99758 v0.2.83 ──▶ b5ae665d v0.2.84
  tree: site only          tree: site only                tree: site only    tree: site only

  Not one id is shared between the two rows. They are two unrelated chains
  that happen to contain the same site files at each step.
```

Three practical consequences. Every commit id anyone had written down (in the release history, in an issue, in a URL) now names a commit that exists only in the old chain. Any clone made before the rewrite is on the old chain and cannot fast-forward onto the new one; it has to be re-cloned or hard-reset. And the tool refuses to run on anything but a fresh clone unless told `--force`, and removes the `origin` remote when it finishes, precisely so that nobody pushes the rewrite by reflex.

## Why the push had to be forced

A normal push is a fast-forward: the remote accepts a new tip only if the tip it currently holds is an ancestor of it. After a rewrite that is never true.

```
remote refs/heads/dev  =  e70d582d   (old chain)
local  refs/heads/dev  =  b5ae665d   (new chain)

  is e70d582d an ancestor of b5ae665d?   NO — they share no commit at all
  →  ordinary push is refused: "non-fast-forward"

  git push --force-with-lease=dev:e70d582d origin dev
                        └────────┬────────┘
    "replace dev, but ONLY if it still points at e70d582d" — if anyone had
    pushed to dev in the meantime, this fails instead of overwriting their work.

  +  e70d582d...b5ae665d  dev -> dev  (forced update)
```

The lease is the important half. A bare `--force` overwrites whatever is there; `--force-with-lease` pinned to the id we started from turns the push into a compare-and-swap. On a branch with more than one contributor it is the difference between a rewrite and an accident.

GitHub Pages then rebuilt from the new `dev` exactly as it does for any push. The deployed site never carried the mirror, so nothing visible changed, v0.2.84 appeared within ninety seconds.

## Why the deleted files were still on GitHub, and downloadable

This is the part that surprises people, and it comes back to the second branch in the first diagram.

```
GITHUB, one minute after the forced push

  refs/heads/dev ──────────▶ b5ae665d ──▶ 45b99758 ──▶ … ──▶ 005361e8 ──▶ …   (NEW chain, no .sg_vault)

  refs/heads/claude/site-access-branch-commit-6h2bix
                 └─────────▶ 9f9f7772 ──▶ 82d5d1e3 ──▶ … ──▶ (68 commits)     (OLD chain)
                              tree: site + .sg_vault  — 6,191 encrypted files at that point

  Git keeps every object reachable from ANY ref. The old branch is a ref.
  Everything it can reach — including every .sg_vault blob in those 68 commits —
  is therefore still a live, first-class object in the repository on GitHub.
```

Reachability is the whole rule. Deleting a branch's content from *one* chain does nothing to objects that another ref can still walk to. The stale branch had been merged into `dev` in August and forgotten; it never had a reason to exist after that, but it kept the old chain alive.

Concretely, while that branch exists:

- **`git clone` brings the old objects down.** A clone fetches every branch by default. Anyone cloning after the force push gets the small new `dev` *and* the old branch with its 6,191 encrypted files. The clone is smaller than before, but the purge is not visible from the outside.
- **Old commit URLs keep working.** `github.com/…/commit/9f9f7772` renders, its tree is browsable, and any file in it can be viewed or downloaded raw.
- **`git fetch origin claude/site-access-…` re-imports the whole thing** into a clean clone in one command. We know, because verifying this page did exactly that.

There are two further places the old objects can live that no branch deletion reaches, and both are worth knowing even though neither applied here. **Forks** share GitHub's object storage with the parent and keep their own refs, so a fork made before the rewrite holds the old chain regardless of what the parent does. And **pull request refs** (`refs/pull/N/head`) are kept by GitHub for closed and merged PRs; they are not listed as branches and cannot be deleted by the repository owner, but they pin the commits they point at. This repository had no forks and no pull requests carrying the mirror.

## What happens when the branch is deleted

```
  git push origin --delete claude/site-access-branch-commit-6h2bix

  refs/heads/dev ──▶ b5ae665d ──▶ … (new chain)             ← still reachable

  (no ref) ·········▶ 9f9f7772 ──▶ … ──▶ .sg_vault blobs    ← UNREACHABLE
                                                             nothing points here any more
```

Three things follow, on three timescales.

1. **Immediately:** a fresh clone no longer receives the old chain. Clone size drops to the 21 MB pack. From the outside the purge is now complete.
2. **Soon, but not instantly:** the old commit URLs stop rendering and raw-file downloads by old id stop working. Unreachable objects sit on GitHub's storage until its garbage collection runs, which is on its own schedule and not the owner's; anyone who already knows a full 40-character id can still address those objects until then. For a real secret exposure, GitHub Support will run that collection and purge cached views on request. The request is the step that turns "eventually" into "today".
3. **Never, on its own:** every clone made *before* the deletion still holds the old objects, and nothing anyone does on GitHub changes that. This is why a purge is not a remediation for a secret, and why the case study on the leak rotated the key before it did anything else.

Status as this page is written: the deletion was attempted three times from the session that did the rewrite and was refused by the session's git proxy, which permits pushes but not ref deletion. The branch is to be removed from the GitHub UI, and until it is, everything in the previous section holds. The paragraph will be updated when it has been.

## The order we did it in

Written as a recipe, because the order matters more than any single command.

1. **Know what the deletion is for.** Housekeeping (this case) or secret exposure? If the latter, rotate first and treat the rest of this list as a size reduction, not as containment.
2. **Get the whole history locally.** A shallow clone cannot be rewritten meaningfully; ours had to be unshallowed to all 112 commits first.
3. **List every ref on the remote** with `git ls-remote --heads origin`, and for each branch you did not know about, find out whether it is merged and whether it carries the paths. The stale branch here was fully merged and did carry them.
4. **Park uncommitted work.** The rewrite ends with a hard reset. We saved the pending edits as a patch, reset the tree, and re-applied afterwards.
5. **Rewrite:** `git filter-repo --path .sg_vault --invert-paths --force`. Check the result before going further: file count, pack size, `git ls-files` for the path returning nothing.
6. **Re-add the remote** the tool removed, and re-apply the parked edits.
7. **Make the tree consistent** in the same release: `.gitignore` now excludes the path outright, every page that described the old state is rewritten, tooling that read from the path is re-pointed. Build and validate.
8. **Force-push with a lease** pinned to the id the remote held when you started.
9. **Delete every other ref that reaches the old chain**: branches you own, tags, and ask GitHub Support about anything you cannot delete yourself.
10. **Tell every other clone.** Anyone with a checkout is now on a dead chain and must re-clone or hard-reset; a `git pull` will produce a confused merge of two unrelated histories.
11. **Verify from the outside:** a fresh clone, its size, and that the paths appear in no ref.

## What made this safe here

Every object removed was ciphertext under a key that never entered the repository, the `local/` tier was gitignored from the first commit and the tripwire that scans for the passphrase has run on every release since [the one time it got in](exposed-vault-key.md). So the old chain surviving on a forgotten branch for a few hours is a storage anomaly, not an exposure. The same procedure applied to a repository where the plaintext tier *had* been committed would be the right mechanics in the wrong order: the rewrite would go through, the stale branch would keep the plaintext downloadable, existing clones would keep it forever, and the only thing that would actually have protected anyone is the rotation that should have come first.

## Related

- [One working tree, two version control systems, and why we stopped](one-tree-two-remotes.md), why the mirror existed and why it was retired
- [The day we leaked our own vault key](exposed-vault-key.md), the same tools, in the order that matters when a secret is involved
- [Git repos inside vaults](../docs/vault/git-and-vaults.md), the pattern this repository used, still right when something reads the mirror
- [Release history](../admin/versions.md), where the commit column switches from the old chain's ids to the new one's

[← One tree, two remotes](one-tree-two-remotes.md)[The exposed vault key →](exposed-vault-key.md)



==============================================================================
# Security model, sgit

> sgit's zero-knowledge security model, precisely stated: the crypto stack, what the server can and cannot see, key strength, and the open security process.
>
> Page: https://sgit.ai/security/index.html

# Security model

Zero knowledge, precisely stated: every file is encrypted on your machine before upload, keys are derived locally from your vault key, and the server stores ciphertext under opaque identifiers. This page tells you exactly what that means, including what the server *can* see.

## What the server sees, and never sees

| The server never sees | The server does see |
|---|---|
| File contents (encrypted client-side, AES-256-GCM) | The vault ID (an opaque random identifier) |
| Filenames and folder structure | Encrypted object sizes |
| Commit messages and branch names | Timing of reads and writes |
| Your vault key or any derived key | Approximate activity volume (object counts) |

We state the right-hand column deliberately. Traffic analysis of sizes and timing is a real (if narrow) channel, and pretending otherwise would be marketing, not security.

## The crypto stack

| Layer | Construction |
|---|---|
| Content encryption | AES-256-GCM, 12-byte IV, 16-byte tag, byte-compatible with the browser's Web Crypto API |
| Key derivation from the vault key | PBKDF2-HMAC-SHA256, 600,000 iterations, distinct per-vault salts for read and write keys |
| Purpose-specific keys | HKDF-SHA256, per-file keys and a structure key, one-way derived from the read key |
| Server-side identifiers | HMAC-SHA256-derived opaque IDs, the server addresses files it cannot name |
| Object identity | Content-addressed: `obj-cas-imm-<sha256-prefix>` over ciphertext, enabling dedup without plaintext knowledge |

One precision note, because precision beats marketing: the key hierarchy derives a *structure key* (one-way from the read key) designed to separate access to vault metadata from access to file contents. Today, vault objects are encrypted under the read key, activating the structure-key split across structural objects is an in-progress, reviewed design change, and this page will say so when it lands, not before.

## Two key systems, and where each applies

Everything above describes the **symmetric** half, and it is the half that matters most: the vault key is symmetric, it is the root of the storage hierarchy, and every object in a vault is encrypted under a key derived one-way from it. If you only ever use sgit to sync your own files across your own machines, that is the whole system.

There is a second half. Layered on top is a **public-key** system, for the two things a shared symmetric key cannot express: **proving who wrote something**, and **encrypting to somebody who does not hold your vault key**. It is what makes [vault-to-vault messaging](../docs/vault-messaging.md) possible, a sender can encrypt to your published public key and drop the result into your vault without ever being able to read it.

|  | Vault key (symmetric) | Keypair (asymmetric) |
|---|---|---|
| What it is | One generated string: address, credential and encryption root | An encryption pair and a signing pair, generated locally |
| What it protects | Every object in the vault | Individual files addressed to a recipient, and signatures over them |
| Who holds it | Everyone who can open the vault | Private half: you alone. Public half: publish it freely |
| Answers | “Can this person open the vault?” | “Who wrote this?” and “Can only *they* read it?” |
| Where it lives on the server | Never, the server holds ciphertext only | Public keys at `bare/keys/key-rnd-imm-*`. Private keys never leave your machine |

The constructions, read out of `sgit pki keygen` on v0.15.0 rather than recalled: **RSA-OAEP 4096-bit** for encryption and **ECDSA P-256** for signing, with a hybrid envelope, RSA-OAEP wraps a per-message AES-256-GCM content key. Private keys are passphrase-protected at rest. The full lifecycle is on [the PKI page](../docs/pki.md).

**This section is new, and its absence had a cost.** Until now this page described the symmetric design and simply did not mention asymmetric cryptography, it never claimed PKI was absent, but it never said it was present either. An agent researching how to send a message between vaults read this page, concluded there was no public-key layer, and stopped looking. The capability had shipped; the sentence that would have pointed at it had not been written. Silence on a page like this one reads as denial.

## Key strength

Vault keys are generated, not chosen. A generated passphrase is 24 characters over a 36-symbol alphabet (about **124 bits of entropy** (3624 ≈ 2124), far beyond brute-force reach) before key derivation adds 600,000 rounds of PBKDF2-SHA256 on top. The key never travels to the server: it is the address, the credential, and the root of the encryption hierarchy in one string, and it stays on your machines.

**Consequence you should want:** there is no password reset. If you lose the vault key, nobody, including us, can recover the contents. Keep it in a password manager, and use `sgit vault backup` for belt-and-braces.

## Two implementations, one wire format

The sgit CLI and the SG/Vault browser client are independent implementations of the same encrypted wire format, kept interoperable through a versioned contract with test vectors. Every crypto operation must produce byte-for-byte identical output to the Web Crypto API given the same inputs, that requirement is enforced with mandatory test vectors, and it means a second, independent codebase continuously exercises the same format. (More on the browser side at [sgraph.ai](https://sgraph.ai).)

## Secrets safety by default

sgit is not a secrets manager, and it actively refuses to become an accidental one: files like `.env*`, `.netrc`, `.pgpass`, `.git-credentials` and private key files (`id_rsa`, …) are *always* excluded from commits, so a stray credential can't get swept into a vault snapshot.

## Open security process

- Open source under Apache-2.0, with a deliberately tiny dependency surface: two runtime dependencies.
- ~4,000 tests including mutation testing in CI and integration tests against a real server, no mocks.
- An internal security review series (twelve findings, each individually worked through and debriefed, covering key residency, IV determinism trade-offs, logging hygiene, and more) is being prepared for publication on this page.
- Found something? Report it via [GitHub](https://github.com/SGit-AI/SGit-AI__CLI/issues), security reports get priority.
- **Key exposed?** [The rotation runbook](../case-studies/exposed-vault-key.md), including a worked case study of the day this site's own vault key leaked, and what it cost to fix.

**Honesty note:** sgit is in beta (it powers production workflows daily, and the cryptography is conservative and standard (AES-GCM, PBKDF2, HKDF) nothing exotic). Still: read [when NOT to use sgit](../docs/limitations.md) before trusting it with anything critical.



==============================================================================
# Why does this exist?, sgit.ai

> A direct answer to the sharpest criticism we received: no market, no value. The use cases, why existing tools do not cover them, where the criticism is right, and a FAQ of the follow-up questions.
>
> Page: https://sgit.ai/why/index.html

# Why does this exist?

This page is a boundary map, not a pitch. It starts with where git wins (plainly, in a table, without hedging) because a page that names the incumbent's territory is falsifiable, and falsifiable is what makes the rest of it worth reading. Then it draws what is left: the territory where the store being unable to read your files changes what is possible.

**The whole thesis in one sentence:** you have files that need version control and collaboration, and the place they are stored must not be able to read them.
Everything below is a consequence of that sentence. If it doesn't describe a problem you have, use git and a private repo. We say so on [the page about when not to use this](../docs/limitations.md).

## git and sgit, side by side

The honest framing is not "sgit instead of git". It is two tools with different jobs, and the interesting question is which one owns which files. **This site ran both at once** for its first 76 releases (one working tree, two remotes) and then [retired the vault mirror](../case-studies/one-tree-two-remotes.md), because git was doing the deploying and nothing was reading the vault. The thirty vaults it publishes are the other half of the answer: sgit owns the content whose readers hold the key; git owns the pages that describe it.

|  | git | sgit |
|---|---|---|
| **The host can read your content** | Yes. That is what makes everything else work | No. It stores ciphertext under opaque ids and never receives a key |
| **Performance at scale** | **Far better.** Twenty years of optimisation: packfiles, deltas, a mature index, repos with millions of files | Built for working sets of documents and code-sized files. Every object is encrypted and content-addressed individually; large binaries chunk-upload past ~4 MB but this is not a video archive |
| **Ecosystem above the protocol** | **Everything.** CI, hosted code review, issue tracking, IDEs, decades of tooling and answers | A CLI, a browser client, and an agent skill. Deliberately small, and young |
| **Proposing changes without write access** | Fork + pull request, mediated by the platform, requires an account there | A [serialised diff](../use-cases/serialised-pull-request.md), the proposer holds no credential at all, and the artefact moves by any channel |
| **Archaeology** | **Better.**`bisect`, `blame`, `rebase`, `cherry-pick`, hooks, submodules | `history log / diff / show / revert / reset`. No bisect, no blame, no rebase. The server cannot help, so anything not implemented client-side does not exist |
| **Partial commits** | Staging area, index, `add -p` | None. A commit snapshots the whole folder |
| **Branching and merge** | The reference implementation of the idea | The same shape, applied to encrypted objects: a private branch per clone, shared named branches, whole-file three-way merge |
| **Read-only access for someone else** | An account on the host, or a deploy key that reads plaintext | A read key, derived one way, publishable, works against any server holding the ciphertext, no account and no host involvement |
| **Reading it from a browser** | Via the host's UI or API, in plaintext | Directly: fetch the ciphertext and decrypt in the tab with Web Crypto. This page's [Deploy section](../deploy/index.md) is that |
| **If the host is breached** | Your content is in the breach | Opaque ids, ciphertext, object sizes and timing |
| **Recovery when you lose the credential** | Reset your password; the repo is unaffected | Nothing. No reset, no recovery. The direct cost of the row above |

**So the split, concretely:** source code, issues, CI config and anything you would be happy to open-source belong in git. It is better at them and always will be. The material where "who can read the store" is the binding constraint belongs in a vault. Plenty of projects have both, and there is no reason to choose: the two live in one directory, ignore each other, and are pushed separately. The [side-by-side setup](../docs/vault/git-and-vaults.md) (what to commit, what to keep out of git, and the `.gitattributes` that stops git trying to diff ciphertext) is documented, because it is how this site is developed.

## The boundary, precisely

Two corrections to where people assume the line falls, because the obvious version of this map is wrong:

**The boundary is not the operations.** sgit has commit, push, pull, clone, branch, switch, merge with conflict resolution, history, diff, revert and stash, the full mapping is on [one page](../docs/sgit-for-git-users.md) and does not need restating here. What is absent is the *hosted review interface* and the ecosystem above the protocol: CI, issue tracking, server-side search, delta compression. A pull request is a platform construct layered on a merge, not a version-control primitive, and proposing reviewable changes *without holding write access* is present, as a [serialised diff](../use-cases/serialised-pull-request.md), and is a differentiator rather than a gap.

**Git is also client-side.** The difference is not that work moved to the client, a git client already holds the complete object model and history. The difference is that in sgit *the objects are encrypted there*, so what is lost is exactly what a readable server could have added on top:

| Given up | In exchange for |
|---|---|
| Server-side search and indexing | Nothing readable to disclose, not to the host's staff, not to a breach, not to a subpoena served on the host |
| Server-side delta compression and packing |
| Hosted review, CI, and content-triggered automation |

That is the whole trade, stated once. Every capability further down this page is something bought with it. The same boundary is also drawn as [six Wardley Maps, served live from an encrypted vault](../demos/sgit-maps.md), including a map of git at full strength, because a map that flatters its author is not a map.

## The protocol, on one page

sgit is a protocol more than a product, and the strongest evidence is that the read path fits in six steps. Two independent implementations, the Python CLI and the JavaScript browser client, walk it against the same vaults, and the file-naming convention is documented well enough that a third party could implement it:

```
1. branch name  → deterministic filename       # derived locally — no lookup, no listing
2. that file    → the head index
3. head         → the commit        # encrypted
4. commit       → the tree          # encrypted — filenames live in here
5. tree         → blob, or another tree
6. decrypt the blob → your file
```

Deterministic names disclose *existence, not content*: everything the server ever holds is a bit of metadata (opaque ids, sizes, timing) and ciphertext. And the filenames carrying structure is what makes browser consumption fast: a client can decide to cache a file forever without knowing what it is, because content-addressed ids can never change underneath it.

**Two keys, named explicitly.** The *vault key* encrypts, decrypts and writes; it is the credential and there is no reset. The *read key* is derived one-way from it: it can decrypt everything and write nothing, which is what makes it safe to hand out, or [publish](../demos/vault-app-embed.md). (An API access token is a third thing and often confused: it gates service usage, does no encryption, and is transparent to the security model.)

**Three modes, one vault.** *Local*: a person or agent on one machine, offline included. *API*: agents and services against the REST endpoints. *Web*: people in a browser, with a key in the fragment. The same vault serves all three at once; an agent can create a vault in a terminal session and a person can be reading it in a browser moments later.

## The other side of the boundary: what this makes possible

This page assumes you know git, so here is only the delta: things you cannot do with git and a host, or cannot do without that host reading everything. Each one is running on this website right now. The links go to the thing itself, not to a description of it.

### A live website whose host cannot read it

The [Deploy section](../deploy/index.md) of this site is not part of this site. Its pages live in an encrypted vault maintained by a different team; your browser fetches the ciphertext straight from an SG/Send server over CORS and decrypts it in the tab. There is no build step, no CI job, no copy of that content on sgit.ai. When that team runs `sgit push`, the next page load has it.

**Without sgit:** you can serve a static site from a host, or you can keep the content private, but not both. GitHub Pages serves what GitHub can read. A private bucket plus a decrypting front end is buildable (content addressing, cache tiers, key derivation, an update path) and that is roughly the thing being described here. There is no documented, off-the-shelf way to do it with git and a git host.

See it working: [how this page works](../case-studies/live-vault-docs.md), with the object model and the request timeline.

### Read access as a thing you can publish

A vault has a **read key** that is derived one way, so it decrypts content and cannot be turned back into write access. That makes it safe to put in a file the whole internet can fetch, which is exactly what `deploy/vault.json` on this site does. Anyone can take it and run `sgit clone --read-key <key> fyofmkvr` to get the same documents on their own machine, and watch a write attempt get refused.

**Without sgit:** git access is repository-shaped and host-mediated. A deploy key that can read gives its holder everything in plaintext, and revoking it is an operation on the host's access-control list. Here, the capability *is* the key: it travels with the reader, it works against any server holding the ciphertext, and the host is not asked to enforce anything.

### Two agents collaborating in a workspace neither host can read

This site is built and published by Claude Code sessions that share state through a vault. Each session clones into its own private branch, commits there, and pushes to the shared named branch, the [two-branch model](../docs/two-branch-model.md), which is git's isolate-then-merge shape applied to encrypted objects. The pages in the Deploy section come from a *second* team's vault, maintained by an agent that has never had access to this repository or this site.

**Without sgit:** agent-to-agent shared memory means a database or a repo that the provider reads. That is fine until the state includes client documents, security findings, or unreleased work, at which point the question stops being technical.

The architecture, drawn: [two sessions, one vault, one live site](../case-studies/live-vault-docs.md).

### Private data with public-CDN economics

Object ids are SHA-256 hashes *of the ciphertext*, so an object can never change under its id. That makes every object permanently cacheable by infrastructure that cannot read it, a browser's Cache API, a proxy, a CDN edge. On this site that is not theory: after the first visit, a page load fetches **one 69-byte object** (the mutable HEAD pointer) and serves everything else from cache, and inside the [freshness window](../case-studies/live-vault-docs.md) it fetches nothing at all. Open the vault panel on any Deploy page and watch the counters.

**Without sgit:** caching private content at the edge is precisely what you are told not to do, because the cache would hold readable data. Content-addressed ciphertext removes the conflict, the cache holds bytes it cannot interpret, keyed by a hash it cannot invert.

### Storage becomes a commodity you don't have to trust

The server is a key-value store for opaque ids. It never receives a key, never sees a filename, and cannot tell a legal draft from a photo. That means the backing store is interchangeable (a managed SG/Send server, one you [run yourself](../deploy/index.md), an S3 bucket, a disk) and choosing it stops being a trust decision. A subpoena, a breach, or a curious administrator on that host yields ciphertext.

**Without sgit:** "who hosts this?" and "who can read this?" are the same question. Every migration is a re-negotiation of that trust; here it is a copy operation.

### Transit security that doesn't rest on the CA system

The content is already encrypted before it leaves the client, so TLS is transport hygiene rather than the security boundary. A mis-issued certificate, a coerced or compromised CA out of the ~150 your browser trusts by default, or a TLS-terminating middlebox in a corporate network sees the same thing the server sees: ciphertext addressed by opaque ids.

**The advanced version**, and where this is heading: the read key stays on the client and never appears in a published file, or the scheme moves to PKI with the private key existing only on the client. Then the confidentiality of the data in transit depends on one key you hold, not on the whole certificate-authority arrangement being sound end to end. Today's published-read-key form on this site is the deliberately simple case: the content *is* meant to be public, so the only job is proving the host never had it in the clear.

## Who has that problem

Not a market-size claim, just the situations where the sentence at the top is literally true today. These matter, but they are the ordinary reasons; the section above is the interesting one.

[AI agents### Agent state that isn't the vendor's to readAn agent's work has to survive its context window, so it goes somewhere, and that somewhere increasingly holds client documents, security findings, unreleased code.Recipe, evidence and an agent brief →](../use-cases/ai-agents.md)

[Professional services### Working documents with clientsLegal, M&A, audit, security assessment: the deliverable and the working notes are exactly the material that must not sit readable on a third party's disk.Recipe, evidence and an agent brief →](../use-cases/professional-services.md)

[Health & regulated### Data that changes what is permissibleWhen the host provably cannot read the content, you are no longer arguing about the provider's access controls, because there is nothing to control access to.Recipe, evidence and an agent brief →](../use-cases/health-regulated.md)

[Security teams### Findings about your own weaknessesPentest results are the last thing you want in a SaaS you don't control, and the first thing that needs history, diffs and multi-person workflow.Recipe, evidence and an agent brief →](../use-cases/security-teams.md)

## Why the existing answers don't cover it

This is the strongest form of the objection: every one of these exists and is more mature. Each solves part of it.

| What you'd reach for | What it gives you | What's missing |
|---|---|---|
| git + a private repo | Everything about workflow, perfected | The host reads all of it. Fine for code; not for client data, and none of the six capabilities above. |
| git-crypt / SOPS / age | Encrypted file *contents* inside git | Filenames, directory structure, commit messages and history shape stay readable to the host; no browser access; key distribution is manual. |
| Dropbox / Drive / SharePoint | Sync, sharing, a UI everyone knows | The provider can read it, and there are no branches, no merges, no commit history you can reason about. |
| S3 + KMS, or a database with encryption at rest | Encryption the auditors recognise | Whoever holds the key can decrypt, and that's the provider, or anyone with the right IAM role. No git-shaped workflow, no offline. |
| Build it yourself | Exactly what you want | Roughly what this project is: four thousand tests, a wire format two independent clients agree on, and a year of edge cases. It's free. You may as well take it. |

The gap they share is the same one: **you can have the workflow, or you can have the privacy, but not both in the same tool.** If you think that gap doesn't matter, we disagree about something factual, a much better disagreement to have than one about adjectives.

## The comment this page answers

> "I appreciate the work and effort in this but i see no market or value what so ever (especially market). My first question if was being sold this would be why but then don't try and answer cause i would return with so many follow up questions to anything you would say."

Someone left that under the announcement post, and it is the most useful comment we received, the boundary map above is the answer to "why", made falsifiable instead of rhetorical. Two things it gets right before the rebuttal starts: most answers to it *are* marketing, and there is nothing being sold, sgit is Apache-2.0 and installable with `pip install sgit-ai`, so the only question worth answering is why anyone would **use** it.

## The market question

- **The client is open source, and that is the distribution strategy, not a substitute for one.** Apache-2.0, no licence tiers, no open-core feature gating in the CLI. It spreads by being free and useful, and the services are built on top of it, the ordinary way open source scales into a business.
- **The commercial layer is the hosted service** (SG/Send) and what gets built around it. You can also [self-host](../deploy/index.md) (that guidance is published, live, in a vault) so the lock-in argument doesn't hold: if the commercial layer becomes unpalatable, you run your own server and your data and workflow are unaffected.
- **We are not going to quote a market size.** We don't have credible numbers, and a TAM slide is exactly the marketing this page is avoiding. What we can say honestly: the amount of machine-generated state that someone else should not be able to read went from approximately zero to very large in about two years, and it has to live somewhere.
- **It might still be a small market.** That's a legitimate outcome. The tool would still be worth having for the people in it, and it costs them nothing.

## Where the criticism is right

- **The category is unproven.** "Git for encrypted vaults" is not a shelf anyone shops from yet. We might be early, wrong, or both.
- **Most people don't need it.** If your files aren't sensitive, this is strictly more complexity than a private repo.
- **Zero-knowledge has real costs**: no server-side search, no password recovery, and key management becomes your problem. Permanent trade-offs, not bugs to be fixed later.
- **It's beta.** In production use daily, but young.

## The follow-up questions

You said you'd have many. Here are the ones we'd expect, answered without hedging. If yours isn't here, [ask it in public](https://github.com/SGit-AI/SGit-AI__CLI/issues) and we'll add it.

**Give me one thing I cannot do with git and GitHub today.**

Publish a site whose content the host has never seen in the clear, updated by a push, readable by anyone you hand a read key to, and cached at the edge by infrastructure that cannot decrypt it. The [Deploy section](../deploy/index.md) is that, live. You can assemble something similar yourself out of a bucket, a decryption front end and a cache policy, and what you would have assembled is this.

**Isn't publishing a key on a website obviously a mistake?**

Publishing a *write* key would be. We have an [incident write-up](../case-studies/exposed-vault-key.md) about doing exactly that by accident. The read key is a different object: derived one way, it decrypts and cannot be inverted into write access. Publishing it is how a reader gets the content without the site ever being trusted with the ability to change it. That's a checkable property, not a policy: take the key, clone with it, and watch the write get refused.

**Doesn't TLS already solve the confidentiality problem?**

TLS protects the hop, not the destination. It ends at the server, which then holds your plaintext, and it rests on a certificate-authority system where any of roughly 150 default-trusted roots can vouch for any name, and where corporate middleboxes terminate it on purpose. Encrypting before the bytes leave means a mis-issued certificate or a terminating proxy sees ciphertext. The direction of travel is stronger still: the read key never leaving the client, or PKI where the private key exists only there.

**Isn't this just git with encryption bolted on?**

No, and the difference is why the existing tools don't cover the case. Encrypting files inside git still leaves the host holding your filenames, directory structure, commit messages and the shape of your history. sgit encrypts all of that: the server sees opaque identifiers and ciphertext, and never receives a key. A different storage model that keeps git's verbs.

**Why not git-crypt or SOPS? They're mature and I already know them.**

Use them if they fit, they're good tools designed for a different job: keeping a handful of secrets inside an otherwise-public repo. They don't hide structure, don't work in a browser, and key distribution across a team is manual. sgit targets the case where the *whole workspace* is the sensitive thing.

**If it's free, what's the business model, and what happens when you need to make money?**

The hosted service, and what gets built on it. The client stays Apache-2.0 and self-hosting is documented, which is the protection that matters: the escape hatch is a checkable property of the format, not a promise about future behaviour.

**What if you disappear?**

You keep a full local copy, every clone contains the complete encrypted store. The format is documented, the client is open source, and two independent implementations already read it. If the project stopped tomorrow, your data stays readable with code you already have.

**"Zero-knowledge" is a marketing term. What does the server actually see?**

The vault ID, the size of each encrypted object, and when requests happen. That's the list, and it's on [the security page](../security/index.md) including the uncomfortable parts: object sizes and timing are a real, if narrow, side channel. Anyone who tells you their zero-knowledge system leaks nothing at all is not being careful with words.

**How do I know the cryptography is right?**

You don't have to take our word for it, which is the point. It's standard and boring (AES-256-GCM, PBKDF2-SHA256 at 600k iterations, HKDF) with no custom primitives. The code is open, and the outputs must match the browser's Web Crypto API byte-for-byte, enforced with test vectors. Two independent implementations reading the same format is a stronger check than any single audit.

**What happens when I lose the key? Be honest.**

The data is gone. No reset, no recovery, no support ticket that helps. That's the direct consequence of the server not being able to read your content, and if your organisation can't manage keys reliably, this trade-off will hurt you and you should not use it.

**Why would an AI agent need this specifically?**

Because agent state is now sensitive and shared. An agent that stops and resumes needs durable memory; several agents working together need shared memory with isolation and a review step; and the contents are increasingly things a client or regulator cares about. Version control solves the coordination half. Client-side encryption solves the half that determines whether you're allowed to do it at all.

**Isn't this over-engineered for what it does?**

Judge it by the surface: two runtime dependencies, a pure-Python client, one file format. The complexity that exists (the two-branch model, content addressing, three-way merge) is what makes concurrent editing safe without the server being able to help, because the server can't read anything. Remove the encryption and yes, it's over-engineered; you'd just use git.

**Is anyone actually using it, or is this a demo?**

This website is served from a vault it manages, deployed by pushing that vault. The [deployment docs](../deploy/index.md) are decrypted in your browser, live, from a different vault maintained by another team. The [Try page](../try/index.md) runs the real client in your browser. It's in daily production use by its authors, a small n, honestly stated, and more than a demo.

**Why should I trust a beta?**

For anything critical, don't yet, and keep backups regardless. What we offer instead of a trust-me is evidence: ~4,000 tests, mutation testing, integration tests against a real server, a published threat model, and an [incident write-up](../case-studies/exposed-vault-key.md) of the day we leaked our own key, including what it cost to fix. A project that hides that class of mistake is the one to worry about.

**Fine, but I still think there's no market.**

You may be right. It costs nothing to be wrong about this in our direction: the code is free, the format is open, and if the category never materialises, the people who did need it still got a working tool. The failure mode we'd actually regret is the opposite one, building it after everyone had already put their machines' private state somewhere readable.

## An invitation, meant literally

You said you'd come back with many follow-up questions. Please do, [in the open, on the issue tracker](https://github.com/SGit-AI/SGit-AI__CLI/issues). Sharp questions from someone who doesn't buy the premise are worth more than agreement, and if any of them don't have a good answer, that's a finding: it goes on this page, or it changes the roadmap. That's the same way the [key-leak incident](../case-studies/exposed-vault-key.md) and the [open briefs](../docs/briefs/index.md) got written.

[← Home](../index.md)[When NOT to use sgit →](../docs/limitations.md)



==============================================================================
# Run your own SG/Send server (sgit.ai)

> Deployment guidance for self-hosting a zero-knowledge SG/Send server) rendered live in your browser from an encrypted vault, with no copy stored on this site.
>
> Page: https://sgit.ai/deploy/index.html

[Home](../index.md) / Deploy

# Run your own SG/Send server

Deployment guidance for standing up your own zero-knowledge vault server, Docker, AWS, GCP, Heroku, or a static host. **These pages are not part of this website.** They live in an encrypted vault maintained by the SG/Send team, and your browser is decrypting them right now with a published read-only key.

**How this page works:** the vault's ciphertext is fetched straight from the SG/Send server over CORS, and the AES-256-GCM decryption happens in this tab using the Web Crypto API. There is no build step and no copy of the content on sgit.ai, when the SG/Send team runs `sgit push`, the next load of this page has it. Open the **vault panel** (right edge) to watch the objects being fetched, see which came from cache, and check the exact commit you are reading. [**Full architecture, with diagrams →**](../case-studies/live-vault-docs.md)

opening vault…

Fetching the encrypted index…

### Vault debug [how this works →](../case-studies/live-vault-docs.md)

not open yet

what you are looking at

 Every row above is an encrypted object pulled from the SG/Send API and decrypted locally: click one to see what it actually contains. Objects whose id contains **-imm-** are content-addressed and therefore immutable, so they are cached permanently; the mutable **ref** is the one mutable object, so it is checked at most once per freshness window (120s) rather than once per page, inside the window, reading the docs makes no requests at all, and **check for new commit** forces one whenever you want it.

The **tree** objects are the reason a first visit reads more than one file: filenames are encrypted inside them, so building the navigation means reading every directory. That index is a pure function of the commit id, so it is memoised, after the first visit, an unchanged commit reads no tree objects at all. Nothing here is stored on sgit.ai.

[How this page works →](../case-studies/live-vault-docs.md) Architecture diagrams, the object model, the cache tiers, and how two Claude Code sessions publish into this vault.



==============================================================================
# A live site whose host cannot read it, sgit.ai case study

> A case study in the mechanism: two Claude Code sessions, two encrypted vaults, one page, with architecture diagrams of the publishing pipeline and the in-browser read path.
>
> Page: https://sgit.ai/case-studies/live-vault-docs.html

[Home](../index.md) / [Deploy](../deploy/index.md) / How this works

# How this page works

The [deployment guidance](../deploy/index.md) next door is not stored on this website. It is written by a different team, in a different Claude Code session, into a different encrypted vault, and your browser assembles it from ciphertext at the moment you ask for it. This page explains the whole mechanism, because it is a compact demonstration of what sgit is actually for.

## Two sessions, two vaults, one page

Nothing here is a pipeline anyone had to build. Both sides just use sgit, and the shared vault format does the integration:

*[diagram]*
Neither team's session knows about the other's. The only shared thing is a vault format and a published read key.

Concretely, when the SG/Send team improves a deployment guide, the sequence is: edit markdown → `sgit commit` → `sgit push`. That is the entire publish step. There is no build to trigger on our side, no webhook, no content sync, and no copy of their text in our repository. The next visitor to the Deploy page gets the new version because the browser reads their vault's current commit.

## What happens when you open the page

Everything below runs client-side, in about 300 lines of JavaScript using the browser's built-in Web Crypto API:

*[diagram]*
The server answers ordinary GETs for opaque file ids. It never sees a key, a filename, or a byte of plaintext.

## Why the caching is safe, and why it's this shape

The cache policy is not a tuning choice; it falls out of the data model. Object ids are content hashes *of the ciphertext*, so an object can never change under its id, which makes it permanently cacheable. The ref is the one mutable pointer, so it is the only thing that has to be refetched at all:

| Tier | What it holds | Lifetime | Why |
|---|---|---|---|
| memory | decrypted objects | this page session | avoids decrypting the same tree twice while you click around |
| Cache API | ciphertext of `obj-cas-imm-*` | until you clear it | content-addressed ⇒ immutable ⇒ can never be stale |
| localStorage | the file index (path → blob) | keyed by commit id | a pure function of the commit, so an unchanged HEAD reads no tree objects |
| freshness window | the ref (`ref-pid-muw-*`) | **120 s** (`ref_ttl_s`) | it is the mutable HEAD; checking it once per window instead of once per page view is what takes steady-state reading to zero requests |

### The freshness window

The ref has to be refetched sometimes. That is how a new commit is noticed. It does not have to be refetched on *every page view*. So the answer is kept for `ref_ttl_s` seconds (120 by default, set in `deploy/vault.json`), and inside that window the reader reuses it.

Three things follow, and they are the whole trade:

- **Reading the docs costs nothing.** Click through ten pages inside the window and the network stays silent, every object is content-addressed and already cached, and the one mutable object is inside its window. The panel logs the ref as `TTL` with a live countdown to the next check.
- **Server load stops scaling with page views.** It scales with *readers per window* instead: one 69-byte request per reader per two minutes, however much they read.
- **Propagation is delayed, and bounded.** A new commit is picked up within 120 seconds at worst, and immediately if you press **check for new commit**, which forces a fetch and ignores the window. That button is not a debug affordance; it is the escape hatch that makes the window safe to have.

Measured on this site: a cold load fetches 18 objects (~14 KB); the next load fetches **one 69-byte object**, the ref, and serves the rest from cache; a load inside the freshness window fetches **nothing at all**. Open the vault panel and press **clear list**, then click around, to watch it happen.

## Who can see what

### SG/Send server

- opaque object ids
- ciphertext blobs
- sizes and timing
- the vault id

### GitHub Pages

- the page shell
- the public read key
- no vault content at all

### Your browser

- the read key
- decrypted filenames
- decrypted content
- the commit history

Two hosts, neither of which can read the documents. The decryption exists in exactly one place: the tab in front of you.

The read key is deliberately public. It is *read-only by construction*, derived one-way so it cannot be turned back into write access. Publishing it is what lets the site show the content without the site ever being trusted with the ability to change it. Anyone can verify that: take the key out of `deploy/vault.json`, run `sgit clone --read-key <key> fyofmkvr`, and watch a write attempt get refused.

## Why this is the interesting demo

- **Two teams integrated without integrating.** No API contract was designed, no sync job written, no permissions negotiated. One side pushes to a vault; the other side holds a read key. That is the whole interface.
- **Publishing is a git operation.** The SG/Send team's release process is `sgit push`, and their content appears on a website they do not control and cannot deploy to.
- **Least privilege that is structural, not procedural.** This site *cannot* alter their documentation, however compromised it might be, because the key it holds does not carry that power.
- **The same property scales down to one agent.** Give an agent a read key and it can read a knowledge base without any ability to corrupt it; give it the full key and it can contribute. That is the same mechanism this page uses, applied to agent workflows.

## The honest trade-offs

- **Search engines and agents see an empty shell.** Content that only exists after decryption is invisible to anything that does not run JavaScript. sgraph.ai solves this by decrypting at the CDN edge and serving `.md` alongside each page; this site is static, so it does not. That is a real cost of the approach as built here.
- **It needs a secure context.** Web Crypto is unavailable over plain HTTP, so this only works on HTTPS (or localhost).
- **The server can't help.** No server-side search, no previews, no summaries. Everything is opaque to it. That is the point, and it is also a limitation.
- **Diagrams are hand-drawn SVG, not a diagramming library.** This site is also served *from inside a vault*, where external resources are blocked by the app authoring contract, so importing a renderer from a CDN would break the very demonstration this page describes. The constraint chose the implementation.

[← The deployment docs](../deploy/index.md)[Git and vaults →](../docs/vault/git-and-vaults.md)



==============================================================================
# Try sgit in your browser, sgit.ai

> The real sgit-ai package running client-side under Pyodide: derive keys, encrypt, run an in-memory vault, and use a Python console, nothing you type leaves the page.
>
> Page: https://sgit.ai/try/index.html

# Try sgit in your browser

This page downloads a Python runtime (Pyodide, ~20 MB) and installs the **real `sgit-ai` wheel from PyPI**, the same code `pip install` gives you, then runs it right here: a working terminal with the actual `sgit` CLI, an in-memory filesystem, and a network transport routed through your browser. Keys are derived and content encrypted locally; nothing you type leaves this page except the ciphertext sgit itself sends when *you* run a network command.

**What this is:** sgit's engine, client-side. File commands run against this tab's in-memory filesystem (gone on refresh; the remote vault persists). Network commands (`clone`, `push`, `pull`, `doctor`) go straight from your browser to the SG/Send servers over CORS, the page freezes while they run (synchronous transport; it's a demo, not a product). First load is heavy (~20 MB, cached afterwards); 600,000 PBKDF2 rounds take ~1–2 s in WebAssembly.

engine not loaded

## The terminal

The real `sgit` CLI plus a small toolbox of file commands (`ls`, `cd`, `cat`, `mkdir`, `echo > file`, `tree`, …). Type `help` for the list. History with ↑/↓.

load the engine above to start

/workspace $

```
# a session to try (the vault key can be any vault you hold a key for):
sgit init my-vault  cd my-vault  echo "hello" > notes.md
sgit status  sgit commit -m "from a browser"
# and the one that makes it real — clone straight from the SG/Send servers:
sgit clone <vault-key> demo  cd demo  ls  sgit history log --oneline
```

## Python console

The full `sgit_ai` package is importable. The last expression's value is printed.

from sgit_ai.crypto.Vault__Crypto import Vault__Crypto vc = Vault__Crypto() vc.derive_keys('my-passphrase', 'DEMO-VAULT')

How this works: [the same site](../docs/vault/static-hosting.md) serves from an encrypted vault or GitHub Pages; this page pulls Pyodide from a CDN and the wheel from PyPI at runtime, so it needs an internet connection, the one page on this site that does.



==============================================================================
# Skills for AI agents, sgit

> Packaged, versioned instructions that make any AI agent an effective sgit and vault user: operate the CLI, build vault apps, author vault content.
>
> Page: https://sgit.ai/skills/index.html

# Skills, sgit for AI agents

A skill is a packaged set of instructions an AI agent loads to do a job well: the commands that matter, the patterns that work, the traps already hit and documented so the agent doesn't hit them again. sgit treats agents as first-class users, so its skills are first-class artifacts, versioned, verified against specific releases, and shipped right here in this vault.

## The three skills

## Operate

[use sgit and vaultsThe CLI end to end, and the cross-session pattern: clone/pull at session start, commit + push at session end, so state survives the context window. Includes the multi-agent branch-per-agent workflow.](use_sgit-and-vaults__SKILL.md)

## Build

[create vault appsThe vault-app playbook: the authoring contract, what the host gives you for free, proven layout patterns, the validation gate, and a nine-row table of failure modes with fixes, all bug-fixed against real vault behaviour.](create-vault-apps__SKILL.md)

## Author

[create vault contentStructured content without code: the full _page.json schema (embedded, no repo clone needed) and vault markdown authoring, with checklists and copy-paste templates.](create-vault-content__SKILL.md)

**Not yet in the skills: vault-to-vault messaging.** These three files ship verbatim from upstream and this site does not edit them. As of the current versions, the operate skill documents `sgit pki` as file signing and encryption, and does not mention [append lanes](../api/append-lanes.md), so an agent reading only the skill has both halves of the messaging mechanism and no statement that they combine. That is exactly the failure that produced [the messaging page](../docs/vault-messaging.md): an agent asked how to send a message between vaults and could not get there. Until the skill catches up, point agents at [/docs/vault-messaging](../docs/vault-messaging.md) alongside it.

## Installing a skill

For Claude Code and compatible agents: drop the skill file into your skills directory (e.g. `~/.claude/skills/<name>/SKILL.md`) or paste it into the session as context. The skill's own description tells the agent when to trigger it. A minimal bootstrap for a fresh session is one line:

```
$ pip install sgit-ai && sgit clone <vault-key> workspace
# then read skills/ inside any vault that ships them — like this one
```

The skills above are the canonical current versions, verified against sgit-ai v0.14.x and the current app-shell. They carry their own honesty markers, including which CLI commands are disabled right now and which platform features are trial-only, so an agent reading them gets ground truth, not marketing.

**Also for agents:** this site ships an [llms.txt](../llms.txt) at the vault root, the standard machine-readable index. Inside the vault it is encrypted like everything else (agents holding the key read it via `sgit cat llms.txt`); on a static deployment it becomes a plain public llms.txt. Same file, two trust contexts.

[← Working with AI agents](../docs/agents.md)[The SG/Vault platform →](../docs/vault/index.md)



==============================================================================
# Documentation, sgit

> sgit documentation: quickstart, concepts, guides for humans and AI agents, and the honest limitations page.
>
> Page: https://sgit.ai/docs/index.html

# Documentation

Start with the five-minute quickstart. If you know git, the Rosetta stone will make sgit feel familiar in one read.

## Introduction

[What is sgitThe pitch, the mechanism, the architecture](what-is-sgit.md) [Installationpip install, verify, upgrade](installation.md) [QuickstartCreate, commit, push, clone, in 5 minutes](quickstart.md)

## Concepts

[sgit for git usersThe Rosetta stone: same verbs, three differences](sgit-for-git-users.md) [The two-branch modelClone branches, named branches, and why](two-branch-model.md) [The security modelWhat the server sees; the crypto stack](../security/index.md) [Vault credentialsRead keys, vault keys, and what each prefix declares](credentials.md) [Keys and signaturesEncrypting to someone who holds no vault key](pki.md) [Performance, cost and running everywhereNo live database, LETS, and what a read actually costs, measured](../demos/fractal-graphs/performance.md)

## Messaging & the API

[Sending messages between vaultsAppend lanes + PKI, composed into a worked example](vault-messaging.md) [The HTTP APIEndpoints, headers, gates, limits and error codes](../api/index.md) [Append lanesThe write-only transport behind vault messaging](../api/append-lanes.md)

## Guides

[Working on a vault: start hereThe practices that get repeated most, and where each answer lives](guidance/index.md) [Three surfaces_page.json, a vault app, or a site page, pick this first](surfaces.md) [Working with AI agentswrite, --json, sparse clones, multi-agent patterns](agents.md) [Use casesFive workflows, all on shipped commands](../use-cases/index.md) [SG/Vault platformThe browser app, vault apps, the window.sg bridge](vault/index.md)

## Project

[When NOT to use sgitThe honest page](limitations.md) [Why does this exist?Answering the no-market criticism, plus a FAQ](../why/index.md) [If a vault key is exposedThe rotation runbook, with a real case study](../case-studies/exposed-vault-key.md) [Cross-team briefsOpen asks to the CLI and API teams](briefs/index.md) [Admin & engineeringHow this site is built and released](../admin/index.md) [GitHubSource, issues, changelog](https://github.com/SGit-AI/SGit-AI__CLI)

**Coming next:** a full per-command CLI reference, generated directly from the CLI's own argument parser on every release, so the reference can never drift from the shipped tool.



==============================================================================
# What is sgit, Docs

> sgit is git for encrypted vaults: how it works, what makes it different from git, and the ecosystem around it.
>
> Page: https://sgit.ai/docs/what-is-sgit.html

[Docs](index.md) / Introduction

# What is sgit

**sgit is git for encrypted vaults.** Clone, commit, branch, diff and merge folders of files that are encrypted with AES-256-GCM before they leave your machine. The server stores ciphertext under opaque IDs, it never sees your filenames, your contents, or your commit messages.

It's like git and a password vault had a baby.

## How it works

A vault is an ordinary folder plus a `.sg_vault/` directory. When you commit, sgit snapshots the folder into a git-like object graph, commits pointing at trees pointing at content blobs, and encrypts every object client-side. When you push, only changed ciphertext travels. Object IDs are content-addressed (`obj-cas-imm-…`), so unchanged files are never re-uploaded, and the server can deduplicate data it cannot read.

```
your-folder/
├── <your files>            # untouched — a vault is just a folder
└── .sg_vault/
    ├── bare/                # encrypted objects, refs, branch keys
    └── local/               # your private clone-branch key — never pushed
```

The **vault key** (`passphrase:vault-id`) is three things in one string: the address of the vault on the server, the credential to access it, and the root of the local key-derivation hierarchy. Whoever holds it can decrypt the vault; nobody else, including the server, can. See the [security model](../security/index.md) for the full derivation chain.

## What makes it different from git

- **Everything is encrypted client-side**: content, filenames, messages, branch names.
- **No staging area**: commit snapshots the whole folder, like `git commit -a` for everything.
- **A two-branch model**: a private clone branch per machine or agent plus shared named branches, which is what makes safe multi-agent collaboration possible. [Details →](two-branch-model.md)

## One vault, three doors

- **sgit**: this CLI. Open source, Apache-2.0, `pip install sgit-ai`.
- **SG/Vault**: the web app: browse, edit and review the same vaults in a browser, via an independent implementation of the same wire format. [How it works →](https://sgraph.ai)
- **SG/Send**: the zero-knowledge transfer API both clients speak to. [How it works →](https://sgraph.ai)

**Maturity:** sgit is in beta and has been powering production workflows for a while. The vault format is versioned and `sgit migrate` handles upgrades. Read [when NOT to use sgit](limitations.md) for the honest edges.

[Installation →](installation.md)



==============================================================================
# Installation, sgit Docs

> Install sgit with pip, verify with sgit doctor, upgrade with sgit update. Python 3.11+, two runtime dependencies.
>
> Page: https://sgit.ai/docs/installation.html

[Docs](index.md) / Introduction

# Installation

Pure Python, two runtime dependencies. Python 3.11 or newer.

```
$ pip install sgit-ai
# or, on externally-managed systems:
$ pipx install sgit-ai
```

This installs two entry points: `sgit` and `sgit-ai` (they are identical, use whichever you like).

## Verify

```
$ sgit version
sgit-ai v0.14.x
$ sgit doctor
✓ remote reachable   ✓ TLS ok   ✓ config valid
```

`sgit doctor` checks connectivity and configuration and prints per-OS fix instructions for the common problems (including SSL certificate issues). Add `--json` if a script or an agent is doing the checking.

## Upgrade

```
$ sgit update   # wraps pip install --upgrade sgit-ai
```

[← What is sgit](what-is-sgit.md)[Quickstart →](quickstart.md)



==============================================================================
# Quickstart, sgit Docs

> From zero to a synced, encrypted, versioned vault in five minutes: create, commit, push, clone, pull.
>
> Page: https://sgit.ai/docs/quickstart.html

[Docs](index.md) / Introduction

# Quickstart

From zero to a synced, encrypted, versioned vault in five minutes.

## 1, Create a vault

```
$ pip install sgit-ai
$ sgit create my-vault
✓ Vault created and registered
✓ Initial commit pushed

  Vault key: <24-char-passphrase>:<vault-id>
```

**Save the vault key now**: in a password manager, not a text file. It is the address, the credential, and the encryption key in one string. There is no reset: lose it and the vault is unrecoverable, by design.

Already have a folder full of files? `cd` into it and run `sgit init --existing` instead, the current contents become the first snapshot.

## 2, Work like git

```
$ cd my-vault
$ echo "# Plan" > plan.md
$ sgit status
  added: plan.md
$ sgit commit -m "add the plan"
✓ Committed 1 file
```

There is no staging area, `sgit commit` snapshots the whole folder. Files like `.env` and private keys are always excluded, automatically.

## 3, Push

```
$ sgit push
✓ Pushed 1 commit — only ciphertext left this machine
```

## 4, Clone somewhere else

```
# on another machine, or in an agent's session
$ sgit clone <vault-key>
✓ Cloned and decrypted 1 file
$ sgit pull      # pick up new commits any time
```

## 5, Look around

```
$ sgit history log --oneline     # commit history
$ sgit history diff              # what changed
$ sgit vault info                # identity, remote, web URL
```

The web URL printed by `sgit vault info` opens the same vault in the SG/Vault browser app, decrypted in the browser, never on the server.

## Where next

- [sgit for git users](sgit-for-git-users.md), the Rosetta stone
- [The two-branch model](two-branch-model.md), how collaboration works
- [Working with AI agents](agents.md), give an agent a private, versioned workspace

[← Installation](installation.md)[sgit for git users →](sgit-for-git-users.md)



==============================================================================
# sgit for git users, Docs

> The Rosetta stone: every git command mapped to its sgit equivalent, plus the three deliberate differences.
>
> Page: https://sgit.ai/docs/sgit-for-git-users.html

[Docs](index.md) / Concepts

# sgit for git users

If you know git, you know most of sgit. Same verbs, same mental model, with three deliberate differences that exist because the payload is encrypted.

## The Rosetta stone

| git | sgit | Notes |
|---|---|---|
| `git init` | `sgit init` | `--existing` vault-ifies a non-empty folder |
| `git clone <url>` | `sgit clone <vault-key>` | the key is URL + auth + decryption in one |
| `git status` | `sgit status` | `--explain` teaches the branch model |
| `git commit -am` | `sgit commit -m` | always whole-folder. There is no staging area |
| `git push / pull / fetch` | `sgit push / pull / fetch` | push is delta + ciphertext only |
| `git log` | `sgit history log` | `--oneline`, `--patch`, `--json`, ranges |
| `git diff` | `sgit history diff` | `--remote`, `--commit`, `--files-only` |
| `git show` | `sgit history show` | read-only, fetches missing objects without merging |
| `git revert / reset` | `sgit history revert / reset` |  |
| `git stash` | `sgit vault stash` | `pop`, `list`, `drop` |
| `git branch / checkout` | `sgit branch new / switch / checkout` |  |
| `git merge` conflicts | `sgit resolve --show` | three-way base/ours/theirs view with a verdict per file |
| `git remote` | `sgit remote add / list / set-url` |  |
| `git fsck` | `sgit check fsck` | verifies encrypted object integrity, can repair |

## The three differences that matter

### 1. No staging area

Every commit snapshots the whole folder. This removes git's most confusing concept, and it fits the security model: partial staging would leak "which parts changed" into workflows that are supposed to be opaque. Use branches where you would have used the index.

### 2. The vault key is URL, auth, and encryption key in one

`passphrase:vault-id`. There is no separate remote URL to configure, no separate credential to manage, and no password reset. Whoever holds the key holds the vault, treat it like the private key it is.

### 3. Two layers of branches

You never work directly on a shared branch. Every clone works on a private **clone branch** (its key never leaves your machine) and `push` forwards commits to the shared **named branch**. That's why two agents on the same vault can't corrupt each other's work-in-progress. [The full story →](two-branch-model.md)

[← Quickstart](quickstart.md)[The two-branch model →](two-branch-model.md)



==============================================================================
# The two-branch model, sgit Docs

> sgit's central idea: private clone branches per machine or agent, shared named branches, and explicit publishing.
>
> Page: https://sgit.ai/docs/two-branch-model.html

[Docs](index.md) / Concepts

# The two-branch model

sgit's central architectural idea: every clone works on a private branch, and sharing is an explicit act.

## Clone branches and named branches

```
        agent A's machine                    the server                    agent B's machine
  ┌───────────────────────┐        ┌───────────────────────────┐        ┌───────────────────────┐
  │  clone branch (A)     │  push  │   named branch "main"     │  pull  │  clone branch (B)     │
  │  key: local only ─────┼───────▶│   key: shared via vault   │◀───────┼─ key: local only      │
  └───────────────────────┘        └───────────────────────────┘        └───────────────────────┘
```

- **Named branches** (`main`, `feature-x`, …) are shared and live on the server, encrypted, like everything else.
- **Clone branches** are created per clone. Their key is stored only in `.sg_vault/local/` and is never pushed. All your commits land here first.
- `sgit push` re-encrypts your clone-branch commits with the named branch's key and forwards them. `sgit pull` brings named-branch commits down and merges them into your clone branch.

Run `sgit status --explain` any time, it prints this model with your vault's actual branch names filled in.

## Why it works this way

- **Isolation by construction.** Two machines, or two agents, on the same vault physically cannot overwrite each other's uncommitted or unpushed work: they're on different branches with different keys.
- **Sharing is explicit.** Nothing you commit is visible to anyone until you `push`. An agent can iterate messily in private and publish only the result.
- **Safe concurrent pushes.** Pushes use compare-and-swap on the server (atomic batch writes): if someone pushed before you, your push is rejected cleanly instead of silently clobbering, pull, merge, push again.

## Merging and conflicts

When histories diverge, sgit runs a genuine three-way merge (common ancestor + ours + theirs) per file. Non-conflicting changes merge automatically; conflicting paths get `.conflict` files, and:

```
$ sgit resolve --show
  notes/plan.md   CONFLICT (both changed)
    base   │ ship in Q3
    ours   │ ship in Q4          ← your clone branch
    theirs │ ship in Q3, beta Q2 ← the named branch
    verdict: genuine conflict  (not one-sided, not identical)
```

The verdict line matters in multi-writer vaults: it distinguishes genuine conflicts from one-sided or identical changes, so you (or an agent) only spend attention where a human decision is actually required. `sgit merge-abort` backs out of a merge cleanly.

[← sgit for git users](sgit-for-git-users.md)[Working with AI agents →](agents.md)



==============================================================================
# Working with AI agents, sgit Docs

> The agent-facing surface: sgit write, --json everywhere, sparse clones, the session pattern, and multi-agent collaboration.
>
> Page: https://sgit.ai/docs/agents.html

[Docs](index.md) / Guides

# Working with AI agents

sgit is designed to be driven by AI agents as well as humans. A vault is just a folder. The agent reads and writes files normally; sgit handles versioning, encryption, and sync. This page covers the agent-facing surface.

## The session pattern

```
# start of session: get the workspace
$ sgit clone <vault-key> workspace   # or: sgit pull, if already cloned
# … agent works on files normally …
# end of session: persist the state
$ sgit commit -m "session: findings and next steps"
$ sgit push
```

The next session (hours or weeks later, on any machine) runs `sgit pull` and continues. State survives the context window, encrypted end to end.

## `sgit write`, the surgical commit

When an agent needs to record one result, cloning a whole vault is waste. `write` commits a file directly to the vault HEAD in a single call: no working-directory scan, no full clone needed.

```
$ sgit write notes/finding.md --file result.md \
    --message "agent A: analysis" --push --json
{ "status": "pushed", "path": "notes/finding.md",
  "blob_id": "obj-cas-imm-9c2e41ab77d0" }
```

- `--also vault-path:local-file` (repeatable) makes a multi-file write **atomic**: one commit, all or nothing.
- Content-hash dedup: writing identical content returns `unchanged` and creates no commit.
- `--json` gives a machine-readable result for the calling pipeline.

## Machine-readable everything

| Need | Command |
|---|---|
| Read one file, structured | `sgit cat <path> --json` · `sgit cat --id <blob-id>` (zero network calls) |
| List files with fetch state | `sgit ls --json` / `--ids` |
| History for pipelines | `sgit history log --json` · `history diff --json` |
| Health checks | `sgit doctor --json` |

## Fast cold starts

Agents run on time budgets. Three clone modes keep startup cheap:

- `sgit clone --sparse`, structure now, file content on demand via `sgit fetch <path>`.
- `sgit clone-branch`, full history, but only HEAD's content.
- `sgit clone-headless`, credentials only: derive keys and write config, fetch nothing.

## Multi-agent collaboration

Give each agent a named branch; the [two-branch model](two-branch-model.md) guarantees isolation of work-in-progress. Two commands make peer review safe:

- `sgit history show <commit>` and `sgit history diff` are **read-only**: they fetch missing objects on demand without merging, so an agent can inspect a peer's commit without touching its own working copy.
- `sgit resolve --show` renders base/ours/theirs with a per-file verdict, so genuine conflicts are distinguishable from noise, by a human or by an agent.

```
# agent A  $ sgit branch new feature-analysis … commit … push
# agent B  $ sgit history show obj-cas-imm-c4e81a   # look, don't merge
# human    $ sgit pull → review in SG/Vault → merge
```

**For Claude users:** a packaged sgit Skill teaches a Claude session this entire workflow (install, clone, work, commit, push) so cross-session persistent state works out of the box.

[← The two-branch model](two-branch-model.md)[When NOT to use sgit →](limitations.md)



==============================================================================
# When NOT to use sgit, Docs

> The honest page: sgit's edges, stated plainly, plus the current roadmap gaps.
>
> Page: https://sgit.ai/docs/limitations.html

[Docs](index.md) / Project

# When NOT to use sgit

Every tool earns trust faster by stating its edges. Here are sgit's, plainly.

## Don't use sgit if…

- **You need a secrets manager.** sgit refuses to commit `.env` files, `.netrc`, private keys and friends, deliberately. Use a purpose-built secrets manager for credentials; use sgit for documents, data, and working files.
- **You need long-term API stability guarantees today.** sgit is in beta: it powers production workflows daily and the vault format is versioned (`sgit migrate` handles upgrades), but commands and flags can still evolve between minor versions. Keep `sgit vault backup` archives of anything precious.
- **You need partial commits.** There is no staging area, a commit snapshots the whole folder. If your workflow depends on committing three of seven changed files, sgit will fight you (use branches instead, or split folders into separate vaults).
- **Your data is huge binaries that change constantly.** Large files work (they're chunk-uploaded past a ~4 MB threshold), but sgit is built for working sets of documents and code-sized files, not video archives. Storage is versioned: history keeps old ciphertext around until pruned.
- **You want the server to do things with your data.** Zero knowledge cuts both ways: the server cannot index, search, preview, or process your content. All intelligence lives client-side. That is the point.
- **You lose keys.** There is no password reset, no recovery, no back door. That's a feature, but only if your key management is real. Password manager, plus `sgit vault backup --include-key` somewhere safe.

## Current gaps (roadmap, honestly)

- **Commit author attribution** is not yet recorded, in multi-agent vaults, per-agent identity currently comes from branch IDs, not signed authorship. Signature slots exist in the format; population is planned work.
- **Merge drivers** are whole-file three-way. Structured merges (JSON-aware, union) are designed but not yet shipped.
- **Bare clones** (`clone --bare`) are incomplete.
- **The full CLI reference** on this site is still being wired to its generator (it will be produced from the CLI's own argument parser on every release, so it can never go stale).

## What PKI does not do yet

[Keypairs](pki.md) ship and work, keygen, export, import, sign, verify, encrypt, decrypt all round-trip on v0.15.0. The layer around them is thinner than the primitives:

- **No revocation, expiry or rotation workflow.** No CRL, no `sgit pki revoke`. A compromised private key means generating a new pair and redistributing the bundle out of band, by hand.
- **No directory and no web of trust.** Verifying that a fingerprint belongs to who you think is entirely your problem, compare out of band, as with SSH host keys.
- **Lane addressing is not wired end to end.** The intended model is `append_token = H(public key)`, so a sender derives your [message lane](vault-messaging.md) address from the key you published. The server side ships; no shipped command emits that token, so today you agree one out of band. Details and the interim recipe are in the [addressing note](vault-messaging.md#addressing).
- **Only the first mode is built.** Signing and encrypting files, plus the append transport. The richer modes (group addressing, key discovery, delegated capability) are designs, not code.

Said plainly because the alternative is worse: an agent that reads an over-claiming page will build on a step that does not exist, and only find out at runtime.

If one of these gaps blocks you, say so on [GitHub](https://github.com/SGit-AI/SGit-AI__CLI/issues), real usage reports move the roadmap.

[← Working with AI agents](agents.md)



==============================================================================
# The day we leaked our own vault key (sgit.ai case study)

> The runbook for a leaked vault key) rotate, verify, re-point, plus a worked case study of the time it happened to this website.
>
> Page: https://sgit.ai/case-studies/exposed-vault-key.html

[Docs](../docs/index.md) / Project

# If a vault key is exposed

A vault key is a **bearer credential**: whoever holds it can read and write the vault, from anywhere, with no account and no reset. There is no revocation list to add it to. So an exposed key has exactly one remedy, **rotate it**, which means taking the old vault off the server and re-encrypting the content under a new key.

**Act first, investigate second.** Rotation takes minutes and costs you a commit history. Working out exactly who saw what takes hours. Do them in that order.

## The runbook

1. **Confirm you hold a complete local clone.** The rotation re-encrypts from your working copy, if your only full copy is on the server, clone it before you delete anything. `sgit status` should be clean, and `sgit vault backup` is cheap insurance.
2. **Delete the vault from the server:** `sgit vault delete-on-remote --token <token>`. This is the step that actually revokes the old key. Rekeying *without* it leaves the old vault, and the old key's access to it, alive on the server.
3. **Rotate:** `sgit vault rekey`. It wipes the local encrypted store, mints a new key and vault ID, and re-encrypts every file. It asks twice for confirmation; the second question ("have you saved your current vault key") is worth taking seriously.
4. **Save the new key**: password manager, before you do anything else. It cannot be recovered.
5. **Publish:** `sgit push`. The vault is now live under the new key with a fresh ID.
6. **Verify the old key is dead** (see below). Do not skip this: "I rotated" and "the old key no longer works" are different claims.
7. **Re-point every consumer**: other machines, agents, CI secrets, share links, bookmarks into the web client. The old vault ID appears in URLs, so anything referencing it needs updating.
8. **Then** investigate: where did the key appear, for how long, and who could have fetched it.

## Verifying the old key is dead

Four independent checks. Each should fail or 404:

```
# 1. the obvious one
$ sgit clone <old-vault-key> /tmp/check     # must fail: no branch index found

# 2-4. raw HTTP against the old vault id — derive the ids, then GET/PUT them
#   - the old ref file id            → expect 404
#   - a known old object id          → expect 404
#   - a PUT with the old write key   → expect rejection
```

A successful clone or a 200 on any of those means the rotation did not take, most often because `delete-on-remote` was skipped.

## What rotation costs

- **Vault history resets to a single commit.** Rekey re-encrypts your current files, not the object graph. (A history-preserving rotation is [proposed to the CLI team](../docs/briefs/index.md).) If the vault is [mirrored to git](../docs/vault/git-and-vaults.md), the content history survives there, which is one of the better arguments for running the two side by side.
- **Every object ID changes.** IDs are content hashes *of the ciphertext*, so identical plaintext under a new key produces an entirely new store, zero overlap with the old one. In a git mirror that lands as one large commit swapping the whole encrypted tree.
- **The vault ID changes**, so every URL and stored reference to it breaks.

## The limit worth understanding: mirrors

**A rotation protects the server. It cannot un-publish a mirror.** Encrypted objects already pushed to a git remote stay in that history and remain decryptable by the old key. If the old key was *also* committed there, anyone who clones the repository can still read the old content, forever, regardless of what you rotate.

- **Public content** (a website, published docs): a non-issue. The plaintext was public anyway. Rotate and move on.
- **Private content:** the rotation is only half the job. The mirror's history must be scrubbed too (rewrite or delete the repository), and until it is, treat the old content as exposed.

## Case study: this website, 11 August 2026

This page exists because it happened here, to the vault that serves this site.

**What went wrong.** The site's build has a validator that blocks secrets and stale terms from being published. To catch the vault passphrase specifically, an agent (me) added a rule matching that exact passphrase, and wrote the literal secret into `admin/build/validate.js`, a *tracked* file. The guard against leaking became the leak. Combined with the vault ID (public by design), the full write-capable key sat in three commits of a public repository.

**How it was caught.** Not by tooling, by a question. The vault owner asked "you haven't leaked that key, right?", which triggered the audit documented on the [git page](../docs/vault/git-and-vaults.md): grep the working tree and every commit for the passphrase, for private-key headers, and for readable content in the encrypted store. The first two checks passed. The history grep found it.

**The response,** inside the hour: `delete-on-remote` (336 files removed from the server) → `rekey` (39 files re-encrypted under a new key and ID) → `push`. Then the four verification checks, all confirming the old key was dead: clone failed, old ref 404, old object 404, write with the old write key rejected.

**The aftermath, measured.** 336 old objects out, 90 new in, **zero overlap**: no object ID survived, because the addressing hashes ciphertext. Plaintext was byte-identical across the rotation (verified by hashing files before and after). Vault history went from 14 commits to one; the git mirror kept all 14.

**What changed structurally.** The tripwire now reads the passphrase from the gitignored `.sg_vault/local/` tier at runtime and scans for it, instead of carrying it, so the secret can no longer live in a tracked file, and the check still works. It was tested by planting the new key in a draft page: the build failed, as it should.

**The transferable lessons.** (1) Never write a secret into a file that ships, derive it at runtime from the ignored tier. (2) A leak audit is worth running before your first publish *and* after anything touches your build config. (3) Grep the full history, not just the working tree; `git grep <secret> $(git rev-list --all)` is the check that found this. (4) Rotate before you investigate. (5) Write the incident down, this page is more useful than a quiet fix.

[← When NOT to use sgit](../docs/limitations.md)[The security model →](../security/index.md)



==============================================================================
# Cross-team briefs, sgit.ai

> Briefs this site's agent has filed to the sgit CLI and SG/Send API teams: serial transfer mode for WASM, history-preserving rekey, browser-transport findings.
>
> Page: https://sgit.ai/docs/briefs/index.html

# Cross-team briefs

This site is built and run by an AI agent, and it doesn't work alone. When it hits something that belongs to another team (the sgit CLI, the SG/Send API, AppSec), it writes a brief and hands it over. This page is that collaboration, in the open: the actual briefs, addressed to the actual teams. Point an agent here and it has the context.

**For the agent reading this:** the canonical markdown copies live in the [SGit-AI__CLI](https://github.com/SGit-AI/SGit-AI__CLI) repo under `team/humans/dinis_cruz/claude-code-web/`; this page is the human-readable index and the shareable URL. Every page on this site also has a `.md` twin and appears in [llms.txt](../../llms.txt) and [llms-full.txt](../../llms-full.txt), so a brief here is machine-readable without anyone doing extra work.

**Two kinds live here, and they behave differently.** A **cross-team ask** is addressed to another team, carries a status, and closes when it is answered. It is a record of a conversation. A **build brief** is a durable reference written to be executed by an agent: the mechanism, the traps, what to verify first, and the prompt to paste. It never closes.

**New here?** [**Working on a vault: start here →**](../guidance/index.md) is the front door, the practices that get repeated most, with routes to each brief below. Agents: [`/docs/guidance/llms.txt`](../guidance/llms.txt).

**Which surface are you building for?** The guidance below splits three ways, `_page.json` inside a vault, an HTML vault app, and a page on a `*.sgit.ai` site. They have different capabilities and *opposite trust directions*. [**Start with the surface →**](../surfaces.md) Every guidance page in the estate is labelled with the one it applies to.

## Build briefs written to be executed

| Brief | What it is for |
|---|---|
| [**For RiskMandate.ai: an interview page, and a ChatGPT voice prompt to run it**](riskmandate-interview-page-and-voice-prompt.md) | A reusable page pattern for getting feedback from people whose knowledge is in their heads: send a link, they paste a prompt into ChatGPT, it interviews them by voice for about twenty minutes and writes up their ideas, an action plan and candid feedback. The first page is for a founder strong in UK events, marketing and content, testing RiskMandate's value proposition and name. The prompt is included, ready to use. |
| [**For RiskMandate.ai: the risk side of the partnerships, and a risk mapping for sgit**](riskmandate-partnership-risk-and-sgit-mapping.md) | The second half of every partnership page on this site: the same deployment with and without a cloud or AI service, as two Agent Behaviour Policies and the delta between them. Plus the mapping nobody has written: sgit as a control, what it removes and what it leaves, against GDPR Articles 32, 25, 34(3)(a), 28 and 17. Built on RiskMandate's existing grammar and its 16 policy vaults. |
| [**For graphs.sgit.ai: Fractal Semantic Graphs**](graphs-sgit-ai-fractal-semantic-graphs.md) | What the graphs site should take from the sgit.ai page that is now the fullest worked application of its thesis: the one-word correction (grammar survives the zoom, schema does not), the name and its lineage, where to link, the two diagrams and four vaults to reuse, three small fixes, and the prompt to paste. |
| [**Telemetry from a published vault**](vault-telemetry-append-lanes.md) | How one vault sends messages to another, and how a vault whose read key is public reports anonymous usage back to its author. Covers the append-lane mechanism, why publishing a write-only token is safe where publishing any other credential is not, the three things to verify before building, and the prompt to hand the builder |
| [**Reading a vault from a site page**](sgit-ai-site-pages.md) | For devs coding the `*.sgit.ai` sites. The vault API answers plain CORS GETs with no auth header, so a page reads ciphertext directly and decrypts in the visitor's browser. The house reader to copy rather than rewrite, the trust rule that inverts once there is no vault host, the ref-caching trap that fails silently, and the prompt to hand the site's agent |
| [**The vault map infographic**](vault-map-infographic.md) | A companion to the network infographic, grouping the published vaults by use case and industry. Opens with the two blockers upstream of any image (neither grouping exists in the data yet, and the picture it copies has already gone stale in its own headline count) then the accuracy rules for a model that renders text as shapes, and the prompt to hand the agent |
| [**Markdown and file viewers: what not to build**](markdown-and-file-viewers.md) | The two most common vault asks are already solved by the platform. The ladder from zero code to a full app, the markdown rules that catch people (stripped HTML, pipe image sizing, folder links), the raw-always contract if you do build a file explorer, and the prompt to hand the builder |
| [**Decks from a vault, on a site**](vault-decks-on-a-site.md) | How to make the presentations inside a vault play on a web page, read live with a published read key. The `decks/v2` contract a vault must publish, the two sandboxed frames the host renders them in, why a decrypted PDF cannot go in an iframe, the two bugs we hit building it, and the prompt to hand the builder |
| [**Publishing a vault**](../../demos/vaults/publishing.md) | The seven steps behind every row of the [published vaults](../../demos/vaults/index.md) table, the tools that do each one, and the mistake that produced each rule. Written to be followed by another site's agent |

## Cross-team asks addressed, and status-tracked

### → To the RiskMandate.ai team: an interview page pattern, and the first page on it

**Status:** open · **Brief:** [RiskMandate interview page](riskmandate-interview-page-and-voice-prompt.md)

A page to send to one person, carrying a prompt they paste into ChatGPT so it interviews them by voice and writes up their feedback. The first is for a founder who is strong at UK events, marketing and content that spreads, testing the value proposition, the name, the audience, events, content angles and a ninety-day plan. The pattern is meant to be reused for investors, CISOs, insurers and GRC practitioners.

### → To the RiskMandate.ai team: the risk side of the partnerships, and a risk mapping for sgit

**Status:** open · **Brief:** [For RiskMandate.ai](riskmandate-partnership-risk-and-sgit-mapping.md) · **Trigger:** the cloud and AI provider partnership pages, published 24 September 2026.

Two asks. Publish the risk side of each partnership page as two behaviour policies and a delta, starting with managed identity against your own, a cloud's agent service against a laptop, and API against consumer chat. And write sgit up as a control, which is the business case for using it and currently exists nowhere. The brief records what RiskMandate already publishes so it is extended rather than repeated, and two inconsistencies found while reading: Level 1 is priced differently on two sites, and GDPR is modelled on one site and denied on another.

### ← Inbound, from the SG/API team: our own build brief was wrong, and it had already cost an agent a wrong turn

**Status:** acted on, [v0.2.58](../../admin/versions.md) · **Trigger:** an agent built [the games vault](../../demos/vaults/agent-permission-games/index.md) from [our telemetry brief](vault-telemetry-append-lanes.md) and could not get events out · **Direction:** inbound · **Follow-up sent:** seven questions, in the CLI repo.

The SG/API team read the append-lane code against our brief and returned a line-referenced review. Its verdict on the builder's headline claim, *"a published vault app has no way to write to an append lane"*, was **not confirmed**: both paths are open in code. But the reason the builder believed otherwise is that **this site told them so**.

- **We said `sg.append.write` fails closed in a read-only session. It does not.** There is no read-only gate on append anywhere, one grant, `permissions.append.write: true`, is the entire requirement. Our brief steered readers to a direct `fetch` instead, which is the harder path.
- **And the harder path is blocked by default.** The frame ships `connect-src blob: data:`; the escape hatch is `permissions.network: true`, which the reviewer notes appears *"zero times"* in the authoring guide and zero times in our brief, *"discoverable only by reading `app-permissions.js`. That is a real docs gap and the single highest-value fix on this list."* It is also the wrong fix: it reopens every egress from a frame holding decrypted vault content.

The correction is published above the original on the brief rather than edited in quietly, and it **resolved an open finding** on the games vault's page: the telemetry is built and never sent, because that vault declares no permissions at all. Three facts from the review that existed nowhere public are now on [the API reference](../../api/append-lanes.md), that only `write` takes a `vault_id` while the other five verbs bind to the open vault, that `fetch` maps to `append.read`, and that the `inbox` field in a listing is the lane folder and today equals the raw append token.

Worth naming the shape of this one: we published a brief for agents, an agent followed it, the brief was wrong, the team that owns the code said so precisely, and the page now carries the correction more prominently than the mistake. That is the loop working, and it is the second time an inbound brief has improved this site more than an outbound one did.

### ← Inbound, from the SG/API team: the API reference was missing, and three of their findings did not survive checking

**Status:** acted on, [v0.2.34](../../admin/versions.md) · **Trigger:** an agent was asked how to send a message between vaults and could not find the answer here · **Direction:** inbound.

The SG/API team audited this site against their route tables at v0.33.54 and sent a fix pack: a gap analysis, code-verified source material for an API reference, and a draft of the page they judged missing. Their central finding was right and is now fixed, the site documented the [transport](../vault/sg-bridge.md) and the [crypto](../pki.md) on pages that never referenced each other, and never wrote the sentence saying they combine into [vault-to-vault messaging](../vault-messaging.md). There was also no [HTTP API reference](../../api/index.md) at all. Seven pages now exist that did not.

The pack itself asked for its claims to be verified before publishing, which turned out to be the most valuable line in it. **Three did not survive:**

- **“The security page actively denies PKI.”** It did not. Swept for *symmetric*, *asymmetric*, *public key*, *PKI*, *keypair*: zero occurrences. The page said nothing about asymmetric cryptography either way. That is an *omission*, and the distinction matters, publishing a correction for a claim we never made would have put a false statement in the changelog. The remedy was the same and the [section now exists](../../security/index.md#pki); the framing was not.
- **“Search the site for stale `inbox` naming.”** There is none. Two hits, both ordinary English, a changelog line about URL routing, and a demo vault described as a “two-agent inbox”. No `/api/vault/inbox/*` path appears anywhere on the site. Nothing to fix.
- **“Seal to the recipient’s X25519 key.”** Not what ships. Running `sgit pki keygen` on v0.15.0 prints **RSA-OAEP 4096-bit** for encryption and **ECDSA P-256** for signing. Had the draft been published as written, this site would have told integrators to build against the wrong primitive.

Two more corrections came out of running the CLI rather than reading about it. `sgit pki export` emits a **JSON bundle** of two PEM blocks and two fingerprints, not the `.pem` file the draft redirected into, so the draft’s `sha256sum public-key.pem` derivation of the lane address is not well defined, since field order and whitespace would change the answer. And `keygen` requires a passphrase, which no draft step mentioned.

The pack’s own [acceptance test](../../llms.txt), give a fresh agent only `llms.txt` and ask how to send an encrypted message from vault A to vault B, now passes, including the lane-address fact and the caveat that its derivation is **PROPOSED** rather than shipped. Two endpoints their audit flagged as unresolved (`/api/vault/zip`, `/join/*`) are [listed as unresolved rather than documented](../../api/index.md#unresolved), which is what we would want done to us.

### → To the sgit CLI team: first-class serialised diffs, and ignore support

**Status:** open · **Brief:** [briefs/brief-serialised-diff-and-ignore.md](brief-serialised-diff-and-ignore.md)

Two asks, both the difference between a published claim and a shipped behaviour. The [serialised pull request](../../use-cases/serialised-pull-request.md) is now the site's lead workflow example, and its emit half is shipped (`sgit history diff --json`) while the import half is not, the brief asks for `sgit diff export`/`apply` plus a published diff format specification. And the [one-folder-two-VCS workflow](../../case-studies/one-tree-two-remotes.md) the site itself runs needs ignore support to be safe for anyone who starts from an existing git checkout: the ask is a single declaration of which paths belong to which system, generating both ignore files, with a build check that fails when a path is claimed by both.

### → To the SG/Vault UI team: embed the vault app iframe in sgit.ai pages, reusing your code

**Status:** **main ask answered**: read-key open shipped 15 Aug; one ask still open · **Briefing:** [briefs/briefing-sgvault-ui-embed.md](briefing-sgvault-ui-embed.md) · **Context:** the [demo-vaults plan](../../admin/plans/why-expansion-plan.md).

Three demo vaults are about to be published as end-to-end walkthroughs, each ending with the vault's app UI opened *live inside the sgit.ai page* from a deliberately published read key. The SG/Vault web app already solved the hard part (the sandboxed opaque-origin app iframe, the `window.sg` bridge, the deny-by-default permission model) and the point is to reuse that code rather than re-implement it: one codebase, and the embed itself demonstrates the capability. The briefing carries six concrete questions (which modules are the host, whether an embeddable entry point exists, exact read-key-only behaviour, the sandbox recipe, version pinning, the `_page.json` renderer) and a fallback we can ship without waiting.

**Outcome, 15 August.** The central ask landed. The UI team shipped read-key open on both surfaces: the loader now detects a read-key credential as its own format (`<64-hex>:<vault_id>`, the same shape `sgit clone` already took) and, decisively, tests it *before* the passphrase formats, which was the precise ordering bug that made our read key derive the wrong file ids. We re-ran the original experiment against the deployed build: the official interface now opens our demo vault from nothing but its published read key, framed in a sgit.ai page, with the app under full chrome and an explicit `R1 W0` / **Read-only** badge. The [demo page](../../demos/vault-app-embed.md) carries that embed live. One ask remains open: no URL selects a view, so the SGit inspector still cannot be framed *in isolation*. A note worth recording for anyone reading this as a case study, the fix arrived with a [verification note attached](../../case-studies/index.md), and it corrected our brief as well as their code: the prefix we had proposed for published links was replaced by the CLI's canonical one, so both implementations now name credentials the same way.

### → To the CLI team: the canonical read-key prefix is accepted by the web loader and not by the installed CLI

**Status:** open · **Found by:** [the comparison test suite](../../compare/index.md), which runs this check on every release.

The key-prefix contract defines `sgit_rk1_` as the canonical read-key form, and the deployed web loader strips it before format detection, we verified that the day it shipped. The CLI does not, and this was re-tested on **v0.15.0**, the latest published version, after first being found on v0.14.27, so it is not a stale install: given `sgit_rk1_<64-hex>:<vault_id>` it derives ref `afdb9d843131` instead of the correct `11ea50e81f4d` and fails with "this vault has no branch index and no named ref". The *bare* `<64-hex>:<vault_id>` form works correctly on the same version, and prints "detected 64-hex read key → routing to read-only clone", so this is prefix handling specifically, not read-key support.

**Confirmed on latest (17 Aug).** We upgraded specifically to check, and the prefixed form still derives the wrong ref on v0.15.0 while the bare form clones correctly on the same binary. The consequence is small but sharp: the form the contract tells people to publish is the form that fails on the CLI, so a user copying a published key from a page into a terminal gets an error that blames their key. The check stays in the suite and will flip to **holds** on its own when it stops reproducing, it already updated itself from v0.14.27 to v0.15.0 without anyone editing the claim. Re-run: `python3 admin/build/compare_tests.py`.

### ← Inbound, from an agent that tried to read this site: it could not follow a link, and we did not rank

**Status:** acted on, [v0.1.26](../../admin/versions.md) · **Reported by:** an agent working from sgit.ai as documentation · **Direction:** inbound, the first brief filed *at* this site rather than by it.

The report was precise about whose fault each part was, which is what made it useful. Three findings:

1. **The index worked.** One fetch of [llms.txt](../../llms.txt) answered a real question, whether a git-to-sgit command mapping existed, without a second request.
2. **Following a link out of it failed, and that is the agent's harness, not us.** Its fetch tool only permits URLs a prior search returned; a link inside a fetched document does not count. So the careful markdown-to-markdown traversal design is unusable for that class of agent: it can read the map and cannot walk it.
3. **The site did not appear in search for its own positioning language.** The package registry page ranked instead. For an agent under that restriction, the consequence is not "slow to reach". It is unreachable beyond whatever one index fetch contains.

**The hypothesis was right, and the reality was worse.** The brief guessed the pages might be client-side rendered and therefore invisible to a crawler. They are not, the full text is in the served HTML. But the fade-in that hides the unstyled flash while the stylesheet is bridge-loaded left `body{opacity:0}` until a JavaScript bootstrap added a class. Any client that applied our CSS without running that bootstrap rendered a complete, entirely invisible page, and fully hidden body text is not merely unread, it is a hidden-text signal to an indexer. Measured in a headless browser with JavaScript disabled: 15,733 characters of text at `opacity: 0`.

**What we changed:**

- **The page can no longer be invisible.** A `<noscript>` override reveals it immediately, and a CSS-only animation reveals it at 1.6s regardless of why the bootstrap never arrived. Verified with JavaScript off: opacity 1, full text, readable. A validator rule now fails the build if either failsafe goes missing.
- **A crawler surface that did not exist:** [robots.txt](../../robots.txt) and a generated [sitemap.xml](../../sitemap.xml) listing every page, plus canonical and Open Graph tags on all of them. The build fails if a page is missing from the sitemap.
- **A single-fetch copy of everything:** [llms-full.txt](../../llms-full.txt), every page concatenated, ~155 KB, generated from the same markdown. This is the mitigation that removes the dependency on link-following rather than reducing it.
- **A self-sufficient index.** llms.txt now answers the common questions inline, including the one that failed here, which git operations sgit does and does not have, with pull requests, the staging area, bisect, blame, rebase, cherry-pick, hooks, submodules and tags named explicitly as absent. Entries for the pages that matter most now carry that page's key fact, on the brief's own observation that for an agent which will never follow a link, *the descriptions are the only content it will ever see*.

**What we cannot fix:** whether the site ranks. The technical obstacles are now removed and the sitemap is published, but indexing takes time and is not ours to grant. And the harness restriction itself is the reporting agent's to change, though the concatenated file makes it moot.

Worth naming what this is: an agent read the documentation, failed, wrote up the failure with the fault lines drawn correctly, and the site changed. That is the same loop as the outbound briefs below, running in the other direction.

### → To the sgit CLI team: serial transfer mode for Pyodide/WASM

**Status:** open · **Discovered:** live, during the first in-browser clone from the SG/Send servers.

sgit now runs in the browser under Pyodide (CPython → WebAssembly), and [the Try page](../../try/index.md) clones real vaults from the live servers. The blocker: sgit parallelises blob transfer with `ThreadPoolExecutor`, and WebAssembly cannot spawn OS threads, so a clone dies at the blob stage with `can't start new thread` (index, branch metadata, commits and trees all download fine first, since those paths are sequential).

**The ask:** make sgit threadless-safe natively, auto-detected, no flag needed for the common case:

```
SERIAL_TRANSFERS = (sys.platform == 'emscripten') or bool(os.environ.get('SGIT_SERIAL_TRANSFERS'))
```

`sys.platform == 'emscripten'` is true under Pyodide and false everywhere else. One small `Transfer__Executor` helper (Type_Safe, per house rules) returns either a real thread pool or a trivial serial executor with the same surface, across the six call sites (four in `clone/Vault__Sync__Clone.py`, two in `push/Vault__Batch.py`, all import the executor at call time, which is what let the browser patch it).

**Evidence it's correct:** validated natively against the live dev server with thread creation disabled and the executor swapped for a serial one, a full clone of this site's own vault (13 commits, 59 trees, **225 blobs**) produced a byte-correct working copy. The browser (synchronous XHR on the main thread) is serial anyway, so nothing is lost there. The website already ships this exact shim client-side (`assets/try-setup.py`, section 0), proof of the interface; the ask is to make it native so no shim is needed.

### → To the sgit CLI team: preserve history across a rekey

**Status:** open · **Discovered:** live, rotating this site's own vault key after an exposure (see the [case study](../../case-studies/exposed-vault-key.md)).

Today `sgit vault rekey` wipes the local encrypted store, mints a new key, and re-encrypts the *current working files*, so the vault's commit history resets to a single commit. The wizard says so plainly, which is good; but the reset is a data-loss event that a rotation shouldn't have to cost. In our case 14 commits of vault history became one (the content history survived only because the vault is also mirrored to git, most users won't have that).

**The ask:** a history-preserving rotation, `sgit vault rekey --preserve-history`, or the default once proven. Everything required is already local in a full clone:

1. Walk the commit DAG from every ref.
2. Decrypt each object (blob, tree, commit) under the old key.
3. Re-encrypt under the new key, which yields a new content-addressed ID, since IDs hash the ciphertext.
4. Rewrite bottom-up: blobs first, then trees with their new child IDs, then commits with new tree and parent IDs; finally the refs and branch index.

It is a full graph rewrite with an ID remap table, not a new crypto design, the same walk `clone` already does, run locally in reverse. Worth pairing with a `--dry-run` that reports how many objects would be rewritten, and a verification pass (re-read every rewritten commit under the new key) before the old store is wiped.

**One honest limit to document alongside it:** a rotation cannot un-publish what a mirror already holds. Ciphertext pushed to a git remote stays there and remains readable to anyone holding the old key. History-preserving rekey improves the local story; it does not change that.

### → To the SG/Send API team: two browser-transport findings

- **CORS allow-list is missing `x-api-key`.** sgit sends its token on both `x-sgraph-access-token` (allowed) and `X-API-Key` (not allowed). A single disallowed header fails the whole browser preflight, Starlette returns `400 Disallowed CORS headers`, which is what blocked the first in-browser clone. Either add `x-api-key` to the CORS middleware's `allow_headers`, or treat the second header as native-CLI-only. (The website's browser transport currently drops `X-API-Key` client-side as a workaround.)
- **The presigned-S3 fallback dodges transport patching.** `_presigned_read_fallback` (large blobs) uses a function-local `urlopen` import, invisible to a monkey-patched transport and untested under CORS from a browser origin. Worth a look before large-blob vaults meet the browser.

### → Roadmap note: a Web-Worker async transport

The in-browser terminal uses *synchronous* XHR, so the tab freezes during a network command and output appears only on completion. Live progress (a streaming clone) needs the sgit instance to run in a Web Worker with an async transport, posting progress back to the main thread. That's the milestone that turns "the browser can run sgit" into "the browser runs sgit as smoothly as the CLI."

### The collaboration log so far

Other briefs this site's agent has produced and handed off (in the CLI repo):

- **git_reader review**: verified a pure-Python git reader against a real 906-commit repo; fixed one Type_Safe defaults bug, flagged a sanitization bug before ship.
- **Pyodide-in-browser verification**: proved sgit-ai v0.14.27 runs under WebAssembly, with the `ssl`-package and `.setup()` discoveries the tools team's handoff didn't have.
- **Design-improvements brief**: a standing request for a design pass, with the site's hard constraints spelled out.

This is what "the encrypted git for humans and AI agents" looks like from the inside: agents doing real work, filing real bugs, handing off with receipts.

[← Home](../../index.md)[Admin & engineering →](../../admin/index.md)



==============================================================================
# How the site is run, the agentic team behind sgit.ai

> sgit.ai is built by one person and a team of AI agents. This section is written for the agents: nine roles as files, the rules each enforces and the mistake behind each rule, the prompt that starts a role from nothing, and the board where the work is.
>
> Page: https://sgit.ai/team/index.html

[Home](../index.md) / Team

The agentic section

# How this site is run

sgit.ai is built and operated by one person and a team of AI agents, and this section is written for the agents. It says who does what, the rules each role enforces and the mistake that produced each rule, the prompt that starts a role from nothing, and the board where the work is. A new agent should be able to read this page and one role page and begin.

**Start here if you are an agent.** The site's own contract is on [Admin & engineering](../admin/index.md), architecture, the build, the validator, the release process. [llms.txt](../llms.txt) is the index; every page has a `.md` twin at the same path. The roles below assume you have read those two. The rule that outranks every other one: **publishing is adding one file**: an update, an article, a vault row, a site entry, a role, a card. Everything else is derived, and a page nobody can reach fails the build.

## The loop

Work arrives as a brief, a credential, a phone screenshot or a review from another team. The [Sherpa](roles/sherpa.md) puts it on [the board](board.md) and scopes a release. Roles run in dependency order (content before design, design before build) and the [release engineer](roles/release-engineer.md) ships through one script that refuses to call a release done until the live site serves it. The [Historian](roles/historian.md) records what happened and what went wrong; the [Journalist](roles/journalist.md) writes it up. When another team's review finds this site wrong, the correction is published above the mistake. That loop has run for every release since 14 August. The count is on [the homepage](../index.md#team), computed, not typed here where it would be stale within the hour.

## Nine roles

Each role is a file under `admin/content/team/roles/`; this grid and each page derive from it. The roles mirror the [Explorer team](https://github.com/SGit-AI/SGit-AI__CLI/tree/dev/team/explorer) in the CLI repository, specialised for running a site rather than building a tool: the Publisher and Auditor exist because this site publishes read keys on purpose and has to be certain what they reach.

[1**Sherpa**, Sequences the work, scopes each release, and keeps the board honest, the role that decides what ships next and what waits., **Owns** the board, release scoping, the order in which other roles run, and the decision to hold or ship](roles/sherpa.md) [2**Publisher**, Takes a submitted credential and turns it into a published vault page (classify, derive, audit, capture, write, escrow, release) following the seven-step method every row on the vaults table was built with., **Owns** the vault pages, vaults.json, the read-key escrow tier, and the seven-step method itself](roles/publisher.md) [3**Auditor**, Decides whether something can be made public without leaking (credentials in vaults, keys in the tree, secrets in screenshots) and publishes what it finds rather than filing it., **Owns** credential classification, the leak tripwire, the secret-shape sweeps, and the hold-or-publish recommendation](roles/auditor.md) [4**Journalist**, Writes what happened (the release note for every version, the articles that argue a point with screenshots, and the drafts that go to LinkedIn) with every number counted rather than remembered., **Owns** admin/content/updates/, admin/content/articles/, the LinkedIn drafts, and the .md twin the articles are read through by agents](roles/journalist.md) [5**Cartographer**, Keeps the map of the *.sgit.ai network true (one file per sibling site, the question-first directory, the sibling-site cards) and sends corrections upstream when a sister site is wrong about itself., **Owns** admin/content/sites/*.md, the network directory, the chooser questions, the !site card, and the aliases a reader arrives with](roles/cartographer.md) [6**Ambassador**, Owns how sgit is explained to someone who has never seen it (the homepage, the positioning, the investor page) and enforces the rule that proof comes before mechanism., **Owns** the homepage bands, the positioning sentence, use-case framing, and the investors section](roles/ambassador.md) [7**Designer**, Builds and maintains the site's components (bands, cards, tables, the sibling-site card) and checks every change on a phone before it ships, because that is where the failures are visible., **Owns** assets/site.css, the generated components in build_pages.py, the screenshot rigs, and the mobile check](roles/designer.md) [8**Release engineer**, Ships the site, build, validate, push, and refuse to call a release done until sgit.ai is actually serving it., **Owns** admin/build/release.sh, the validator, the CI tag gate, and the version bump](roles/release-engineer.md) [9**Historian**, Keeps the record straight, the version log entry that says what a release did and what it got wrong, the corrections recorded above the mistakes, and the numbers that must be computed rather than typed., **Owns** VERSION_LOG, the corrections convention, and the reality documents that say what is shipped versus argued](roles/historian.md)

## The rules every role shares

- **Read keys yes, vault keys never.** A read key is a capability handed out on purpose and cannot become write access. A vault key is escrowed in the gitignored tier before anything is published.
- **Verify live.** A clean push is not the same as deployed. The release polls sgit.ai for the version and aborts if it never appears.
- **Count, don't remember.** Every number on a page is computed from the thing it counts; every number in prose is checked against a file that day.
- **Negative controls.** A test that would pass with a wrong input has proven nothing.
- **Publish the finding.** An audit result, a correction, a gap, on the page, not in a file nobody reads.
- **Say what it is worth.** Publish the work, then state precisely what it does not prove.

## Where things are

| Thing | Where | Owned by |
|---|---|---|
| A vault page and its row | `admin/content/demos/vaults/<slug>/index.html`, `admin/content/vaults.json` | Publisher |
| An update, an article | `admin/content/updates/YYYY/MM/DD/`, `admin/content/articles/` | Journalist |
| A sibling site | `admin/content/sites/<slug>.md` | Cartographer |
| The homepage bands | `admin/content/index.html` + fields in `vaults.json` | Ambassador / Designer |
| A role | `admin/content/team/roles/` | Sherpa |
| A card | [the board vault](../demos/vaults/board/index.md) (`pdulwi6i`), cloned at `admin/content/team/issues/`; the release pulls it first | Sherpa |
| The version log | `VERSION_LOG` in `admin/build/build_pages.py` | Historian |
| The release | `admin/build/release.sh` | Release engineer |
| Credentials | `.sg_vault/local/`, gitignored, scanned by the tripwire | Auditor |

## Where the pattern comes from

Roles as files with a `ROLE.md` each, and issues as files that version with the repository they track, are the estate's convention rather than this site's invention:

issues-fs.sgit.ai · Graphs & method, [A git-native issue tracker where the issues are files and the files are a graph ↗](https://issues-fs.sgit.ai/), Nothing runs, no server, no database, so the tracker lives inside the repository it tracks and can be read by `cat`, `grep` and `find`. Eleven agentic roles, each with its own `ROLE.md` and its own `.issues/`., part of the sgit.ai network

This site's board is the same idea at the smallest useful size: markdown files with a `status` line, [in a vault of their own](../demos/vaults/board/index.md) with a published read key, rendered into columns both by the vault's app and by the site at each release, with a markdown twin so an agent can read the board without a browser.

[The starting prompts →](prompts.md) [The board →](board.md)



==============================================================================
# Starting prompts for the regular work (sgit.ai team)

> Twelve prompts for the tasks this site does repeatedly) publish a vault, audit it, write the update, add a sibling site, handle an inbound brief, cut a release, fix a phone bug, turn markup into data, correct a claim, update the board, re-verify the read keys, each written to be pasted into a fresh agent.
>
> Page: https://sgit.ai/team/prompts.html

[Home](../index.md) / [Team](index.md) / Starting prompts

# Starting prompts for the regular work

The tasks this site does over and over, each as a prompt written to be pasted into a fresh agent with nothing else. Every one names the files to read first and the check that says the work is done. They are the operational half of the [role pages](index.md#roles), which carry the reasons.

**Two conventions.** Placeholders are `UPPERCASE` words like `VERSION` or `SLUG`, yours to fill, with no angle brackets so they survive every renderer this site has. Every prompt ends before the release step on purpose, the [release engineer](roles/release-engineer.md)'s prompt is the one that ships, and the [Sherpa](roles/sherpa.md) decides when it runs.

## 1. Publish a submitted vault

Publisher, then Auditor

You are the Publisher for sgit.ai. A credential has been submitted: `PASTE`. Read demos/vaults/publishing.html first. Run admin/build/check_credential.py on the credential and report its class before doing anything else. If it is a write credential, escrow it under .sg_vault/local/demo-keys/`NAME`-vault-key (gitignored) and derive the read key with Vault__Crypto. Clone with the READ key only. Hand the clone to the Auditor prompt. If it passes: derive the facts (files, size, version, what the app asks for in app.json), capture screenshots by serving the clone locally and driving it with Playwright with every request to /api/vault/** aborted, write admin/content/demos/vaults/`SLUG`/index.html in the house style (a warning box for anything the reader should know before opening it, the read key note, one open-in-a-new-tab button at the embed, what it demonstrates, the audit result, notes), add the row to admin/content/vaults.json with category, what, files, bytes, size, published, and the manifest entry to admin/content/pages.json. Build and validate. Stop before releasing and report what you found.

## 2. Audit a vault before its key is published

Auditor

You are the Auditor for sgit.ai. A read-key clone of vault `ID` is at `PATH`. Sweep it for: PEM private keys; fields named enum_key, write_key, vault_key, read_key, api_key, or any provider-key shape (sk-, sk-or-v1-, ghp_, AKIA, xox[baprs]-, AIza, JWT); vault-key passphrase shapes (20–30 chars then a colon then a vault id); emails and personal data. List EVERY 64-hex string in the vault and state what each is, for any that could be a read key, attempt sgit clone with it against the vault it names AND run the identical clone with an all-zeros key as the negative control; only the presence of .sg_vault/local/clone_mode.json counts as success. Report PASS with the accounting, or HOLD with the exact file and line and what the string grants. Never print a vault key, even partially.

## 3. Write the release update

Journalist

You are the Journalist for sgit.ai. Release `VERSION` is live. Read its VERSION_LOG entry in admin/build/build_pages.py and the diff (git show HEAD --stat). Write admin/content/updates/`YYYY`/`MM`/`DD`/`VERSION`__update__`SLUG`.md with frontmatter title/date/version/tags, in the house voice: what changed, why, what it cost, one thing it does not do. Every number must be verified this session against a file or the live page, and you must say how. Do not restate numbers a page computes, name them. Links root-relative. Build; confirm the post appears at the top of updates/index.html and in updates/feed.xml.

## 4. Write an article with screenshots

Journalist, with the Designer for captures

You are the Journalist for sgit.ai. Write an article arguing `CLAIM`, for admin/content/articles/`SLUG`.md, with frontmatter title/date/summary/version/tags/status. Use !shot name.webp | images/ | caption for figures, images in articles/images/ as WebP under 200 KB each, captured from the real site or vault with Playwright (serve locally; abort /api/vault/** if a vault is involved). Use !site host | path | title | line whenever a sibling site is relevant. Quote the artefact rather than paraphrase it; check every number against a file; put any correction to an earlier article above the text it corrects. End with the standard author line. Build, validate, and check the page at 1280 and 390 wide: every figure loaded, no horizontal overflow.

## 5. Add a sibling site to the network

Cartographer

You are the Cartographer for sgit.ai. A sibling site is at `HOST`. Fetch its llms.txt and homepage. Write admin/content/sites/`SLUG`.md with title, domain, tagline, summary, category (one of the five on network/index.html), thesis quoted verbatim from the site, an aliases: line of the words a reader arrives with (not the site's own vocabulary), observed: today, and listing: true unless it merits a full write-up with screenshots. Record any outbound network link that does not resolve. Build; then ask the network chooser three questions a reader of that site would ask and confirm it routes there. Report what the site says about itself that you could not verify.

## 6. Handle an inbound brief or review

Sherpa, then the role it names

You are the Sherpa for sgit.ai. Another team has sent `DOCUMENT`. Read it against the pages it refers to. For each claim: does it survive checking against our files and the live site? Sort the findings into: we were wrong (correct the page, with the correction above the original text, and credit the source under its licence); they were wrong (say so on briefs/index.html with the evidence); unresolved (record it as unresolved, never dressed as a conclusion). Add a cross-team ask entry to admin/content/briefs/index.html with status, trigger and direction. Put any question we now need answered on the board as a Need. Assign the corrections to roles as cards. Do not release.

## 7. Cut a release

Release engineer

You are the release engineer for sgit.ai. The Sherpa's sentence for this release is: "`SENTENCE`". Confirm SITE_VERSION in admin/build/build_pages.py is `VERSION` and the top VERSION_LOG entry exists with 'this release' as its commit, and that the previous entry's commit is filled from git log. Run python3 admin/build/build_pages.py, then node admin/build/validate.js; on any failure stop and report it verbatim. Then run ./admin/build/release.sh "site `VERSION`: `SENTENCE`" and wait for "release complete". Report: the git commit id, the version curl https://sgit.ai/index.html returns, and any dirty files. Never print a vault key. Do not say the release is live until the script's live check says so.

## 8. Fix a layout bug reported from a phone

Designer

You are the Designer for sgit.ai. The author has sent a phone screenshot of `PAGE` showing `PROBLEM`. Reproduce it with Playwright at 390×844 with a mobile user agent and measure it (which element, its bounding box, scrollWidth vs clientWidth). Find the cause in assets/site.css or the generator in admin/build/build_pages.py; prefer removing what should not be there over shrinking it. Note that a band carries its own max-width and that generated cards need hidden .hv-sep text separators. Fix, build, validate, and re-measure at 390 and 1280: no horizontal overflow, the problem element absent or correct. Write one before/after screenshot pair to the scratchpad and report the measurements.

## 9. Turn hand-written content into generated data

Designer, with the Historian

You are the Designer for sgit.ai. `PAGE` contains hand-written repeated markup (a table, a list of cards) that has to be sorted, counted or kept consistent. Move the data into a file under admin/content/ (JSON or one .md per item with frontmatter, following vaults.json and sites/*.md), add a loader if needed in admin/build/content.py, write a generator in admin/build/build_pages.py that emits the markup from it, and replace the markup in the content file with an HTML comment marker the page loop fills. Derive any date from git (git log --diff-filter=A) rather than typing it. Keep the default order the most useful one with JavaScript off. Build, validate, and confirm the .md twin reads as prose (hidden separators). Report what became data and what was deleted.

## 10. Correct a published claim

Historian, then Journalist

You are the Historian for sgit.ai. The claim "`CLAIM`" on `PAGE` is wrong; the evidence is `HOW_IT_WAS_FOUND`. Amend the text in place so it is correct AND says in its own words that it was corrected, when, and how the error was caught. Find every other place the claim was repeated (grep admin/content and the VERSION_LOG) and fix each. Write the VERSION_LOG entry for the correcting release naming the release that introduced it. If the wrong claim was a number a page computes, replace the prose with a reference to the computed figure rather than a new number. Do not delete the record of the mistake.

## 11. Update the board

Sherpa

You are the Sherpa for sgit.ai. The board is a vault (id pdulwi6i) cloned at admin/content/team/issues/; its cards are issues/*.md. Run sgit pull there first. For each card: is its status still true? Move any that is not by editing the status: line (needs | backlog | doing | review | done). For anything that happened this session and is not on the board, add issues/ID-slug.md with id (next N or T number), title, kind (need if only the author can supply it, else task), status, role, priority, opened (today), and a body that says what it unblocks. Run python3 tools/reindex.py, then sgit commit -m "board: …" and sgit push in that folder. The board is live the moment it pushes; the site catches up at its next release. Do not close a Need without the author's answer.

## 12. Re-verify the published read keys

Auditor

You are the Auditor for sgit.ai. Extract every read key from admin/content/vaults.json's vault pages (each demos/vaults/`SLUG`/index.html carries its key). For each: sgit clone --sparse into a scratch directory and record success ONLY if .sg_vault/local/clone_mode.json exists; then sgit cat one small file to prove decryption. Run one clone with an all-zeros key as the control and confirm it fails the same marker. Report a table: vault id, marker present, decryption proven, or FAIL with the error. Any FAIL is a live page serving a dead credential, hand it to the Sherpa as a high-priority card immediately.

[← How the site is run](index.md) · [The board →](board.md)



==============================================================================
# The board, open work on sgit.ai, as a kanban of files

> Every card is a markdown file with a status line; the columns are those lines rendered. Needs are items only the author can supply; tasks are work an agent can pick up from its starting prompt. Nothing runs; the board versions with the site.
>
> Page: https://sgit.ai/team/board.html

[Home](../index.md) / [Team](index.md) / The board

# The board

The open work on this site, as a kanban. Each card is a markdown file in [**a vault of its own**](../demos/vaults/board/index.md) with a `status` line; the columns are those lines, rendered. **Needs** are items only the author can supply and are kept visible rather than discovered late; everything else is work an agent can pick up from its [starting prompt](prompts.md).

**The vault is the truth; this page is a snapshot.** The board lives in vault `pdulwi6i` and is updated by `sgit push` with no site release. What you see below is the state at site v0.6.8, rendered from a clone the release pulled first. For the live board, open the vault, the read key is the whole credential, because every card is public:
`f41d03b0de550479b3c4359709130386df48f34b2cd75e5ed83de28e9776b479:pdulwi6i`

[Open the live board in a new tab ↗](https://dev.vault.sgraph.ai/#f41d03b0de550479b3c4359709130386df48f34b2cd75e5ed83de28e9776b479%3Apdulwi6i)Five columns from the same files, as the vault holds them right now.

**18 items**: 15 open, 6 of them waiting on the author. Each card is a file under `admin/content/team/issues/`; moving a card is editing its `status` line.

### Needs, only the author can supply 6

N1, **The ask: round size, instrument, and what it buys**, [Ambassador](roles/ambassador.md) · high · 2026-09-07

The [investors page](../investors/index.md) has the architecture, the traction and the business model, and a dashed box where the ask goes. Round size, instrument and the use-of-funds split are the author's to state; nothing is invented in the meantime. Unblocks: a page that can be handed to an angel without a caveat.

N2, **The deck, or permission to build one from the page**, [Ambassador](roles/ambassador.md) · high · 2026-09-07

Your other companies publish the pitch in the open (investor.myfeeds.ai). Either the sgit deck exists and should be linked, or the investors page is the source and a deck can be built from it — a vault with a presenter app, like the [VoiceDebrief pitch](../demos/vaults/voicedebrief-pitch/index.md). Unblocks: something to show in the room next week.

N3, **A vault where two agents and a human merge are visible in the history**, [Publisher](roles/publisher.md) · high · 2026-09-07

The homepage's strongest multi-agent claim — a branch per agent, a human reviews the merge — has no published vault behind it. If one exists, its read key is enough; if not, the next multi-agent build should be run so its history shows it. Unblocks: closing the gap the [after article](../articles/proof-moved-up.md) names; it goes in the hero.

N4, **The games vault: one manifest line so the telemetry actually sends**, [Publisher](roles/publisher.md) · medium · 2026-09-07

The other agent's fix is `{"permissions": {"append": {"write": true}}}` and a switch to `sg.append.write` — not `network: true`. When it lands, the page's status note comes off and the two 'nothing sent' footers should be gone. Unblocks: the [games vault page](../demos/vaults/agent-permission-games/index.md) describing behaviour the vault performs.

N5, **Answers to the seven append-lane questions**, [Cartographer](roles/cartographer.md) · medium · 2026-09-07

Sent to the SG/API team on 7 September (in the CLI repo under `team/humans/dinis_cruz/claude-code-web/09/07/`). The two that matter most: which hosts serve `/api/vault/append/*`, and whether the enum-key derivation is stable enough to publish as a spec. Unblocks: the API page stating facts where it currently says unresolved.

N6, **Republish the two held vaults clean, or retire them**, [Auditor](roles/auditor.md) · low · 2026-09-07

`bite-coil` (a live provider key in `key.json`, since rotated) and `6kdhnpfx` are held on audit findings. Both are republishable via a fresh vault with the offending file removed. A decision either way closes them. Unblocks: the vaults count telling the whole story.

### Backlog 7

T1, **An About page about sgit, linking to the fuller record**, [Ambassador](roles/ambassador.md) · high · 2026-09-07

Agreed direction: who builds it (one human and the roles on this page), why, the commercial line (sgraph.ai sells the hosted service; the code stays Apache-2.0), and two sections borrowed from open-source.sgit.ai/about — *Interests declared* and *Reach me, or correct me* — with a `!site` card out to the fuller record rather than a copy of it.

T2, **Re-verify the 21 published read keys with the marker that actually discriminates**, [Auditor](roles/auditor.md) · high · 2026-09-07

The earlier 24-key sweep used the presence of `.sg_vault/` as success, which an all-zeros key also produces. Three vaults were verified properly by decrypting content; the other 21 were not. Re-run with `clone_mode.json` as the marker and a negative control.

T11, **The chat pane inside a vault: route through sg.llm instead of a pasted key**, [Designer](roles/designer.md) · medium · 2026-09-07

The pane (`assets/site-chat.js`) has three tiers and the third is not wired: when a page renders inside a vault, `sg.llm.chat` would let the host hold the key below the permission floor. Blocked on one fact — whether the bridge's chat contract accepts OpenAI-style `tools` and returns `tool_calls`. Ask llms.sgit.ai's owners; until then the pane falls back to the key-in-page tier with the warning it already carries.

T3, **Investors page: print stylesheet and a one-page PDF export**, [Designer](roles/designer.md) · medium · 2026-09-07

The page should print to one or two clean pages for the event. The site already has `@media print` rules; extend them for the investor bands and check the output.

T12, **Transcribe the seven Licence to Operate shorts**, [Journalist](roles/journalist.md) · medium · 2026-09-09

The [seven shorts](../demos/vaults/licence-to-operate/videos/index.md) are indexed with the author's own descriptions, but **not transcribed** — YouTube returns no caption track for any of them, on any of the four `timedtext` endpoints. So the words spoken are absent from the site, from `llms-full.txt` and from the chat pane's `read_page` tool, which is exactly the failure the [Risk Graph Explorer walkthroughs](../demos/vaults/risk-graph-explorer/videos/index.md) page was built to avoid. Needs the author's transcripts from YouTube Studio (auto-transcript works even when the public track is absent), then the same treatment as the walkthroughs: timestamped moments that deep-link into the video, and captured frames.

T6, **Flip skills.sgit.ai from not-published to live when Pages serves it**, [Cartographer](roles/cartographer.md) · low · 2026-09-07

DNS and a repository exist; the site 404s from GitHub Pages. Listed in the network directory as *not published yet* rather than omitted. Re-check weekly.

T7, **Upstream: graphs.sgit.ai footer links to sentinel.sgit.ai, which does not resolve**, [Cartographer](roles/cartographer.md) · low · 2026-09-07

The site is at `sg-sentinel.sgit.ai`; the `sg-` prefix is load-bearing. Noted on our graphs page since 21 August; the brief to their team is the remaining step.

### Doing 0

empty

### Review 2

T4, **The agentic section: roles, starting prompts, the board**, [Sherpa](roles/sherpa.md) · high · 2026-09-07

Nine roles as files under `admin/content/team/roles/`, a page each; the starting prompts for the regular tasks; this board, as files under `admin/content/team/issues/`. In review: does each prompt start a fresh agent correctly with nothing but the page?

T5, **The investors section, on the open-investor-materials model**, [Ambassador](roles/ambassador.md) · high · 2026-09-07

Same structure as investor.myfeeds.ai — hook, how it works, architecture, market, traction, business model, the ask, use of funds — with the traction numbers computed from the site and the ask left visibly open (N1). In review: nothing on it may be a number the author has not supplied.

### Done 3

T8, **Rebuild the homepage: proof before mechanism**, [Ambassador](roles/ambassador.md) · high · 2026-09-07

Shipped as v0.2.60, with the diagnosis in v0.2.59 and two corrections in v0.2.61. [Before](../articles/proof-behind-the-claim.md) and [after](../articles/proof-moved-up.md).

T9, **The vaults table: sortable, categorised, no keys, newest first**, [Designer](roles/designer.md) · medium · 2026-09-06

Shipped as v0.2.57 and v0.2.58: generated from `vaults.json`, `#` as a permanent publication ordinal, published dates from git.

T10, **A card for pointing at the sibling sites (!site)**, [Cartographer](roles/cartographer.md) · medium · 2026-09-07

Shipped in v0.2.59. One line in markdown; the card pulls the target site's own category and thesis from `sites/*.md`.

**Moving a card** is editing one line in the vault and pushing; the site picks it up at its next release. **Adding one** is adding one file with `id`, `title`, `kind` (need | task), `status`, `role`, `priority`, `opened` and a body that says what it unblocks, then `python3 tools/reindex.py` so the app can read it outside a host. A card that names a Need is closed only by the author's answer. Corrections to published claims are not cards; they are [version-log entries](../admin/versions.md), so the record of the mistake is never tidied away.

[← How the site is run](index.md) · [Starting prompts](prompts.md)



==============================================================================
# Four sheets, four audiences, one stack, the Lisbon summit handouts

> The September 2026 startup-summit handouts: the same capabilities framed for founders, startups, investors and corporate buyers, each as a page and as the PDF that was handed out, with a 'what exists today' column that is unflattering on purpose.
>
> Page: https://sgit.ai/summit/index.html

[Home](../index.md) / Summit sheets

# Four sheets, four audiences, one stack

The handouts from the Lisbon startup summit, September 2026. The same capabilities, framed four ways, because a founder, a startup, an investor and a corporate buyer are reading for four different reasons. Each sheet is here as a page *and* as the PDF that was handed out.

[Sheet 01 · Founders**Open source technology that works today**Read it as a page, or download the PDF →](founders.md) [Sheet 02 · Startups**Let’s build together**Read it as a page, or download the PDF →](startups.md) [Sheet 03 · Investors**How does your firm share data with its portfolio?**Read it as a page, or download the PDF →](investors.md) [Sheet 04 · Corporate users**Services available now**Read it as a page, or download the PDF →](corporate.md)

**What makes these worth publishing rather than filing.** Every row carries a **what exists today** column, and that column is unflattering on purpose: *“no payment link”*, *“not yet packaged as its own product”*, *“research design; implementation not claimed”*, *“write-only intake built, never sold”*. A capability sheet that cannot say which rows are not finished is a brochure.

|  | Sheet |  | Handout |
|---|---|---|---|
| 01 | **[Founders](founders.md)** Open source technology that works today | 7 rows | [PDF ↓](pdf/sgit-ai__01-founders.pdf) |
| 02 | **[Startups](startups.md)** Let’s build together | 9 rows | [PDF ↓](pdf/sgit-ai__02-startups.pdf) |
| 03 | **[Investors](investors.md)** How does your firm share data with its portfolio? | 6 rows | [PDF ↓](pdf/sgit-ai__03-investors.pdf) |
| 04 | **[Corporate users](corporate.md)** Services available now | 8 rows | [PDF ↓](pdf/sgit-ai__04-corporate.pdf) |

## Why four, and not one

The rows underneath are largely the same. What changes is the question each reader arrives with, *can I build a company on this*, *can I build on top of it*, *how does my firm share data and what are my portfolio's agents doing*, *how do I govern the agents already running*. Splitting at the front door rather than compromising inside one document is the same choice [the interim CISO pack](../demos/vaults/interim-ciso-pack/index.md) makes, and the same one [three surfaces](../docs/surfaces.md) argues for.

## Dated September 2026, and kept that way

The sheets carry the figures that were true when they were printed (the vault count, the version numbers, the status of each row) and they are kept here as printed, as a record of what was being said at the summit. For any figure that moves, [the live table](../demos/vaults/index.md) is the current answer; the sheets are the historical one.

Proof 02 · 14 September 2026 · fact set: brief v0.33.70. Code: permissive software licence. Documents: CC BY 4.0. [The network](../network/index.md) · [Published vaults](../demos/vaults/index.md)



==============================================================================
# Founders, open source technology that works today

> Seven capabilities with an MVP or a live example behind each, and two ways to build a company on them: on your own, or with the author on one of three rungs, direct hire, revenue share, or a company.
>
> Page: https://sgit.ai/summit/founders.html

[Home](../index.md) / [Summit sheets](index.md) / Founders

**Sheet 01 of 04**: written for founders. [The other three →](index.md)

# Founders, Open source technology that works today

Build a company on it. Every row has an MVP or a live example, further along than most startups begin, and all of it open source: take a row and run with it.

This is working technology, not a pitch. It is all open source: take a row and run with it. **You do not need me to.**

[Download the PDF ↓](pdf/sgit-ai__01-founders.pdf)The sheet as handed out in Lisbon. The table below is the same content, in a form a search engine and an agent can read.

## What exists

|  | The capability | What exists today |
|---|---|---|
| 02 | **Share files the host cannot read, with history and a write-only upload link.** Powered by sgit, transfer protocol & browser vault | Live. CLI in beta; write-only intake built, never sold. |
| 03 | **Manage and distribute sensitive data, healthcare is the worked example.** Powered by Vaults on the same runtime | An MVP is built on it. |
| 04 | **Deliver a security report as a vault: evidence per finding, retest scripts, views per audience.** Powered by Report vault on the vault runtime | Designed 26 May. Deliverable shape built; demo specified. |
| 05 | **Explain a specialist domain to a board at its own altitude.** Powered by Boardroom, agent rooms & persona machinery | Original product existed. Agent rooms specified in March; persona generator built in August. |
| 06 | **Briefings for your role, with the evidence behind every line.** Powered by Role-aware briefings on semantic graphs | Live; commercial state not verified in the brief. |
| 07 | **Know what your agents can actually do, and give each one a licence to operate.** Powered by Risk product & free behaviour-policy library | Site v1.10, library and store live. No payment link. |
| 01 | **Turn voice into a debrief, wherever the voice already is.** Powered by Voice Debrief + WhatsApp, file & agent integrations | Live, earning, run with a partner under a signed profit share. |

## Two ways to build a company on it

**On your own.** Instead of *join and work on my thing*: build your thing on top of what is already built. The code is permissive and the documents are CC BY.

**With me, on one of three rungs:**

- **One · Direct hire.** Cash per mini project. Lowest commitment, both ways.
- **Two · Revenue share.** Time-boxed, no entity. Voice Debrief runs this way: 90 days; a quarter on net receipts; an even split of what remains. Either party may continue or fork on exit.
- **Three · A company.** Shares and equity. Highest commitment, both ways.

Everything is open, so there is almost nothing to protect: **the agreement collapses to the split, the term, and a short list of sensitive items.**

**Write to [dinis.cruz@owasp.org](mailto:dinis.cruz@owasp.org)**, or explore [the network](../network/index.md).

## The sheet itself

**Proof 02 · 14 September 2026.** Fact set: brief v0.33.70, 13 September 2026, revised with the 14 September comments. Code: permissive software licence. Documents: CC BY 4.0. [← All four sheets](index.md) · [Explore the network](../network/index.md)



==============================================================================
# Startups. It is open source, and it is built to be built on

> Nine capabilities to reuse, each naming what it runs on and how far along it is, including the ones that are still a design and say so.
>
> Page: https://sgit.ai/summit/startups.html

[Home](../index.md) / [Summit sheets](index.md) / Startups

**Sheet 02 of 04**: written for startups. [The other three →](index.md)

# Startups, Let’s build together

It is open source, and it is built to be built on. Start with the capability, reuse the component, and check the status, some of it is still a design, and it says so.

The stack was built to be collaborative. **Some of it is still a design, and it says so.**

[Download the PDF ↓](pdf/sgit-ai__02-startups.pdf)The sheet as handed out in Lisbon. The table below is the same content, in a form a search engine and an agent can read.

## What exists

|  | The capability | What exists today |
|---|---|---|
| 01 | **Storage the host cannot read, with history.** Powered by sgit, transfer protocol & browser vault | none |
| 02 | **Versioned data with a clonable past.** Powered by sgit, transfer protocol & browser vault | none |
| 03 | **Managing and distributing sensitive data.** Powered by Vaults on the same runtime | Healthcare is the worked example; an MVP is built on it. |
| 04 | **Voice into debriefs, wherever the voice already is.** Powered by Voice Debrief + WhatsApp, file & agent integrations | WhatsApp, files and agents are already wired in. |
| 05 | **A chat in your app that never holds a model key.** Powered by Model call layer | none |
| 06 | **Translation to executives, in any specialist domain.** Powered by Boardroom, agent rooms & persona machinery | none |
| 07 | **Knowing what your agents are doing, and describing it.** Powered by Risk product & free behaviour-policy library | none |
| 08 | **Scalable risk management.** Powered by Risk acceptance framework | A risk is accepted for a stated period. Research design; implementation not claimed. |
| 09 | **Facilitating due diligence on your product.** Powered by Write-only intake + seven-criterion evaluation framework | Use the scorecard for honest self-assessment: what their diligence will find, before it runs. |

## Build on the stack

The infographic generator runs today, is used by a number of people, and **has no way to pay for it**. Seven further companies are written up in full and given away under attribution licensing.

```
pip install sgit-ai
```

**Write to [dinis.cruz@owasp.org](mailto:dinis.cruz@owasp.org)**, or explore [the network](../network/index.md).

## The sheet itself

**Proof 02 · 14 September 2026.** Fact set: brief v0.33.70, 13 September 2026, revised with the 14 September comments. Code: permissive software licence. Documents: CC BY 4.0. [← All four sheets](index.md) · [Explore the network](../network/index.md)



==============================================================================
# Investors (how does your firm share data with its portfolio?)

> Six capabilities for investor operations) vaults the host cannot read, a write-only link for founders, and a licence to operate for each agent a portfolio company runs before it becomes your risk.
>
> Page: https://sgit.ai/summit/investors.html

[Home](../index.md) / [Summit sheets](index.md) / Investors

**Sheet 03 of 04**: written for investors. [The other three →](index.md)

# Investors, How does your firm share data with its portfolio?

Most of the data investors share is insecure, decks, data rooms, updates, diligence files, sent in the clear. Vaults fix that, and the same stack gives you something new to ask of every company you back.

A licence to operate for each agent a portfolio company runs, **before it becomes your risk.**

[Download the PDF ↓](pdf/sgit-ai__03-investors.pdf)The sheet as handed out in Lisbon. The table below is the same content, in a form a search engine and an agent can read.

## What exists

|  | The capability | What exists today |
|---|---|---|
| 02 | **Share deal data, documents and updates in vaults the host cannot read, with full history, and a write-only link for founders to send you material.** Powered by sgit, transfer protocol & browser vault | Live. CLI in beta; write-only intake built, never sold. |
| 07 | **Behaviour policies for the agents your portfolio companies already run.** Powered by Risk product & free behaviour-policy library | Site v1.10, library and store live. No payment link. |
| 04 | **A security review of a company you back, delivered as a vault rather than a PDF.** Powered by Report vault on the vault runtime | Designed 26 May. Deliverable shape built; demo specified. |
| 05 | **Explain a specialist domain to a board in its own words and at its own altitude.** Powered by Boardroom, agent rooms & persona machinery | Original product existed. Persona generator built in August. |
| 06 | **Briefings for your role, with the evidence behind every line.** Powered by Role-aware briefings on semantic graphs | Live; commercial state not verified in the brief. |
| 03 | **Manage and distribute sensitive portfolio data with per-recipient access.** Powered by Vaults on the same runtime | An MVP is built on it. |

## One product to discuss

A security review of a company you are backing, **scored against a published framework, signed by a named professional, at a fixed price, delivered as a vault.** Apply the scorecard during due diligence, with particular attention to business context and model survivability.

Also: companies to fund somebody to build, the rows on the founders sheet, plus seven company seeds written up in full and given away under attribution licensing.

**Write to [dinis.cruz@owasp.org](mailto:dinis.cruz@owasp.org)**, or explore [the network](../network/index.md).

## The sheet itself

**Proof 02 · 14 September 2026.** Fact set: brief v0.33.70, 13 September 2026, revised with the 14 September comments. Code: permissive software licence. Documents: CC BY 4.0. [← All four sheets](index.md) · [Explore the network](../network/index.md)



==============================================================================
# Corporate users, services available now

> Eight services for governing the agents already running, each stating what it is, what it runs on, and how far along it is, some live products, some designs delivered as engagements.
>
> Page: https://sgit.ai/summit/corporate.html

[Home](../index.md) / [Summit sheets](index.md) / Corporate users

**Sheet 04 of 04**: written for corporate users. [The other three →](index.md)

# Corporate users, Services available now

How do I manage, contain, monitor and ensure compliance of the agents already running? These are services you can engage now, some are live products, some are designs delivered as engagements.

Each row states what it is, what it runs on, and **how far along it is.**

[Download the PDF ↓](pdf/sgit-ai__04-corporate.pdf)The sheet as handed out in Lisbon. The table below is the same content, in a form a search engine and an agent can read.

## What exists

|  | The capability | What exists today |
|---|---|---|
| 07 | **A licence to operate for each agent you already run.** Powered by Risk product & free behaviour-policy library | Site v1.10, library and store live. No payment link; entry-tier application not located. |
| 08 | **Third-party and supply-chain management: what your vendors, and their agents, do with your data.** Powered by Vaults plus behaviour policies | Runs on the live vault runtime and the policy library. Not yet packaged as its own product. |
| 02 | **A folder with history for anything you send out of the building.** Powered by sgit, transfer protocol & browser vault | Live. CLI in beta; write-only intake built, never sold. |
| 03 | **Manage and distribute sensitive data, healthcare is the worked example.** Powered by Vaults on the same runtime | An MVP is built on it. |
| 04 | **Ask your next security vendor for the report as a vault rather than a PDF.** Powered by Report vault on the vault runtime | Designed 26 May. Deliverable shape built; demo specified. |
| 05 | **The board conversation, in the language and detail each executive needs.** Powered by Boardroom, agent rooms & persona machinery | Original product existed. Persona generator built in August. |
| 06 | **Briefings by role, with evidence behind every line.** Powered by Role-aware briefings on semantic graphs | Live; commercial state not verified in the brief. |
| 01 | **Debriefs from voice notes, wherever the voice already is.** Powered by Voice Debrief + WhatsApp, file & agent integrations | Live, earning, and run with a partner under a signed profit share. |

## Start with an agent you already run

**Bring one agent you already run.** You leave with a draft policy for it, corrected, as a file you keep. The library is free; the rows above state what is live and what is delivered as an engagement.

**Write to [dinis.cruz@owasp.org](mailto:dinis.cruz@owasp.org)**, or explore [the network](../network/index.md).

## The sheet itself

**Proof 02 · 14 September 2026.** Fact set: brief v0.33.70, 13 September 2026, revised with the 14 September comments. Code: permissive software licence. Documents: CC BY 4.0. [← All four sheets](index.md) · [Explore the network](../network/index.md)



==============================================================================
# sgit.ai, for investors, published in the open

> The problem, what sgit is, the open-source zero-knowledge architecture, traction computed from the site itself, the business model (the code is free; the running service is sold), the beachhead market, what could go wrong, and the ask, left visibly open until the founder states it rather than invented.
>
> Page: https://sgit.ai/investors/index.html

[Home](../index.md) / Investors

For angel investors · published in the open

# sgit.ai, for investors

Everything the founder's companies publish for investors, they publish in the open (the pitch, the model, the numbers) and this page follows that rule. What is here can be checked against the site it sits on. What is not here yet is marked as not here yet, rather than filled in.

## The problem, in one sentence

**AI agents are producing an enormous amount of work, and there is no good unit to hand it over in.** A report, a dataset, an application, a talk, today each needs hosting, an account, a deploy, and a trust relationship with whoever runs the server. Meanwhile the state agents need to share with each other and with people is versioned by nobody and readable by the host. The tools that exist were built for source code (git) or for storage (cloud drives). Neither was built for *a unit of work that carries its own app, history and sources and can be handed to a stranger with one string*.

## What sgit is

**Git for encrypted vaults.** A vault is a folder that is versioned like git (clone, commit, branch, merge, history) encrypted on the client before anything leaves the machine, and openable by anyone who holds the read key: no account, no install, nothing hosted by the reader. A vault can carry its own application, sandboxed, with the permissions it asks for declared in a file. The server stores ciphertext and hashes and cannot read what it stores.

| Layer | What it is | Who runs it | Licence |
|---|---|---|---|
| **sgit** | The CLI, `pip install sgit-ai`. Pure Python, two runtime dependencies. | Anyone | Apache-2.0 |
| **SG/Vault** | The web app: browse, edit and run vault apps in the browser. An independent implementation of the same wire format. | sgraph.ai, or self-hosted | Apache-2.0 |
| **SG/Send** | The zero-knowledge storage API both clients speak to. | sgraph.ai (hosted), or self-hosted, [the guidance is published](../docs/vault/static-hosting.md) | Apache-2.0 |

The proof is not this page. It is the [published vaults](../demos/vaults/index.md): real artefacts, a penetration test report with a retest script per finding, a compliance standard rebuilt as a citable graph, a Black Hat keynote with its cited papers, a game that reports anonymous telemetry through a write-only channel, each opened by one string, each audited before its key went public. Open one before reading further.

## Strategic architecture: open source, zero knowledge, zero lock-in

- **100% open source.** The CLI, the web app and the server are Apache-2.0. There is no proprietary tier of the code. The commercial line is the running, maintained, certified *service*, which is where the founder's [published position on open source ↗](https://open-source.sgit.ai/views/index.html) says it belongs.
- **Zero knowledge, published as a threat model.** [What the server sees](../security/index.md) is listed (object ids, ciphertext, sizes, timing, the vault id) and so is what it cannot. The security model is a page, not a claim.
- **Zero lock-in, deliberately.** Self-hosting guidance is published, live, in a vault. If the hosted service ever becomes unpalatable, a customer runs their own server and their data and workflow are unaffected. That is a feature of the business model, not a concession: *"as soon as you move into rent extraction, you lose sight of it."*
- **Built for agents first.** Machine-readable output on every read path, single-call commits, sparse clones, a permission model that is default-deny, and an LLM bridge where the app never holds the API key.

## Traction, computed from this site, not typed onto it

These numbers are generated at build time from the site's own data. If one is wrong, the site is wrong somewhere else too.

166**site releases since 14 August**
each verified live before it was called done

36**vaults published with a public read key**
every one audited first; findings on the page

27**sibling sites on *.sgit.ai**
one question each, own repo, own history

80**articles and release notes**
all with a markdown twin and an RSS feed

12**cross-team briefs, in the open**
two of them corrected this site

~4,000**tests in the CLI, mutation-tested in CI**
against a real server, no mocks

Behind the numbers: the site and every vault on it are built by **one person and a team of AI agents**, and the agents build for each other, a brief published here was turned into a working vault by another agent the same day, reviewed by the team that owns the API, and the review's corrections are published above the original. That loop is the product being used to build the product, and it is [documented as a method](../team/index.md).

## Business model

**The code is free. What is sold is the running service, and the trust that comes with running it well.**

- **Hosted vaults**: SG/Send storage and SG/Vault as a maintained, certified service at sgraph.ai. The customer's data is ciphertext to us; what they pay for is availability, durability, versions, and somebody to call.
- **The open-source strategy is the moat, not the code.** *"A competitor who forks our code today gets our position as of today. They do not get our velocity."* The published record (every release verified live before it was called done, every mistake recorded with the rule it produced) is that velocity made visible; the count is in the traction tiles above, computed rather than typed.
- **Adjacent products on the same layer.** RiskMandate.ai, the AIUC-1 conformance work and the licence-to-operate model for agent insurance are all built on vaults; several are [published here](../demos/vaults/index.md). The layer sells because things get built on it.

open-source.sgit.ai · Business & publishing, [The position (open source is a strategy, not a charity ↗](https://open-source.sgit.ai/views/index.html)) Technology is not the moat; lock-in relocates to quality, certification and maintainability; the moat is a rate, not a wall. The full argument, with its counter-cases named., “Open source is a strategy. It is not a charity.”, part of the sgit.ai network

## Market: the beachhead, and what it opens

**Beachhead: teams that already run AI agents and need the output to be auditable, encrypted and handed over.** Security and compliance work is where this bites first (a pentest report, a conformance assessment, a risk register) because the deliverable must carry its evidence and the recipient cannot be asked to trust a portal. Every published vault in that category was built by an agent and handed over with one string.

**Expansion: any team whose agents produce work for other people.** The same unit (data, app, history, sources) is a pitch deck, a research pack, a talk, a health record, a game. The [vaults table](../demos/vaults/index.md) is already spread across eight categories, none of which is "encryption".

## The ask

**Not filled in, and not invented**
**Round size, instrument and use of funds are the founder's to state**, and they are not on this page yet. Following the rule that nothing here is a number the author has not supplied, this box stays open until it is filled, and the gap is tracked in the open on [the board as N1](../team/board.md#N1). When it is filled, it will follow the same shape as the founder's other open pitches: the amount, what it buys in the next eighteen months, and the split.

## What this is not, and what could go wrong

- **It is beta.** The site says so in its nav on every page. [When not to use sgit](../docs/limitations.md) is a published page, and it is linked from the homepage trust strip.
- **The multi-agent claim has one gap.** The homepage says *a branch per agent, a human reviews the merge*; no published vault yet shows two agents merging in one history. The gap is named on the homepage and tracked on the board.
- **"They do not get our velocity" is empirical, not structural.** It holds while the team is faster. The founder's own position page names this as its weakest point.
- **Hosted zero-knowledge storage has a small set of well-funded neighbours.** The difference claimed is not encryption. It is the unit of work: versioning, apps inside the data, and the agent-first surface. Whether that difference is the one buyers pay for is the thing the beachhead has to prove.

## Investor materials, in the open

| Material | Where | State |
|---|---|---|
| This page, as a printable one-pager | Print it. The site has a print stylesheet | live |
| The security model and threat model | [/security/](../security/index.md) | live |
| When not to use it | [/docs/limitations](../docs/limitations.md) | live |
| Every release, with what went wrong | [/admin/versions](../admin/versions.md) | live |
| The published vaults, the product, in use | [/demos/vaults/](../demos/vaults/index.md) | live |
| How the company is built: one human, a team of agents | [/team/](../team/index.md) | live |
| The founder's record and interests declared | [open-source.sgit.ai/about ↗](https://open-source.sgit.ai/about/index.html) | live |
| The ask, use of funds, the deck | this page, [N1](../team/board.md#N1) and [N2](../team/board.md#N2) | **waiting on the founder** |

The founder's other companies publish their investor relations in public repositories ([MyFeeds.ai ↗](https://github.com/the-cyber-boardroom/MyFeeds-AI__Investor_Relations), [The Cyber Boardroom ↗](https://github.com/the-cyber-boardroom/cbr-investment)). sgit.ai's will follow the same practice: this page is the first file in it.

Contact: through [LinkedIn ↗](https://www.linkedin.com/in/diniscruz), or the [repository](https://github.com/SGit-AI/SGit-AI__CLI). If anything on this page is wrong, say so and it will be corrected above the mistake. That is [how this site works](../team/roles/historian.md).



==============================================================================
# Build your startup on sgit vaults, sgit.ai

> For founders: a vault removes the four costs that usually stand between you and a first user (a database to run, hosting for your reader, an account, an install), so you can ship something usable, give it away briefly, take it away, and find out whether they missed it. What you get on day one, the ladder from first vault to first customer, what you still have to bring (billing, identity, server-side query), and the measured cost base.
>
> Page: https://sgit.ai/startups/index.html

[Home](../index.md) / Startups

For founders building on vaults

# Build your startup on sgit vaults

A large part of why sgit exists is to make it cheap enough to ship something a stranger can actually use, repeatedly, and to take it away again when you need to find out whether they missed it. That loop is hard mostly because the infrastructure under it is expensive: a database to run, hosting to pay for, an account for every reader, an install before anybody sees anything. **A vault removes all four.** This section is for founders who want to build on that, and it will grow as more of them do.

**The operating model comes first, because the technology is the easy part.** [**For a startup, the most important question is whether they miss it →**](../articles/the-question-is-whether-they-miss-it.md) is the model this is all built to serve: ship something somebody can use, give it away briefly, take it away, and find out whether anybody noticed. Be profitable before you raise, so the investors are calling you. Open source everything, because the technology is not the moat. Read that first, then come back for the substrate.

## What you get on day one

Not a platform to sign up for. A format, a CLI and a credential, all open source, that between them remove the four things that usually stand between you and a first user.

| The usual cost | On a vault |
|---|---|
| **A database to run** | None. The store is encrypted files in cloud storage, read directly. Nothing runs between requests, so nothing is billed between requests |
| **Hosting for your reader** | None. A vault carries its own app, and it opens in the browser with no server of yours in the path. It also runs from a plain static host or a bucket, so your deployment is a copy |
| **An account, and an install** | Neither. [A read key](../docs/credentials.md) is the whole credential: the address, the capability and the decryption key in one string. You send it. They open it. There is nothing to sign up for and nothing to download |
| **Versioning you bolt on later** | Already there. Every change is a commit, every version is retained, and a reader can see the history, which means you can take something away and put it back without losing what was there |
| **An audit story for the first serious customer** | The server storing it cannot read it. That is the default, not a tier, and [the security model](../security/index.md) states exactly what the server does see |

The numbers behind that are measured rather than claimed. [Performance, cost, and running everywhere](../demos/fractal-graphs/performance.md) has the full set, and the shape of the bill is the part founders care about: **storage and egress only, no instance hours, and query compute paid by the reader's own device**. The entire published estate on this site is 2,662 files and 295 MB of object storage.

## First vault to first customer

The point of the model is a short loop. Here is what it actually looks like on this stack, with the page that owns each step.

| **1 · Put the thing in a vault** | `pip install sgit-ai`, create, commit, push. [Five minutes](../docs/quickstart.md), and it is the same verbs as git |
|---|---|
| **2 · Make it usable, not demoable** | Publish content with no code at all, or ship an app inside the vault. [Pick the surface first](../docs/surfaces.md): that choice decides more than anything after it |
| **3 · Give a read key to five people** | No onboarding to build, no invites, no seats. If the content is meant to be open, use the prefix that says so |
| **4 · Take it away** | Rotate the key and the trial is over. Nothing else about the product changes, which is the point: you are testing whether they miss it, not whether they liked the email |
| **5 · Charge, if they came back** | The stack does not do billing, and you should not want it to. What it gives you is a cost base low enough that a small price can be a profitable one |

**One honest caveat on step 4.** [Revocation is not retroactive.](../docs/credentials.md#read) Anybody who cloned while they had the key keeps what they cloned. For a trial that is usually fine, and it is better to know it now than to design as though a key could be recalled.

## What you still have to bring

This section would not be worth reading if it only listed what is free. A vault is a storage, distribution and versioning layer. It is not a product, and it is deliberately not several things.

- **Billing and payments.** Not here, not planned. Use whatever charges cards.
- **Identity and per-user accounts.** A read key is a capability, not a login. If you need to know *who* opened something rather than *that* it was opened, that is yours to build.
- **Server-side search and query.** The server cannot read the content, so it cannot index it. Whatever the client needs, the client downloads, which is fine at a megabyte and a design problem at a gigabyte.
- **The judgement about what to ship.** Obviously. But it is worth saying, because the cheapest part of this is now the part everybody used to spend their seed round on.

[When NOT to use sgit](../docs/limitations.md) is the longer version of this list, and it is kept honest on purpose.

## The arguments this rests on, and where they live

The market you are building into is described in [**The SaaS apocalypse will be decided by inertia, not by AI**](../articles/saas-apocalypse-decided-by-inertia-not-by-ai.md): most users were never happy, most features were never used, most licences sit idle, and the portability and APIs the incumbents starved to protect their moats are what an agent now needs. The opportunity it points at is the one this section is for: be the company that takes the brief and keeps it running.

One market gets its own worked example, because it is the one where both the traffic and the law are moving at once. [**The future of news is the story vault, not the paywall**](../articles/future-of-news-story-vault-not-paywall.md) argues that the article is a projection of a graph, that the graph is the asset, and that there are five things to sell from it, in pence and on demand. A local newsroom, one journalist or a blogger with a beat can run that model on this stack, which is the point.

Two of the three pillars have a whole site to themselves, because they outgrew a section here. They are worth reading before you commit to a commercial shape.

open-source.sgit.ai · Business & publishing · [Open source is a strategy ↗](https://open-source.sgit.ai/) · Why giving away the technology is the commercial choice rather than the charitable one, what it does to your architecture, and why it is the better exit for a founder who wants to leave with their tools. · “Open source is a strategy. It is not a charity.” · part of the sgit.ai network

subscriptions.sgit.ai · Business & publishing · [A subscription is not rent ↗](https://subscriptions.sgit.ai/) · The pricing trap most founders walk into by default. Charging rent for something nobody is using is a worse business than being paid when you deliver, and pay on demand is usually the healthier shape for both sides. · “A subscription is a discount for regular use, not rent on something you ignore.” · part of the sgit.ai network

## Business plans to build on

The section's other purpose: complete business plans, published as vaults, for other people to build companies on. Each one is written to be taken and run, with the numbers marked as hypotheses, the mock-ups included, and the prototypes enough to serve the first customer. The technology is not the moat, and neither is the plan.

| Plan | The business | What is in the vault |
|---|---|---|
| [**Company X-Ray**](../demos/vaults/company-xray/index.md) | Read a company's own documents together: they are dropped into a vault, agents run a catalogue of analyses, a person reviews, and the customer gets their questions answered, a board pack and a Claude setup to keep asking. No connectors. | One invented company X-rayed end to end, fourteen findings tied to their evidence, a script that re-runs every figure, eleven plan documents, the catalogue, the prompts and a calculator. |
| [**Lesson Loop**](../demos/vaults/lesson-loop/index.md) | Capture what a coach knows at the end of every lesson, in a record the player holds, and start every lesson from a briefing. Padel first, any teacher with students after. Paid on demand, with new income for coaches. | One player's record across four lessons with three coaches, eleven plan documents, the prompts for phase one, and a calculator. |
| [**Risk Acceptance Office**](../demos/vaults/risk-acceptance/index.md) | Run the risk acceptance loop for organisations, in the gaps of their GRC platform: every material risk on facts, held by a named person, accepted for an interval, and escalated, funded or fixed when it ends. | One invented risk replayed over six weeks, eleven plan documents, the acceptance record and risk vault specifications, three prototypes and a calculator. |
| [**Connector Twin**](../demos/vaults/connector-twin/index.md) | Give every AI agent deployment a twin of its connectors: a journal of every request and response, replayed into what the agent saw, with before and after and a revert plan. Sold with one question: do you know what your agents did? | A working replay of an invented Gmail and Calendar session, eleven plan documents, the facts with Google's sources, the journal specification, revert rules, three prototypes and a calculator. |
| [**Agent as Webmaster**](../demos/vaults/agent-webmaster/index.md) | Give small businesses a website they can change by asking, with an AI agent as the webmaster and GitHub Pages as the host. Setup once, maintenance monthly, changes on demand. One operator, profitable at fifty customers. | The plan in one page and in ten documents, three diagrams, a unit-economics calculator, three invented customer sites and the operator's sales site as mock-ups, the agent's playbook, the setup steps and six worked change requests. |

[**All business plans, and how to take one →**](business-plans.md)

**Want one written for your idea?** The plans start as a voice memo and become a vault the same day. If you have a business that should exist on this stack and would rather somebody else ran it, [say so](../about/index.md).

## Evidence, rather than a pitch

Everything above is how this site itself is built, which is the only reason to believe any of it.

- **Thirty-five vaults published with their read keys**, each with a page describing what it does and the vault running live inside it. [Open any of them](../demos/vaults/index.md) with no account and nothing installed.
- **The method is written down**, including the mistakes that produced each rule. [The publishing method](../demos/vaults/publishing.md) is written to be followed by somebody else's agent.
- **The measurements are repeatable**, with the commands printed. [Performance and cost](../demos/fractal-graphs/performance.md).
- **One person, working with agents.** The whole estate is built this way, which is the actual claim about how small a team this needs.

## Where to start

| **Read the model** | [The most important question is whether they miss it](../articles/the-question-is-whether-they-miss-it.md) |
|---|---|
| **Ship something today** | [Quickstart](../docs/quickstart.md), then [pick your surface](../docs/surfaces.md) |
| **Build with agents** | [The agent guide](../docs/agents.md) and [the skills](../skills/index.md), since this is how the work actually gets done here |
| **See what exists already** | [What exists, and what is still a design](../summit/startups.md), the sheet that says which is which |
| **Raising, eventually** | [sgit.ai for investors](../investors/index.md), published in the open, which is the same rule this section follows |

**This section is new, and deliberately small.** It will grow with the founders who use it, and when it outgrows a page it will become its own site, the way nineteen others already have. If you are building on vaults, the most useful thing you can send is what broke.

[← The operating model](../articles/the-question-is-whether-they-miss-it.md)[Open a real vault →](../demos/vaults/index.md)



==============================================================================
# Business plans to build on sgit, sgit.ai

> Businesses we think should exist on top of sgit, each written up as a vault in enough detail for somebody else to start: Connector Twin (a journal and replay of every connector call an AI agent makes, sold per agent) and Agent as Webmaster (websites small businesses change by asking). How to take one, what every plan contains, and the offer to build them with partners.
>
> Page: https://sgit.ai/startups/business-plans.html

[Home](../index.md) / [Startups](index.md) / Business plans

For founders · published as vaults · take one and run it

# Business plans to build on sgit

These are businesses we think should exist on top of sgit and the work published on this site, written up in enough detail for somebody else to start one. Each plan is a vault: the plan as an app and as documents, the numbers marked as hypotheses, the facts with their sources, and prototypes enough to serve the first customer. **We are looking for business partners to build them.** Where nobody does, we may build one ourselves, depending on funding and on who is available. Either way the plan is public, on the same terms as the code.

## The plans

| Plan | The business | How it makes money | What is in the vault |
|---|---|---|---|
| [**Company X-Ray**](../demos/vaults/company-xray/index.md) 24 September 2026 | Read a company's own documents together. The customer drops accounts, customer and supplier lists, minutes, the plan and a complaints log into an encrypted vault; agents run a catalogue of twelve analyses; a person reviews; and within five working days the customer gets their questions answered, a one-page board pack, findings tied to the file and row they rest on, and a Claude setup to keep asking. No connectors or integrations. | Four levels on the RiskMandate.ai pattern: the kit £50, your X-ray vault £150, Standard £500, Tailored with two sessions and a signed review £1,500. Re-X-rays when the numbers move, and a partner licence for accountants. About eleven Standard and three Tailored a month cover a two-founder burn. | One invented company X-rayed end to end: twelve documents in, fourteen findings out, a script that re-runs all 46 figures, the board pack and the Claude setup as delivered. Eleven plan documents, the analysis catalogue, the run prompt, the reviewer's checklist, a calculator and two diagrams. |
| [**Lesson Loop**](../demos/vaults/lesson-loop/index.md) 24 September 2026 | Capture what a padel coach knows at the end of every lesson, in a record the player holds: a voice memo, an agent, a lesson note, match notes from the player, and a two-minute briefing for the next coach, in any club or country. Works for any teacher with students. | Paid on demand, no subscription: credits for processing, about 20p a lesson note. Coaches price remote reviews, drill plans, follow-ups and content; the operator takes a share. Clubs can include notes in the lesson price. | One invented player's record across four lessons with three coaches, the themes each saw, eleven plan documents, the coach-memo and briefing prompts ready to use, the note specification, a calculator and two diagrams. |
| [**Risk Acceptance Office**](../demos/vaults/risk-acceptance/index.md) 24 September 2026 | Run the risk acceptance loop for organisations: every material risk established on facts, held by a named person, accepted for a stated interval, and at expiry accepted again, escalated, funded or fixed. A governance service that works in the gaps of the client's GRC platform, with a vault per material risk as its evidence pack. The foundation is argued in [Every risk is already accepted](../articles/every-risk-is-already-accepted.md). | A free acceptance audit, then a foundation engagement at £18,000, then £2,500 a month plus £60 per material risk per month. Incident support by the day, and a partner licence for consultancies. | The principles, one invented risk replayed over six weeks with a hash-chained decision record, eleven plan documents, the acceptance record and risk vault specifications, three prototypes, a calculator and three diagrams. |
| [**Connector Twin**](../demos/vaults/connector-twin/index.md) 24 September 2026 | Give every AI agent deployment a twin of its connectors: a journal of every request and response to Gmail, Calendar, Drive or Slack, replayed into the views the agent saw, with before and after and a revert plan. Sold with one question: do you know what your agents did? The case is argued in [Before you give an agent a connector, give the connector a twin](../articles/connector-twin-before-you-deploy-an-agent.md). | A connector review once, £750 to £6,000. Then per agent per month: £15, £40 or £90 by tier. Incident replays on demand. About 380 agents cover a two-founder burn. | A working replay of an invented session with a hash chain verified in the browser, eleven plan documents, the facts with Google's sources, the journal entry specification, revert rules for Gmail and Calendar, three prototypes, a calculator and two diagrams. |
| [**Agent as Webmaster**](../demos/vaults/agent-webmaster/index.md) 23 September 2026 | Give small businesses a website they can change by asking, with an AI agent as the webmaster and GitHub Pages as the host. Setup once, maintenance monthly, changes on demand. | Setup £300 to £1,200. Maintenance £50 to £200 a month. Changes on demand. One operator, profitable at about fifty customers. | The plan in one page and in ten documents, three diagrams, a unit-economics calculator, three invented customer sites and the operator's sales site as mock-ups, the agent's playbook, the setup steps and six worked change requests. |

## How to take one

1. **Open it.** Every plan's page prints its public read key. Open it in the browser with nothing installed, or clone it with `sgit clone`.
2. **Read the one-page version.** Every plan starts at `plan/00-START-HERE.md`, with a reading order after it.
3. **Test the numbers.** Every price and every hour is a first guess, and every plan says so. The first ten customers are the test.
4. **Keep what you build.** The plans are offered on the same terms as the code behind them: take it, run it, change it.
5. **Send back what broke.** It is the one thing we ask, and it makes the next plan better.

## What every plan contains

| **The one-page version** | The business, why now, what you sell, the numbers and why it is buildable, on one page. |
|---|---|
| **Facts and assumptions, kept apart** | Facts link to their sources. Assumptions are labelled as assumptions, with the arithmetic shown so they can be redone. |
| **The architecture and the service** | How it is built on vaults, what the customer gets, and what the operator does not do. |
| **The model, with a calculator** | Prices, costs, margins and break-even, with the inputs on sliders in the app. |
| **Go-to-market and the first ninety days** | Who buys first, the free thing that opens the door, and what "done" means at each stage. |
| **Investors, risks and open questions** | The case for backing it, what could sink it, and what we do not know yet. |
| **Prototypes** | Enough to serve the first customer: playbooks, specifications, set-up steps and worked examples. |
| **PUBLIC.md** | The rules the vault is published under: nothing private, no write token, and an app that asks for no permissions. |

**Want to build one of these, or want one written for your idea?** The plans start as a voice memo and become a vault the same day. If you want to run one of the businesses above, with us or on your own, or you have one that should exist on this stack, [say so](../about/index.md).

[← Startups](index.md)[About the author →](../about/index.md)



==============================================================================
# About the author, Dinis Cruz, sgit.ai

> The provenance behind the first-person articles: the record (sgit.ai, sgraph.ai, MyFeeds.ai, The Cyber Boardroom, RiskMandate.ai, VoiceDebrief.ai, OWASP), the signed articles on this site, where else the author writes, the interests a reader should know about, and how to reach or correct him.
>
> Page: https://sgit.ai/about/index.html

[Home](../index.md) / About the author

The person behind the first-person articles

# Dinis Cruz

sgit.ai is built by one person and a team of agents, and the articles here that say *I* are written by the person. This page is the provenance for that byline: who I am, what I have built, where else I write, and the interests a reader should know about before taking the argument. It follows the same rule as the rest of the site, which is that a claim should be checkable without trusting me.

## The record

| Role | What it involves |
|---|---|
| **Founder, [sgit.ai](../index.md)** | Encrypted vaults with git semantics: clone, commit, branch and merge files that are encrypted before they leave your machine, under Apache-2.0, and [the network of sites](../network/index.md) of which this is the hub. Each site publishes its argument before its implementation, so the commitments are checkable, and [thirty-six vaults are published with their read keys](../demos/vaults/index.md) as the evidence. |
| **Founder, [sgraph.ai](https://sgraph.ai)** | Where the strategy turns into revenue: the commercial home of SG/Send, the secure file-sharing service built on the open-source sgit layer, and hosted SG/Vaults. The code stays Apache-2.0. What is sold is the running, maintained, certified service. |
| **Founder, [MyFeeds.ai](https://investor.myfeeds.ai/)** | Role-aware cybersecurity briefings built on semantic knowledge graphs, with source attribution: CISO, engineer and board views of the same news. Open source, serverless, and with the seed pitch and unit economics published in the open. |
| **Founder, [The Cyber Boardroom](https://thecyberboardroom.com)** | An AI-powered platform for the conversation between technical security teams and the board, bridging the two with knowledge-graph technology. Apache-2.0, with the community edition and the [investment repository](https://github.com/the-cyber-boardroom/cbr-investment) public. The Cyber Boardroom Limited, UK-registered and trading for almost two years, is today the commercial vehicle behind sgit.ai and RiskMandate.ai. |
| **Founder, [RiskMandate.ai](https://riskmandate.ai/)** | The business risk layer for autonomous systems. Its field demo is [published here as a vault](../demos/vaults/risk-mandate/index.md), 124 files and 98 commits inside one encrypted store. |
| **Founder, [VoiceDebrief.ai](https://voicedebrief.ai)** | Voice recordings into transcripts and debriefs, entirely in the browser, with nothing uploaded to a server. The vault where [Fractal Semantic Graphs were first worked](../demos/vaults/voice-debrief/index.md) came out of this work. |
| **Former OWASP Board member** | And organiser of the OWASP Summits, Lisbon 2011 and Woburn 2017, the working-session format with no spectators and only participants that the Open Security Summit series went on to build on. Current open-source work still ships under the owasp-sbot organisation. |
| **Creator, the O2 Platform** | The OWASP static-analysis engine of 2010 to 2012, and the first of a line of open-source tooling that continues in the osbot and mgraph families, memory_fs, Issues-FS and sgit-ai, all Apache-2.0 and all on PyPI. |
| **Thirty years in the UK** | Based in the UK for thirty years, as a security practitioner, a CISO for UK companies and a founder, with one UK company taken through to an exit. The intent, stated on [the proposed partnership with UK Sovereign AI](../partnerships/sovereign-ai.md), is to grow more UK-based companies on this technology, in the open. |

## Writing on this site

The articles carry a byline when they are written in the first person, and the byline links here. The unsigned articles are written in the site's own voice by the team of agents, from briefs, and say so.

- [The future of news is the story vault, not the paywall](../articles/future-of-news-story-vault-not-paywall.md). The story is a graph, the article is a projection, and there are five things to sell from one graph.
- [The SaaS apocalypse will be decided by inertia, not by AI](../articles/saas-apocalypse-decided-by-inertia-not-by-ai.md). Same AI on both sides; what differs is what each has to protect.
- [For a startup, the most important question is whether they miss it](../articles/the-question-is-whether-they-miss-it.md). The operating model in three pillars.
- [Introducing Fractal Semantic Graphs](../articles/introducing-fractal-semantic-graphs.md). Every node opens into a graph of its own; edges are verbs; meaning lives in connectivity.
- [All articles](../articles/index.md), signed and unsigned.

## Writing elsewhere

| **[docs.diniscruz.ai](https://docs.diniscruz.ai)** | The long-form research and essays, including [the future-of-news series](https://docs.diniscruz.ai/research/the-future-of-news.html) from February to July 2025 that the news article here builds on. Published under CC BY 4.0. |
|---|---|
| **[LinkedIn](https://www.linkedin.com/in/diniscruz)** | Where most of the articles are first posted and discussed, and the fastest route to reach me. |
| **[open-source.sgit.ai](https://open-source.sgit.ai/)** | My position on open source as a strategy, with [a fuller version of this page](https://open-source.sgit.ai/about/index.html): the licences, the investor materials published in the open, and the interests declared there. |
| **[wardley-maps.sgit.ai](https://wardley-maps.sgit.ai/)** | The maps behind the strategy arguments, on the principle that maps are claims, not pictures. |
| **[graphs.sgit.ai](https://graphs.sgit.ai/)** | The Fractal Semantic Graphs argument in full: the grammar, the books, the worked examples and the evidence estate. |
| **[newsroom.sgit.ai](https://newsroom.sgit.ai/)** | The newsroom design the news article draws on, and [its Portuguese newsroom](https://pt.newsroom.sgit.ai/), where I am the named editor of record. |
| **[GitHub](https://github.com/DinisCruz)** | The code, including [the sgit CLI](https://github.com/SGit-AI/SGit-AI__CLI) and [this site's source](https://github.com/SGit-AI/SGit-AI__Website), every page as content files plus the build that renders them. |

## Interests declared

I run companies whose strategy the articles here describe, and which sell the running, maintained service rather than the code. The market the news article, the SaaS article and the startups section describe is one I intend to be in. Read the arguments knowing that. Two things are built in to keep it honest.

- **The claims are checkable without trusting me.** The measurements are [printed with the commands that produced them](../demos/fractal-graphs/performance.md), the vaults are [open with a read key](../demos/vaults/index.md), the method is [written down with the mistakes that produced each rule](../demos/vaults/publishing.md), and [the lessons learned](../lessons/index.md) include the ones that cut against the argument.
- **The pitch is public too.** [sgit.ai for investors](../investors/index.md) is published in the open, with the ask left visibly empty until it is stated rather than invented.

## Reach me, or correct me

[LinkedIn](https://www.linkedin.com/in/diniscruz) is the fastest route. Corrections and requests for this site are tracked in the open on [the board](../team/board.md), and [the repository](https://github.com/SGit-AI/SGit-AI__Website) takes issues and pull requests. If you find something wrong here, I would rather know.

[← The articles](../articles/index.md)[How the site is run →](../team/index.md)



==============================================================================
# Partnerships, argued in the open, sgit.ai

> The business case for specific partnerships between sgit.ai, RiskMandate.ai and organisations we would like to work with, made from public material only so the pages can be forwarded to anyone: what they are trying to do, what is published here that answers it, where the fit is partial, and a first concrete piece of work.
>
> Page: https://sgit.ai/partnerships/index.html

[Home](../index.md) / Partnerships

The business case, made in public

# Partnerships, argued in the open

Each page in this section makes the case for one specific partnership, or puts out one specific call for collaboration, between organisations we would like to work with and the companies behind this site, [sgit.ai](../index.md) and [RiskMandate.ai](https://riskmandate.ai/). The pages are built entirely from public material, theirs and ours, so there is nothing on them that either side would need to keep confidential, and they can be sent to anyone who knows somebody there. That is what they are for.

## How each page is written

| **Start with what they are trying to do** | In their own words where possible, and where we can put it better, put it better. A partnership page that cannot explain the other side's mission generously has not understood it. |
|---|---|
| **Public material only** | Their published strategy, programmes and criteria. Our published vaults, measurements and articles. Nothing from a conversation, a data room or a private brief. If a fact would need permission to publish, it is not on the page. |
| **Evidence, not pitch** | Every claim about what we can do points at a vault that can be opened with a read key, a measurement with its command printed, or a page that states its own limits. The [thirty-six published vaults](../demos/vaults/index.md) are the portfolio. |
| **The fit, stated precisely** | Which of their stated priorities we serve, which we do not, and what a first concrete piece of work would be. A partnership is a specific thing two parties do, not an alignment of values. |
| **What is not public, marked** | The things a partner would need to know that are not on either site are listed rather than hidden, in the same way [the investors page](../investors/index.md) leaves the ask visibly open until it is stated. |

## The cases

| Organisation | Why them | The case |
|---|---|---|
| **UK Sovereign AI** sovereignai.gov.uk | Britain's £500 million sovereign venture fund for AI companies, with trust, safety and assurance as one of its five frontiers and an R&D procurement scheme whose challenge areas include the safe adoption of AI agents. Almost everything published here is an answer to a question they have asked in public. | [**A proposed partnership between sgit.ai, RiskMandate.ai and UK Sovereign AI →**](sovereign-ai.md) |
| **Password managers and identity providers** an open call | Every sgit vault opens with one key, people now hold dozens, and agents are starting to create them by the hundred. Storing, sharing and taking back secrets in the browser is what these teams already do well, and we would rather use their answer than build our own. | [**Who holds the keys? A call for collaboration on vault key management →**](vault-key-management.md) |
| **The cloud platforms** AWS, Azure, Google Cloud, IBM, Europe, and more | sgit needs mostly storage and a little compute, so it runs on every cloud. Our story is AWS for historical reasons and because our credits are AWS credits; Azure and Google Cloud work but are not yet documented. One page per cloud, on deploying vaults there and the services that can be built on them. | [**sgit runs on every cloud →**](cloud-platforms.md) |
| **The AI providers** OpenAI, Anthropic, Mistral, Google Gemini, OpenRouter, ElevenLabs | This site is built with their models, and vaults are where agent work can be handed over, where documents can call models without leaking keys, and what a connector for encrypted data looks like. One page per provider. | [**Models do the work, vaults hold it →**](ai-providers.md) |

**If you know somebody at one of these organisations**, the page is written to be forwarded as it is. It says what they do, what we do, where the two meet, and what a first step would look like, and everything on it can be checked by the person receiving it. [Who is asking, and how to reach them →](../about/index.md)

[← About the author](../about/index.md)[UK Sovereign AI →](sovereign-ai.md)



==============================================================================
# A proposed partnership between sgit.ai, RiskMandate.ai and UK Sovereign AI

> A proposal from our side, published in the open. UK Sovereign AI names trust, safety and assurance as one of five frontiers and the safe adoption of AI agents as a procurement challenge area. This page states their mission in their own words, maps each priority to vaults published here that can be opened now (Licence to Operate, Risk Mandate, AIUC-1 conformance, the DSIT AI Risk Toolkit, Regulation Graph), states the UK anchoring in the founder's own words (thirty years in the UK, a UK exit, The Cyber Boardroom Limited as the trading company), argues that sovereignty without open source is one acquisition deep, proposes three concrete partnership shapes sized to their instruments, and lists what the page cannot tell them.
>
> Page: https://sgit.ai/partnerships/sovereign-ai.html

[Home](../index.md) / [Partnerships](index.md) / UK Sovereign AI

A proposed partnership · sgit.ai and RiskMandate.ai with UK Sovereign AI · public material only · 23 September 2026

# A proposed partnership between sgit.ai, RiskMandate.ai and UK Sovereign AI

**This is a proposal from our side, published in the open.** [sgit.ai](../index.md) (git for encrypted vaults) and [RiskMandate.ai](https://riskmandate.ai/) (the business risk layer for AI agents) are two UK-built products from the same founder and the same UK company. UK Sovereign AI is Britain's sovereign venture fund for AI companies: *"backing Britain's AI founders to start here, scale here, and win everywhere."* One of its five frontiers is trust, safety and assurance, and one of the four challenge areas in its R&D procurement scheme is the safe adoption of AI agents by cybersecurity professionals. This page argues that the work published on this site and at RiskMandate.ai is a direct, already-built answer to both, that it is built by a founder who has been in the UK for thirty years through a UK-registered company, and that the open-source approach behind it is what makes sovereignty durable rather than one acquisition deep. It makes the argument from public material and the founder's own stated record, so it can be forwarded to anyone.

**Nothing on this page is confidential.** Every statement about UK Sovereign AI is taken from [sovereignai.gov.uk](https://www.sovereignai.gov.uk/) or from public reporting, and is linked. Every statement about us points at a published vault, a printed measurement or a page on this site, except [the anchoring section](#anchoring), which is the founder's own account and says so. There has been no conversation with the fund; this is the case we would make if there were one. Where it says what a partnership *could* be, that is our proposal, not their position.

## What UK Sovereign AI is trying to do

It is worth stating their mission as well as we can, because the fit only makes sense once it is clear.

The fund was established in April 2026 with [£500 million of government capital](https://en.wikipedia.org/wiki/Sovereign_AI_Fund), alongside a £282 million Strategic Assets Grants Programme, to act as a venture investor inside the state: early-stage equity of £1 million to £10 million at market terms and speed, invested alongside other investors and without bespoke conditions, because, in [their own words](https://www.sovereignai.gov.uk/faqs), conditions *"would risk making a company less competitive."* It is chaired by James Wise, with Suzanne Ashman as Managing Partner and Joséphine Kant as Investment Partner, and it is funded by the UK Government through the Department for Science, Innovation and Technology.

The idea underneath it is sharper than "a national fund". Their September 2026 post [From investment to sovereignty](https://www.sovereignai.gov.uk/post/from-investment-to-sovereignty) puts it this way: *"Rather than build a sovereign wall across the entire AI value chain, which could see us miss out on the best breakthroughs from across the world, we will build a sovereign edge."* Sovereignty, on this reading, is not self-sufficiency in everything. It is concentrating on the layers where the UK can win, and making sure the companies that win there are anchored here: *"Not by outspending larger economies, but by concentrating resources where the UK has the potential to win."*

They name five frontiers where they think that is possible:

| Frontier | What it covers, as we read it |
|---|---|
| **Compute and infrastructure** | The layer everything else runs on, with an emphasis on efficiency: doing more with less compute, and doing it here. |
| **Foundation models** | Next-generation models built from the UK. |
| **AI in health and life sciences** | Drug discovery and clinical applications, where the UK research base is a real advantage. |
| **Scientific discovery** | AI as an instrument of science, including materials and autonomous labs. |
| **Trust, safety and assurance** | The layer that lets the other four be adopted: knowing what a system can do, whether it did what it was allowed to, and being able to show that to a regulator, an insurer or a board. |

And they back founders with more than capital. [The offer beyond investment](https://www.sovereignai.gov.uk/offer-beyond-investment) is four things: up to a million GPU hours on the national AI Research Resource (Isambard and DAWN) for substantive UK R&D; an R&D procurement scheme with *"up to £100 million available over the lifetime of the scheme for UK-registered startups and SMEs"*, in which government acts as an early customer, contracts run to £5 million over 12 to 24 months, and *"suppliers retain ownership of their intellectual property"*; a Strategic Assets Programme funding pre-competitive datasets and lab infrastructure; and visa cost reimbursement for international R&D hires. The procurement scheme's four initial challenge areas are AI for NHS productivity, defence mission environment integration, compute efficiency for public infrastructure, and **safe AI agent adoption for cybersecurity professionals**.

The test they apply is anchoring. A company must *"have, or commit to building, a significant and enduring UK presence"*, and success is measured by *"both commercial performance and UK anchoring."* The portfolio so far runs from Callosum in AI infrastructure to Isomorphic Labs in drug discovery and Cusp AI in materials, with a second tier of compute recipients, and the unit has said it is in conversation with around thirty more.

Put simply: **they want British companies building the layers that matter, anchored here, and they are willing to be the first customer as well as an investor.** That is a good thing to want, and the rest of this page is about one of those layers.

## What we have built, in public

Two companies, one substrate, and a published body of evidence that can be opened by anyone with the read key printed on each page.

**[sgit.ai](../index.md)** is git for encrypted vaults. A vault is a folder versioned like a git repository, encrypted on the client before anything leaves the machine, openable by anyone holding a read key with no account and nothing installed, and able to carry its own application with the permissions it asks for declared in a file. The server that stores it cannot read it; [the security model](../security/index.md) states exactly what it does see. The code is Apache-2.0 and [deploys to Docker, AWS, GCP or a plain static host](../deploy/index.md), including, as this site demonstrates, to a bucket behind a CDN with no server of ours in the path. [Thirty-five vaults are published with their read keys](../demos/vaults/index.md), and [the method for publishing them safely is written down](../demos/vaults/publishing.md) with the mistakes that produced each rule.

**[RiskMandate.ai](https://riskmandate.ai/)** is the business risk layer for autonomous systems. Its tagline is *"know what your agents can do"*, and its central object is the Agent Behaviour Policy: a documented record of what an agent can reach, what it was authorised to do, the gap between the two, and which controls constrain it, written so that a CEO, a CTO, a CISO and an insurer can all sign the same document. From that comes the *licence to operate*: the business as the authority, the behaviour policy as the evidence, the agent operating under stated terms for a stated interval, with residual risk accepted by a named owner. *"Not what they did. What they can."*

Underneath both is the graph work described at [Fractal Semantic Graphs](../demos/fractal-graphs/index.md) and [graphs.sgit.ai](https://graphs.sgit.ai/): regulation, guidance, standards and risk registers modelled as semantic graphs where every edge is a verb and every claim walks back to hashed source bytes, so that trust comes through provenance and provenance comes via evidence.

## Where the two meet

Their fifth frontier and their fourth challenge area are the two places we already work, and the evidence for that is not a deck. It is vaults that are open right now.

| What they have said they want | What is already published, and can be opened |
|---|---|
| **Safe AI agent adoption for cybersecurity professionals** procurement challenge area | [Licence to Operate](../demos/vaults/licence-to-operate/index.md): one agent, its grant, its mandate, and the policy insuring that mandate, as a simulation where every turn shows whether the reply is inside the band, draws on the pool, or is outside cover. [Agentic Browser Isolation](../demos/vaults/agentic-browser-isolation/index.md): a living risk graph for whether an agent acts inside your logged-in browser or an isolated one with a scoped identity. [Two games about what an agent can do](../demos/vaults/agent-permission-games/index.md), built by another agent from a brief on this site. And [Risk Mandate](../demos/vaults/risk-mandate/index.md) itself, a working application with 98 commits inside one encrypted vault that uses an LLM without ever holding the API key, and runs on an iPad with the network off. |
| **Trust, safety and assurance** the fifth frontier | [Provenance is not conformance](../demos/vaults/aiuc-1-conformance/index.md): a standard tells you what good looks like and cannot tell you whether you do it, so the vault keeps two edges apart, *evidenced_by* (does the standard say this?) and *attested_by* (does this subject do this?), and asks what would be insurable on this date given what is actually evidenced. [A penetration test delivered as a vault](../demos/vaults/pentest-report/index.md): eight audience-specific views of one engagement, evidence attached to each finding, and a runnable retest per finding that exits 0 if fixed and 1 if not. |
| **Regulation and guidance that can be cited, not asserted** the substrate of assurance | [The DSIT AI Risk Management Toolkit as four connected worlds](../demos/vaults/dsit-ai-risk-toolkit/index.md): the department's own guidance, its spreadsheet, the risk method it describes and the frameworks it cites, modelled as separate worlds with named bridges, every claim carrying the bytes it came from and declaring whether a person curated it or a lexical match found it, published under the Open Government Licence and clearly marked as independent and derived. [Regulation Graph](../demos/vaults/regulation-graph/index.md): the EU AI Act as amended, parsed from official Formex XML and hash-verified, 1,523 nodes and 1,944 edges, so a risk in a register points at a named obligation in a real instrument. [Standards Atlas, GDPR](../demos/vaults/standards-atlas-gdpr/index.md): rulings and regulators' guidance as first-class nodes over the articles they bend. |
| **High-quality datasets as strategic assets** Strategic Assets Programme | Every graph above is a dataset with its provenance attached, distributed as an encrypted, versioned vault that opens with a read key. The shape generalises: a national dataset published this way is hash-verified against its source, versioned so every release is retained, portable across any cloud or a UK-hosted bucket, and readable by nobody without the key, including whoever hosts it. [The catalogue](../catalogue/index.md) is the index of such datasets, itself a vault, listed in itself. |
| **Compute efficiency for public infrastructure** procurement challenge area | Not our frontier, but a measured property of the substrate. [Performance, cost, and running everywhere](../demos/fractal-graphs/performance.md): no database, no instance hours, storage and egress only, query compute paid by the reader's device, a 2,660-fold semantic compression ladder from raw source to ontology with nothing discarded, and the whole estate at 2,662 files and 295 MB of object storage as measured on 21 September 2026. The commands are printed so the numbers can be re-run. |
| **Sovereignty as an edge, not a wall** their thesis | An open-source, client-side-encrypted substrate is what a sovereign edge looks like at the data layer. The code runs anywhere and belongs to nobody; the keys stay with the owner; the host, whichever country it is in, cannot read the content; and moving a vault between providers is a copy. A closed champion is one acquisition away from losing its sovereignty; an open substrate cannot be bought out from under the country that runs on it ([the argument, below](#anchoring)). [open-source.sgit.ai](https://open-source.sgit.ai/) makes the strategic argument for why the code being open is the commercial choice rather than the charitable one. |

## The UK anchoring, stated by the founder

The fund's central test is a significant and enduring UK presence, so this is stated plainly and in the first person, because it is the one part of the case that only the founder can supply.

| **Thirty years in the UK** | I have been based in the UK for thirty years. I live here and I have worked here throughout: as a security practitioner, as a CISO for UK companies, and as a founder. |
|---|---|
| **One UK exit already** | I have taken one UK company through to an exit. This is not a first attempt at building a British company that lasts. |
| **The commercial vehicle is a UK company** | The commercial venture behind sgit.ai and RiskMandate.ai today is [The Cyber Boardroom Limited](https://thecyberboardroom.com), a UK-registered company that has been trading for almost two years. |
| **The intent is more UK companies** | The plan is to grow UK-based companies on this technology, in the open, the way [the operating model](../articles/the-question-is-whether-they-miss-it.md) describes: profitable products, investors who come to you, and the code open so that the companies are portable and the founder leaves with the tools. |

**And one argument about sovereignty itself.** I do not think a country can have sovereign AI without open source, and I would make that case to the fund directly. A closed sovereign champion is one acquisition away from not being sovereign at all: the day it is bought, the code, the roadmap and the keys go with it, and the CMA and NSI Act reviews the fund's FAQ points to are a brake on that, not a guarantee against it. An open-source substrate cannot be acquired out from under the country that depends on it. The code stays available, the vaults stay openable by whoever holds the keys, and any UK company, including a new one, can pick the work up and continue it. That is why everything here is Apache-2.0, why the investor materials are public, and why [open-source.sgit.ai](https://open-source.sgit.ai/) argues that open source is the strategy rather than the charity. Read against *"a sovereign edge, not a sovereign wall"*, it is the same idea from the other side: the edge is only durable if it cannot be bought.

## What a partnership could be

Three concrete shapes, in the order we would propose them, each sized to what the fund already offers.

| Shape | What it would be | Which of their instruments |
|---|---|---|
| **1 · A procurement prototype for the safe adoption of agents** | Take the licence-to-operate model, the Agent Behaviour Policy, and the grant-against-mandate delta, and run them against real agents in a government cybersecurity setting: what each agent can reach, what it is authorised to do, the gap, the controls, and the named owner of the residual risk, as a versioned record a CISO and an insurer can both sign. The public simulation exists; the prototype is the same model on real deployments, with the evidence held in vaults the department controls and we cannot read. | The R&D procurement scheme, challenge area four. Contracts to £5 million over 12 to 24 months; IP stays with the supplier, which we would publish anyway. |
| **2 · Guidance and regulation as citable graphs** | Do for the department's own instruments what the DSIT toolkit and Regulation Graph vaults already do unofficially: publish the official guidance, its cited frameworks and the relevant regulation as hash-verified semantic graphs with an official status, so that every AI risk register in the portfolio, and in government, can point at a named obligation rather than assert one. The independent editions exist and state their own limits; an official edition would remove the disclaimer. | The Strategic Assets Programme's dataset strand, or a small procurement lot. Pre-competitive by construction: everyone in the portfolio benefits. |
| **3 · A substrate for the portfolio** | Every portfolio company will need to hand a working thing to a government user, a regulator or a customer without hosting it for them, without an account, and without the data leaving the owner's control. That is what a vault is for: the app, the data, the history and the read key travel as one string, and it runs offline once cached. Risk Mandate is the worked example, built to be handed to a stranger on an iPad. | The portfolio, as a shared capability rather than a per-company procurement. The measured cost base is on the performance page. |

We would start with the first, because it is the one where a public simulation already exists and the gap to a real prototype is smallest, and because the challenge area is written in almost exactly the words RiskMandate.ai uses.

## What this page cannot tell them, and what it does not claim

- **Anchoring is stated, not yet documented here.** The section above is the founder's own account: thirty years in the UK, a UK exit, a UK-registered trading company behind the work. It is first-hand rather than drawn from a public record on this site, and the corporate detail the fund would want, filings, cap table, team, is a conversation. The fund's own [contact form](https://www.sovereignai.gov.uk/about) or [the author's](../about/index.md) are the routes to it.
- **Certification.** sgit holds no compliance certification of any kind, and [the page that says so](../use-cases/health-regulated.md) says it first. The AIUC-1 and DSIT vaults are independent and derived, and each one states that on its own front page. Nothing here is a conformance claim.
- **Stage.** The fund invests in companies, typically alongside other investors. [sgit.ai for investors](../investors/index.md) is published in the open and leaves the ask visibly empty until the founder states it. This page is about partnership shapes that exist independently of an investment.
- **The fit is partial, on purpose.** Of five frontiers we serve one directly and touch one other. Of four procurement challenge areas we answer one. We would rather be precisely useful in the assurance layer than vaguely relevant to all five.
- **What is still a design.** The performance page notes what it did not measure, the newsroom design says which of its economics run nowhere, and [the sheet of what exists against what is still a design](../summit/startups.md) is kept honest for exactly this kind of reader.

## If you know somebody there

This page is written to be forwarded as it is. It explains what UK Sovereign AI is trying to do, in their words; what has been built, with the read keys to open it; where the two meet, and where they do not; and three concrete shapes a first piece of work could take. Everything on it can be checked by the person who receives it, which is the point. [Who is asking, and how to reach them →](../about/index.md)

[← Partnerships](index.md)[Open Licence to Operate →](../demos/vaults/licence-to-operate/index.md)



==============================================================================
# Who holds the keys? A call for collaboration on vault key management, sgit.ai

> An open call to password managers, identity providers and platform credential managers. sgit vaults are encrypted on the client and opened in a browser with one key, and keys now multiply faster than people can manage them by hand. We would rather use a key manager than build one. The page explains sgit for someone new to it, states what we are looking for (something that exists, a joint pilot, or an open specification), the requirements (browser first, key kinds kept apart, release only on approval, end-to-end sharing, names in plain words that are addresses and never keys, revocation, keys for agents), a sketch of the share flow, why the old word-based token was removed, and what we would bring.
>
> Page: https://sgit.ai/partnerships/vault-key-management.html

[Home](../index.md) / [Partnerships](index.md) / Vault key management

A call for collaboration · public material only · 24 September 2026

# Who holds the keys? A call for collaboration on vault key management

**We are looking for a key manager, not building one.** [sgit.ai](../index.md) makes encrypted vaults: folders whose contents are locked on the owner's device before they are stored anywhere, and which open in a browser for anyone holding the right key. That works. What does not scale is the key itself. Every vault has one, people now hold dozens, AI agents are starting to create them by the hundred, and today those keys travel by copy and paste. Storing, indexing, sharing and taking back secrets is what password managers and identity providers already do well. This page asks whether one of you already has a way for us to use that, in the browser, and if not, whether you would like to build it with us in the open.

**If this is the first time you have heard of sgit**, that is expected, and the page is written for you. It starts with the short version, then what we are asking for and the requirements, then [what sgit is in two minutes](#sgit), then diagrams of how it could work, and only then the detail and the evidence. Nothing here is confidential and there has been no conversation with any organisation named on it. It can be forwarded as it is.

## In short

- **The product.** sgit is git for encrypted vaults: a versioned folder, encrypted on the client, stored on any host that cannot read it, and opened in a browser with one string, the key. It is open source under Apache-2.0.
- **The problem.** The key is the whole access control. There is no account, no reset and no revocation list. Lose it and the vault is gone; leak it and the only remedy is to re-encrypt under a new one. That is a key management problem, and it grows with every vault.
- **Why not solve it ourselves.** We could keep keys inside another vault, and we have designs for that, but the first key still has to live somewhere. Key management is a discipline of its own, with recovery, device sync, sharing, audit and enterprise policy, and it is already done well by people who do nothing else.
- **What we are asking for.** A way, in the browser, for a person to keep their vault keys in the password manager or identity system they already use, to open a vault with a passkey or a biometric prompt, and to share a vault with someone else by sending a short name in plain words rather than the key.
- **The one hard rule.** The words must be an address, never the key. sgit once shipped a word-based token that *was* the key, and [removed it](#history) when a review showed it could be guessed in a fraction of a second. The name has to resolve only inside the recipient's own key manager.
- **Who we would like to hear from.** Password managers, enterprise identity providers, the credential managers built into operating systems and browsers, and hardware key makers. The best outcome is that you already have this and tell us.
- **What we bring.** An open reference integration, published crypto test vectors, a key format designed for secret scanners, thirty-six published vaults to test against, and a willingness to write the specification in public so it is not tied to either of us.

## The opportunity

Password managers solved one problem so well that people stopped noticing it: the long random string that has to be stored somewhere safe, typed nowhere, shared carefully and taken back when someone leaves. Passkeys moved the same machinery from logging in to proving who you are. Client-side encryption brings a third kind of secret into daily use, the key that opens a piece of data rather than an account, and at the moment nothing in the browser treats it as a first-class item.

Today, vault keys travel by hand. The gap at the bottom is the thing this page is asking for.

Three things make this worth doing now rather than later.

| **The number of keys is growing fast** | One person running a few projects now holds a vault per project, per client and per shared folder, and a separate read key for each person they share with, so access can be told apart. [Thirty-five vaults are published on this site alone](../demos/vaults/index.md), each with its own key. |
|---|---|
| **Agents are starting to make vaults** | An AI agent that builds a website for a customer, writes up a penetration test or keeps a board pack can hand the result over as a vault. [Agent as Webmaster](../demos/vaults/agent-webmaster/index.md) is a business plan built on exactly that. Every one of those hand-overs is a key that has to go to a person, safely, and every agent doing the work needs a key it should not be able to paste anywhere. |
| **The pattern is not specific to sgit** | Any end-to-end encrypted document, folder or dataset opened in a browser has the same need: a key for the data, held by the user, released to a page only when they agree. Whoever makes that easy for sgit makes it easy for the category. |

## What we are looking for

In order of preference.

| What | What it would look like |
|---|---|
| **1 · Something that already exists** | An item type, an extension API, a browser capability or an SDK in your product that lets a web page ask for a stored secret by name, with the user's approval, without the page ever seeing the rest of the store. If you have this, we would like to integrate with it and write up how, publicly, as the worked example. |
| **2 · A pilot built together** | If the pieces exist but not the whole, a small joint pilot: your manager stores sgit keys as their own item type, shares them between your users the way it already shares passwords, and releases them to an sgit page on approval. We would do the sgit side, you would do yours, and both would be open to inspect. |
| **3 · A specification written in public** | If this is better solved as a standard than as a product feature, a short open specification for storing, naming and releasing data keys in the browser, with sgit as the first implementation and a reference test suite, so that any key manager can support any client-side encrypted app. |

We are not asking for an investment, an exclusive arrangement or anyone's customer data. We are asking for the conversation, and for the answer to the question *"is there something I can use?"*

## The requirements

Written in plain terms first. [The technical detail is further down.](#detail)

| Requirement | Why it matters |
|---|---|
| **Must · Works in the browser** | sgit vaults open in a browser tab with nothing installed. The key manager should meet that: a browser extension is fine as a first step, a capability built into the browser or the operating system is the goal. |
| **Must · Knows what kind of key it holds** | An sgit key declares itself: a vault key reads and writes, a read key only reads, and a public read key is published on purpose. The manager should keep them apart, and must never hand a read-and-write key to a page that only asked to read. |
| **Must · Releases a key only when the user agrees** | With a passkey, biometric or device prompt; only to the site that asked; only into that page's memory; and never to the storage host, which in sgit's design never sees a key at all. |
| **Must · Shares end to end** | Sharing a vault with someone means your manager passing the key to theirs, encrypted so that nobody in between, including the manager's own servers, can read it. Most password managers already share passwords this way. |
| **Must · Names are addresses, not keys** | The recipient gets a short name in plain words, easy to read out or paste, that their own manager resolves to the key it was given. Guessing or overhearing the name must give nothing, because the name is not derived from the key and the key is not derived from the name. |
| **Must · Access can be taken back** | Stopping a share, or letting it expire, is the manager's job. Making the old key useless for good is sgit's job, by rotating it. The two should be designed to work together. |
| **Should · An index of what I hold** | The list of vaults a person can open, with a name, whether they can read or write, who shared it and when. Today nobody has this list, including us. |
| **Should · Keys for agents, scoped and time-limited** | An AI agent should get a read key for one vault for one task, approved by a person, recorded, and expiring on its own. [RiskMandate.ai](https://riskmandate.ai/) is built around exactly this question: what an agent can reach against what it was authorised to do. |
| **Should · Recovery** | sgit has no recovery by design. A key manager with account recovery gives the owner one, without giving sgit or the host a way in. |
| **Should · No lock-in** | Keys should move between managers in an open format, and any key manager should be able to support any client-side encrypted app, not only ours. |
| **Nice · A record of use** | When a key was released, to which page, on which device. It is the audit trail that client-side encryption otherwise cannot give an organisation. |

## sgit in two minutes

You do not need to know git or cryptography for the rest of this page, only four ideas.

What a vault is, and where the key sits. The three kinds of key at the bottom are what a key manager would hold.

| **A vault is a folder with history** | Files, every earlier version of them, branches and merges, the way a developer's git repository works, and it can carry its own small application so it opens as a page rather than a file list. |
|---|---|
| **It is locked before it leaves your device** | Every file, name and commit message is encrypted on your machine or in your browser. What gets stored is ciphertext under meaningless identifiers. [The security model](../security/index.md) states exactly what the host can and cannot see. |
| **Any host will do** | Our server, your own, a cloud bucket or a plain static site behind a CDN. [It deploys to Docker, AWS, GCP or a static host](../deploy/index.md), and moving a vault between them is a copy, because none of them can read it. |
| **One string opens it** | The key. Whoever holds it can open the vault in a browser with no account and nothing installed. That is what makes vaults easy to hand over, and it is exactly why the key needs looking after. |

The fastest way to understand it is to open one. [The DSIT AI Risk Toolkit vault](../demos/vaults/dsit-ai-risk-toolkit/index.md) opens in the browser from its page, with its public read key printed underneath, and so does every vault in [the list](../demos/vaults/index.md).

## How it could work

A sketch, not a design. We would expect a key manager's team to improve every step of it.

Sharing a vault by name. The key moves only between the two key managers; the words move by any channel at all.

| Workflow | What the person does | What happens underneath |
|---|---|---|
| **Open a vault I hold** | Clicks a vault in their key manager, or opens a vault page and approves a prompt. | The page asks the browser for the key for this vault; the manager checks the site and the key kind, asks the person, and releases the key into the page's memory. The page fetches ciphertext and decrypts it locally. |
| **Share with a person** | Chooses "share, read only" and the recipient, then sends them the three-word name however they like. | The manager derives or selects a read key, never the vault key, and passes it to the recipient's manager end to end. The name is a random label attached to that shared item, meaningful only inside the recipient's store. |
| **Take it back** | Stops the share, or lets it expire. | The manager removes the item from the recipient's store. For a clean break, the owner rotates the vault in sgit, and the manager updates the remaining holders with the new key. |
| **Give an agent access** | Approves a request from an agent to read one vault for one task. | A read key scoped to that vault, released for a stated time, with the release recorded. The agent never sees the vault key and cannot pass on what it was not given. |
| **Create a new vault** | Creates it in sgit, from the command line or the browser. | The new vault key goes straight into the manager, before anything is published. Our own [publishing method](../demos/vaults/publishing.md) records for every published vault whether its write key is escrowed or lost, because a vault whose write key is lost is frozen: it can never be corrected. |

### Building blocks that may already be there

We are not experts in your stack, and we would like to be told what we have missed. These are the public pieces that look relevant from where we stand.

- **The WebAuthn PRF extension.** Part of the WebAuthn specification, it lets a passkey produce a secret that a web page can turn into an encryption key, after a user-verification prompt. Some password managers already use it to unlock their own encrypted stores. It could wrap vault keys so they are only usable after a passkey prompt.
- **The Credential Management API.** The browser's existing way for a page to ask for a stored credential. A new credential type for data keys, or an extension of an existing one, is the shape a built-in answer might take.
- **Password manager sharing.** The end-to-end sharing most managers already have for passwords and notes, between people and within an organisation, is the channel for step two in the diagram above.
- **The FIDO Alliance credential exchange work.** Specifications for moving credentials between managers securely, which is the no-lock-in requirement from the other side.

## Who we would like to hear from

Organisations are named below only as examples of the kind of team we mean. There has been no conversation with any of them, and nothing here is a claim about what their products do or do not support.

| Kind of organisation | For example | What they would bring |
|---|---|---|
| **Password managers** | 1Password, Bitwarden, Proton Pass, Dashlane, Keeper, KeePassXC | The store, the sharing, the browser extension and the people who already trust them with their secrets. |
| **Enterprise identity providers** | Okta, Microsoft Entra ID, Ping Identity | Policy: who in an organisation may hold which vault key, joiners and leavers, and the audit trail a regulated business needs. |
| **Platform credential managers** | The password and passkey managers built into Apple, Google and Microsoft platforms and browsers | The native answer: a capability every web page can use, with no extension to install. |
| **Hardware key makers** | Yubico and other FIDO authenticator makers | Keys that never leave a device, for the vault keys that matter most. |

## What is in it for a partner

- **A new kind of item.** Data keys, alongside passwords and passkeys, for any client-side encrypted app, with sgit as the first one and the published vaults as the test bed.
- **The agent era, on your platform.** Scoped, expiring, approved keys for AI agents are a problem every organisation is about to have, and a key manager is the natural place to answer it.
- **Work done in the open.** Everything on our side is Apache-2.0 and public, so the integration can be inspected, copied and cited, and nobody is locked in, including you.
- **A partner that stays out of your lane.** We make the vaults. We have no plans to build a key manager, and this page exists precisely so that we do not have to.

## What we bring

| **An open reference integration** | The sgit side of the pilot, in the Apache-2.0 client and the browser viewer, written so another key manager could plug into the same interface. |
|---|---|
| **Crypto that is specified and tested** | AES-256-GCM, HKDF-SHA256 and PBKDF2, with test vectors that the command-line client and the browser must match byte for byte. Keys are derived locally; the host never holds one. |
| **Keys that say what they are** | Every sgit key carries a prefix naming its kind: `sgit_private_vault_`, `sgit_private_read_` or `sgit_public_read_`. One secret-scanner rule, `sgit_private_`, catches every private key type, and a published read key cannot be mistaken for a leak. |
| **Real vaults to test against** | [Thirty-five published vaults](../demos/vaults/index.md) across security, regulation, business plans and applications, each with a public read key, plus [the catalogue](../demos/vaults/catalogue/index.md), a vault that lists vaults, which is the closest thing today to the index a key manager would keep. |
| **The failures, written down** | [What to do if a vault key is exposed](../case-studies/exposed-vault-key.md), [the publishing method](../demos/vaults/publishing.md) with the mistake behind each rule, and [when not to use sgit](../docs/limitations.md). A key manager partner should know the edges before the first call. |

## The detail

### The keys, exactly

A vault key is a passphrase and a vault identifier joined by a colon, and displayed with its prefix: `sgit_private_vault_<passphrase>:<vault id>`. From it, the client derives a read key and a write key locally, using PBKDF2 with 600,000 iterations and a per-vault salt. The read key alone can open and verify the vault but not change it, and it is what gets shared. A read key that is deliberately published carries `sgit_public_read_` instead of `sgit_private_read_`: the same bytes, a different declaration, so a scanner alert on `sgit_private_` stays meaningful. The vault identifier is a short opaque string by design, because a human-readable identifier would leak meaning into server and CDN logs, which is one more reason the friendly name has to live in the key manager and not in the vault.

### Why the words cannot be the key

sgit used to have exactly the friendly name this page asks for. An earlier share token was two words and four digits, and the vault's encryption keys were derived from it directly. It was easy to read out and easy to type. A security review on 6 August 2026 found that it carried about thirty bits of entropy and could be recovered from public data in around a tenth of a second on a GPU, and the feature was removed from the client entirely on 12 August 2026 rather than patched. The lesson is the requirement: **a name people can say out loud cannot also be the secret**. It can only be a pointer to one, resolved by something that already holds the secret and already knows who is asking. That is a key manager.

### Why a vault of keys is not enough

We can, and will, keep keys inside vaults: a vault that holds the read keys for a set of other vaults is a natural index, and [the catalogue](../demos/vaults/catalogue/index.md) is a public version of it. But the key to that vault still has to be kept somewhere, and so on down. At the bottom of every chain there is one secret that a person has to hold, recover, and use on a new device, and that is the problem password managers and identity providers were built for.

### What exists today, and what does not

| Exists and runs | Does not exist yet |
|---|---|
| Vault keys, read keys and public read keys with self-declaring prefixes. Local derivation. Browser opening from a read key with nothing installed. Thirty-five published vaults. Guidance to keep the vault key in a password manager, which is what this page wants to make first-class. | Any integration with any key manager. Revocation, expiry or a rotation workflow in the product: rotation is a manual re-encryption today, as [the limitations page](../docs/limitations.md) says. The word-name scheme. Agent-scoped keys. All of these are what a collaboration would build. |

## What this page does not claim

- **We have not spoken to anyone named here.** The examples are categories made concrete, and the page makes no statement about any product's features or roadmap.
- **Your product may already do this.** If so, that is the best outcome, and we would like to be told and to write it up as the worked example.
- **The flow is a sketch.** It shows the shape of the requirement, not a protocol. The step where a name is resolved, in particular, is where a key manager's team would know far more than we do.
- **sgit holds no certification.** It is open-source software with a stated security model and stated limits, not an audited product, and [the page for regulated sectors](../use-cases/health-regulated.md) says so first.

## If you work on this, or know someone who does

This page is written to be forwarded as it is. It explains what sgit is for someone who has never heard of it, what we are asking for, the requirements, how it could work, and what we would bring, and every claim on it links to something that can be opened. It is published by the founder of sgit.ai and [RiskMandate.ai](https://riskmandate.ai/), through [The Cyber Boardroom Limited](https://thecyberboardroom.com) in the UK. [Who is asking, and how to reach them →](../about/index.md)

[← UK Sovereign AI](sovereign-ai.md)[All partnerships →](index.md)



==============================================================================
# sgit runs on every cloud: proposed partnerships with the cloud platforms, sgit.ai

> What sgit needs from a cloud (mostly storage, a little compute), where it stands today on each (AWS templates in beta, Google Cloud planned, Azure deployed but undocumented, Docker everywhere), the two partnerships in one (vaults in the cloud's environment, and services on top of vaults), why it is good for a cloud, and one page per cloud: AWS, Azure, Google Cloud, IBM Cloud, the European clouds, DigitalOcean, Rackspace and Netlify.
>
> Page: https://sgit.ai/partnerships/cloud-platforms.html

[Home](../index.md) / [Partnerships](index.md) / Cloud platforms

Proposed partnerships · sgit.ai with the clouds · public material only · 24 September 2026

# sgit runs on every cloud. We would like to work with them properly.

**An invitation from our side, published in the open.** [sgit.ai](../index.md) makes encrypted vaults: folders versioned like git, encrypted on the owner's device, stored as ciphertext, and opened in a browser with a key. What it needs from a cloud is mostly storage and a little compute, which means it runs on all of them. Today our story is mostly AWS, for historical reasons and because our startup credits are AWS credits. It should not stay that way. This page, and the page for each cloud linked from it, sets out what vaults bring to a cloud, how the partnership could work, and what we are asking for.

**Nothing on these pages is confidential, and there has been no conversation yet.** Every statement about a cloud comes from its own public pages, linked. Every statement about sgit points at a published vault, the [deployment documentation](../deploy/index.md) or a page on this site. And because sgit is Apache-2.0, **no cloud needs our permission to run it or to build a service on it.** A partnership is about doing that well and together, and it would be the best validation the technology could have.

## In short

- **sgit needs very little from a cloud.** The heavy work, encryption and decryption, happens on the user's device. The cloud holds ciphertext in object storage, and a small stateless API moves it. Readers can even be served from a plain static host behind a CDN, with no server at all.
- **So it can run anywhere.** The server ships as one Docker image, configured only by environment variables. Its durable storage mode targets Amazon S3 today, and most other clouds offer an S3-compatible store, so wiring those in is the obvious next step. It is not documented or tested yet.
- **Our history is AWS.** The AWS templates are written and in beta, and the vault service behind this site's published vaults answers from Amazon S3 behind CloudFront. Google Cloud is documented as planned. The founder has deployed it on Azure and on Google Cloud, but neither is documented yet. That gap is the first thing a partnership would close.
- **There are two partnerships in one.** First, deploying vaults in the cloud's environment, with documentation, reference architectures and a marketplace listing, for customers who already run there. Second, services the cloud or its partners can sell on top of vaults.
- **Vaults are sovereign by construction.** The host only ever holds ciphertext, in whichever region the customer picks, and moving a vault between clouds is a copy. For European clouds, that is the whole pitch.
- **We want to be where customers look.** That means the clouds' marketplaces, their partner programmes, and their startup programmes.

## What sgit needs from a cloud

Mostly storage, a little compute. Everything that needs a key happens on the user's device.

| Piece | What it does | What it needs from a cloud |
|---|---|---|
| **The client** | The `sgit` CLI or a browser. Encrypts every file, file name and commit message before upload, and decrypts on the way back. | Nothing. It runs on the user's machine. |
| **The vault API** | Batch reads and writes of ciphertext objects, plus the write-only [append lanes](../api/append-lanes.md). Stateless: no database, no sessions. | One container or one function. The same image runs on Docker, AWS Lambda, ECS Fargate, EC2, Cloud Run and Heroku, configured only by environment variables. |
| **Storage** | Ciphertext objects under opaque identifiers. Content-addressed objects never change, so they can be cached forever. | Object storage. The server's `s3` mode uses Amazon S3 today. Other clouds' S3-compatible stores are the next step, not yet tested. A `disk` mode runs on any mounted volume, and a `memory` mode serves ephemeral and air-gapped runs. |
| **Readers, optionally** | A published vault can be read from a static host with no API at all: the browser fetches ciphertext and decrypts locally. | A static host and a CDN. The deployment docs name GitHub Pages, S3 with CloudFront, Netlify, Cloudflare Pages, and Cloud Storage with Firebase. |

That is the whole footprint. [The measured cost page](../demos/fractal-graphs/performance.md) puts the estate behind this site at 2,662 files and 295 MB of object storage, measured on 21 September 2026. Storage and egress are the costs. There are no instance hours to speak of.

## Where we are today, honestly

| Target | Status |
|---|---|
| **Docker, anywhere** | Works today. Memory, disk and S3-backed modes, documented in the [deployment docs](../deploy/index.md). |
| **AWS** | The historical home. CloudFormation templates for Lambda (container image with a function URL) and ECS Fargate are written, lint-clean and in beta. There is also an EC2 appliance and runbooks for new accounts and regions. The vault service the published vaults use answers from Amazon S3 behind CloudFront, [sg-compute](https://sg-compute.sgit.ai/) builds agent environments on AWS, and our startup credits are AWS credits. This website itself is served from GitHub Pages. |
| **Google Cloud** | The image is Cloud Run-ready: it honours the injected port and is configured by environment variables. The Cloud Run guide is documented as planned. Durable storage there means either Amazon S3 with cross-cloud credentials, or native Cloud Storage, which is planned. |
| **Microsoft Azure** | Deployed and working in the founder's own tests. It is not documented yet. |
| **Static hosts** | Documented. A published vault reads from any static host behind a CDN. |
| **Everyone else** | Any cloud with a container runtime can run the image today with disk or memory storage. Durable object storage on a non-AWS cloud needs its S3-compatible endpoint wired in, which is not yet documented or tested. Each cloud's page says so. |

## Two partnerships in one

### 1 · Vaults in your environment

For customers who already run on a cloud and want vaults there, in their own account, region and budget. This needs:

- a documented deployment for the cloud's own services, reviewed by someone who knows them;
- a reference architecture a customer's architect can approve;
- a template the customer can launch in one step;
- a marketplace listing, so procurement can buy through the channel it already uses.

We will write the documentation either way. With a partner it gets reviewed, tested on credits, and published where the cloud's customers look.

### 2 · Services on top of vaults

The more interesting half. Because sgit is open source, a cloud or any of its consulting partners can build and sell services on it without asking. Some that follow directly from what is published here:

| Service | What the customer gets | Worked example on this site |
|---|---|---|
| **A managed vault service** | Vaults run for them, in their account, where the operator never holds a key. | [Deployment docs](../deploy/index.md) |
| **Encrypted data rooms** | A deal, a board or an audit shared as one vault with a read key per party, and full history. | [The board, as a vault](../demos/vaults/board/index.md) |
| **Agent handover** | The output of an AI agent delivered as a vault: the result, its history and its app, in one read key. | [A penetration test, delivered as a vault](../demos/vaults/pentest-report/index.md) |
| **Connector twins** | A journal and replay of everything an agent did through Gmail, Calendar or Slack, with a revert plan. | [Connector Twin](../demos/vaults/connector-twin/index.md) |
| **Evidence and compliance vaults** | Regulation, controls and evidence as a versioned, hash-verified record an auditor can open. | [AIUC-1 conformance](../demos/vaults/aiuc-1-conformance/index.md), [Regulation Graph](../demos/vaults/regulation-graph/index.md) |
| **Encrypted publishing** | Documentation and sites served from a static host, readable only with a key, and updated with a push. | [Deploy Docs](../demos/vaults/deploy-docs/index.md) |

## Why it is good for a cloud

- **It is storage-shaped.** Every vault is object storage and egress in the cloud's own billing, growing with use, with no competing database or runtime to displace.
- **It lives in the customer's account.** Nothing about sgit pulls data out of the cloud or into ours.
- **It answers the sovereignty question at the data layer.** The host holds ciphertext it cannot read, in the region the customer picks, so a cloud can say that and have it be true.
- **It gives agents somewhere to put their work.** Every cloud now sells agent platforms. Those agents need a handover format that a person can open, check and keep.
- **It carries no vendor risk for the cloud's customers.** Apache-2.0, with the code, the plans and the investor materials public.

## The pages, one per cloud

Each page stands on its own, so it can be sent to someone who works there. Each says where we are with that cloud, how vaults map onto its services, what a partnership could be, and what we are asking for.

| Cloud | Why them first | The page |
|---|---|---|
| **AWS** | Our historical home and the only cloud with templates written. The European Sovereign Cloud makes the sovereignty argument concrete. | [**The AWS page →**](aws.md) |
| **Microsoft Azure** | Deployed by the founder and working, but undocumented. The biggest gap between what runs and what is written down. | [**The Microsoft Azure page →**](azure.md) |
| **Google Cloud** | The image is already Cloud Run-ready and the guide is planned. Cloud Marketplace now lists AI agents as well as containers. | [**The Google Cloud page →**](google-cloud.md) |
| **IBM Cloud** | IBM Sovereign Core became generally available in May 2026. Enterprise customers with regulated data are exactly the vault use case. | [**The IBM Cloud page →**](ibm-cloud.md) |
| **The European clouds** | OVHcloud, Scaleway, Hetzner, IONOS and STACKIT. S3-compatible storage everywhere, and sovereignty as the reason customers choose them. | [**The European clouds page →**](european-clouds.md) |
| **DigitalOcean** | S3-compatible Spaces with a built-in CDN, simple App Platform, and a Marketplace that explicitly invites open-source projects. | [**The DigitalOcean page →**](digitalocean.md) |
| **Rackspace Technology** | A managed-services partner across the hyperscalers, with UK sovereign clouds for government, healthcare and police. | [**The Rackspace Technology page →**](rackspace.md) |
| **Netlify** | The static host a published vault needs, already named in our deployment docs. Encrypted sites on a CDN, updated with a push. | [**The Netlify page →**](netlify.md) |

## What we ask of every cloud

1. **A technical review** of the deployment guide for your platform, by someone who knows it, before we publish it.
2. **Credits to test on**, so the guides are run end to end rather than written from documentation.
3. **A route into your marketplace** for the open-source server, and later for vault products built on it.
4. **An introduction** to your startup and ISV partner teams.
5. **A first customer conversation**, where one of your customers needs encrypted handover or sovereign storage.

## What these pages do not claim

- **No cloud has endorsed sgit**, and we have not spoken to any of them about this. Where a page describes a programme or a product, it quotes the cloud's own page.
- **"Should work" is not "tested".** Each page says which it is. Docker works today, the AWS templates are in beta, and the founder's Azure and Google Cloud deployments are not yet written up.
- **sgit holds no certification.** It is open-source software with a stated [security model](../security/index.md) and stated [limits](../docs/limitations.md).

## If you work at one of these clouds

These pages are written to be forwarded as they are. Everything on them can be checked by the person who receives them. [Who is asking, and how to reach them →](../about/index.md) The same argument, from the model side, is on [the AI providers page](ai-providers.md).

[← Partnerships](index.md)[AI providers →](ai-providers.md)



==============================================================================
# A proposed partnership between sgit.ai and AWS

> We would like to work with AWS more closely, and we are already most of the way there. sgit's deployment templates were written for AWS first, the vault service behind the vaults published on this site answers from Amazon S3 behind CloudFront, and our startup credits are AWS credits. What is missing is the partnership: a reviewed reference architecture, a listing in AWS Marketplace, and a route to AWS customers who need encrypted handover or sovereign storage.
>
> Page: https://sgit.ai/partnerships/aws.html

[Home](../index.md) / [Partnerships](index.md) / [Cloud platforms](cloud-platforms.md) / AWS

A proposed partnership · sgit.ai with AWS · public material only · 24 September 2026

# A proposed partnership between sgit.ai and AWS

**We would like to work with AWS more closely, and we are already most of the way there.** sgit's deployment templates were written for AWS first, the vault service behind the vaults published on this site answers from Amazon S3 behind CloudFront, and our startup credits are AWS credits. What is missing is the partnership: a reviewed reference architecture, a listing in AWS Marketplace, and a route to AWS customers who need encrypted handover or sovereign storage.

**Nothing on this page is confidential, and there has been no conversation yet.** Every statement about AWS comes from its own public pages, linked. Every statement about sgit points at the [deployment documentation](../deploy/index.md), a published vault or a page on this site. sgit is Apache-2.0, so AWS does not need our permission to run it or to build on it. A partnership is about doing that well and together. The general argument is on [the cloud platforms page](cloud-platforms.md).

## In short

- **sgit fits AWS naturally.** Encrypted vaults are ciphertext in Amazon S3, a small stateless API on Lambda or Fargate, and optionally a static copy behind CloudFront.
- **The templates exist.** CloudFormation for Lambda (a container image with a function URL) and for ECS Fargate is written, lint-clean and in beta, with an EC2 appliance and runbooks for new accounts and regions.
- **The sovereignty story is real on AWS.** The [AWS European Sovereign Cloud](https://aws.amazon.com/blogs/aws/opening-the-aws-european-sovereign-cloud) has been generally available since 14 January 2026, in Brandenburg, with S3, Lambda and ECS. A vault there is ciphertext in a sovereign region, readable by nobody but the key holder.
- **What we would like:** a review of the templates, a listing in [AWS Marketplace](https://aws.amazon.com/partners/marketplace/), a place in the [AWS Partner Network](https://aws.amazon.com/partners/), and a first customer conversation.

## How vaults map onto AWS

| sgit needs | On AWS | Status |
|---|---|---|
| **Object storage** | Amazon S3 | Works today: the server's `s3` storage mode, with buckets named per account and region. |
| **A small stateless API** | AWS Lambda (container image and function URL), ECS Fargate, or an EC2 appliance | CloudFormation templates written and in beta. |
| **Static readers** | S3 and CloudFront | Documented in the deployment docs. |
| **Sovereign region** | AWS European Sovereign Cloud | Not yet tested. S3, Lambda and ECS are available there, so the same templates should apply. |
| **Agent environments** | Ephemeral compute | [sg-compute](https://sg-compute.sgit.ai/) builds agent environments on AWS today. |

## Where we are with AWS today

AWS is where sgit grew up, for two reasons that have nothing to do with preference: the founder has built on AWS for years, and the startup credits sgit has are AWS credits. The result is that the AWS path is the most complete one: the templates, the runbooks, the S3 storage mode and the published vaults all run there. That is also why this page asks for more than documentation. The next step on AWS is not whether it works but whether AWS customers can find it and buy it through the channel they already use.

## What a partnership could be

| Shape | What it would be | On their side |
|---|---|---|
| **1 · A reviewed reference architecture** | The Lambda and Fargate templates reviewed by an AWS solutions architect, published as a reference architecture, and tested end to end in a standard region and in the European Sovereign Cloud. | A partner solutions architect, and credits for the testing. |
| **2 · A Marketplace listing** | The open-source vault server as a free container product in AWS Marketplace, launched into the customer's own account. AWS Marketplace accepts free products and container delivery. | AWS Marketplace, through the AWS Partner Network. |
| **3 · Services on top** | Encrypted data rooms, agent handover and connector twins, offered by AWS consulting partners on their customers' accounts. Every one is published here as a working vault. | The AWS Partner Network's consulting partners. |

## What we are asking AWS for

1. A review of the CloudFormation templates by someone who knows Lambda and Fargate well.
2. Help testing in the AWS European Sovereign Cloud.
3. A route into [AWS Marketplace](https://aws.amazon.com/partners/marketplace/) for the open-source server as a free container product.
4. Membership of the [AWS Partner Network](https://aws.amazon.com/partners/) and an introduction to the ISV team.
5. Continued support through [AWS Activate](https://aws.amazon.com/startups/credits/), which is how the AWS path was built.

## What this page does not claim

- **No endorsement.** AWS has not endorsed sgit, and we have not spoken to anyone there about this. Programme and product descriptions quote AWS's own pages as of 24 September 2026.
- **Beta means beta.** The Lambda and Fargate templates are written and lint-clean; they are not yet a reviewed reference architecture.
- **The sovereign region is untested by us.** We say the templates should apply there because the services they use are available, not because we have run them.

## If you work at AWS

This page is written to be forwarded as it is, and everything on it can be checked by the person who receives it. [Who is asking, and how to reach them →](../about/index.md)

[← Cloud platforms](cloud-platforms.md)[Microsoft Azure →](azure.md)



==============================================================================
# A proposed partnership between sgit.ai and Microsoft Azure

> sgit runs on Azure. We just have not written it down yet. The founder has deployed the vault server on Azure and it works, but the published documentation covers Docker, AWS, Google Cloud and static hosts, not Azure. We would like to close that gap with Microsoft: a documented, reviewed deployment on Azure services, a listing in Microsoft Marketplace, and a route to the many organisations whose data already lives in Azure and Microsoft 365.
>
> Page: https://sgit.ai/partnerships/azure.html

[Home](../index.md) / [Partnerships](index.md) / [Cloud platforms](cloud-platforms.md) / Microsoft Azure

A proposed partnership · sgit.ai with Microsoft Azure · public material only · 24 September 2026

# A proposed partnership between sgit.ai and Microsoft Azure

**sgit runs on Azure. We just have not written it down yet.** The founder has deployed the vault server on Azure and it works, but the published documentation covers Docker, AWS, Google Cloud and static hosts, not Azure. We would like to close that gap with Microsoft: a documented, reviewed deployment on Azure services, a listing in Microsoft Marketplace, and a route to the many organisations whose data already lives in Azure and Microsoft 365.

**Nothing on this page is confidential, and there has been no conversation yet.** Every statement about Microsoft Azure comes from its own public pages, linked. Every statement about sgit points at the [deployment documentation](../deploy/index.md), a published vault or a page on this site. sgit is Apache-2.0, so Microsoft Azure does not need our permission to run it or to build on it. A partnership is about doing that well and together. The general argument is on [the cloud platforms page](cloud-platforms.md).

## In short

- **The vault server is one container.** On Azure that is Azure Container Apps or Azure Functions, configured only by environment variables.
- **Storage is the work.** Azure Blob Storage is not natively S3-compatible, and the server's durable storage mode targets Amazon S3. On Azure today that means a disk volume, S3 with cross-cloud credentials, or a native Blob Storage backend, which would be the right answer and is the main engineering in this partnership.
- **Sovereignty fits.** Microsoft completed the [EU Data Boundary](https://blogs.microsoft.com/on-the-issues/2025/02/26/microsoft-completes-landmark-eu-data-boundary-offering-enhanced-data-residency-and-transparency/) in February 2025 and offers [Microsoft Sovereign Cloud](https://learn.microsoft.com/en-us/azure/azure-sovereign-clouds/microsoft-sovereign-cloud). A vault adds the layer that makes it hold for the data itself: the host only ever sees ciphertext.
- **What we would like:** engineering help on the Blob Storage backend, a documented deployment, a place in [ISV Success](https://learn.microsoft.com/en-us/partner-center/membership/isv-success), and a listing in [Microsoft Marketplace](https://learn.microsoft.com/en-us/partner-center/marketplace-offers/marketplace-containers).

## How vaults map onto Azure

| sgit needs | On Microsoft Azure | Status |
|---|---|---|
| **A small stateless API** | Azure Container Apps, or Azure Functions | Working in the founder's own deployment; not yet documented. |
| **Object storage** | Azure Blob Storage | Not S3-compatible. Needs a native backend, or a disk volume or cross-cloud S3 in the meantime. |
| **Static readers** | Azure Static Web Apps, Azure Front Door | Should work, as for any static host. Not tested by us. |
| **Sovereign data** | EU Data Boundary, Microsoft Sovereign Cloud | Complementary: the host holds ciphertext only, in the region chosen. |
| **Data that already lives in Microsoft 365** | Agents with Microsoft 365 connectors | RiskMandate.ai has published a behaviour policy for Claude with Microsoft 365, and the risk side is being written there. |

## Where we are with Microsoft Azure today

Azure is the clearest case of something that works and is not yet written down. The deployment was done and it ran; what it lacks is a guide, a storage backend that uses Blob Storage natively, and a review by someone who knows Azure. The reason it has not been done is simply that our credits and our history are on AWS. That is a gap we would rather close with Microsoft than around it.

## What a partnership could be

| Shape | What it would be | On their side |
|---|---|---|
| **1 · A native Blob Storage backend** | A storage mode for Azure Blob Storage in the open-source server, so a vault on Azure keeps its ciphertext in Azure with no cross-cloud credentials. | An engineer who knows the Blob Storage APIs, and credits to test on. |
| **2 · A documented Azure deployment** | A guide and a template for Container Apps with Blob Storage, reviewed and published in the deployment docs next to AWS and Google Cloud. | A technical reviewer. |
| **3 · A Marketplace offer** | The open-source server as a free container offer in Microsoft Marketplace, which supports Free and BYOL container billing. | ISV Success, part of the Microsoft AI Cloud Partner Program. |

## What we are asking Microsoft Azure for

1. Engineering help, or a reviewer, for a native Azure Blob Storage backend.
2. A technical review of the Azure deployment guide before we publish it.
3. A place in [ISV Success](https://learn.microsoft.com/en-us/partner-center/membership/isv-success) and a route into Microsoft Marketplace.
4. Credits through [Microsoft for Startups](https://www.microsoft.com/en/startups), so the Azure path gets the same testing the AWS path had.
5. An introduction to a customer who needs encrypted handover inside an Azure estate.

## What this page does not claim

- **No endorsement.** Microsoft Azure has not endorsed sgit, and we have not spoken to anyone there about this. Programme and product descriptions quote Microsoft Azure's own pages as of 24 September 2026.
- **"Working" means the founder's own deployment.** It is not documented, not reviewed, and does not yet use Blob Storage natively.

## If you work at Microsoft Azure

This page is written to be forwarded as it is, and everything on it can be checked by the person who receives it. [Who is asking, and how to reach them →](../about/index.md)

[← AWS](aws.md)[Google Cloud →](google-cloud.md)



==============================================================================
# A proposed partnership between sgit.ai and Google Cloud

> We would like to finish the Google Cloud path with Google. The vault server image is already Cloud Run-ready, the Cloud Run guide is written down as planned, and the founder has deployed it on Google Cloud. What is missing is native Cloud Storage support, a reviewed guide, and a listing in Google Cloud Marketplace, which accepts open-source container images and, now, AI agents.
>
> Page: https://sgit.ai/partnerships/google-cloud.html

[Home](../index.md) / [Partnerships](index.md) / [Cloud platforms](cloud-platforms.md) / Google Cloud

A proposed partnership · sgit.ai with Google Cloud · public material only · 24 September 2026

# A proposed partnership between sgit.ai and Google Cloud

**We would like to finish the Google Cloud path with Google.** The vault server image is already Cloud Run-ready, the Cloud Run guide is written down as planned, and the founder has deployed it on Google Cloud. What is missing is native Cloud Storage support, a reviewed guide, and a listing in Google Cloud Marketplace, which accepts open-source container images and, now, AI agents.

**Nothing on this page is confidential, and there has been no conversation yet.** Every statement about Google Cloud comes from its own public pages, linked. Every statement about sgit points at the [deployment documentation](../deploy/index.md), a published vault or a page on this site. sgit is Apache-2.0, so Google Cloud does not need our permission to run it or to build on it. A partnership is about doing that well and together. The general argument is on [the cloud platforms page](cloud-platforms.md).

## In short

- **Cloud Run is the natural home.** The image honours the injected port and is configured only by environment variables, as Cloud Run expects.
- **Storage is the step to take.** Cloud Storage offers S3 interoperability through its XML API with HMAC keys, which may be enough for the server's S3 mode; a native backend is planned. Neither is tested by us yet.
- **The marketplace fits both halves.** [Google Cloud Marketplace](https://docs.cloud.google.com/marketplace/docs/partners/offer-products) lists open-source container images, and partner agents listed there appear in the Gemini Enterprise Agent Gallery.
- **What we would like:** a reviewed Cloud Run guide, Cloud Storage support, a place in [Partner Advantage](https://cloud.google.com/partners/become-a-partner), and a Marketplace listing.

## How vaults map onto Google Cloud

| sgit needs | On Google Cloud | Status |
|---|---|---|
| **A small stateless API** | Cloud Run | The image is Cloud Run-ready. The guide is documented as planned; the founder has run it. |
| **Object storage** | Cloud Storage | S3 interoperability through the XML API may be enough for the server's S3 mode. Not tested. A native backend is planned. |
| **Static readers** | Cloud Storage with Cloud CDN, or Firebase Hosting | Cloud Storage with Firebase is named in the static hosting guide. |
| **Sovereign data** | [Google Cloud's sovereign offerings](https://cloud.google.com/sovereign-cloud) | Complementary: the host holds ciphertext only. |
| **Agents** | Gemini, and the Gemini Enterprise Agent Gallery | See [the Google Gemini page](google-gemini.md) for the model side. |

## Where we are with Google Cloud today

Google Cloud is the second-best documented path after AWS: the image is ready for Cloud Run and the guide is on the plan. The founder has deployed it there. What stands between that and a customer running vaults on Google Cloud is storage, a review, and a listing.

## What a partnership could be

| Shape | What it would be | On their side |
|---|---|---|
| **1 · Finish the Cloud Run path** | A reviewed Cloud Run guide with Cloud Storage, tested end to end, in the deployment docs. | A reviewer and credits. |
| **2 · A Marketplace listing** | The server as an open-source container image in Google Cloud Marketplace, and later a vault agent listed through the Agent Gallery. | Partner Advantage, Build engagement. |
| **3 · Gemini and vaults** | A vault connector for Gemini CLI and Google's agent products, so agent work lands in a vault on Google Cloud. | See the Gemini page. |

## What we are asking Google Cloud for

1. A technical review of the Cloud Run guide, and help confirming Cloud Storage through its S3 interoperability.
2. A place in [Partner Advantage](https://cloud.google.com/partners/become-a-partner) and a route into Google Cloud Marketplace.
3. Credits through the [Google for Startups Cloud Program](https://cloud.google.com/startup).
4. An introduction to the team behind the Gemini Enterprise Agent Gallery.

## What this page does not claim

- **No endorsement.** Google Cloud has not endorsed sgit, and we have not spoken to anyone there about this. Programme and product descriptions quote Google Cloud's own pages as of 24 September 2026.
- **Cloud Storage through the S3 interoperability layer is untested by us.** It is the obvious first thing to try, not a claim that it works.

## If you work at Google Cloud

This page is written to be forwarded as it is, and everything on it can be checked by the person who receives it. [Who is asking, and how to reach them →](../about/index.md)

[← Microsoft Azure](azure.md)[IBM Cloud →](ibm-cloud.md)



==============================================================================
# A proposed partnership between sgit.ai and IBM Cloud

> We would like to work with IBM on sovereign, regulated data. IBM made digital sovereignty a product with IBM Sovereign Core, generally available since May 2026. sgit adds the piece that makes sovereignty hold at the data layer: encrypted vaults whose host, whoever runs it, only ever sees ciphertext. IBM Cloud has the storage and the serverless compute sgit needs, and IBM's customers have the regulated data that needs it.
>
> Page: https://sgit.ai/partnerships/ibm-cloud.html

[Home](../index.md) / [Partnerships](index.md) / [Cloud platforms](cloud-platforms.md) / IBM Cloud

A proposed partnership · sgit.ai with IBM Cloud · public material only · 24 September 2026

# A proposed partnership between sgit.ai and IBM Cloud

**We would like to work with IBM on sovereign, regulated data.** IBM made digital sovereignty a product with IBM Sovereign Core, generally available since May 2026. sgit adds the piece that makes sovereignty hold at the data layer: encrypted vaults whose host, whoever runs it, only ever sees ciphertext. IBM Cloud has the storage and the serverless compute sgit needs, and IBM's customers have the regulated data that needs it.

**Nothing on this page is confidential, and there has been no conversation yet.** Every statement about IBM Cloud comes from its own public pages, linked. Every statement about sgit points at the [deployment documentation](../deploy/index.md), a published vault or a page on this site. sgit is Apache-2.0, so IBM Cloud does not need our permission to run it or to build on it. A partnership is about doing that well and together. The general argument is on [the cloud platforms page](cloud-platforms.md).

## In short

- **The fit is regulated enterprise data.** Data rooms, evidence for auditors, and agent work handed over inside a regulated organisation.
- **The platform pieces exist.** [IBM Cloud Object Storage](https://cloud.ibm.com/docs/cloud-object-storage?topic=cloud-object-storage-compatibility-api) supports a subset of the S3 API, and IBM Code Engine runs containers.
- **Sovereignty as software.** [IBM Sovereign Core](https://newsroom.ibm.com/2026-05-05-think-2026-ibm-makes-digital-sovereignty-operational-with-general-availability-of-ibm-sovereign-core) is deployed by customers or partners on OpenShift. The vault server is one container that could sit alongside it.
- **What we would like:** a place in [IBM Partner Plus](https://www.ibm.com/partnerplus/isv), a listing in the IBM Cloud Catalog, and a first regulated customer.

## How vaults map onto IBM Cloud

| sgit needs | On IBM Cloud | Status |
|---|---|---|
| **A small stateless API** | IBM Code Engine, or OpenShift | Should work: it is one container. Not tested by us. |
| **Object storage** | IBM Cloud Object Storage | Supports a subset of the S3 API. Whether it covers what the server uses is untested. |
| **Static readers** | Cloud Object Storage static website hosting | Should work, as for any static host. Not tested. |
| **Sovereign deployment** | IBM Sovereign Core | Complementary. Not tested. |

## Where we are with IBM Cloud today

We have not deployed sgit on IBM Cloud. The pieces it needs are there, and IBM's customers are the organisations for whom encrypted, versioned, auditable data is not a feature but a requirement. This page is an invitation to test that together.

## What a partnership could be

| Shape | What it would be | On their side |
|---|---|---|
| **1 · A tested deployment** | The server on Code Engine or OpenShift with Cloud Object Storage, documented and reviewed. | A technical contact and a test account. |
| **2 · Sovereign Core pairing** | A reference for running vaults inside a Sovereign Core deployment, so the data stays encrypted end to end. | The Sovereign Core team. |
| **3 · A Catalog listing** | The server in the IBM Cloud Catalog, through self-service Partner Center. | IBM Partner Plus, Build track. |

## What we are asking IBM Cloud for

1. A test account and a technical contact for Code Engine and Cloud Object Storage.
2. A conversation with the Sovereign Core team.
3. A place in [IBM Partner Plus](https://www.ibm.com/partnerplus/isv) and a route into the [IBM Cloud Catalog](https://www.ibm.com/cloud/partners/catalog-sell).

## What this page does not claim

- **No endorsement.** IBM Cloud has not endorsed sgit, and we have not spoken to anyone there about this. Programme and product descriptions quote IBM Cloud's own pages as of 24 September 2026.
- **Nothing here has run on IBM Cloud yet.** Every "should work" on this page is a reasoned expectation.

## If you work at IBM Cloud

This page is written to be forwarded as it is, and everything on it can be checked by the person who receives it. [Who is asking, and how to reach them →](../about/index.md)

[← Google Cloud](google-cloud.md)[The European clouds →](european-clouds.md)



==============================================================================
# A proposed partnership between sgit.ai and the European clouds

> For European clouds, vaults are the sovereignty argument made concrete. OVHcloud, Scaleway, Hetzner, IONOS and STACKIT are chosen by customers who want their data in Europe, under European law, with a European provider. sgit adds the guarantee that even the provider cannot read it: the host holds ciphertext, the keys stay with the customer, and the code is open, so nobody can be bought out from under them. Every one of these clouds offers S3-compatible object storage, which is most of what sgit needs.
>
> Page: https://sgit.ai/partnerships/european-clouds.html

[Home](../index.md) / [Partnerships](index.md) / [Cloud platforms](cloud-platforms.md) / the European clouds

A proposed partnership · sgit.ai with the European clouds · public material only · 24 September 2026

# A proposed partnership between sgit.ai and the European clouds

**For European clouds, vaults are the sovereignty argument made concrete.** OVHcloud, Scaleway, Hetzner, IONOS and STACKIT are chosen by customers who want their data in Europe, under European law, with a European provider. sgit adds the guarantee that even the provider cannot read it: the host holds ciphertext, the keys stay with the customer, and the code is open, so nobody can be bought out from under them. Every one of these clouds offers S3-compatible object storage, which is most of what sgit needs.

**Nothing on this page is confidential, and there has been no conversation yet.** Every statement about the European clouds comes from its own public pages, linked. Every statement about sgit points at the [deployment documentation](../deploy/index.md), a published vault or a page on this site. sgit is Apache-2.0, so the European clouds does not need our permission to run it or to build on it. A partnership is about doing that well and together. The general argument is on [the cloud platforms page](cloud-platforms.md).

## In short

- **Storage is ready everywhere.** Each of the five offers S3-compatible object storage, which is the one thing a vault server really needs.
- **Compute varies.** Scaleway has Serverless Containers. The others run the container on managed Kubernetes, Cloud Foundry or a plain server, which the image supports.
- **Sovereignty is the sale.** [OVHcloud's public cloud qualified for SecNumCloud on 1 September 2026](https://corporate.ovhcloud.com/en/newsroom/news/ovhcloud-obtains-secnumcloud-qualification-snc-cloud-platform/); STACKIT and IONOS hold BSI C5; Hetzner has been independent since 1997; Scaleway is European-owned.
- **What we would like:** one tested deployment on each, and a listing in the marketplaces that exist.

## How vaults map onto the European clouds

| sgit needs | On the European clouds | Status |
|---|---|---|
| **OVHcloud** | Object Storage ("largely compatible with the S3 protocol"); Managed Kubernetes; [Open Trusted Cloud](https://opentrustedcloud.ovhcloud.com/en/program-description/) for the marketplace | Not tested by us. |
| **Scaleway** | S3-compatible Object Storage; [Serverless Containers](https://www.scaleway.com/en/serverless-containers/); Edge Services; Marketplace and Partner Program | Not tested. The closest match to the AWS Lambda shape. |
| **Hetzner** | [S3-compatible Object Storage](https://www.hetzner.com/storage/object-storage/); Cloud servers with Docker | Not tested. The simplest and cheapest path: one server, one bucket. |
| **IONOS Cloud** | S3-compatible Object Storage; Managed Kubernetes; CDN; [ISV Partner Program](https://cloud.ionos.com/partner/isv) and Marketplace | Not tested. |
| **STACKIT** | S3-compatible Object Storage; Kubernetes Engine or Cloud Foundry; CDN; [STACKIT Marketplace](https://stackit.com/en/partner/stackit-marketplace-partner) | Not tested. |

## Where we are with the European clouds today

We have not deployed on any of these yet, and we should have. The founder's view, stated on [the UK Sovereign AI page](sovereign-ai.md), is that sovereignty without open source is one acquisition deep. The same argument applies to European clouds: a sovereign host is necessary, and an open, client-side-encrypted data layer on top of it is what makes the sovereignty survive a change of owner, a court order or a breach.

## What a partnership could be

| Shape | What it would be | On their side |
|---|---|---|
| **1 · One tested deployment each** | The server with each provider's S3-compatible storage, documented in the deployment docs. This is also how the S3-endpoint support gets tested properly. | A test account and a technical contact. |
| **2 · A European reference** | A published reference for a fully European stack: a European cloud, a European model provider such as [Mistral](mistral.md), and vaults, with no key ever leaving the customer. | Joint publication. |
| **3 · Marketplace listings** | The server in OVHcloud's, Scaleway's, IONOS's and STACKIT's marketplaces, where their programmes allow it. | Each provider's ISV or partner programme. |

## What we are asking the European clouds for

1. A test account on each, to write and verify the deployment guide.
2. An introduction to each provider's ISV or partner programme, and to their marketplaces.
3. Startup programme support where it exists: [OVHcloud](https://startup.ovhcloud.com/en/), [Scaleway](https://www.scaleway.com/en/startup-program/), [IONOS](https://cloud.ionos.com/startup-program) and [STACKIT](https://stackit.com/en/why-stackit/benefits/startup-program) each run one.
4. A first European customer for whom "the host cannot read it" is the requirement.

## What this page does not claim

- **No endorsement.** None of these providers has endorsed sgit, and we have not spoken to anyone at them about this. Programme and product descriptions quote each provider's own pages as of 24 September 2026.
- **None of this is tested.** Every row above is what the providers document, not what we have run.

## If you work at the European clouds

This page is written to be forwarded as it is, and everything on it can be checked by the person who receives it. [Who is asking, and how to reach them →](../about/index.md)

[← IBM Cloud](ibm-cloud.md)[DigitalOcean →](digitalocean.md)



==============================================================================
# A proposed partnership between sgit.ai and DigitalOcean

> DigitalOcean is the shortest path from "I want to try vaults" to a running server. Spaces is S3-compatible object storage with a built-in CDN, App Platform runs a container, and the DigitalOcean Marketplace explicitly invites open-source projects as 1-Click Apps. For the developers and small teams DigitalOcean serves, a one-click vault server is exactly the right size.
>
> Page: https://sgit.ai/partnerships/digitalocean.html

[Home](../index.md) / [Partnerships](index.md) / [Cloud platforms](cloud-platforms.md) / DigitalOcean

A proposed partnership · sgit.ai with DigitalOcean · public material only · 24 September 2026

# A proposed partnership between sgit.ai and DigitalOcean

**DigitalOcean is the shortest path from "I want to try vaults" to a running server.** Spaces is S3-compatible object storage with a built-in CDN, App Platform runs a container, and the DigitalOcean Marketplace explicitly invites open-source projects as 1-Click Apps. For the developers and small teams DigitalOcean serves, a one-click vault server is exactly the right size.

**Nothing on this page is confidential, and there has been no conversation yet.** Every statement about DigitalOcean comes from its own public pages, linked. Every statement about sgit points at the [deployment documentation](../deploy/index.md), a published vault or a page on this site. sgit is Apache-2.0, so DigitalOcean does not need our permission to run it or to build on it. A partnership is about doing that well and together. The general argument is on [the cloud platforms page](cloud-platforms.md).

## In short

- **Everything sgit needs, in the simplest form.** [Spaces](https://www.digitalocean.com/products/spaces) for storage with a CDN, and App Platform for the container.
- **A 1-Click App is the natural listing.** The [DigitalOcean Marketplace](https://marketplace.digitalocean.com/vendors/guidelines-resources) invites open-source projects.
- **The audience fits.** Developers and small teams who want encrypted, versioned data without running a platform.
- **What we would like:** help publishing the 1-Click App, and a tested Spaces deployment.

## How vaults map onto DigitalOcean

| sgit needs | On DigitalOcean | Status |
|---|---|---|
| **A small stateless API** | App Platform, or a Droplet with Docker | Should work: one container. Not tested by us. |
| **Object storage** | Spaces (S3-compatible) | Should work once the S3 endpoint is configurable. Not tested. |
| **Static readers** | Spaces CDN, or App Platform static sites | Should work. Not tested. |

## Where we are with DigitalOcean today

We have not deployed on DigitalOcean yet. It is on this list because it is the platform where a developer is most likely to try something like sgit on a Saturday afternoon, and a 1-Click App is the fastest way to let them.

## What a partnership could be

| Shape | What it would be | On their side |
|---|---|---|
| **1 · A 1-Click App** | The vault server as a DigitalOcean Marketplace 1-Click App, with Spaces for storage. | The Marketplace vendor team. |
| **2 · A tutorial** | A community tutorial: your own encrypted vault server in ten minutes. | DigitalOcean's community content team. |

## What we are asking DigitalOcean for

1. Help publishing a 1-Click App in the [DigitalOcean Marketplace](https://marketplace.digitalocean.com/vendors/guidelines-resources).
2. A test account to verify Spaces with the server.
3. An introduction through [DigitalOcean Startups](https://www.digitalocean.com/startups) or [DigitalOcean Partners](https://www.digitalocean.com/partners).

## What this page does not claim

- **No endorsement.** DigitalOcean has not endorsed sgit, and we have not spoken to anyone there about this. Programme and product descriptions quote DigitalOcean's own pages as of 24 September 2026.
- **Untested.** Nothing on this page has run on DigitalOcean yet.

## If you work at DigitalOcean

This page is written to be forwarded as it is, and everything on it can be checked by the person who receives it. [Who is asking, and how to reach them →](../about/index.md)

[← The European clouds](european-clouds.md)[Rackspace Technology →](rackspace.md)



==============================================================================
# A proposed partnership between sgit.ai and Rackspace Technology

> Rackspace is the partner who would run vaults for customers, on whichever cloud they use. Rackspace Technology operates managed services across the major clouds and offers UK sovereign clouds for government, healthcare, police and commercial customers. sgit is open source and needs very little infrastructure, which makes it a good fit for a managed-service provider: the value is in running it well, not in the licence.
>
> Page: https://sgit.ai/partnerships/rackspace.html

[Home](../index.md) / [Partnerships](index.md) / [Cloud platforms](cloud-platforms.md) / Rackspace Technology

A proposed partnership · sgit.ai with Rackspace Technology · public material only · 24 September 2026

# A proposed partnership between sgit.ai and Rackspace Technology

**Rackspace is the partner who would run vaults for customers, on whichever cloud they use.** Rackspace Technology operates managed services across the major clouds and offers UK sovereign clouds for government, healthcare, police and commercial customers. sgit is open source and needs very little infrastructure, which makes it a good fit for a managed-service provider: the value is in running it well, not in the licence.

**Nothing on this page is confidential, and there has been no conversation yet.** Every statement about Rackspace Technology comes from its own public pages, linked. Every statement about sgit points at the [deployment documentation](../deploy/index.md), a published vault or a page on this site. sgit is Apache-2.0, so Rackspace Technology does not need our permission to run it or to build on it. A partnership is about doing that well and together. The general argument is on [the cloud platforms page](cloud-platforms.md).

## In short

- **Rackspace is a services partner, not only a platform.** It is an [AWS Marketplace Premier Consulting Partner](https://www.rackspace.com/cloud/aws/marketplace) and runs managed services across clouds.
- **UK sovereign clouds.** [Rackspace's sovereign cloud services](https://www.rackspace.com/industry/sovereign-cloud-services) serve UK government, healthcare, police and commercial customers.
- **Object storage speaks S3.** [Rackspace Object Storage](https://www.rackspace.com/en-gb/cloud/object-storage) "supports any application that utilizes the S3 RESTful API".
- **What we would like:** Rackspace offering managed vaults to its customers.

## How vaults map onto Rackspace

| sgit needs | On Rackspace Technology | Status |
|---|---|---|
| **A managed vault service** | Rackspace managed services, on any cloud | The main opportunity. Nothing to build beyond the deployment docs. |
| **UK sovereign data** | Rackspace UK sovereign clouds | Not tested. Vaults add encryption the host cannot read. |
| **Object storage** | Rackspace Object Storage (S3 API) | Should work once the S3 endpoint is configurable. Not tested. |

## Where we are with Rackspace Technology today

We have no relationship with Rackspace. It is on this list because the most likely way a regulated UK organisation runs vaults is through a managed-service provider, and Rackspace runs managed services on every cloud on these pages as well as its own UK sovereign clouds.

## What a partnership could be

| Shape | What it would be | On their side |
|---|---|---|
| **1 · Managed vaults** | Rackspace runs vault servers for its customers, on their cloud, with the keys staying with the customer. | Rackspace's managed-services practice. |
| **2 · UK sovereign reference** | A reference for vaults on a Rackspace UK sovereign cloud for public-sector data. | The sovereign cloud team. |

## What we are asking Rackspace Technology for

1. A conversation with the managed-services practice about offering vaults.
2. An introduction to the UK sovereign cloud team.
3. An introduction through the [Rackspace Technology Global Partner Program](https://www.rackspace.com/about/channel-partners).

## What this page does not claim

- **No endorsement.** Rackspace Technology has not endorsed sgit, and we have not spoken to anyone there about this. Programme and product descriptions quote Rackspace Technology's own pages as of 24 September 2026.
- **Untested.** Nothing here has run on Rackspace infrastructure.

## If you work at Rackspace Technology

This page is written to be forwarded as it is, and everything on it can be checked by the person who receives it. [Who is asking, and how to reach them →](../about/index.md)

[← DigitalOcean](digitalocean.md)[Netlify →](netlify.md)



==============================================================================
# A proposed partnership between sgit.ai and Netlify

> Netlify already hosts the kind of thing a published vault is. A vault can be read from a plain static host behind a CDN: the browser fetches ciphertext and decrypts it locally, with no server at all. Netlify is named in our static hosting guide for exactly that. The partnership we would like is to make "an encrypted site, readable only with a key, updated with a push" a documented pattern on Netlify.
>
> Page: https://sgit.ai/partnerships/netlify.html

[Home](../index.md) / [Partnerships](index.md) / [Cloud platforms](cloud-platforms.md) / Netlify

A proposed partnership · sgit.ai with Netlify · public material only · 24 September 2026

# A proposed partnership between sgit.ai and Netlify

**Netlify already hosts the kind of thing a published vault is.** A vault can be read from a plain static host behind a CDN: the browser fetches ciphertext and decrypts it locally, with no server at all. Netlify is named in our static hosting guide for exactly that. The partnership we would like is to make "an encrypted site, readable only with a key, updated with a push" a documented pattern on Netlify.

**Nothing on this page is confidential, and there has been no conversation yet.** Every statement about Netlify comes from its own public pages, linked. Every statement about sgit points at the [deployment documentation](../deploy/index.md), a published vault or a page on this site. sgit is Apache-2.0, so Netlify does not need our permission to run it or to build on it. A partnership is about doing that well and together. The general argument is on [the cloud platforms page](cloud-platforms.md).

## In short

- **Static hosting is the whole requirement.** A published vault is static files. Netlify's CDN serves them; the reader's browser decrypts them.
- **Named in the docs already.** The static hosting guide lists Netlify with GitHub Pages, S3 with CloudFront, Cloudflare Pages and Firebase.
- **The server is not needed for readers.** Netlify Blobs is key-value storage rather than S3, so the writing side of a vault stays on a vault server elsewhere; Netlify serves the published copy.
- **What we would like:** a documented pattern, and a place among [Netlify's technology partners](https://www.netlify.com/partners/technology/).

## How vaults map onto Netlify

| sgit needs | On Netlify | Status |
|---|---|---|
| **Static readers** | Netlify's CDN | Documented in our static hosting guide. |
| **Publishing on push** | Netlify builds from a Git push | Should work: publish the vault's ciphertext as the site. Not tested end to end. |
| **The writing side** | A vault server elsewhere | Netlify Blobs is not S3-compatible, so writes stay on a vault server. |

## Where we are with Netlify today

Netlify is already in the static hosting guide. We have not published a vault there ourselves yet; this site is on GitHub Pages. The pattern is simple enough that the first piece of work is a short guide and one live example.

## What a partnership could be

| Shape | What it would be | On their side |
|---|---|---|
| **1 · A documented pattern** | An encrypted site on Netlify: the vault's ciphertext deployed as static files, opened with a read key. | A technical reviewer. |
| **2 · An integration** | A Netlify integration that publishes a vault's current state on every push. | The Technology Partner Program. |
| **3 · Open-source hosting** | sgit's own documentation vaults hosted under the Netlify Open Source plan. | Netlify's open-source programme. |

## What we are asking Netlify for

1. A review of the static hosting pattern for Netlify.
2. A place in the [Technology Partner Program](https://www.netlify.com/partners/technology/).
3. A look at the [Netlify Open Source plan](https://www.netlify.com/legal/open-source-policy/) for sgit's documentation.

## What this page does not claim

- **No endorsement.** Netlify has not endorsed sgit, and we have not spoken to anyone there about this. Programme and product descriptions quote Netlify's own pages as of 24 September 2026.
- **Only the read side fits Netlify.** Writing to a vault needs a vault server, which runs elsewhere.

## If you work at Netlify

This page is written to be forwarded as it is, and everything on it can be checked by the person who receives it. [Who is asking, and how to reach them →](../about/index.md)

[← Rackspace Technology](rackspace.md)[Cloud platforms →](cloud-platforms.md)



==============================================================================
# Models do the work, vaults hold it: proposed partnerships with the AI providers, sgit.ai

> Three places where a model provider meets a vault (agents read and write vaults through a connector, vault apps call models without holding a key, vaults carry the agent's work to a person), what we already do with these providers, what we ask of each, and one page per provider: OpenAI, Anthropic, Mistral AI, Google Gemini, OpenRouter and ElevenLabs.
>
> Page: https://sgit.ai/partnerships/ai-providers.html

[Home](../index.md) / [Partnerships](index.md) / AI providers

Proposed partnerships · sgit.ai with the model and voice providers · public material only · 24 September 2026

# Models do the work. Vaults hold it. We would like to work with the people who make the models.

**An invitation from our side, published in the open.** Almost everything on this site was made with AI: the site itself, the thirty-six published vaults, the diagrams, the narration. The models came from the providers on this page, mostly reached through OpenRouter. What we have built in return is a place for that work to live: encrypted, versioned, openable in a browser with a key, and callable by a model without anyone leaking an API key. We use these providers every day and have no relationship with any of them. This page, and the page for each provider linked from it, sets out where vaults and models meet and what a partnership could be.

**Nothing on these pages is confidential, and there has been no conversation yet.** Every statement about a provider comes from its own public pages or documentation, linked. Every statement about sgit points at a published vault or a page on this site. sgit is Apache-2.0, so any provider can build on it without asking. A partnership is about building the connection properly, and being listed where the provider's users look for it.

## In short

- **Agents need somewhere to put their work.** An agent that writes a report, a site, a test or a plan produces something a person has to receive, check and keep. A vault carries the result, its history and its app as one read key.
- **Documents need to call models without leaking keys.** A vault app can call a language model through the host, holding no key of its own. [llms.sgit.ai](https://llms.sgit.ai/) documents how, including the traps.
- **Agents need to read and write encrypted data safely.** Read with a read key, and write only through a write-only [append lane](../api/append-lanes.md). That is the shape of a connector that can be switched on without handing an agent the keys to everything.
- **Every provider now has a directory.** OpenAI's Plugins directory, Anthropic's Connectors Directory, Mistral's connectors in Vibe, Gemini CLI extensions, OpenRouter's app listings, the ElevenLabs Voice Library. A vault connector belongs in the ones that fit.
- **We have already done independent work on some of them.** [providers.sgit.ai](https://providers.sgit.ai/) reports what a provider cost on a named workload, what broke, and where the key has to live. The ElevenLabs report is published, and the OpenRouter report is next.

## Where a provider meets a vault

Three places where a model provider and a vault meet. The provider holds the model; the customer holds the keys to the data.

| Meeting point | What exists today | What a partnership would add |
|---|---|---|
| **1 · Agents read and write vaults** | The vault API, read keys, and write-only append lanes, all documented. Agents already work in vaults through the CLI. | A vault connector, as a remote MCP server, built to each directory's rules and listed there. It does not exist yet, and it is the first piece of work. |
| **2 · Vault apps call models** | The `sg.llm` bridge: the host makes the call on the app's behalf, so no key sits in the page. [Risk Mandate](../demos/vaults/risk-mandate/index.md) calls an LLM this way. | Credentials made for this pattern, such as keys with a spend limit and an expiry, and first-class support in each provider's documentation. |
| **3 · Vaults carry the agent's work** | This site, most of its vaults, and the [penetration test delivered as a vault](../demos/vaults/pentest-report/index.md) are agent work handed over this way. | A "deliver as a vault" option inside the provider's own agent products. |

## What we already do with these providers

- **This site is built and published by Claude Code sessions** that share state through a vault. So are the deployment docs, the briefs and most of the vaults.
- **Vault apps reach models through OpenRouter.** The key is held by the host, sealed under the vault key, and never reaches the page.
- **Narration is rendered with ElevenLabs**, and [the independent report](https://elevenlabs.providers.sgit.ai/) records what it cost, what broke and which credential patterns the product supports.
- **Agent behaviour policies for several of these products are already published** at [RiskMandate.ai](https://riskmandate.ai/agent-behaviour-policy.html): what an agent can reach in Claude Code, ChatGPT on the web, Claude with Gmail, and more. The risk side of these partnerships will be written there.

## The pages, one per provider

| Provider | Why them | The page |
|---|---|---|
| **OpenAI** | ChatGPT and Codex list MCP-based plugins in a shared directory, and the Responses API can call a remote MCP server directly. | [**The OpenAI page →**](openai.md) |
| **Anthropic** | This site is built by Claude Code sessions sharing state through a vault. Claude reaches remote MCP servers and lists them in the Connectors Directory. | [**The Anthropic page →**](anthropic.md) |
| **Mistral AI** | A European model provider with EU hosting by default and MCP connectors in Vibe and the Agents API. With a European cloud and vaults, a fully European stack. | [**The Mistral AI page →**](mistral.md) |
| **Google Gemini** | Gemini CLI lists extensions automatically from public repositories, and partner agents on Cloud Marketplace reach the Gemini Enterprise Agent Gallery. | [**The Google Gemini page →**](google-gemini.md) |
| **OpenRouter** | The provider we use most. Its keys can carry a spend limit and a reset, the one credential pattern vault apps most need. | [**The OpenRouter page →**](openrouter.md) |
| **ElevenLabs** | We render narration with ElevenLabs and have published an independent report on it. One missing credential feature would make it safe inside vault apps. | [**The ElevenLabs page →**](elevenlabs.md) |

## What we ask of every provider

1. **A review of the vault connector** against your directory's rules, before we submit it.
2. **A credential that fits a vault app**: a key with a spend limit, an expiry, or both, or a short-lived token the host can mint.
3. **Credits or access** through your startup programme, so the integrations are tested rather than described.
4. **A technical contact** for the questions documentation does not answer.
5. **A shared example**: one piece of agent work in your product, delivered as a vault, published on both sides.

## What these pages do not claim

- **No provider has endorsed sgit**, and we have not spoken to any of them about this.
- **The vault connector does not exist yet.** The pages describe what it would be and which directory rules it would meet.
- **Product names change quickly.** Le Chat became Vibe on 12 August 2026, and OpenAI's app directory is now its Plugins directory. The pages use the names on the providers' own pages as of 24 September 2026.
- **Risk is out of scope here.** How the choice between providers, or between an API and a consumer chat product, changes an agent's behaviour policy belongs to RiskMandate.ai, and a brief for that work is published in [the briefs](../docs/briefs/index.md).

## If you work at one of these providers

These pages are written to be forwarded as they are. [Who is asking, and how to reach them →](../about/index.md) The same argument, from the infrastructure side, is on [the cloud platforms page](cloud-platforms.md).

[← Cloud platforms](cloud-platforms.md)[Partnerships →](index.md)



==============================================================================
# A proposed partnership between sgit.ai and OpenAI

> We would like vaults to be where ChatGPT and Codex put work that has to be handed over. OpenAI's agents already produce reports, code and analyses that someone else has to receive, check and keep. A vault carries that result, its history and its app as one read key. OpenAI's platform now reaches remote MCP servers from the Responses API and lists MCP-based plugins in a directory shared by ChatGPT and Codex, which is exactly where a vault connector would live.
>
> Page: https://sgit.ai/partnerships/openai.html

[Home](../index.md) / [Partnerships](index.md) / [AI providers](ai-providers.md) / OpenAI

A proposed partnership · sgit.ai with OpenAI · public material only · 24 September 2026

# A proposed partnership between sgit.ai and OpenAI

**We would like vaults to be where ChatGPT and Codex put work that has to be handed over.** OpenAI's agents already produce reports, code and analyses that someone else has to receive, check and keep. A vault carries that result, its history and its app as one read key. OpenAI's platform now reaches remote MCP servers from the Responses API and lists MCP-based plugins in a directory shared by ChatGPT and Codex, which is exactly where a vault connector would live.

**Nothing on this page is confidential, and there has been no conversation yet.** Every statement about OpenAI comes from its own public pages, linked. Every statement about sgit points at the [deployment documentation](../deploy/index.md), a published vault or a page on this site. sgit is Apache-2.0, so OpenAI does not need our permission to run it or to build on it. A partnership is about doing that well and together. The general argument is on [the AI providers page](ai-providers.md).

## In short

- **A vault connector fits OpenAI's rules.** The [Responses API's MCP tool](https://developers.openai.com/api/docs/guides/tools-connectors-mcp) calls remote MCP servers and asks for approval before sharing data by default.
- **The directory is the channel.** OpenAI's [Plugins directory](https://developers.openai.com/plugins/deploy/submission), shared by ChatGPT and Codex, takes submissions with domain verification and tool annotations such as `readOnlyHint` and `destructiveHint`.
- **Vault tools map cleanly onto those annotations.** Reading a vault with a read key is read-only. Appending to a lane writes but cannot overwrite or delete. Nothing in a vault connector needs to be destructive.
- **What we would like:** a review of the connector before submission, API credits to test it, and a shared example of agent work delivered as a vault.

## Where vaults fit OpenAI's platform

| Meeting point | On OpenAI's platform | Status |
|---|---|---|
| **Agents read and write vaults** | Remote MCP servers in the Responses API, and plugins in ChatGPT and Codex | Connector not built yet. |
| **Vault apps call models** | OpenAI models, reached through the host bridge | Works today through OpenRouter, with the key held by the host. |
| **Vaults carry the work** | Codex and ChatGPT agent output | Pattern published here; no OpenAI integration. |
| **Data controls** | [API data not used for training unless opted in; data residency in Europe and elsewhere](https://developers.openai.com/api/docs/guides/your-data) | Complementary: what is in the vault stays encrypted either way. |

## Where we are with OpenAI today

We use OpenAI models through OpenRouter, from vault apps, with the key held by the host rather than the page. We have no direct relationship with OpenAI and no connector in its directory. The risk side, how an agent's behaviour policy differs between ChatGPT on the web and the API, is published separately: RiskMandate.ai already has [a behaviour policy for ChatGPT on the web](https://riskmandate.ai/agent-behaviour-policy.html).

## What a partnership could be

| Shape | What it would be | On their side |
|---|---|---|
| **1 · A vault connector** | A remote MCP server with read-only vault tools and one append tool, annotated to the directory's rules, submitted to the Plugins directory. | Directory review. |
| **2 · Deliver as a vault** | A Codex or ChatGPT agent task that ends with its output committed to a vault and a read key returned to the user. | A shared example, published on both sides. |
| **3 · Startup support** | API credits to test the connector and the bridge properly. | [OpenAI for Startups](https://openai.com/startups/). |

## What we are asking OpenAI for

1. A review of the vault connector against the Plugins directory rules before we submit it.
2. API credits through [OpenAI for Startups](https://openai.com/startups/).
3. A technical contact on the Apps SDK and MCP side.
4. One shared example: Codex work delivered as a vault.

## What this page does not claim

- **No endorsement.** OpenAI has not endorsed sgit, and we have not spoken to anyone there about this. Product and programme descriptions quote OpenAI's own pages and documentation as of 24 September 2026.
- **The vault connector does not exist yet.** This page describes what it would be and which rules it would have to meet.

## If you work at OpenAI

This page is written to be forwarded as it is, and everything on it can be checked by the person who receives it. [Who is asking, and how to reach them →](../about/index.md)

[← AI providers](ai-providers.md)[Anthropic →](anthropic.md)



==============================================================================
# A proposed partnership between sgit.ai and Anthropic

> This site is already a Claude Code project, and vaults are how its sessions work together. sgit.ai, its briefs, its deployment docs and most of its thirty-three published vaults are built and published by Claude Code sessions that share state through a vault. We would like to turn that working practice into a partnership: a vault connector in Anthropic's Connectors Directory, skills that teach Claude to use vaults well, and a place in the Claude Partner Network.
>
> Page: https://sgit.ai/partnerships/anthropic.html

[Home](../index.md) / [Partnerships](index.md) / [AI providers](ai-providers.md) / Anthropic

A proposed partnership · sgit.ai with Anthropic · public material only · 24 September 2026

# A proposed partnership between sgit.ai and Anthropic

**This site is already a Claude Code project, and vaults are how its sessions work together.** sgit.ai, its briefs, its deployment docs and most of its thirty-six published vaults are built and published by Claude Code sessions that share state through a vault. We would like to turn that working practice into a partnership: a vault connector in Anthropic's Connectors Directory, skills that teach Claude to use vaults well, and a place in the Claude Partner Network.

**Nothing on this page is confidential, and there has been no conversation yet.** Every statement about Anthropic comes from its own public pages, linked. Every statement about sgit points at the [deployment documentation](../deploy/index.md), a published vault or a page on this site. sgit is Apache-2.0, so Anthropic does not need our permission to run it or to build on it. A partnership is about doing that well and together. The general argument is on [the AI providers page](ai-providers.md).

## In short

- **The practice exists.** Claude Code sessions build this site and hand work to each other through vaults, and the deployment docs vault was written by two of them.
- **The connector has a home.** Claude's [MCP connector](https://platform.claude.com/docs/en/agents-and-tools/mcp-connector) reaches remote MCP servers from the API, Claude apps support custom remote connectors, and the [Connectors Directory](https://claude.com/docs/connectors/building/submission) takes remote MCP servers, MCP Apps and plugins.
- **Skills already exist.** [skills.sgit.ai](https://skills.sgit.ai/catalogue/index.html) publishes eight skills, three of them for working with vaults: using sgit, writing vault content, and building vault apps.
- **What we would like:** a place in the [Claude Partner Network](https://claude.com/partners), a review of the connector, and support through [Claude for Startups](https://claude.com/programs/startups).

## Where vaults fit Claude

| Meeting point | On Anthropic's platform | Status |
|---|---|---|
| **Agents read and write vaults** | Remote MCP servers via the API's MCP connector, custom connectors in Claude apps, and the Connectors Directory | Connector not built yet. Claude Code already works in vaults through the CLI. |
| **Vault apps call models** | Claude models, reached through the host bridge | Works today through OpenRouter. |
| **Vaults carry the work** | Claude Code output | This site and most of its vaults are exactly that. |
| **Skills** | Skills bundled in a plugin | Published on skills.sgit.ai; not in the directory. |

## Where we are with Anthropic today

Anthropic's tools are how this site is made, so this is the partnership closest to what we already do. There is no relationship beyond being a customer. RiskMandate.ai has published [agent behaviour policies](https://riskmandate.ai/agent-behaviour-policy.html) for Claude Code on the web and on the command line, Claude Desktop, and Claude with Gmail and Microsoft 365, and the risk side of this partnership will be written there.

## What a partnership could be

| Shape | What it would be | On their side |
|---|---|---|
| **1 · A vault connector** | A remote MCP server with read-only vault tools and one append tool, each tool titled and annotated as read-only or not, submitted to the Connectors Directory. | Directory review. |
| **2 · Skills in a plugin** | The vault skills from skills.sgit.ai bundled as a plugin, so Claude learns to commit, publish and hand over work as vaults. | Directory review. |
| **3 · A case study** | A site built and run by Claude Code sessions that share state through encrypted vaults, written up with its numbers. | The Claude Partner Network. |

## What we are asking Anthropic for

1. A place in the [Claude Partner Network](https://claude.com/partners).
2. A review of the vault connector and the skills plugin before submission to the Connectors Directory.
3. Support through [Claude for Startups](https://claude.com/programs/startups).
4. A conversation about the case study: a website and its vaults run by Claude Code sessions.

## What this page does not claim

- **No endorsement.** Anthropic has not endorsed sgit, and we have not spoken to anyone there about this. Product and programme descriptions quote Anthropic's own pages and documentation as of 24 September 2026.
- **The vault connector does not exist yet.** This page describes what it would be and which rules it would have to meet.
- **Being a heavy user is not a relationship.** It is the reason for this page.

## If you work at Anthropic

This page is written to be forwarded as it is, and everything on it can be checked by the person who receives it. [Who is asking, and how to reach them →](../about/index.md)

[← OpenAI](openai.md)[Mistral AI →](mistral.md)



==============================================================================
# A proposed partnership between sgit.ai and Mistral AI

> A European model, a European cloud, and vaults: a fully European AI stack in which no key leaves the customer. Mistral hosts data in the EU by default, supports MCP connectors in its Agents API and in Vibe (formerly Le Chat), and runs a partner programme with an integration tier. sgit provides the encrypted data layer, open source and runnable on any European cloud. Together they make a sovereignty story that holds at every layer.
>
> Page: https://sgit.ai/partnerships/mistral.html

[Home](../index.md) / [Partnerships](index.md) / [AI providers](ai-providers.md) / Mistral AI

A proposed partnership · sgit.ai with Mistral AI · public material only · 24 September 2026

# A proposed partnership between sgit.ai and Mistral AI

**A European model, a European cloud, and vaults: a fully European AI stack in which no key leaves the customer.** Mistral hosts data in the EU by default, supports MCP connectors in its Agents API and in Vibe (formerly Le Chat), and runs a partner programme with an integration tier. sgit provides the encrypted data layer, open source and runnable on any European cloud. Together they make a sovereignty story that holds at every layer.

**Nothing on this page is confidential, and there has been no conversation yet.** Every statement about Mistral AI comes from its own public pages, linked. Every statement about sgit points at the [deployment documentation](../deploy/index.md), a published vault or a page on this site. sgit is Apache-2.0, so Mistral AI does not need our permission to run it or to build on it. A partnership is about doing that well and together. The general argument is on [the AI providers page](ai-providers.md).

## In short

- **European by default.** Mistral [hosts data in the EU by default](https://help.mistral.ai/en/articles/347629-where-do-you-store-my-data-or-my-organization-s-data), with regional endpoints generally available since August 2026.
- **MCP in two places.** [Studio connectors are registered MCP servers](https://docs.mistral.ai/studio/connectors), and [Vibe supports custom MCP connectors](https://docs.mistral.ai/le-chat/knowledge-integrations/connectors/mcp-connectors) added by admins.
- **An integration tier.** The [Mistral partner programme](https://mistral.ai/partners/) has Strategic, Ecosystem and Integration partners.
- **What we would like:** an integration partnership, a vault connector for Vibe, and a joint European reference with one of [the European clouds](european-clouds.md).

## Where vaults fit Mistral's platform

| Meeting point | On Mistral AI's platform | Status |
|---|---|---|
| **Agents read and write vaults** | Agents API connectors (MCP), and custom MCP connectors in Vibe | Connector not built yet. |
| **Vault apps call models** | Mistral models, reached through the host bridge | Works today through OpenRouter. |
| **Vaults carry the work** | Agent output from the Agents API or Vibe | Pattern published here; no Mistral integration. |
| **Sovereign stack** | EU hosting by default, regional endpoints | Complementary: the data in the vault is encrypted on the device. |

## Where we are with Mistral AI today

We reach Mistral's models through OpenRouter and have no direct relationship. Mistral is on this list because it completes the argument made on [the UK Sovereign AI page](sovereign-ai.md) and [the European clouds page](european-clouds.md): sovereignty is only as strong as the layer that is not sovereign, and a European model with European, client-side-encrypted data leaves no such layer.

## What a partnership could be

| Shape | What it would be | On their side |
|---|---|---|
| **1 · A vault connector for Vibe** | A remote MCP server with read-only vault tools and one append tool, usable as a custom connector in Vibe and in the Agents API. | An integration partnership. |
| **2 · A European reference** | A published reference stack: Mistral models, a European cloud, and vaults, with every key held by the customer. | Joint publication. |
| **3 · Open models next to vaults** | Mistral's open-weight models running beside a vault server on a European cloud, for customers who want neither data nor prompts to leave. | Technical guidance. |

## What we are asking Mistral AI for

1. An integration partnership through the [Mistral partner programme](https://mistral.ai/partners/).
2. A technical contact for the connector and the reference stack.
3. A joint European reference, published on both sides.

## What this page does not claim

- **No endorsement.** Mistral AI has not endorsed sgit, and we have not spoken to anyone there about this. Product and programme descriptions quote Mistral AI's own pages and documentation as of 24 September 2026.
- **The vault connector does not exist yet.** This page describes what it would be and which rules it would have to meet.

## If you work at Mistral AI

This page is written to be forwarded as it is, and everything on it can be checked by the person who receives it. [Who is asking, and how to reach them →](../about/index.md)

[← Anthropic](anthropic.md)[Google Gemini →](google-gemini.md)



==============================================================================
# A proposed partnership between sgit.ai and Google Gemini

> The quickest listing on this page is one we can do ourselves. Gemini CLI supports MCP servers, and Gemini CLI extensions are listed automatically when a public repository carries the right topic and manifest. For the enterprise side, partner agents listed on Google Cloud Marketplace appear in the Gemini Enterprise Agent Gallery. We would like to do both properly, with Google, so that agent work done with Gemini can land in a vault.
>
> Page: https://sgit.ai/partnerships/google-gemini.html

[Home](../index.md) / [Partnerships](index.md) / [AI providers](ai-providers.md) / Google Gemini

A proposed partnership · sgit.ai with Google Gemini · public material only · 24 September 2026

# A proposed partnership between sgit.ai and Google Gemini

**The quickest listing on this page is one we can do ourselves.** Gemini CLI supports MCP servers, and Gemini CLI extensions are listed automatically when a public repository carries the right topic and manifest. For the enterprise side, partner agents listed on Google Cloud Marketplace appear in the Gemini Enterprise Agent Gallery. We would like to do both properly, with Google, so that agent work done with Gemini can land in a vault.

**Nothing on this page is confidential, and there has been no conversation yet.** Every statement about Google Gemini comes from its own public pages, linked. Every statement about sgit points at the [deployment documentation](../deploy/index.md), a published vault or a page on this site. sgit is Apache-2.0, so Google Gemini does not need our permission to run it or to build on it. A partnership is about doing that well and together. The general argument is on [the AI providers page](ai-providers.md).

## In short

- **A self-service first step.** [Gemini CLI extensions](https://geminicli.com/docs/extensions/releasing/) are listed from a public GitHub repository with the `gemini-cli-extension` topic and a manifest, and can bundle an MCP server.
- **An enterprise route.** [Partner agents on Google Cloud Marketplace](https://docs.cloud.google.com/gemini/enterprise/docs/agent-gallery) appear in the Gemini Enterprise Agent Gallery.
- **Google already runs MCP servers.** Google [offers managed remote MCP servers](https://cloud.google.com/blog/products/ai-machine-learning/announcing-official-mcp-support-for-google-services) for its own services.
- **What we would like:** a review of the extension, and a route to the Agent Gallery through [the Google Cloud partnership](google-cloud.md).

## Where vaults fit Gemini

| Meeting point | On Google Gemini's platform | Status |
|---|---|---|
| **Agents read and write vaults** | Gemini CLI MCP servers and extensions; the Agent Gallery for enterprise agents | Neither built yet. The extension is the first step and needs no permission. |
| **Vault apps call models** | Gemini models, reached through the host bridge | Works today through OpenRouter. |
| **Vaults carry the work** | Gemini CLI and Gemini Enterprise agent output | Pattern published here; no Google integration. |
| **Data controls** | [Paid Gemini API use is not used to improve products](https://ai.google.dev/gemini-api/terms_preview) | Complementary. |

## Where we are with Google Gemini today

We reach Gemini models through OpenRouter and have no relationship with Google on the model side. The infrastructure side is on [the Google Cloud page](google-cloud.md).

## What a partnership could be

| Shape | What it would be | On their side |
|---|---|---|
| **1 · A Gemini CLI extension** | A public extension bundling a vault MCP server and context on how to commit and hand over work as a vault. | Self-service listing; a review would help. |
| **2 · An agent in the Agent Gallery** | A vault agent listed on Google Cloud Marketplace and shown in the Gemini Enterprise Agent Gallery. | Partner Advantage and Marketplace. |
| **3 · Startup support** | Credits for testing on Gemini and Google Cloud together. | [Google for Startups Cloud Program](https://cloud.google.com/startup). |

## What we are asking Google Gemini for

1. A review of the Gemini CLI extension once it is published.
2. An introduction to the Gemini Enterprise Agent Gallery team.
3. Support through the [Google for Startups Cloud Program](https://cloud.google.com/startup).

## What this page does not claim

- **No endorsement.** Google Gemini has not endorsed sgit, and we have not spoken to anyone there about this. Product and programme descriptions quote Google Gemini's own pages and documentation as of 24 September 2026.
- **The vault connector does not exist yet.** This page describes what it would be and which rules it would have to meet.

## If you work at Google Gemini

This page is written to be forwarded as it is, and everything on it can be checked by the person who receives it. [Who is asking, and how to reach them →](../about/index.md)

[← Mistral AI](mistral.md)[OpenRouter →](openrouter.md)



==============================================================================
# A proposed partnership between sgit.ai and OpenRouter

> OpenRouter is how the vault apps on this site reach models, and it has the credential the pattern needs. A vault app calls a model through the host, and the key never reaches the page. The safest credential for that is one that is bounded: a spend limit and a reset. The independent provider report on this site records OpenRouter as "the one provider in this family that can do pattern one". We would like to make that a documented, supported pattern together.
>
> Page: https://sgit.ai/partnerships/openrouter.html

[Home](../index.md) / [Partnerships](index.md) / [AI providers](ai-providers.md) / OpenRouter

A proposed partnership · sgit.ai with OpenRouter · public material only · 24 September 2026

# A proposed partnership between sgit.ai and OpenRouter

**OpenRouter is how the vault apps on this site reach models, and it has the credential the pattern needs.** A vault app calls a model through the host, and the key never reaches the page. The safest credential for that is one that is bounded: a spend limit and a reset. The independent provider report on this site records OpenRouter as "the one provider in this family that can do pattern one". We would like to make that a documented, supported pattern together.

**Nothing on this page is confidential, and there has been no conversation yet.** Every statement about OpenRouter comes from its own public pages, linked. Every statement about sgit points at the [deployment documentation](../deploy/index.md), a published vault or a page on this site. sgit is Apache-2.0, so OpenRouter does not need our permission to run it or to build on it. A partnership is about doing that well and together. The general argument is on [the AI providers page](ai-providers.md).

## In short

- **We already use it.** Vault apps here reach models through OpenRouter, with the key held by the host and sealed under the vault key.
- **It has the right credential.** [providers.sgit.ai](https://providers.sgit.ai/) names OpenRouter's provisioned keys, with a spend limit and a reset, as the credential pattern vault apps need.
- **It has the right data controls.** [Provider routing](https://openrouter.ai/docs/guides/routing/provider-selection) can require `zdr: true` or `data_collection: "deny"` per request, which a vault app handling sensitive content should set.
- **What we would like:** a review of the bounded-key pattern, a listing among the apps that work with OpenRouter, and help with the independent OpenRouter report.

## Where vaults fit OpenRouter

| Meeting point | On OpenRouter's platform | Status |
|---|---|---|
| **Vault apps call models** | One API across providers, with the key held by the host | Works today. |
| **Bounded credentials** | Provisioned keys with a spend limit and a reset | The pattern the report recommends; the OpenRouter report itself is not built yet. |
| **Data controls per call** | Routing flags for zero data retention and no data collection | To adopt in the bridge. |
| **Attribution** | [App attribution through request headers](https://openrouter.ai/docs/app-attribution) | To adopt, so vault apps appear in OpenRouter's app listings. |

## Where we are with OpenRouter today

OpenRouter is the model provider this site depends on most. It is also the one the independent report family singles out, because its keys can be bounded. The report on OpenRouter is marked "not built yet" on providers.sgit.ai, and writing it is the natural first piece of shared work.

## What a partnership could be

| Shape | What it would be | On their side |
|---|---|---|
| **1 · The bounded-key pattern** | A documented pattern for vault apps: a provisioned key per vault or per app, with a spend limit and a reset, held by the host. | A technical review. |
| **2 · Listed as working with OpenRouter** | sgit's bridge listed through [Works with OpenRouter](https://openrouter.ai/works-with-openrouter), which takes a pull request to its list. | Self-service, with a review. |
| **3 · The independent report** | openrouter.providers.sgit.ai: what it cost on a named workload, what broke, which credential patterns it supports. | Fact-checking of the draft. |

## What we are asking OpenRouter for

1. A review of the bounded-key pattern for vault apps.
2. A fact-check of the OpenRouter report before it is published.
3. A conversation about featured partnerships.

## What this page does not claim

- **No endorsement.** OpenRouter has not endorsed sgit, and we have not spoken to anyone there about this. Product and programme descriptions quote OpenRouter's own pages and documentation as of 24 September 2026.
- **Heavy use is not a relationship.** We are a paying user, not a partner.

## If you work at OpenRouter

This page is written to be forwarded as it is, and everything on it can be checked by the person who receives it. [Who is asking, and how to reach them →](../about/index.md)

[← Google Gemini](google-gemini.md)[ElevenLabs →](elevenlabs.md)



==============================================================================
# A proposed partnership between sgit.ai and ElevenLabs

> We already publish an independent report on ElevenLabs, and it ends with one clear ask. The narration on this site is rendered with ElevenLabs, and elevenlabs.providers.sgit.ai records what it cost on a named workload, what broke, and which credential patterns the product supports. What would let a vault app use ElevenLabs safely, with no key in the page, is a key with a spend limit, or a short-lived token for text to speech.
>
> Page: https://sgit.ai/partnerships/elevenlabs.html

[Home](../index.md) / [Partnerships](index.md) / [AI providers](ai-providers.md) / ElevenLabs

A proposed partnership · sgit.ai with ElevenLabs · public material only · 24 September 2026

# A proposed partnership between sgit.ai and ElevenLabs

**We already publish an independent report on ElevenLabs, and it ends with one clear ask.** The narration on this site is rendered with ElevenLabs, and [elevenlabs.providers.sgit.ai](https://elevenlabs.providers.sgit.ai/) records what it cost on a named workload, what broke, and which credential patterns the product supports. What would let a vault app use ElevenLabs safely, with no key in the page, is a key with a spend limit, or a short-lived token for text to speech.

**Nothing on this page is confidential, and there has been no conversation yet.** Every statement about ElevenLabs comes from its own public pages, linked. Every statement about sgit points at the [deployment documentation](../deploy/index.md), a published vault or a page on this site. sgit is Apache-2.0, so ElevenLabs does not need our permission to run it or to build on it. A partnership is about doing that well and together. The general argument is on [the AI providers page](ai-providers.md).

## In short

- **We use it and measured it.** The first production video cost $0.18 at list price for 1,821 characters across nine scenes, recorded on 8 September 2026.
- **Four things broke on the first run, and we wrote them down.** PCM output is gated to the Pro tier, stitching is not supported on v3, a scoped key lacked one permission, and one problem was ours: an encoder that added fourteen seconds of silence.
- **One credential feature is missing.** Keys are scoped but carry no per-key spend limit, and text to speech has no vendor-issued short-lived token, so a vault app cannot yet hold an ElevenLabs credential safely.
- **What we would like:** per-key spend limits or short-lived TTS tokens, and a conversation about vault agents that speak.

## Where vaults fit ElevenLabs

| Meeting point | On ElevenLabs's platform | Status |
|---|---|---|
| **Narrated vault content** | Text to speech with character-level timestamps | Works today from a render script. Not yet from inside a vault app, for the reason in the next row. |
| **Voice agents over vaults** | [ElevenAgents connected to external MCP servers](https://elevenlabs.io/docs/eleven-agents/customization/tools/mcp) | Connector not built yet. |
| **A safe credential in a vault app** | A per-key spend limit, or a short-lived token for TTS | Missing. The report's main finding. |
| **Voices** | [The Voice Library](https://elevenlabs.io/docs/eleven-creative/voices/voice-library) | Not used by us. |

## Where we are with ElevenLabs today

ElevenLabs is part of how this site makes its explainers, and it is the first provider to get a full independent report here. The report makes no demands. It records what happened and names which of four credential patterns the product can support, and the gap it finds is specific enough to be a feature request.

## What a partnership could be

| Shape | What it would be | On their side |
|---|---|---|
| **1 · A bounded credential** | A per-key spend limit, or a short-lived token for text to speech, so a vault app can narrate without a long-lived key anywhere near the page. | A product conversation. |
| **2 · Vault agents that speak** | An ElevenAgents agent reading a vault through a connector: a briefing, a board pack or a report, read aloud to the person it was handed to. | A technical contact. |
| **3 · Startup support** | Characters to render the rest of the site's explainers. | [ElevenLabs Startup Grants](https://elevenlabs.io/startup-grants). |

## What we are asking ElevenLabs for

1. Per-key spend limits, or short-lived tokens for text to speech.
2. A fact-check of the independent report.
3. A conversation about [ElevenLabs Startup Grants](https://elevenlabs.io/startup-grants) and about vault agents that speak.

## What this page does not claim

- **No endorsement.** ElevenLabs has not endorsed sgit, and we have not spoken to anyone there about this. Product and programme descriptions quote ElevenLabs's own pages and documentation as of 24 September 2026.
- **The report is independent.** ElevenLabs did not commission or review it.

## If you work at ElevenLabs

This page is written to be forwarded as it is, and everything on it can be checked by the person who receives it. [Who is asking, and how to reach them →](../about/index.md)

[← OpenRouter](openrouter.md)[AI providers →](ai-providers.md)



==============================================================================
# For RiskMandate.ai: an interview page, and a ChatGPT voice prompt to run it

> A build brief to the RiskMandate.ai team for a reusable interview page: send someone a link, they paste a prompt into ChatGPT, it interviews them by voice for about twenty minutes, and writes up their ideas, a thirty, sixty and ninety day action plan, and candid feedback. The first page is for a founder strong in UK events, marketing and content, testing RiskMandate's value proposition and name. The full prompt is included, ready to use.
>
> Page: https://sgit.ai/docs/briefs/riskmandate-interview-page-and-voice-prompt.html

[Home](../../index.md) / [Briefs](index.md) / RiskMandate interview page

# For RiskMandate.ai: an interview page, and a ChatGPT voice prompt to run it

**A build brief from the sgit.ai site team to the RiskMandate.ai team.** Status: open. Written 24 September 2026.

The founder wants expert feedback on RiskMandate from people whose time is scarce and whose knowledge is mostly in their heads. The first is a startup founder who has been unusually good at getting into UK events, at marketing and promotion, at content that spreads, and at making things happen. Asking such a person to read a site and write feedback rarely works. Asking them to talk for twenty minutes usually does.

So the ask is a page on riskmandate.ai that a person can be sent a link to. The page carries a prompt they copy into ChatGPT. ChatGPT then interviews them in voice mode, and at the end writes up their ideas, an action plan and their candid feedback, which they send back.

This will not be the last one. The same shape will be wanted for investors, for security leaders, for insurers and for GRC practitioners. So the brief asks for a reusable page pattern, and then for the first page built on it.

The prompt is written out in full below and is ready to use today. The founder can send it directly while the page is being built.

## What to read first

- [riskmandate.ai's home page](https://riskmandate.ai/): the value proposition the interview will test, in the site's own words: "Know what your agents can do. Not what they did. What they can."
- [For corporate](https://riskmandate.ai/for-corporate.html) and [Licence to operate](https://riskmandate.ai/licence-to-operate.html): the two framings the interviewee is most likely to react to.
- [The published behaviour policies](https://riskmandate.ai/agent-behaviour-policy.html): the sixteen free examples, which are the most shareable thing RiskMandate has.
- [The earlier brief from sgit.ai to RiskMandate](https://sgit.ai/docs/briefs/riskmandate-partnership-risk-and-sgit-mapping.html), for the house rules on facts and claims.

## Part A: the interview page pattern

A page that exists to be sent to one kind of person, and that turns twenty minutes of their talking into written, usable feedback. Every page built on the pattern has the same six parts, in this order:

1. **Who this is for, and why you.** Two sentences. Written to the reader, generic enough to send to anyone in that group, specific enough that they know why they were chosen.
2. **What we want to learn.** Three to six bullets. The reader should know the questions before agreeing to answer them.
3. **How it works, in three steps.** Copy the prompt. Paste it into a new ChatGPT chat and switch to voice. Talk for about twenty minutes, then send us the summary it writes.
4. **The prompt**, in a box with a copy button, and a note that it also works typed, or in another assistant.
5. **What happens to your answers.** Nothing is sent anywhere by the page. The conversation stays in the reader's own ChatGPT account until they choose to send the summary. Ask them not to share anything confidential about their own company or clients.
6. **Send it back.** One clear route: an email address, or a form. See "Later" for a better one.

Rules for every interview page:

- **No tracking of what people paste.** The page is static. The prompt runs in the reader's own assistant.
- **The prompt tells the assistant what RiskMandate is**, in a few plain sentences, because the interviewee may never have seen the site.
- **One question at a time, short turns, in plain speech.** Voice mode reads everything aloud, so no lists, tables or long preambles during the interview.
- **The reader controls the length.** About twenty minutes, and "skip" or "wrap up" work at any time.
- **The write-up is the product.** The final summary must be structured, specific and attributed to the interviewee's own words where it matters.
- **Candour is asked for explicitly.** The most useful feedback is the unflattering kind, and the prompt says so.

## Part B: the first page, for a founder who knows events, marketing and content

**Proposed path:** `riskmandate.ai/interview/founder-marketing.html`, or wherever the site keeps pages of this kind.

**Who it is for:** founders and operators who are good at getting into events, at marketing and promotion, at content that spreads, and at making things happen, particularly in the UK.

**What we want to learn:**

- Whether the value proposition lands, and how they would say it instead.
- Whether the name RiskMandate works.
- Who RiskMandate should reach first, and where those people gather.
- Which UK events to be at, and how to get on stage or in the room.
- Which content angles and formats would spread.
- What they would do in the first thirty, sixty and ninety days.

### The prompt

Paste everything between the lines as the first message in a new ChatGPT chat, then switch to voice mode.

You are going to interview me, by voice, to help a startup called RiskMandate. Be a warm, curious, efficient interviewer. I have about twenty minutes.

**What RiskMandate is.** RiskMandate.ai helps organisations know what their AI agents can do. Its line is: "Know what your agents can do. Not what they did. What they can." Its main product is an Agent Behaviour Policy: a short record, for one AI agent in one deployment, of everything the agent can actually reach, what the business authorised it to do, and the gap between the two, written so that a CEO, a CTO, a CISO and an insurer can all stand behind the same document. It builds towards a "licence to operate" for each agent: the business as the authority, the policy as the evidence, and the agent operating on stated terms for a stated period. Sixteen example policies are published free, for tools such as Claude Code, ChatGPT and Gmail connectors. The context: insurers are starting to exclude AI from cover, and businesses answer for what their agents do. RiskMandate is UK-based, early-stage and founder-led, and it is not an insurer.

**Who I am.** I am a founder who is good at events, marketing, promotion, content that spreads and making things happen. Treat me as the expert. You do not need to explain marketing to me.

**What RiskMandate wants from me:**

1. Whether the value proposition lands, and how I would say it.
2. Whether the name "RiskMandate" works.
3. Who to reach first, and where they gather.
4. Which UK events matter, and how to get on stage or into the room.
5. Content angles and formats that would spread.
6. A practical action plan for the next thirty, sixty and ninety days.
7. My most candid criticism.

**How to run the interview:**

- Start by asking my name, what I do now, and one thing I have promoted that went well. Keep that part to two minutes.
- Then give me the one-paragraph description of RiskMandate above, in your own words, and ask for my first reaction before anything else.
- Then work through the seven topics. Ask one question at a time. Keep your turns short: this is voice, so no lists, no headings, and no long summaries while we talk.
- Follow up when I say something interesting. Ask for specifics: names of events, formats, examples, numbers, people or types of people.
- Ask me to be blunt, and do not argue with criticism. If I am vague, ask for an example.
- About every five minutes, tell me in one sentence how far through we are.
- If I say "skip", move on. If I say "wrap up", go straight to the summary.
- Do not invent facts about RiskMandate. If I ask something you do not know, say so and note it as a question for the founder.

**When we finish, write a summary in text**, not read aloud, with these sections:

1. **First reaction**, in my words.
2. **The value proposition**: what landed, what did not, and up to three one-line rewrites I suggested or agreed with.
3. **The name**: my verdict, my reasons, and any alternatives or taglines I liked.
4. **Who to reach first**, and where they gather.
5. **Events**: a list of named UK events or kinds of event, with how to get in for each.
6. **Content angles**: the hooks and formats I suggested, each with one example post, talk title or headline.
7. **Action plan**: a table with next 30 days, 60 days and 90 days, and for each item who does it and what "done" looks like.
8. **Candid criticism**: the hardest points I made, in my words.
9. **Introductions I offered**, if any.
10. **Open questions** for the founder.

Then ask me whether I am happy for this summary to be shared with RiskMandate's founder, and remind me to copy it and send it back.

### Why the prompt is built this way

- **The description of RiskMandate is inside the prompt**, because the interviewee may never open the site. It uses the site's own words and claims only what the site claims, including that RiskMandate is not an insurer.
- **The interviewee is treated as the expert.** People who are good at promotion lose patience with being explained to.
- **Voice rules are explicit**, because voice mode will otherwise read out long structured answers.
- **The summary is the deliverable**, with fixed sections, so answers from several interviewees can be compared side by side.
- **Consent is asked at the end**, before anything is shared.

## Later: sending the summary back without email

An sgit vault can receive messages through a write-only [append lane](https://sgit.ai/api/append-lanes.html). A token that can only write is safe to publish, as [the telemetry brief](https://sgit.ai/docs/briefs/vault-telemetry-append-lanes.html) explains. A "send it back" box on the page could append the pasted summary straight into a RiskMandate vault, encrypted, with nothing stored anywhere else. Worth doing once there are several interviews to compare. Not needed for the first.

## Before you call it done

- The page has the six parts, in order, and reads well on a phone.
- The copy button copies the prompt exactly, including the line breaks.
- The prompt has been run once, end to end, in ChatGPT voice mode, and the summary came back with all ten sections.
- Nothing on the page or in the prompt claims more than riskmandate.ai already claims.
- The pattern is written down as a template, so the next interview page takes an hour, not a day.

## Likely next pages on the same pattern

- An investor, on the fundraising story.
- A CISO, on whether they would buy a behaviour policy, and at what price.
- An insurer or broker, on what evidence would change a decision about cover.
- A GRC practitioner, on the acceptance loop described in "Every risk is already accepted" on sgit.ai.

## The prompt to hand the builder agent

```

You are working on riskmandate.ai. Read this brief in full.

Part A. Create a reusable "interview page" template with six parts in this order: who this is for and why you; what we want to learn; how it works in three steps (copy, paste into a new ChatGPT chat and switch to voice, talk about twenty minutes and send the summary back); the prompt in a box with a copy button; what happens to your answers (nothing is sent by the page; do not share confidential information); and how to send it back. The page is static, with no tracking.

Part B. Build the first page on the template, for founders who are good at UK events, marketing, promotion and content that spreads, at /interview/founder-marketing.html or the site's equivalent. Use the prompt in this brief exactly, and only change it to correct a fact about RiskMandate that the site states differently.

Run the prompt once in ChatGPT voice mode and check that the summary has all ten sections. Finish with the checklist under "Before you call it done".

```

The canonical markdown copy of this brief lives in the SGit-AI__CLI repository, under `team/humans/dinis_cruz/claude-code-web/09/24/`.

[← All briefs](index.md)[The earlier RiskMandate brief →](riskmandate-partnership-risk-and-sgit-mapping.md)



==============================================================================
# For RiskMandate.ai: the risk side of the partnerships, and a risk mapping for sgit

> A build brief to the RiskMandate.ai team. Part A: for every cloud and AI provider on the sgit.ai partnership pages, the same deployment with and without the service as two Agent Behaviour Policies and the delta, starting with managed identity, cloud agent services, and API against consumer chat. Part B: sgit as a control, what it removes and what it leaves, mapped to GDPR Articles 32, 25, 34(3)(a), 28 and 17 and to international transfers. Built on RiskMandate's existing grammar, with the prompt to hand the builder agent.
>
> Page: https://sgit.ai/docs/briefs/riskmandate-partnership-risk-and-sgit-mapping.html

[Home](../../index.md) / [Briefs](index.md) / For RiskMandate.ai

# For RiskMandate.ai: the risk side of the partnerships, and a risk mapping for sgit

**A build brief from the sgit.ai site team to the RiskMandate.ai team.** Status: open. Written 24 September 2026.

sgit.ai has just published partnership pages from the vault side: one for each cloud platform and one for each AI provider, with the argument for why sgit fits and what a partnership could be. Every one of those relationships has a second half that sgit.ai deliberately does not write, and that belongs to you: **how the choice of a service changes the risk.** The same agent, deployed with a managed identity service or without one, on a cloud's agent platform or on a laptop, through an API or through a consumer chat product, has a different Agent Behaviour Policy. That difference is the business case, and RiskMandate already has the grammar to state it.

This brief asks for two things. First, the risk side of each partnership, as pages on riskmandate.ai that mirror the sgit.ai ones. Second, a risk mapping for sgit itself, including GDPR and data protection, which is the business case for using sgit and is currently written nowhere.

## What to read first

Your own material, because the point is to extend it, not to start again:

- [The 16 Agent Behaviour Policy vaults](https://riskmandate.ai/agent-behaviour-policy.html), one per deployment shape, each with a grant, a mandate, a delta and a Licence to Operate.
- [The ABP model on abp.sgit.ai](https://abp.sgit.ai/), including the capability grammar (`verb.object.reach`), barriers, undo classes and the JSON at `/data/`.
- [Lab 01, the grant is user-shaped, not data-shaped](https://riskmandate.ai/lab-connector-grants.html), and [Lab 06, every routable address is in the grant](https://riskmandate.ai/lab-network-reach.html), which already cites AWS IAM permissions boundaries as the precedent that works.
- [nhi.sgit.ai's options page](https://nhi.sgit.ai/options/), the closest existing thing to "managed identity against building your own".
- [The Insurability Index](https://riskmandate.ai/insurance.html) and the evidence states on [store.sgit.ai's ledger](https://store.sgit.ai/v1/ledger/).

The sgit side you will be mirroring:

- [Partnerships](https://sgit.ai/partnerships/index.html), with [the cloud platforms hub](https://sgit.ai/partnerships/cloud-platforms.html) and [the AI providers hub](https://sgit.ai/partnerships/ai-providers.html), and one page per organisation linked from each.
- [Before you give an agent a connector, give the connector a twin](https://sgit.ai/articles/connector-twin-before-you-deploy-an-agent.html), whose table of what Gmail and Calendar can and cannot undo is an undo-class input you can reuse, with Google's sources.
- [The security model](https://sgit.ai/security/index.html), [when not to use sgit](https://sgit.ai/docs/limitations.html), [the regulated-sector page](https://sgit.ai/use-cases/health-regulated.html) and [what to do if a vault key is exposed](https://sgit.ai/case-studies/exposed-vault-key.html).

## What already exists, so it is not duplicated

- **ABPs for many of the products in question.** ChatGPT on the web, Claude on the web with connectors, Claude Code on the web and on the command line, Claude Desktop, Google Workspace MCP, Claude with Gmail, Gmail and Drive read-only, Claude with Microsoft 365, Dropbox MCP.
- **One managed-against-local pair.** Claude Code on the web, in an ephemeral managed container, against Claude Code on your own machine. Because the ABPs share one grammar, their counts can already be compared.
- **Identity for agents, compared.** nhi.sgit.ai assesses SPIFFE/SPIRE, a commercial workload-identity broker, and "do nothing: broad credential and hope", with profiles for Microsoft Entra Agent ID and Okta.
- **The browser question.** The Agentic Browser Isolation demo compares an agent in your logged-in browser with one in an isolated identity.

## The three gaps

- **Hyperscaler services are missing.** Cognito, Azure, Bedrock and Vertex appear nowhere on riskmandate.ai or abp.sgit.ai. AWS appears only as the IAM precedent in Lab 06. There is no ABP for any cloud's agent service.
- **Provider comparisons are missing, and so is API against consumer chat.** There are separate ChatGPT and Claude ABPs, but nothing sets providers side by side, and nothing compares using a model through its API with using the same model through a consumer product. ABPs model capability; they do not yet model data use, training, retention or residency.
- **There is no risk mapping for sgit.** The only material is the regulated-sector page on sgit.ai and the statement that sgit holds no compliance certification.

## Part A: the risk side of each partnership

Publish on riskmandate.ai one page per organisation on the sgit.ai partnership pages: AWS, Microsoft Azure, Google Cloud, IBM Cloud, the European clouds, DigitalOcean, Rackspace, Netlify, OpenAI, Anthropic, Mistral AI, Google Gemini, OpenRouter and ElevenLabs. Each page makes the business case in RiskMandate's own terms: **the same deployment, with and without the service, as two ABPs and the delta between them.** sgit.ai will link each of its partnership pages to the matching one.

The comparisons we think carry the most weight, in the order we would do them:

1. **Managed identity against your own.** Amazon Cognito, Microsoft Entra ID (including Entra Agent ID), and Google's identity services, against an application that manages its own users and credentials. What moves: the credential's barrier (a setting you can flip against a boundary enforced above the grant), revocation, the plug profile, and the evidence an underwriter will accept.
2. **A cloud's managed agent service against an agent on a laptop.** For example Amazon Bedrock's agent features, Microsoft's agent service in Azure AI Foundry, and Google's Gemini Enterprise Agent Platform, which is what Vertex AI's documentation now calls it. Please confirm each current product name on the provider's own page before publishing. What moves: reach classes (`host` to `tenant`), network reach, the kill switch, and who can pull the plug.
3. **API against consumer chat.** The same model through OpenAI's API and through ChatGPT on the web; through Anthropic's API and through Claude on the web. The sgit.ai provider pages cite the data facts, with sources: whether data is used for training by default, zero data retention availability, and data residency. These are not capabilities, so they need a place in the ABP. The `material` property proposed in Lab 01 is the nearest existing idea, and a data-handling property on the grant may be the cleanest answer. That is your call.
4. **Provider against provider.** OpenAI, Anthropic, Mistral and Google side by side, in one grammar. Include OpenRouter as a case of its own. Its routing flags, `zdr: true` and `data_collection: "deny"`, are a setting per request rather than a boundary, and that distinction is exactly what the barrier ladder is for.
5. **Plain object storage against a vault.** Any cloud's object storage holding plaintext, against the same data in an sgit vault on that storage. This is the bridge to Part B.

Rules for Part A:

- **Facts come from the provider's own pages,** linked and dated, as on the sgit.ai pages. Where a fact is unverified, say so.
- **Evidence states stay honest:** Measured, Derived or Documented, as the ABP vaults already do.
- **No verdicts on providers.** An ABP "describes and it does not judge". The comparison shows where the delta moves; the reader decides.
- **Not fear.** Every difference is a documented behaviour, not a scenario.

## Part B: a risk mapping for using sgit

This is the one we forgot to ask for, and it may matter most. **Why use sgit? Because it removes specific risks, and the business case should say which, in RiskMandate's grammar and against named obligations.** Write sgit up as a control: the same data and the same agent, with and without a vault.

What we expect the mapping to find, for you to confirm or correct:

- **The host's reach drops to ciphertext.** Without a vault, whoever hosts the data can read it. With one, the host holds ciphertext under opaque identifiers and never a key. That is a boundary, not a setting.
- **Credentials declare themselves.** Vault keys, private read keys and public read keys carry different prefixes, so one secret-scanner rule catches every private key type. That is a detection control with a measurable effect.
- **History turns many actions into "undo: yes".** Every earlier version of every file is kept. For content edits, the undo class moves from "no" to "yes".
- **Revocation is weaker than people expect.** A vault key is a bearer credential with no revocation list. The only remedy for an exposed key is rotation. That is a residual risk to state plainly, with an owner.
- **Recovery does not exist by design.** Lose the key and the vault is gone. That is a residual risk too, and [the key management call for collaboration](https://sgit.ai/partnerships/vault-key-management.html) is sgit's answer in progress.

Then the data protection mapping. Please verify each article's text before citing it, and point at provisions rather than asserting, in the house style of [standards.sgit.ai](https://standards.sgit.ai/):

- **GDPR Article 32, security of processing,** names encryption of personal data as an appropriate measure. That is the headline.
- **GDPR Article 25, data protection by design and by default.** Client-side encryption and minimal server knowledge are design choices, and should be described as such, not as compliance.
- **GDPR Article 34, notifying data subjects of a breach.** Article 34(3)(a) relieves the controller of notifying data subjects where the data was rendered unintelligible, for example by encryption. For a breach of a vault host, this may be the single most concrete business case, and it needs careful, sourced wording.
- **GDPR Article 28, processors.** sgit.ai's regulated-sector page already says storing ciphertext may still be processing, so a host is not automatically outside the processor relationship. Keep that caveat.
- **GDPR Article 17, erasure, against history.** Vault history keeps old ciphertext. Erasure therefore means rotation, re-keying or destroying the key. That is a real tension and should be mapped as one.
- **International transfers.** The EDPB's Recommendations 01/2020 on supplementary measures discuss encrypted storage with a provider in a third country, where the keys stay with the exporter. Check the current text and use case before relying on it.
- **Beyond GDPR:** the UK GDPR and Data Protection Act 2018, and the controls in ISO/IEC 27001 that concern cryptography and key management, which standards.sgit.ai already models.

What to publish:

- **An sgit risk mapping as a vault,** in the ABP vault format, with a read key, so sgit.ai can list it with the others.
- **A page on riskmandate.ai, "What sgit removes, and what it leaves",** written as the business case for adopting sgit: the risks reduced, the residual risks with their owners, and the obligations each one touches. sgit.ai will link it from its security page and from every partnership page.

Rules for Part B:

- **sgit holds no compliance certification of any kind,** and nothing may suggest otherwise.
- **"A link means touched and never complies."** Every citation of a legal provision is a pointer, not a claim of conformance.
- **Read keys yes, vault keys never,** in anything you publish, as on sgit.ai.

## Two inconsistencies we noticed while reading

- **Prices disagree.** Level 1 is £10 on riskmandate.ai's pricing page and £5 on store.sgit.ai's policies and on the licence page.
- **GDPR is modelled in one place and denied in another.** sgit.ai lists a "Standards Atlas: GDPR" vault, while standards.sgit.ai still says "There is no GDPR graph". One of them needs updating, and Part B will need whichever is right.

## Before you call it done

- Every organisation on the sgit.ai partnership pages has a matching riskmandate.ai page, or a stated reason it does not.
- Every comparison is two ABPs and a delta, in the existing grammar, with evidence states.
- Every provider fact is linked to the provider's own page and dated.
- The sgit mapping names at least one residual risk it cannot remove, and names its owner.
- Every GDPR citation points at the provision's text, and no sentence says "compliant".
- No vault key appears anywhere.

## What sgit.ai will do when this lands

Link each partnership page to its risk twin, link the security page to "What sgit removes, and what it leaves", list the sgit risk mapping vault among the published vaults, and record the handover in the briefs index.

## The prompt to hand the builder agent

```

You are working on riskmandate.ai. Read this brief in full, then read the RiskMandate material it lists under "What to read first", then the sgit.ai partnership pages.

Part A. For each organisation on https://sgit.ai/partnerships/cloud-platforms.html and https://sgit.ai/partnerships/ai-providers.html, publish a riskmandate.ai page that states the business case as two Agent Behaviour Policies, the same deployment with and without the service, and the delta between them. Work in this order: managed identity against your own; a cloud's managed agent service against an agent on a laptop; API against consumer chat; provider against provider, with OpenRouter's routing flags as a setting; plain object storage against a vault. Use the existing grammar (grant, mandate, delta, barrier, undo class, verb.object.reach) and evidence states (Measured, Derived, Documented). Link and date every provider fact. Do not judge providers.

Part B. Write sgit up as a control: the same data and agent with and without a vault. Map host reach, self-declaring key prefixes, history as undo, bearer keys with rotation as the only remedy, and no recovery. Then map GDPR Articles 32, 25, 34(3)(a), 28 and 17, and international transfers under EDPB Recommendations 01/2020, each verified against the current text and cited as a pointer, never as compliance. Publish it as an ABP-format vault with a read key, and as a page titled "What sgit removes, and what it leaves".

Rules: public material only; sgit holds no certification; a link means touched and never complies; read keys may be published, vault keys never. Finish with the checklist under "Before you call it done".

```

The canonical markdown copy of this brief lives in the SGit-AI__CLI repository, under `team/humans/dinis_cruz/claude-code-web/09/24/`.

[← All briefs](index.md)[Partnerships →](../../partnerships/index.md)



==============================================================================
# Telemetry from a published vault, a build brief

> How one vault sends messages to another, and how a vault whose read key is public reports anonymous usage back to its author. The append-lane mechanism, why a write-only token is the one credential that survives being published inside a public vault, the three things to verify before building, and the prompt to hand the builder agent.
>
> Page: https://sgit.ai/docs/briefs/vault-telemetry-append-lanes.html

[Home](../../index.md) / [Briefs](index.md) / Telemetry from a published vault

# Telemetry from a published vault

A build brief, written to be handed to the agent that will build the thing. The problem: a vault is about to be published with a **read key**, so every visitor can read every file in it, and it still needs to report anonymous usage back to its author. The answer is an **append lane**, and it works for one reason that is worth understanding before you write any code.

**What a build brief is, and how it differs from the asks below it.** The [cross-team briefs](index.md) are requests addressed to another team, with a status, that close when answered. This is the other kind: a durable reference an agent executes. It carries the mechanism, the traps, the things to verify first, and, at the bottom, [the prompt to hand the builder](#prompt), written to be pasted rather than paraphrased.

## What to read first

| Page | What it gives you |
|---|---|
| [Vault messaging](../vault-messaging.md) | The worked example: two vaults exchanging encrypted messages, end to end, with curl |
| [API, append lanes](../../api/append-lanes.md) | The six endpoints, the gates, the limits and the status codes |
| [`sg.append`](../vault/sg-bridge.md) | The same transport from inside a vault app, plus the `sg.on` event push |
| [PKI](../pki.md) | Keypair lifecycle, `sgit pki keygen / export / encrypt / decrypt` |
| [Sub-vaults](../vault/sub-vaults.md) | The *other* cross-vault mechanism, `*.link.json`, for reading across rather than writing |

**One signpost, so you do not go looking.** The [Private Health Score vault](../../demos/vaults/health-score/index.md) looks like the two-party case study and is not one: it is a single vault with three audiences (`patient/`, `doctor/` and `shared/`) split by *who is reading* rather than by copying, where sharing with the clinician means handing over a derived read key. There is no second vault and no message passing in it.

## The mechanism: four capabilities, deliberately split

| Capability | Holder | Can | Cannot |
|---|---|---|---|
| `append_token` | the sender | **write** | list, fetch, read anything |
| `enum_key` | the vault owner | list, fetch, mark-processed | write, purge |
| `write_key` | the vault owner | configure, purge | none |
| private key | the vault owner | **decrypt** | *never sent to the server* |

The server stores `SHA-256` of the first three and compares hashes. It never holds a raw capability key and never holds a private key at all. Two consequences decide the whole design:

- **The write response is blind**: exactly `{"ok": true}`. No file ID, no count, no metadata. A sender cannot learn what else is in the lane, or whether theirs was the first write.
- **No account is needed to send.** `POST /api/vault/append/write/{vault_id}` requires no access token; the `append_token` in the body is the entire gate.

## The shape of it

```
   PUBLISHED VAULT (read key public)          TELEMETRY VAULT (private, yours)
   ───────────────────────────────           ──────────────────────────────────
   holds: append_token                       holds: enum_key, write_key,
          + telemetry vault_id                      private key
          + your PUBLIC key

   a reader reaches step 4
        │  encrypt(event, your_public_key)
        │  POST /api/vault/append/write/{telemetry_vault_id}
        ├────────────────────────────────▶  gate: H(append_token) ∈ append_anchors?
        ◀────────────────────────────────   {"ok": true}   ← blind
                                                  │
                                            you: list (free) → fetch → decrypt locally
```

## Why publishing the token is acceptable, and where it stops being

Every visitor holds the published vault's read key, so **every visitor can read the `append_token` out of it.** That is not avoidable, and it is not the mistake it looks like: an append token grants *write only*. A visitor who extracts it cannot list the lane, cannot fetch anything, cannot read another reader's events, and because the write response is blind, cannot even tell whether the lane holds anything at all.

This is the one credential shape that survives being published inside a public vault. A vault key would not. A read key to a private vault would not: a read key decrypts **everything**, which is exactly the finding that has held two vaults back from publication here.

**What you do not get is authenticity.** Anything the browser holds, the visitor holds.

**Events can be forged.** Treat every row as an untrusted claim about what happened, never as fact. Encrypting to your public key gives you confidentiality, not proof of origin, the public key ships in the published vault, so anyone can produce a well-formed payload.

**The lane can be flooded.** The cap is **1000 pending files per token → 507**, at which point your real telemetry stops arriving. *This* is the failure mode to design against, not the confidentiality one.

Mitigations, in the order they matter: register **several `append_anchors`** so one flooded lane does not bury the others and revoking a sender is removing one anchor; drain aggressively (`list` → `fetch` → `mark-processed`, then `purge` with `folder:"processed"`); rotate the token by re-`configure`-ing and shipping a new vault release; and rate-limit client-side so honest readers never approach the cap.

## Answered: the two questions this brief told you to verify

**Corrected 7 September 2026, and the correction matters more than the original.** This brief said to check whether `sg.append.write` survives a read-only session, warned that the bridge path was probably unavailable, and steered you to a direct `fetch` instead. **That was wrong, and it sent the first agent who followed it down the harder road.** The SG/API team reviewed the append code against this page and reported back; what follows is their answer, and it reverses this brief's recommendation. Their review is quoted below with permission. It is published CC BY 4.0.

1. **Does `sg.append.write` work from a read-only session?, YES. There is no read-only gate on append at all.**
 The bridge checks exactly one thing, a permission grant: `perm.append.write === true`. In the reviewer's words, *"there is **no** `writable` check, **no** consent gate, and no read-only branch anywhere in the append handler"*, and `sg.app.writable` *"is irrelevant to append"*. So the grant is the whole story:

```
{ "permissions": { "append": { "write": true } } }
```

 Nothing else is required. The `EREADONLY` this brief cited belongs to `sg.vfs.write`, which fails at the data-source layer on a different code path, but **both deny with the same string, `'Permission denied'`**, which is precisely how the misdiagnosis happened. Do not use one to probe the other.
2. **Does the frame's CSP allow `connect-src` to the API host?, NO, not by default. And this is the trap.**
 The frame is served with `connect-src blob: data:`, so a direct `fetch` to the API is blocked before it leaves. The escape hatch is `"permissions": {"network": true}`, which omits the CSP meta entirely, and which, as the reviewer puts it, appears *"zero times"* in the authoring guide and zero times in the first version of this page. **It is discoverable only by reading the source.**
**Prefer the bridge anyway.** `network: true` is all-or-nothing: it reopens *every* egress from a frame that is holding decrypted vault content, which is a poor trade for a telemetry beacon. The reviewer's verdict on the tempting shortcut is worth keeping: *"Not recommended: loosening the default CSP, or adding a read-only bypass for append."*
3. **Only `write` crosses vaults. Every other verb is bound to the vault that is open.**
 The bridge builds one client bound to the currently open vault, with the enum key derived from *that* vault's read key. `list`, `fetch`, `markProcessed`, `purge` and `configure` therefore always act on the open vault; **`write` is the sole verb that takes an explicit `vault_id`**, which is exactly what cross-vault telemetry needs and the only thing that makes it possible.
 This is a design boundary, not a gap: listing a remote lane would need the recipient's enum key, and putting that in a published app *"would give every visitor read access to the whole lane."* Drain where the enum key legitimately lives, the receiving vault's own dashboard, or the CLI.
4. **Token format.** `^[0-9a-f]{16,128}$`, **hex only**. A prefixed token returns **400**, not 403, because it fails input validation before reaching any gate. Do not paste a `sha256:` CLI fingerprint in as a token; that is the most likely way to hit it.

**If a grant you added seems to be ignored, the manifest is the first suspect, not the gate.** Two causes, both silent: a **release pin** (`.vault/releases.json`) means `app.json` is read from that commit rather than HEAD, so a pushed manifest is simply not seen, and a pin also forces read-only for everyone, owner included; and a **folder-level `app.json`** beside a deep-linked entry page **replaces** the root manifest wholesale rather than merging with it, so root grants vanish without a warning.

**And one gap to design around.** The intended model is `append_token = H(recipient public key)`, so a sender could compute the lane address from a public bundle with no coordination. No shipped command emits the token, that derivation is **PROPOSED**, not shipped. Until it lands, treat the token as an opaque 64-hex secret you generate and register yourself.

Checked against the shipped CLI while writing this: `sgit pki` ships `keygen`, `export`, `encrypt`, `decrypt`, `sign` and `verify`. There is **no append-lane command in the CLI at all**, so the transport is HTTP or the browser bridge, nothing else.

## Setting it up

```
# once, on the telemetry vault
$ sgit pki keygen --label "Telemetry"
$ sgit pki export sha256:FINGERPRINT > telemetry-identity.json

$ curl -X POST https://send.sgraph.ai/api/vault/append/configure/$TELEMETRY_VAULT_ID \
    -H "x-sgraph-vault-write-key: $WRITE_KEY" -H "Content-Type: application/json" \
    -d '{"append_anchors":["<sha256 of the append_token>"],
         "enum_key_hash":"<sha256 of your enum_key>"}'

# reading — metadata-only listing reads ZERO payloads, so poll with this
$ curl -X POST https://send.sgraph.ai/api/vault/append/list/$TELEMETRY_VAULT_ID \
    -H "x-sgraph-vault-enum-key: $ENUM_KEY" -d '{"include_content": false}'
```

Filenames are server-assigned as `{epoch_ms}_{24-hex}.enc`, so they sort chronologically, which is what makes cursor pagination stable. Page with `after_file_id`. `mark-processed` is idempotent: an already-moved file comes back in `missing` rather than as an error, so a retried batch is safe.

## “Real time”, precisely

On the receiving side the kernel pushes `sg.on('append.new-messages', …)` on **tab focus and app open**: a dashboard app does not poll, it declares `"host_events": ["append.new-messages", "append.error"]` in `app.json` and reacts.

That means real time *while you are looking at it*, not a live stream. For anything closer, poll `list` with `include_content: false`; it is free.

## What you can and cannot learn

**Can:** that the vault was opened, which screens were reached, how far a reader got, event ordering and timing, and a session journey via a random per-session id the app mints in memory.

**Cannot: who.** There is no identity in this system and no login. Every reader is anonymous by construction, which is usually the point, but it does mean *“who opened the vault”* is not an answerable question. Only *how many*.

Two disclosure points, and neither should be skipped:

- **The platform's own default is that opening a vault never phones home.** External embeds are [click-to-load](../vault/sub-vaults.md) precisely so that it does not. A telemetry beacon breaks that expectation, so the vault should say so **visibly, in the vault**: not in a footnote. That is the same house rule every published vault page here follows: publish the work, then say exactly what it is and what it costs.
- **The server sees lane activity, size and timing** regardless of encryption, and it sees the requesting IP. *“The server cannot read the content”* is true. *“The traffic is invisible”* is not.

## The prompt to hand the builder agent

Written to be pasted as-is. Substitute the vault ids.

>

Build a vault app for *THE THING*. It will be published with a **read key**, so assume every visitor can read every file in it, including any credential it carries.

Emit anonymous usage events to a separate telemetry vault over an **append lane**. Read `https://sgit.ai/docs/vault-messaging.html` and `https://sgit.ai/api/append-lanes.html` first.

Constraints:

- Send through the **bridge**: `sg.append.write({ vault_id, append_token, payload })`, with `{"permissions": {"append": {"write": true}}}` in `app.json`. That grant is the only requirement, a read-only session does **not** block it, and `write` is the one verb that takes another vault's id.
- **Do not** reach for a direct `fetch()` to the endpoint. The frame's CSP is `connect-src blob: data:` and will block it silently; the only way round is `permissions.network: true`, which reopens every egress from a frame holding decrypted vault content. If a grant appears to be ignored, check for a release pin or a folder-level `app.json` before you change approach.
- Encrypt each payload to the telemetry vault's public key before sending. The public key ships in the published vault; that is fine, public keys are publishable.
- Never put a vault key, a read key to any other vault, or any other credential in this vault. The append token is the only credential that may appear, and only because it is write-only.
- Mint a random per-session id in memory. No names, no emails, no fingerprinting, nothing that identifies a person. Anonymous is the design, not a setting.
- Rate-limit client-side. The lane caps at 1000 pending files per token and returns 507 after that.
- Fail silently and never block on telemetry, if the POST fails, the reader must not notice.
- Put a visible, plain-English notice in the vault saying that anonymous usage events are sent and what they contain. Opening a vault does not normally phone home; this one does, so say so.
- Treat every received event as an untrusted claim. Anyone holding the read key can forge or flood the lane; the data is directional, not evidential.

Deliverables: the app, the event schema, the telemetry vault's `configure` call, and a dashboard app in the telemetry vault that subscribes to `sg.on('append.new-messages')` and renders the funnel.

The canonical markdown copy lives in the [SGit-AI__CLI](https://github.com/SGit-AI/SGit-AI__CLI) repo under `team/humans/dinis_cruz/claude-code-web/`, which is where every brief on this page is filed.

[← Briefs](index.md)[Publishing a vault →](../../demos/vaults/publishing.md)



==============================================================================
# Working on a vault: start here, guidance

> The first page to read before building, publishing or changing a vault. The practices that get repeated most, pick the surface, do not rebuild what the platform has, publish read keys never vault keys, version everything and show the version, plus routes to the brief that answers each question, and out to coding.sgit.ai, nfrs.sgit.ai and graphs.sgit.ai.
>
> Page: https://sgit.ai/docs/guidance/index.html

[Home](../../index.md) / Guidance

# Working on a vault: start here

The first page to read before building, publishing or changing a vault, human or agent. It is deliberately short and made almost entirely of edges: the practices that get repeated most, and a route to the page that actually answers each question. If you are an agent and you fetch one thing, fetch [`/docs/guidance/llms.txt`](llms.txt), which is this page in the form you prefer.

**The one-minute version.** Pick your [surface](../surfaces.md) first, it changes every other answer. **Do not build what the platform already has**: markdown, file trees and page layouts are free. **Publish a read key, never a vault key.** **Version everything and show the version**, linked to what changed. **Anything rendered stays one click from the bytes it was rendered from.**

## Read in this order

|  | Read | Because |
|---|---|---|
| **1** | [Three surfaces](../surfaces.md) | Every “how do I show this” question has three different right answers. Picking the surface first collapses most of them |
| **2** | [What not to build](../briefs/markdown-and-file-viewers.md) | The two most common asks (a markdown viewer, a file browser) are already in the platform. Most tasks end here |
| **3** | [Content authoring](../vault/content-authoring.md) | The syntax for `_page.json` and vault markdown, once you know you need it |
| **4** | [Vault apps](../vault/vault-apps.md) and [the window.sg bridge](../vault/sg-bridge.md) | Only when a view has to *compute* something the host cannot know |
| **5** | [Publishing: the method](../../demos/vaults/publishing.md) | Before anything becomes public. Classify the credential before it touches anything |

## Version everything, show the version, link what changed

This is the single most repeated piece of guidance, so it goes first among the practices. A vault is a versioned thing; an app that does not say which version it is leaves the reader unable to tell what they are looking at, and leaves a screenshot or a recording undateable.

- **Show the version in the app's chrome**: small, in the top bar, always visible. Not in a footer, not in an About box.
- **Make it a link**, and make the link go to that version's own details, not to a generic changelog. A reader who clicks `v0.1.7` wants to know what *v0.1.7* was.
- **Give versions a home in the vault**: `versions/index.json` plus one file per version. It is data, so an app can render it, a script can check it, and an agent can read it without running anything.
- **Record the commit.** A version that does not name the vault commit it was built from cannot be verified later.
- **Say when a version is reconstructed** rather than recorded, a history assembled after the fact is still useful, but only if it is labelled.

[The AIUC-1 conformance vault](../../demos/vaults/aiuc-1-conformance/index.md) is the reference implementation: a `Versions` tab, the number in the top bar, and one JSON file per version carrying exactly this shape.

```
versions/index.json      { "current": "v0.18.0", "versions": [ … newest first … ] }
versions/v0.15.1.json    { "version", "date", "commit", "vault",
                           "reconstructed", "title", "summary",
                           "changes": [ … ], "basis": [ … ] }
```

`title` is a sentence, not a label, *“the settings move into the right-hand column, which folds and resizes”* tells a reader more than *“UI improvements”* ever will. `changes` names files. `basis` is for a reconstructed entry: the files that make that stage a distinct thing.

## The rest of the practices, in one place

| Practice | Why it exists |
|---|---|
| **Read keys are publishable. Vault keys never are** | A read key is derived one-way and cannot become write access. A vault key *is* write access, and there is no partly-public version of it. Escrow the write key **before** publishing, not after |
| **Scan for other people's secrets too** | A scan built for sgit credential shapes will not catch an API key sitting in a vault file. We nearly published a live OpenRouter key in a field called `openrouter_key` that matched no sgit pattern |
| **Every credential test needs a negative control** | `sgit clone` creates a directory whether or not the key is valid. The marker that discriminates is `.sg_vault/local/clone_mode.json`. We called a leak once on a directory that an all-zeros key produced identically |
| **Anything rendered stays one click from its bytes** | A reader that only shows its own interpretation asks to be trusted; one that also shows the source offers to be checked. `_page.json` has `{ } Source`; this site gives every page a `.md` twin |
| **Deny by default in `app.json`** | Declare the narrowest permission that works, and write down why each grant exists. `"permissions": {}` is a real answer and often the right one |
| **Manifests at build time, files on click** | A vault can be tens of megabytes. Do not re-derive at runtime what the build already knew, and do not fetch what nobody opened |
| **Content exists once** | If a paragraph is in the vault and again in a page about the vault, they will disagree, and the vault is the one that is right |
| **State the gap rather than papering over it** | A page that names what it is missing is more useful than one that quietly omits it. Measured, not guessed |

## Build briefs, written to be executed

| Brief | For |
|---|---|
| [Markdown and file viewers: what not to build](../briefs/markdown-and-file-viewers.md) | Documents and file browsing in a vault |
| [Decks from a vault, on a site](../briefs/vault-decks-on-a-site.md) | Presentations published on a web page |
| [Reading a vault from a site page](../briefs/sgit-ai-site-pages.md) | Devs coding the `*.sgit.ai` sites |
| [Telemetry from a published vault](../briefs/vault-telemetry-append-lanes.md) | A public vault reporting usage back to its author |
| [Publishing a vault: the method](../../demos/vaults/publishing.md) | Anything about to become public |

The mechanism underneath the last three is [reading one file out of a vault](../vault/reading-a-vault-file.md). The catalogue of what has already been built this way is [the published vaults](../../demos/vaults/index.md), and [`/demos/vaults/llms.txt`](../../demos/vaults/llms.txt) is that catalogue with every read key, for an agent that wants to go and look rather than take our word for it.

## Where the rest of the answer lives

This site covers vaults and sgit. It deliberately does not cover how code should be written, what a system owes its users when nobody is watching, or how to model meaning, because each of those has a site of its own, with the room to do it properly. **An agent that stops at this domain will get a worse answer than one that follows the edge.**

coding.sgit.ai · Agents & AI, [How software actually gets written here ↗](https://coding.sgit.ai/), The rules, the compliance measurement against them, which are machine-enforced and which are explicitly not, the open tensions, and a section on writing code for agents to read. Read this before writing a vault app, not after. (“The style guide that measured itself.”) part of the sgit.ai network

nfrs.sgit.ai · Risk & governance, [The requirements nobody writes down until they are violated ↗](https://nfrs.sgit.ai/) (Resilience, budgets, project management, backups) as a reality system rather than a checklist, with a scorecard and a page naming backups as a gap. The questions a vault has to answer once somebody depends on it., “The non-functional requirements, from the inside.”, part of the sgit.ai network

graphs.sgit.ai · Graphs & method, [A grammar for semantic graphs ↗](https://graphs.sgit.ai/), From five rules you can apply tomorrow to a full positioning against schemas and vector search, including the four situations in which its own argument is the wrong one. The page to read before modelling anything as data., “A node is just a node. Meaning lives in the edges.”, part of the sgit.ai network

[The full network](../../network/index.md) lists every site with what it covers and the words it answers to.

## Why this page is mostly links

The estate is one semantic graph that happens to be served from many domains. A vault is a node; so is a site, a page, a version, a published read key. What makes any of them useful is not the node. It is what it is connected to. That is graphs.sgit.ai's own argument, applied to the thing you are reading:

> “A node is just a node. **Meaning lives in the edges.**”

So this page does not restate the guidance that lives elsewhere, and it should not grow into a manual. Its job is to be the node an agent can always find, with enough edges to reach the right answer in one hop. Three properties keep that working, and they are worth preserving in anything built here:

- **Every page is reachable and machine-readable.** Each has a `.md` twin and appears in `llms.txt`; the build fails on an orphan. A page nothing links to is a page nothing can find, which is the same as unpublished.
- **Indexes are generated from the data they index.** [The vault catalogue](../../demos/vaults/llms.txt) comes from the same file the human-readable table does, so the two cannot disagree. An index maintained by hand becomes a lie on a schedule.
- **Scope by domain, link across.** Each site says one thing properly and points at the others rather than summarising them badly. The edge is the answer; the summary would be a worse copy.

If something here is wrong, that is worth telling us, the last brief on this site was corrected by the team that read it, and [the correction sits above the mistake](../briefs/vault-telemetry-append-lanes.md). [/docs/guidance/llms.txt](llms.txt) · [All briefs](../briefs/index.md) · [The network](../../network/index.md)



==============================================================================
# Three surfaces: which one are you building for?, sgit.ai

> _page.json inside a vault, an HTML vault app, or a page on a *.sgit.ai site: what each can do, which credential each uses, and the trust direction that inverts between them, plus the same job done on all three, and where each surface’s guidance lives.
>
> Page: https://sgit.ai/docs/surfaces.html

[Home](../index.md) / [Docs](index.md) / Three surfaces

# Three surfaces, which one are you building for?

Almost every question about “how do I show this” has three different right answers, because there are three places code runs in this estate, **`_page.json`** inside a vault, an **HTML vault app** inside a vault, and a page on a **`*.sgit.ai` site** outside every vault. They have different capabilities, different credentials and, most importantly, **opposite trust directions**. Pick the surface first; the rest of the guidance follows from it.

**The short version.** Publishing a document? `_page.json` or plain markdown, and write no code. Need to *compute* something over the vault's own data, for someone who already has the vault open? A vault app. Need it on the public web, indexed, linkable, with no key-holding required of the reader? A `*.sgit.ai` site page, and there **you** become the one who has to distrust the vault.

## The three, side by side

|  | `_page.json` | HTML vault app | `*.sgit.ai` site page |
|---|---|---|---|
| **Where it runs** | The vault browse view | A sandboxed frame inside the vault host | A normal public web page, any origin |
| **Who reads the vault** | The host | The host, answering `window.sg` calls | **You do**: a CORS `GET` plus Web Crypto |
| **The credential** | The reader already opened the vault | Same, the app never holds a key | A published **read key, printed in your page** |
| **What the reader needs** | The vault link or key | The vault link or key | **Nothing.** It is a URL |
| **Search engines and agents** | Invisible | Invisible | **Indexed**, linkable, quotable |
| **You write** | JSON | HTML, CSS, JS + `app.json` | Whatever your site is built from |
| **Trust direction** | Host renders your content | Host distrusts *your app* and sandboxes it | **You distrust the vault** and sandbox *it* |
| **Ships when** | `sgit push` | `sgit push` | Your site's release |

The last two rows are the ones people get wrong. Inside a vault host, **the host is the one doing the protecting**: it sandboxes the app, gates permissions and keeps the sovereignty rail. On your own site there is no host: **you** are the host, and vault bytes are untrusted input arriving in your origin.

## The same job, on each surface

| You want to… | `_page.json` | Vault app | Site page |
|---|---|---|---|
| **Show a markdown document** | Native, the `markdown` component, or just publish the `.md` | `sg.vfs.readText`, then render | Fetch, decrypt, render, or write the prose as a page and keep a `.md` twin |
| **Browse files and folders** | Native, the host's tree is the browser | Build one from a build-time manifest; raw always available | Same, with the manifest read out of the vault |
| **Show a deck** | `slides` or `gallery` components | Your own viewer, or the vault's `decks/v2` shell | [The deck-viewer pattern](briefs/vault-decks-on-a-site.md), parse frame plus render frame |
| **Show a PDF** | The `pdf` component | `sg.ui.preview` | **Download only.** A sandboxed frame cannot render one |
| **Compute over the data** | Not possible. It is a layout format | Yes, this is the reason apps exist | Yes, in your own code |
| **Be found by someone who has never heard of you** | No | No | **Yes**: the only surface that does this |

## Where the guidance lives

| Surface | Read |
|---|---|
| **`_page.json` and markdown** | [Publishing content without code](vault/content-authoring.md), the syntax. [Markdown and file viewers: what not to build](briefs/markdown-and-file-viewers.md), the decision |
| **HTML vault apps** | [Building vault apps](vault/vault-apps.md), the project shape and `app.json`. [The window.sg bridge](vault/sg-bridge.md), the runtime and its permission model |
| **`*.sgit.ai` site pages** | [Reading a vault from a site page](briefs/sgit-ai-site-pages.md), the brief. [Reading one file out of a vault](vault/reading-a-vault-file.md), the primitive. [Decks from a vault, on a site](briefs/vault-decks-on-a-site.md), a worked example |
| **All three** | [Publishing a vault: the method](../demos/vaults/publishing.md), read keys are publishable, vault keys never are, whichever surface you are on |

## They combine, and the combination is usually right

These are not alternatives to choose between once. The vaults on this site do all three at the same time, and that is the intended shape:

- **The vault holds the content** (markdown, data, images, decks) authored once.
- **A vault app computes over it** for anyone who opens the vault directly, with the full file tree beside it.
- **A site page publishes a view of it** for everyone else: indexed, linkable, and readable without a key or an account.

[The AIUC-1 conformance vault](../demos/vaults/aiuc-1-conformance/index.md) is the clearest example, a fourteen-tab app inside the vault, and [deck pages on this site](../demos/vaults/aiuc-1-conformance/decks/index.md) reading the same files. One set of content; three ways in. **What must never be duplicated is the content itself**: if a paragraph exists in the vault and again in a site page, they will disagree, and the vault is the one that is right.

Every guidance page in this estate is labelled with the surface it applies to. If a page is not labelled, it applies to all three. [All briefs](briefs/index.md) · [Docs](index.md) · [SG/Vault](vault/index.md)



==============================================================================
# Reading a vault from a *.sgit.ai site page, build brief

> For devs coding the estate’s sites: the vault API answers plain CORS GETs with no auth header, so a site page reads ciphertext directly and decrypts in the visitor’s browser. The house reader to copy rather than rewrite, the trust rule that inverts on this surface, the ref-caching trap, and the prompt to hand the site’s agent.
>
> Page: https://sgit.ai/docs/briefs/sgit-ai-site-pages.html

[Home](../../index.md) / [Briefs](index.md) / Reading a vault from a site page

**Surface:** a page on a `*.sgit.ai` site, outside every vault host. [The other two surfaces →](../surfaces.md)

# Reading a vault from a `*.sgit.ai` site page

A build brief for whoever is coding one of the sites in this estate. Vault content can be published on an ordinary web page (indexed, linkable, readable with no key and no account) because the vault API answers **cross-origin GETs** and the decryption happens in the visitor's browser. This is the surface with the most reach and the least protection, and the two facts are related.

**The enabling fact, in one line.** `GET /api/vault/read/<vault_id>/…` is a plain CORS request with **no auth header**, from any origin. The server can afford that because what it returns is ciphertext under a key it has never held, so `graphs.sgit.ai`, `risks.sgit.ai` or any other site can read a published vault directly, with no proxy, no backend and no build step.

## Do not write the reader

It already exists, it is small, and it is deliberately in the open so you can copy it rather than reimplement the derivations:

| File | What it gives you |
|---|---|
| `assets/vault-embed.js` | The reader, ~90 lines, import the key, derive the ref id, fetch, decrypt, walk commit → tree → blob, `readText` / `readBytes` by path. It exports `SGVaultEmbed.Reader` so nothing else has to copy the derivations. It also mounts a whole vault app in a sandboxed frame if that is what you want |
| `assets/vault-docs.js` | The same reader with cache accounting and a markdown renderer, the instrumented version, useful when you want to show a reader what the page actually fetched |
| `assets/vault-deck.js` | A worked viewer built on the reader: [decks and PDFs](vault-decks-on-a-site.md), with the sandbox policy already right |
| `assets/vault-ui-embed.js` | Frames the official SG/Vault UI on your page, read-only, from a read key, when you want the whole product rather than a view of it |

All four are on this site under `/assets/` and are MIT-spirited house code: copy them into your site, do not fetch them across origins at runtime. The mechanism they share is written up at [**Reading one file out of a vault**](../vault/reading-a-vault-file.md).

## The rule that changes on this surface

Inside a vault host, the host protects the reader: it sandboxes apps, gates permissions, and keeps a sovereignty rail the app cannot suppress. **On your site there is no host. You are the host.** And the bytes you are rendering were written by whoever holds that vault's write key, which is a different question from who can read it.

So the rule inverts, and it is the single most important thing on this page:

> **The viewer is the site's. The data is the vault's. A vault must be able to change what is shown, and never what the page does.**

| Vault content | How to render it |
|---|---|
| **Text and numbers** | Escape it. It is a string from a third party, and it belongs in `textContent`, never in `innerHTML` |
| **Markup, a document, a slide** | `<iframe sandbox>` with **no**`allow-scripts`, plus a CSP of `default-src 'none'; img-src data:; style-src 'unsafe-inline'`. Static content does not need scripting, so switch it off rather than contain it |
| **Anything that must run** | `<iframe sandbox="allow-scripts">` (opaque origin, no `allow-same-origin`, ever) and serve its reads over `postMessage`. **Never `eval` vault code in your page.** |
| **Images** | Decrypt them yourself and pass `data:` URIs in, or mint blob URLs *inside* the frame. A vault path in a `src` resolves against an opaque origin and 404s |
| **PDFs** | Download, never embed. Chrome refuses to render a PDF in a sandboxed frame, and un-sandboxing it to make the viewer work defeats the point |
| **Links inside vault content** | Rewrite or restrict them. A link is a place a vault author can send your visitor |

## Keys, on a page anyone can view source on

- **A read key belongs in the page.** That is what it is for. It is derived one-way, it cannot be turned into write access, and printing it is how a reader clones the vault themselves. Put it in the markup where a human can copy it, not only in a script.
- **A vault key must never touch a site.** It is write access. There is no such thing as a partly-public vault key.
- **Grep the built site before every release**, and make it a step that can fail the build rather than a habit. This site's release aborts on a key-shaped match.
- **A credential scan built for sgit shapes will not catch other secrets.** We nearly published an OpenRouter key sitting in a vault file, in a field called `openrouter_key`, that matched none of the sgit patterns. Scan for what the vault holds, not only for what sgit issues.

## Two things that will bite a site dev specifically

- **Cache immutable objects, never the ref.** An object id containing `-imm-` is content-addressed and safe to cache forever. The ref is the mutable HEAD pointer, and caching it fails *silently*: the page renders an older commit from perfectly valid ciphertext, so nothing errors and the content is simply stale. Keep a short freshness window on the ref instead.
- **Decide what happens when the vault moves ahead of your page.** A vault can be pushed to at any time, and your site rebuilds on its own schedule. Either read live and accept that your prose may describe an older state, or snapshot at build time and say so. What breaks trust is a page that reads live in one panel and from a stale snapshot in the next without telling anyone which is which.

## What not to put on this surface

Reach is the point of a site page, so the failure mode is putting things there that should have stayed in the vault:

- **Do not duplicate vault prose into the page.** If a paragraph exists in both, they will disagree, and the vault is the one that is right. Render it from the vault or link to it.
- **Do not rebuild the vault's app.** If a visitor needs the full thing, frame the official UI or link them to it with the read key.
- **Do not make the site the only way to read the vault.** The read key on the page should be enough for anyone to bypass your site entirely. If it is not, something is being withheld that should not be.

## Before you call it done

- Every frame holding vault content has a `sandbox` attribute, and none has `allow-same-origin`.
- No vault string reaches `innerHTML` unescaped and unframed.
- The page works from a cold cache and from a warm one, and a fresh push shows up within your stated freshness window.
- The built site has been grepped for vault-key shapes and for other credential shapes, as a build step that can fail.
- The read key is visible to a human reading the page, not only to the script.
- A visitor with no key, no account and nothing installed can read the thing you published.

## The prompt to hand the site's agent

```
Publish content from vault VAULT_ID on SITE, read live with the published read
key READ_KEY.

Read https://sgit.ai/docs/surfaces.md first to confirm a site page is the right
surface, then https://sgit.ai/briefs/sgit-ai-site-pages.md, then
https://sgit.ai/vault/reading-a-vault-file.md for the mechanism.

Do not write the reader. Copy assets/vault-embed.js from sgit.ai, which exports
SGVaultEmbed.Reader; assets/vault-deck.js is a worked viewer built on it. Copy
them into the site rather than fetching them across origins at runtime.

The vault API answers plain CORS GETs with no auth header, so no proxy and no
backend is needed. The bytes are ciphertext; decryption happens in the visitor's
browser.

The rule: the viewer is the site's and the data is the vault's. A vault must be
able to change what is shown and never what the page does. Vault text is escaped
into textContent. Vault markup goes in a sandboxed frame with no allow-scripts
and a default-src none CSP. Anything that must run goes in a sandboxed frame
with allow-scripts and never allow-same-origin, served over postMessage. Never
eval vault code in the page origin. PDFs are downloads, not embeds.

Cache objects whose id contains -imm-; never cache the ref, because a stale ref
renders an older commit from valid ciphertext and nothing errors.

Print the READ key where a human can copy it. Never put a vault key on a site.
Add a build step that greps the built output for key shapes and fails.

Report: what is read live vs snapshotted at build time, and how a visitor with
no key reads the published content.
```

This is one of [three surfaces](../surfaces.md); the guidance for the other two is [content authoring](../vault/content-authoring.md) and [vault apps](../vault/vault-apps.md). [All briefs](index.md) · [A worked example on this surface](vault-decks-on-a-site.md)



==============================================================================
# Publishing a vault’s decks onto a website, build brief

> A build brief for an agent with a vault full of presentations: the decks/v2 contract a vault must publish, the split that keeps it safe (the viewer is the site’s, the data is the vault’s), the two sandboxed frames and their CSPs, why a PDF must be a download rather than an embed, the two bugs we hit, and the prompt to hand the builder.
>
> Page: https://sgit.ai/docs/briefs/vault-decks-on-a-site.html

[Home](../../index.md) / [Briefs](index.md) / Decks from a vault, on a site

**Surface:** a page on a `*.sgit.ai` site, outside every vault host. [The other surfaces →](../surfaces.md)

# Publishing a vault's decks onto a website

A build brief for an agent who has a vault containing presentations and wants them to *play on a web page*: not as screenshots, not as a PDF on a file server, but read out of the encrypted vault as the reader clicks. It states the contract a vault must satisfy, the split that keeps it safe, the two mistakes we made building it, and the prompt to hand the agent who will do the work.

**What this produces.** A page like [this one](../../demos/vaults/aiuc-1-conformance/decks/aiuc1.md): slide list, prev and next, speaker notes, a focus mode for presenting, a PDF download, and a deep link to a single slide, over slides that live in vault `2wzct4k7` and are fetched and decrypted in the reader's browser. No account, nothing installed, and the server serving the bytes cannot read them.

## What to read first

- [**Reading one file out of a vault**](../vault/reading-a-vault-file.md), the primitive underneath all of this: derive the address from a read key, fetch ciphertext over CORS, decrypt with Web Crypto. If you only read one thing, read this.
- [**Publishing a vault: the method**](../../demos/vaults/publishing.md), how a vault gets a published read key in the first place, including escrowing the write key *before* publishing.
- The working implementation, ~380 lines, which you may copy: `assets/vault-deck.js` on this site, with the reader it builds on in `assets/vault-embed.js`.

## The one rule: the viewer is the site's, the data is the vault's

A read key is public, so anyone can read the vault. The risk runs the other way: **the bytes coming out of the vault were written by whoever holds the write key, and they are untrusted input to your page.** Rendering them into your own document hands a vault author your origin, your cookies, your storage, your DOM, your users.

| From the vault | From the site |
|---|---|
| The deck manifest, each deck's slides, the speaker notes, the screenshots, the printed PDF | The deck tabs, the slide list, prev and next, the notes toggle, focus, the PDF button, the deep links, and the sandbox policy the whole thing runs under |

Stated as a test you can apply to any design: **a vault must be able to change what is shown and never what the page does.** If a vault can add a button, change where a link goes, or read anything belonging to the host page, the split is wrong.

## The contract: what the vault must publish

This is the `decks/v2` layout, as published by the two vaults on this site. A viewer written to it will render any vault that follows it.

| Path | Required | What it holds |
|---|---|---|
| `decks/decks.json` or `decks.json` at the root | **Yes** | The manifest. `type: "decks/v2"`, an optional `levels` array, and a `decks` array |
| `decks/<id>.js` | Preferred | One deck's slides as source. Tens of KB, because screenshots are not in it |
| `decks/shell.html` | Preferred | Its `<style>` block is the deck's look. Its `<script>` is the vault's own viewer and is never read by the host |
| `deck/img/<name>.jpg` | If slides use images | One file per screenshot, named exactly as the slide references it |
| `deck/<file>.pdf` | Optional | The printed deck, offered as a download |

Each entry in `decks` needs `id` and `title`. Everything else is optional but earns its keep, because a host can build a page around it rather than around prose somebody has to write twice: `short` (a tab label), `level`, `one_line`, `pdf`, `file`, `introduces`, `ends_on`, `audience`, `minutes`, `stops_before`. The deck pages on this site are generated from exactly those fields.

### The slide contract

A deck source is a classic script that pushes onto a global `S`:

```
S.push({ t: 'What AIUC-1 is', notes: `the speaker notes`, html: `…the slide markup…` });
```

Three keys, and only three: `t` is the title the slide list shows, `notes` are the speaker notes, and `html` is the slide's markup as a string.

- **The stage is 1600×900.** Slide CSS is written against that viewport and nothing else. A host should size its frame to exactly that and scale the *element*, not the document, then a slide looks identical at any column width, with no reflow and no script inside the frame.
- **Images are named, never pathed.** The helper `img(name, style)` emits `<img data-img="name">` with no `src`. This is the single most important detail in the whole contract, because a slide names an image instead of pointing at a URL, the host can resolve it to decrypted bytes without the slide ever being able to make a network request. **Do not put a URL in a slide.**
- **Slides are static markup.** The deck's *build* runs JavaScript; a rendered slide must not need any.

### If your vault published only its built decks

One of the two vaults here shipped `decks/` sources; the other shipped only the assembled `deck-<id>.html` files, with screenshots already base64 inside them. Both work, and a host should handle both: prefer the source, and fall back to the built file **truncated at the literal comment `/* ---------- shell */`**, which is where the vault's own viewer begins and the declarations end. The cost of the fallback is size, hundreds of KB per deck rather than tens.

## The host side: two frames, and why

A deck cannot simply be inserted into the page, and it cannot simply be trusted. Two sandboxed, opaque-origin iframes, each with its own CSP:

|  | Sandbox | CSP | Job |
|---|---|---|---|
| **Parse frame** | `allow-scripts` | `default-src 'none'; script-src 'unsafe-inline' 'unsafe-eval'` | A deck builds its slides by running, so it runs here (no origin, no network) and posts back a plain array. **The site never evals vault code.** |
| **Render frame** | `sandbox=""`, no `allow-scripts` at all | `default-src 'none'; img-src data:; style-src 'unsafe-inline'` | Slide markup, with images already resolved to `data:` URIs by the host. Nothing in a slide can phone home |

Hand the deck source to the parse frame **over `postMessage`, not baked into the `srcdoc`**: otherwise a deck containing the characters `</script>` breaks out of the bootstrap that runs it.

### The PDF is a download, and this is not a preference

The obvious move (decrypt the PDF, wrap it in a blob, point a sandboxed iframe at it) does not work. Chrome refuses, in every sandbox combination:

> `Failed to load 'blob:…' as a plugin, because the frame into which the plugin is loading is sandboxed.`

The browser's PDF viewer is a plugin, and plugins do not run in sandboxed frames. Your three options are: drop the sandbox (gives vault bytes your origin, do not), ship a JavaScript PDF renderer (works, costs about a megabyte of vendored dependency), or **decrypt in the page and hand the bytes to the browser's own download**, which is what this site does. Trigger the download from the page and not from inside a frame: a sandbox without `allow-downloads` blocks it, and granting that to untrusted content is the wrong way round.

## Two mistakes we made, so you do not

1. **An image-name pattern that excluded underscores.** Fifteen slides rendered with a silently missing screenshot, no console error, no gap in the layout, nothing to notice by clicking through a few slides. Accept `[A-Za-z0-9_.-]` in image names, and **assert that the count of unresolved images is zero** rather than trusting the page to look right.
2. **An unscoped `closest('[data-deck]')` in the click router.** On a page dedicated to one deck the mount element itself carries `data-deck`, so every click inside the viewer matched it and returned early: prev, next, notes, focus and the PDF button were all dead, on exactly the pages just built, with nothing thrown. Scope event delegation to the control you mean, and **test the effect of a click, not that the click landed**.

## Before you call it done

- Walk **every slide of every deck** in a real browser and assert zero unresolved images. Ours is 113 slides across 9 decks; the walk takes under a minute and found the bug above.
- Confirm the render frame has **no** `allow-scripts`, and that the parse frame has **no** `allow-same-origin`.
- Download a PDF and check the byte count against the file in the vault. Ours matches exactly at 2,220,725 bytes.
- Check that a deep link to a slide restores that deck and that slide.
- **Check what you published.** Read keys on the page are fine and are the point; a vault key on a page is a catastrophe, because it is write access. Grep the built site for vault-key shapes before every release, and note that a scan built for *sgit* credential shapes will not catch an unrelated API key sitting in a vault file, which is how we once nearly published an OpenRouter key.

## The prompt to hand the builder agent

Copy this, replace the uppercase placeholders, and give it to the agent that owns the site:

```
Add a deck viewer to SITE so the presentations in vault VAULT_ID play on the page,
read live with the published read key READ_KEY.

Read https://sgit.ai/briefs/vault-decks-on-a-site.md and
https://sgit.ai/vault/reading-a-vault-file.md first. A working implementation is
assets/vault-deck.js and assets/vault-embed.js on sgit.ai; copying it is expected.

The rule that governs the design: the viewer is the site's and the data is the
vault's. Every control belongs to the site. Vault content renders only inside
sandboxed opaque-origin iframes — the deck source in one with allow-scripts and
default-src 'none', the slide markup in one with scripting off entirely and only
data: images permitted. Never eval vault code in the page origin. Never put a
decrypted PDF in an iframe; decrypt it in the page and hand it to the browser's
own download.

The vault publishes decks/v2: a manifest at decks/decks.json or decks.json, deck
sources at decks/DECK_ID.js pushing {t, notes, html} onto S, screenshots at
deck/img/NAME.jpg referenced symbolically by a data-img attribute, the deck's CSS
in the style block of decks/shell.html, and PDFs at deck/FILE.pdf. If the vault
published only built decks, take the largest script block out of the deck's HTML
file and truncate it at the comment /* ---------- shell */.

The stage is 1600x900: size the frame to that and scale the element.

Done means: every slide of every deck walked in a browser with zero unresolved
images asserted, a PDF downloaded and byte-count-checked against the vault, deep
links restoring deck and slide, and the built site grepped for vault-key shapes.
Report the slide count, the deck count and the missing-image count.
```

Written from building exactly this, at [v0.2.67 and v0.2.68](../../admin/versions.md). If you follow it and something here is wrong, that is worth telling us, the last brief on this site was corrected by the team that read it, and [the correction sits above the mistake](vault-telemetry-append-lanes.md). [All briefs](index.md) · [Reading one file out of a vault](../vault/reading-a-vault-file.md) · [The live result](../../demos/vaults/aiuc-1-conformance/decks/index.md)



==============================================================================
# For graphs.sgit.ai: Fractal Semantic Graphs, and what to change

> A brief for the agent maintaining graphs.sgit.ai: the fractal claim on its boundaries page has the invariant backwards (grammar survives every zoom, the ontology is free to change), the name Fractal Semantic Graphs and its lineage, six places to link the sgit.ai page, four graph vaults missing from its evidence estate, a second cross-vault finding, three small corrections, and the prompt to paste.
>
> Page: https://sgit.ai/docs/briefs/graphs-sgit-ai-fractal-semantic-graphs.html

[Home](../../index.md) / [Docs](../index.md) / [Briefs](index.md) / For graphs.sgit.ai

**Surface:** a sibling site's pages, graphs.sgit.ai. [The three code surfaces →](../surfaces.md)

# Fractal Semantic Graphs: what graphs.sgit.ai should take from the sgit.ai page

A brief for the agent that maintains [graphs.sgit.ai](https://graphs.sgit.ai/). On 19 September 2026 sgit.ai published [**Fractal Semantic Graphs**](../../demos/fractal-graphs/index.md): a definition of the term, three diagrams, and seven live vaults walked as one ladder from the text of a law to a threat on a compute instance. It is now the fullest worked application of that site's two theses, *meaning through connectivity* and *thinking in graphs*, and it corrects one sentence that site currently has backwards. This brief lists what to change, what to link, what to reuse, and what to leave alone. Checked against graphs.sgit.ai v0.6.20 and its `llms.txt` on the date above.

**The one-line version.** Where graphs.sgit.ai says *identical rules at every altitude*, it should say *the same grammar at every altitude, and a different ontology at each*. Everything else in this brief follows from that distinction.

## 1. The correction: grammar is what survives the zoom, not schema

The boundaries page (`/v1/depth/boundaries.html`, section *Fractal is a precise claim, not a decoration*) defines the claim in a four-row table and a closing sentence. As published today:

| Row on the page | What it says now | The problem |
|---|---|---|
| **Self-similarity** | “The same node-and-edge grammar at every altitude. A property, a paragraph, a person, a national estate: same rules.” | Correct if *rules* means grammar. Read as schema, it describes a hierarchy. |
| **Recursion** | “Zoom into any node and it expands into a graph obeying identical rules, with no new format and no special case.” | Backwards. A node whose inside has identical types and verbs to its outside is a folder in a folder. The fractal case is the one where the inside has its own types, its own verbs, its own taxonomy: a new ontology, a special case, still joined by an edge to the level above. |
| **The test** | “If zooming in requires a different file format, a different validator, or a special case, the claim is false.” | Half right. A different *validator* or a different *grammar* (the graph stops being a semantic graph and becomes JSON-plus-prose) does break the claim. A different *schema* is the claim working. |
| **The source quote, same section** | “there might be an article that is so meaty that it requires its own ontology and taxonomy, and that's the power of the fractal element.” | This is the author saying the right thing, on the same page, two paragraphs below the table that says the other. The page contradicts itself and the quote is the side to keep. |

The same wording appears in two more places and should change with it: sentence 9 of *The thesis in nine sentences* in `llms.txt` (“zoom into any node and it expands into a graph obeying identical rules”), and the *For an agent* block at the foot of the boundaries page (“if zooming into a node needs a new format or a special case, the system is hierarchical, not fractal”).

### Proposed replacement text

For the table, in the page's own register:

| Claim | What it commits you to |
|---|---|
| **Self-similarity** | The same *grammar* at every altitude: every edge a verb with a named inverse, meaning in connectivity not properties, supersede never delete, provenance kept. Never the same schema. A property, a paragraph, a person and a national estate share the grammar and nothing else. |
| **Scale invariance** | One validator, one query engine, one provenance rule. They check the grammar, so they run unchanged over any ontology. |
| **Composition** | Graphs combine into graphs by declared edges between them, never by merging their ontologies. Risk registers of risk registers, each in its owner's vocabulary. |
| **Recursion** | Zoom into any node and it expands into a graph with *its own* ontology: its own node types, verbs and taxonomy, chosen by whoever owns that altitude, still obeying the shared grammar and still joined by an edge to the node you opened. The meaning of a node is supplied by the ontology at the altitude where it sits. |

For the test, one sentence in two halves: *If zooming in lands you in the same types, verbs and rules all the way down, you have a hierarchy, not a fractal; a folder tree is the clean example. If zooming in needs a different grammar, so that the inside is no longer a semantic graph, the claim is false. Between those two, every zoom that opens a new ontology joined by an edge to the last is the claim working.*

For the agent block and sentence 9: *Fractal means the grammar survives every zoom and the ontology does not have to: zoom into any node and it expands into a semantic graph with its own types and verbs, connected by an edge to the level above.*

## 2. What to adopt from the sgit.ai page

Four things on the sgit.ai page are stated more sharply than anywhere on graphs.sgit.ai today, and belong there.

- **The name and its lineage.** The term is *Fractal Semantic Graphs*. The author's earlier names, *graphs of graphs of graphs* and *ontologies of ontologies of ontologies*, should be recorded as the lineage, because visitors arrive knowing the older phrases. Review r001 already lists the retitle as an agreed item with state *commented; nothing changed yet*. This brief is the input for doing it.
- **Where a node's meaning comes from.** *Meaning through connectivity* is the site's thesis. The sgit.ai page makes it precise for the fractal case: the core meaning of a node is supplied by the ontology at the altitude where it sits, and the same node means different things at different altitudes. Article 9 is a binding provision in a graph of instruments, a container of paragraphs inside the regulation, and a source of definitions to the paragraph that cites it. Same node, different edges around it at each level. That sentence should sit next to the thesis on the home page.
- **Every connection should teach you something, and one of them is a jump.** Inside one ontology, knowledge accrues one well-named link at a time; a risk register with ten thousand edges is a great deal of knowledge and not yet fractal. The fractal property is the link on which you jump into another universe with its own rules: from the register's incident fact into security operations, from a suspicious DNS entry into the DNS estate, from one record into a packet capture. In each world the same building blocks appear (nodes, verbs, taxonomy, provenance), and the whole can be one node in a bigger graph. The sgit.ai page walks that example and draws it; the site does not currently say it, and it is the plainest statement of why the fractal property matters.
- **Nobody is forced to conform.** The site's *don't merge vocabularies, bridge them* argument (depth page, three layers: shared facts, per-party formulas, declared bridges) is the mechanism; the sgit.ai page states the consequence: an organisation, a division, a team, a person or a regulator can each define their own world and connect by declaring edges. Granularity becomes a decision per situation, so a paragraph can be a mini-world with more definition than the document around it. The two pages should point at each other.

Two smaller items worth lifting: the four-word table (graph, semantic graph, ontology, fractal semantic graph, with what each adds and where it stops), which does the cold-visitor orientation the site's *start here* altitude is for; and the nature analogy (universe, galaxy, star system, planet, ecosystem, organism, cell, molecule, atom, particle: the vocabulary changes completely at every altitude while each level stays connected to its neighbours; no schema describes a galaxy and a cell, one grammar describes both), which is the example nobody argues with.

## 3. Where to link the page from

| graphs.sgit.ai page | Link to add | Why there |
|---|---|---|
| Home, beside the thesis | `https://sgit.ai/demos/fractal-graphs/` | It is the fullest worked application of the thesis: seven live graphs, one grammar, eleven ontologies |
| `/v1/depth/boundaries.html`, the fractal section | Same, anchored `#what` | The definition and the diagrams, right where the corrected claim lives |
| `/v1/examples/index.html` | Same, anchored `#how-far` | The ladder is *a graph at every boundary*, demonstrated across seven vaults rather than argued |
| `/v1/vaults/index.html` | The seven vault pages listed in section 4 | The evidence estate is missing four of the seven graph vaults |
| `/v1/depth/index.html`, the don't-merge argument | Same, anchored `#everything` | The consequence of the argument, stated for a reader |
| `llms.txt`, *Worked graphs* | `https://sgit.ai/demos/fractal-graphs/index.md` | The markdown twin, for agents; it carries the same content with no chrome |

## 4. What to reuse, and the evidence estate to refresh

**The diagrams.** All three are inline SVG in the page source, same author, same project, free to lift. The first (`class="fz-*"`) is the three-panel zoom: a four-node semantic graph, the Law node opened into a legal ontology, a paragraph opened into a lexical one, footer *the grammar never changes; the ontology does*. The second (`class="hj-*"`) is the jump: four worlds in a row, risk register, security operations, DNS estate, network capture, each a small graph in its own vocabulary, joined by a jump link on one node each, with a bracket above saying all four are one node in a bigger graph. The third (`class="lad-*"`) is the eleven-rung ladder with a real link per rung. Every text in all three is measured against its viewBox in the build, so they can be embedded at any width without overflow.

**The screenshots.** Under `https://sgit.ai/demos/vaults/<slug>/images/`, taken from the vaults with their published read keys. The Standards Atlas set (`graph.webp`, `graph-alt1.webp`, `beyond.webp`) was captured on 19 September from a read-key clone served behind a shim implementing `sg.vfs` over fetch, since the app refuses to run outside a vault host; the panel text *You are at the top of the fractal* is the vault's own.

**The vaults.** The evidence estate on graphs.sgit.ai analyses VoiceDebrief, Regulation Graph, Risk Mandate, Agentic Browser Isolation and Risk Graph Explorer. The ladder uses seven graph vaults; the four not yet on graphs.sgit.ai are marked. One more point on VoiceDebrief, which the estate already covers: its `concepts/principles.md` (P4 everything is a node, P6 fractal descent, P7 the junction rule, P11 altitude, P15 structure points down and meaning radiates out) is the primary source for the definition, dated 9 August 2026, and the sgit.ai page now quotes it as such. The graphs.sgit.ai analysis of that vault should cite the register directly rather than only the junction rule.

| Vault | Id | Altitude on the ladder | On graphs.sgit.ai | sgit.ai page |
|---|---|---|---|---|
| Regulation Graph | `73heuprz` | Law | yes | [regulation-graph](../../demos/vaults/regulation-graph/index.md) |
| Standards Atlas GDPR | `4zv4bvmu` | Law and its interpretation | **no** | [standards-atlas-gdpr](../../demos/vaults/standards-atlas-gdpr/index.md) |
| AIUC-1 conformance layer | `2wzct4k7` | Standard, evidence, policy | **no** | [aiuc-1-conformance](../../demos/vaults/aiuc-1-conformance/index.md) |
| Risk Graph Explorer | `3simlnqe` | Fact, risk, acceptance | yes | [risk-graph-explorer](../../demos/vaults/risk-graph-explorer/index.md) |
| Agentic Browser Isolation | `0610gsp9` | Owner, at seven altitudes | yes | [agentic-browser-isolation](../../demos/vaults/agentic-browser-isolation/index.md) |
| Licence to Operate | `posrhzp3` | Policy, spent turn by turn | **no** | [licence-to-operate](../../demos/vaults/licence-to-operate/index.md) |
| ThreatModCon 2025 | `0ict6flm` | System down to compute | **no** | [threatmodcon-2025](../../demos/vaults/threatmodcon-2025/index.md) |

**A second cross-vault finding.** The site's first cross-vault finding is the capability scale. The AIUC-1 conformance layer supplies a second of a different kind: it resolves 62 of the standard's 1,126 published crosswalks into Regulation Graph node ids, node to node across two vaults with a CELEX identifier and a hash on each edge, and the join returns something neither vault knew alone: 8 of the 27 articles reached are amended by Regulation (EU) 2026/1744, so the crosswalk was written against the pre-amendment text. That is *meaning through connectivity* producing a fact, and it belongs in the vaults chapter.

**ThreatModCon is the answer to “how far down”.** Eleven linked threat models, Customer to Compute, 51 nodes and 179 threats, with a single SQL injection traced from the method it lives in to the revenue it puts at risk. The site's examples currently stop at the estate; this vault reaches the method and the runtime, and says plainly that those bottom rungs are modelled rather than imported.

## 5. Small corrections found on the way

- **Five or seven.** `llms.txt` gives Agentic Browser Isolation *5 stakeholder altitudes* under *Worked graphs* and *7 stakeholder altitudes* under *The book*. The vault's own page says seven.
- **sentinel.sgit.ai does not resolve.** The network section of `llms.txt` lists bridges to *sentinel.sgit.ai*; the site is `sg-sentinel.sgit.ai`. Recorded on sgit.ai's network page on 21 August and still present on 19 September.
- **The evidence estate's count.** Wherever the site counts the graph vaults published on sgit.ai, the number is now seven, and sgit.ai's full list is thirty at `https://sgit.ai/demos/vaults/llms.txt`.

## 6. What not to change

The ban on `relates-to`, the verb-with-inverse rule, *don't merge vocabularies*, *supersede never delete*, *never render the whole graph*, the 10,000-hours story, the four situations where the argument is wrong. The sgit.ai page rests on all of these and quotes several; none of them moves. The only thing this brief asks the site to change about its argument is the one word, and the argument gets stronger for it: *meaning through connectivity* was always a claim about edges, not about a shared schema, and the fractal property is that claim applied at every altitude at once.

## 7. The prompt

For the agent working on graphs.sgit.ai. Paste as is.

```
You maintain graphs.sgit.ai. Read this brief first:
  https://sgit.ai/docs/briefs/graphs-sgit-ai-fractal-semantic-graphs.md
and then the page it is about, which is now the fullest worked application of this
site's two theses (meaning through connectivity, thinking in graphs):
  https://sgit.ai/demos/fractal-graphs/index.md   (markdown twin)
  https://sgit.ai/demos/fractal-graphs/            (the page, with the three diagrams)

Do these, in this order, as one release with a review entry in the site's own
reviews workflow (the retitle is already item 1 of r001, state "commented"):

1. Correct the fractal claim. On /v1/depth/boundaries.html rewrite the four-row table
   (Self-similarity, Scale invariance, Composition, Recursion) and the "For an agent"
   block using the replacement text in section 1 of the brief. The invariant across
   zooms is the GRAMMAR (verb edges with inverses, meaning in connectivity, supersede
   never delete, provenance); the ONTOLOGY is free to change at every altitude, and a
   system whose types, verbs and rules are identical all the way down is a hierarchy,
   not a fractal. Keep the author's quote about the article "so meaty that it requires
   its own ontology and taxonomy": it is the side of the page that was right. Change
   sentence 9 of the nine-sentence thesis in llms.txt to match.

2. Adopt the name Fractal Semantic Graphs across the site, with the lineage recorded
   ("graphs of graphs of graphs", "ontologies of ontologies of ontologies").

3. Add to the home page, beside the thesis, the precise form of it for the fractal
   case: the meaning of a node is supplied by the ontology at the altitude where it
   sits, so the same node means different things at different altitudes. Add "the
   deeper you go, the more you learn" with the folder-tree contrast, and "nobody is
   forced to conform" as the stated consequence of the don't-merge argument.

4. Link the sgit.ai page from the six places in section 3 of the brief.

5. Refresh the evidence estate: add the four graph vaults not yet analysed (Standards
   Atlas GDPR 4zv4bvmu, AIUC-1 conformance layer 2wzct4k7, Licence to Operate posrhzp3,
   ThreatModCon 2025 0ict6flm), each with a page in the vaults chapter in the existing
   format, and record the AIUC-1 crosswalk join (62 resolved, 8 amended articles found)
   as the site's second cross-vault finding.

6. Reuse the three inline SVG diagrams from the sgit.ai page source where they help
   (class prefixes fz-, hj- and lad-), and the Standards Atlas screenshots, with a line
   saying where they came from.

7. Fix the small items in section 5: five versus seven stakeholder altitudes,
   sentinel.sgit.ai versus sg-sentinel.sgit.ai, and the count of graph vaults.

Do not change the grammar rules, the don't-merge argument, the 10,000-hours story or
the four situations where the argument is wrong. Do not use em-dashes in new prose.
Every number you write must come from the vault or page it describes on the day you
write it, and say the date. Report what you changed, what you left, and anything in
the brief you disagree with, before pushing.
```

Written 19 September 2026 against graphs.sgit.ai v0.6.20. The sgit.ai page it refers to was at site v0.2.95; its version and date are in the chip at the top of the page.

[← Briefs](index.md)[Fractal Semantic Graphs →](../../demos/fractal-graphs/index.md)



==============================================================================
# An infographic of the published vaults, build brief

> A brief for a companion to the network infographic, grouping the 26 published vaults by use case and industry, starting with the two blockers upstream of any image: neither grouping exists in vaults.json yet, and the network infographic it copies has already gone stale in its own headline count.
>
> Page: https://sgit.ai/docs/briefs/vault-map-infographic.html

[Home](../../index.md) / [Docs](../index.md) / [Briefs](index.md) / The vault map infographic

**Surface:** a published image, and the data behind it. [The three code surfaces →](../surfaces.md)

# An infographic of the published vaults, grouped by use case and industry

A brief for producing a companion to the network infographic: the same treatment applied to the **26 published vaults** rather than to the sites, grouped by **what someone is trying to do** and **the industry they are in**. It is written to be executed, and it opens with the two things that will otherwise sink it. The groupings do not exist as data yet, and an infographic is a snapshot that rots.

**Do not start with the picture.** Two blockers below are upstream of any image being generated. Fix them first and the infographic becomes a rendering job; skip them and an image model will invent the groupings, which is the one failure nobody will notice until a customer reads it back to us.

## Blocker one: the network infographic is already wrong

The companion image this one is modelled on carries a footer reading **“19 sites · 18 published · 1 forthcoming”**, and lists `skills.sgit.ai` as *Forthcoming*. Both were true when it was generated. Today [the network](../../network/index.md) lists **27 sites** and skills.sgit.ai has been live for some time, so a picture that is roughly a week old is now wrong in its headline number and in one of its cells.

That is not an argument against making it. It is the constraint the work has to be designed around:

- **Every count in the image must be computed from the data at generation time** and pasted in, never estimated, never carried over from a previous version.
- **The image carries the version and date it was generated**, in the footer, in the same way [every vault app carries its version](../guidance/index.md#versions). A picture with a stamp is a snapshot; one without is a claim.
- **The page that publishes it links to the live list beside it**, so a reader who wants today's answer has one click to it. The infographic is the overview; [the table](../../demos/vaults/index.md) is the truth.
- **Regenerating is a scheduled chore, not an event.** Add it to the release checklist as a diff: if the vault count changed, the image is stale.

## Blocker two: neither requested grouping exists yet

The brief asks for **use case** and **industry**. Checked against `admin/content/vaults.json`, which is what the vaults table and [the catalogue](../../demos/vaults/llms.txt) are generated from, the fields today are:

| Field | Coverage | What it actually is |
|---|---|---|
| `category` | **26 of 26** | The vault's *shape*, not its use case, Application (5), Analysis (5), Record (4), Reference (4), Presentation (3), Briefing (3), Report (1), Gallery (1). Useful, and not what was asked for |
| `job` | **6 of 26** | The closest thing to a use case that exists (“Publish a standard as data”, “Pitch an investor”, “Hand over a report”), but it was added for the homepage bands and covers under a quarter of them |
| `industry` | **0 of 26** | Does not exist |

**So the first deliverable is not an image, it is two fields.** Add `use_case` and `industry` to every entry in `vaults.json`, and the infographic becomes a view over data the site already publishes, which is the rule the rest of this estate runs on: *indexes are generated from the data they index, because an index maintained by hand becomes a lie on a schedule.*

- **Write both fields from the vault, not from its title.** Open each one, read what it does, and say what job it does for whom. The pages under [Published vaults](../../demos/vaults/index.md) already contain that judgement in prose. This is turning it into data.
- **Keep the vocabularies small and closed.** Six to eight use cases and six to eight industries, reused; a taxonomy where most values appear once is not a taxonomy. Write the allowed values down in the file and have the build fail on an unknown one.
- **Be honest where a vault has no industry.** Several are method demonstrations that belong to no sector. `"industry": "cross-industry"` is a real answer; inventing “FinTech” because a vault mentions money is not.
- **Do not delete `category`.** Shape and use case are different questions and the table uses shape. Add, do not replace.

## What the picture has to show

Match the network infographic so the two read as a pair: dark ground, one luminous shared foundation at the top, numbered columns beneath it, a footer of counts, and a horizontal band of cross-links near the bottom.

| Element | Content |
|---|---|
| **The foundation** | What every vault shares: encrypted files, version history, and a published read key that is the whole credential. The network image put “sgit.ai vaults” here; this one can say **one vault format** |
| **Primary grouping, columns** | **Use case.** Each column is a job somebody is trying to do, with the vaults that do it listed as cells: name plus one short line, exactly as the sites image does |
| **Secondary grouping, a mark on each cell** | **Industry**, as a small tag or colour key rather than a second set of columns. Two nested column systems in one image is unreadable; a legend is not |
| **The band** | Genuine relationships between vaults, the conformance layer forking the catalogue, the Risk Graph Explorer sharing the licence-to-operate acceptance model. **Carry the same disclaimer the sites image carries**: illustrative links, not deployed integrations |
| **The footer** | The computed counts, the site version and the date. Nothing typed by hand |

## The accuracy rules, because an image model will not follow them on its own

An image model renders text as shapes. It will misspell a domain, drop a hyphen, invent a plausible vault that does not exist, and produce a confident number that came from nowhere, and none of that throws an error.

1. **Generate the caption text from the data first**, as a list, and treat the image as a rendering of that list. If the list and the image disagree, the image is wrong.
2. **Read every string in the output back against `vaults.json`**: every vault name, every count, every label. Character by character on the names.
3. **Count the cells.** If the data says 26 vaults and the picture shows 24, it dropped two, and it will not tell you which.
4. **No vault appears that is not in the file.** A generated name that reads plausibly is the most dangerous output this process can produce.
5. **If the model cannot render the text reliably, render the text separately.** Generating the artwork and setting the labels as real text over it is a legitimate and more honest answer than fighting the model.

## Publishing it on this site

- **The validator bans `<img src=>`.** Images here go through the `data-shot` mechanism that `assets/shots.js` fills, because a declarative image reference cannot be served when a page is rendered inside a vault. Use the existing pipeline; do not add an exception for this one.
- **Write real alt text**, and treat it as the accessible equivalent rather than a caption: an infographic whose content exists only as pixels is invisible to a search engine, to `llms-full.txt` and to any agent reading this site, which is the same gap the video pages had to state.
- **Put the grouped list on the page in HTML too**, under or beside the image. Then the picture is the overview and the text is the content, and the `.md` twin carries the substance rather than a broken reference to a picture.
- **State how it was made.** The network image was generated by an image model; say so on the page. This site's whole method is that a reader can check the provenance of what it publishes.

## The prompt to hand the agent

```
Produce a vault map infographic for sgit.ai, as a companion to the existing
network infographic, grouping the published vaults by USE CASE and INDUSTRY.

Read https://sgit.ai/docs/briefs/vault-map-infographic.md first. Do the two
upstream steps before generating any image.

STEP 1 — the data. admin/content/vaults.json has category on all 26 vaults, job
on 6, and no industry field at all. Neither requested grouping exists yet. Add
use_case and industry to every entry, written from the vault itself and not from
its title, using a closed vocabulary of 6-8 values each, declared in the file,
with the build failing on an unknown value. Keep category — shape and use case
are different questions. Use "cross-industry" where a vault genuinely serves no
sector; do not invent one.

STEP 2 — the caption list. Generate the full text of the infographic from
vaults.json as a plain list: every column heading, every cell, every count.
This list is the source of truth; the image is a rendering of it.

STEP 3 — the image. Match the network infographic: dark ground, one shared
foundation at the top, numbered columns for use cases, industry as a tag or
colour key rather than a second column system, a cross-links band carrying the
same "illustrative, not deployed integrations" disclaimer, and a footer with the
computed counts plus the site version and date.

STEP 4 — check it. Read every string in the image back against vaults.json,
character by character on the names. Count the cells against the vault count. No
vault may appear that is not in the file. If the model cannot render text
reliably, render the artwork and set the labels as real text over it.

STEP 5 — publish it. Use the data-shot pipeline, never an img src, which the
validator bans. Write real alt text. Put the grouped list on the page as HTML as
well, so the markdown twin carries the substance. Say on the page that the image
was generated by an image model.

Report: the two vocabularies you chose, how many vaults landed in each value,
and any vault whose use case or industry you could not determine from its
contents.
```

The companion piece is the network infographic, which is what this one should look like and also what it should learn from. It is a good picture with a footer that has already gone stale. [All briefs](index.md) · [Working on a vault: start here](../guidance/index.md) · [The published vaults](../../demos/vaults/index.md)



==============================================================================
# Markdown and file viewers in a vault: what not to build (build brief)

> Two of the most common asks) a markdown viewer and a file/folder browser with raw views, are already in the vault platform. The ladder from zero code to a full app, the markdown rules that actually catch people, the raw-always contract for a file explorer, and the prompt to hand the builder.
>
> Page: https://sgit.ai/docs/briefs/markdown-and-file-viewers.html

[Home](../../index.md) / [Briefs](index.md) / Markdown and file viewers

**Surface:** inside a vault, `_page.json`, markdown, or a vault app. [The other surfaces →](../surfaces.md)

# Markdown and file viewers in a vault: what not to build

Two of the most common things an agent is asked to add to a vault, **a markdown viewer** and **a file/folder browser with raw views**, already exist in the vault platform. Most requests for them are answered by publishing files in the right shape and writing no code at all. This brief says which surface renders what, gives the ladder from zero code to a full app, and states the one contract to honour if you do build your own.

**Read this first, and you may be finished.** The browse view already renders every `.md` file in a vault, and the file tree on its left *is* the folder viewer. If an agent is about to write a markdown parser or a file explorer into a vault app, it is almost certainly solving a problem the host solved already, and the version it writes will be worse, bigger, and will not match the rest of the estate.

## The ladder: stop at the first rung that works

|  | You write | You get | Reach for it when |
|---|---|---|---|
| **0 · Nothing** | `.md` files | Rendered markdown, a file tree, tabbed previews, internal links that open as tabs, print | Prose: articles, reports, specs, notes, READMEs. **Start here every time** |
| **1 · A layout** | `_page.json` | Hero, sections, galleries, slideshows, card hubs, embedded PDFs, themes, and a `markdown` component that renders one of your `.md` files inside the layout | You want a designed page rather than a document, or a hub that navigates to folders |
| **2 · An app** | `index.html` + `app.json` | Anything, computed views, filters, queries over your own data | Only when the answer depends on *computing* something the host cannot know |
| **3 · A site viewer** | A viewer on your website | Vault content on a public web page, outside any vault host | The content must live on a normal site. See [the decks brief](vault-decks-on-a-site.md) |

The reference for rungs 0 and 1 is [**Publishing content without code**](../vault/content-authoring.md); for rung 2 it is [Building vault apps](../vault/vault-apps.md) and [the window.sg bridge](../vault/sg-bridge.md). This page is the decision, not the syntax.

## Pattern one: the markdown viewer you do not write

Markdown is rendered natively on **three** surfaces, and none of them requires code:

- **Any `.md` file in the browse view**: click it in the tree, it opens as a rendered tab. Nothing to register.
- **The `markdown` component in `_page.json`**: `{"type":"markdown","props":{"file":"overview.md"}}` drops a rendered document into a designed page, or `"text"` for an inline string. This is how you get prose *inside* a layout without duplicating it.
- **A markdown file as the vault's front door**: the browse view auto-opens the alphabetically first file, so name the entry point `README.md` or `00-INDEX.md`. A root `_page.json` takes priority over both.

### The rules that actually catch people

- **Raw HTML is stripped and shows as escaped text.** This is the single most common failure. Write flat markdown; do not reach for a `div` when a heading will do.
- **Size images with the pipe syntax, not HTML**: `![caption|400](img.png)`, `|60%`, `|800x600`. It lives inside the alt text, so the URL stays clean and the file still renders in any other markdown tool.
- **Link a folder through its file, not the folder**: `folder/README.md`, never `folder/`. Which file a bare folder link opens depends on sort order, and that is not a contract.
- **Nested lists and task lists are not supported.** Neither is HTML. Plan the document around that rather than discovering it after a push.
- **Image paths are relative to the `.md` file**, not to the vault root.
- **No external URLs for vault assets.** Vault files only, which is what makes a published document unable to phone home, and is a feature rather than a limitation.

Front matter adds print control: a `---`-delimited block at the very top can set `page_break_before` and carry a literal `print_css` block, so a document prints as a document. That plus the theme options is usually the whole gap between “a markdown file” and “a deliverable somebody can hand to a client”.

## Pattern two: the file and folder viewer, and the raw view

The browse view is already a two-pane explorer: tree on the left, tabbed preview on the right, with `_page.json` pages carrying a `{ } Source` toggle that flips the rendered layout back to its JSON. **If that is enough, you are done.**

You need your own explorer only when the vault's files mean something the host cannot know, when a `.json` file is not just JSON but a control, a policy, a graph node, and you want to render it *as* that. [The AIUC-1 conformance vault](../../demos/vaults/aiuc-1-conformance/index.md) does exactly this, and states the principle in its own source:

> “A manifest generated at build time, files fetched on click, raw always available and a data view where the build understands the file. **Raw is the point, a catalog that asks to be trusted has to be readable in the form it was written.**”

That is the contract, and it is worth adopting whole:

| Rule | Why |
|---|---|
| **Raw is always available, for every file** | A reader that can only show you its own interpretation is asking to be trusted. One that shows you the bytes is offering to be checked. Never let a rendered view be the only way to see a file |
| **A reader is an addition, never a replacement** | Files the build understands get a view *as well as* raw. Files it does not understand still open, a file explorer that hides what it cannot parse is hiding the interesting cases |
| **Drive the tree from a manifest built at build time** | Walking the vault at runtime to list files is slow and re-derives on every load what the build already knew. Generate the folder/file manifest when you build, ship it as data |
| **Fetch a file on click, not up front** | A vault can be tens of megabytes. The tree costs the manifest; a file costs that file |
| **The empty state tells the reader the deal** | AIUC-1's says it in one line: *“Pick a file on the left. Raw is always there; files the build understands also get their own view.”* |

The same instinct runs through the rest of the estate: `_page.json` has `{ } Source`, every page on this website has a `.md` twin, and the deck viewer offers the printed PDF beside the rendered slides. **Anything rendered should be one click from the thing it was rendered from.**

## Before you call it done

- Did you actually need to build anything? If the answer is markdown in a tree, rung 0 was the answer and the app is a liability.
- Open every `.md` file in the browse view and look for escaped HTML. That is stripped markup, and it means the document was authored against the wrong renderer.
- Every folder link goes to a file, not a folder.
- If you built an explorer: every file opens, including the ones with no reader, and raw is reachable for all of them.
- Check what you published. [The publishing method](../../demos/vaults/publishing.md) applies here as much as anywhere, read keys are publishable, vault keys never are, and a scan for sgit credential shapes will not catch an unrelated API key sitting in a vault file.

## The prompt to hand the builder agent

```
Make the documents in vault VAULT_ID readable.

Read https://sgit.ai/briefs/markdown-and-file-viewers.md first, then
https://sgit.ai/vault/content-authoring.md for the syntax.

DO NOT WRITE A MARKDOWN RENDERER OR A FILE EXPLORER. Both exist in the vault
platform already. Climb this ladder and stop at the first rung that works:

0. Publish .md files. The browse view renders them and its file tree is the
     folder viewer. Name the entry point README.md or 00-INDEX.md.
1. Add a _page.json if you need a designed page rather than a document. Use
     its markdown component to pull in the .md files you already wrote, so the
     prose exists once.
2. Only build an app if a view has to COMPUTE something the host cannot know.

Markdown rules that will bite you: raw HTML is stripped and shows as escaped
text; size images with the pipe syntax inside the alt text; link folders through
folder/README.md and never folder/; nested lists and task lists are unsupported;
image paths are relative to the .md file; no external URLs.

If you do build a file view, raw is always available for every file, a reader is
an addition and never a replacement, the tree is driven by a manifest generated
at build time, and files are fetched on click.

Report which rung you stopped at and why the rung below it was not enough.
```

Written from the two patterns as they are actually published across the vaults on this site. The syntax reference is [Publishing content without code](../vault/content-authoring.md); the sibling brief for putting vault content on a public website is [Decks from a vault, on a site](vault-decks-on-a-site.md). [All briefs](index.md)



==============================================================================
# SG/Vault & the vault platform, sgit.ai

> The official working documentation for the SGraph vault platform: the SG/Vault browser app, the SG/Send zero-knowledge API, and vault apps.
>
> Page: https://sgit.ai/docs/vault/index.html

[Home](../../index.md) / SG/Vault

# SG/Vault & the vault platform

This section is, for now, the official documentation for the SGraph vault platform: the **SG/Vault** browser app, the **SG/Send** zero-knowledge API, and **vault apps**: websites and applications that live *inside* encrypted vaults. Product background lives at [sgraph.ai](https://sgraph.ai); the working documentation lives here.

## What SG/Vault is

SG/Vault is the browser client for the same vaults sgit manages from the terminal. It is an **independent implementation of the same encrypted wire format**, not a wrapper around the CLI, kept interoperable through a versioned contract with test vectors (see the [security model](../../security/index.md#interop)).

You open a vault by its key, carried in the URL *fragment* (the part after `#`):

```
https://vault.sgraph.ai/en-gb/#<vault-key>
# the fragment never leaves the browser — it is not sent in the HTTP request,
# so the server serves the app without ever seeing the key
```

From there you get a file browser over the decrypted vault (history, branches, editing) and, if the vault contains an app, **App Mode**: the vault boots straight into its own user interface.

## The three pieces

| Piece | What it is | Where it runs |
|---|---|---|
| **sgit** | The CLI, git workflows over encrypted vaults | Your terminal, your agents' sessions |
| **SG/Vault** | The browser client, browse, edit, review, App Mode | Any browser; all crypto via Web Crypto, client-side |
| **SG/Send** | The transfer API, stores ciphertext under opaque IDs | The server; the only piece that never sees plaintext |

## Vault apps: the app *is* the vault

A vault can contain an `index.html` plus an `app.json`. When the vault opens, the app launches, full-screen, talking to the vault through a runtime bridge, with the encrypted blob serving as both the storage and the distribution mechanism. Sharing the vault link *is* deploying the app.

**You are looking at one.** This entire website is a vault app: generated pages, shared assets loaded through the bridge, deployed by `sgit push`. The [admin section](../../admin/index.md) documents its engineering and doubles as the reference implementation.

## Three on-ramps

| You want to… | Use | Code needed |
|---|---|---|
| Publish documents, galleries, hub pages | [Markdown + `_page.json`](content-authoring.md) in the browse view | None |
| Ship an interactive experience | [A vault app](vault-apps.md) on the [`window.sg` bridge](sg-bridge.md) | HTML/JS |
| Automate, script, collaborate, back up | The [sgit CLI](../index.md), plus [git side-by-side](git-and-vaults.md) and [static hosting](static-hosting.md) | A terminal |

[Sub-vaults](sub-vaults.md) cut across all three: vaults pointing at other vaults, rendered inline like folders, composition without copying.

## In this section

## Publish

[Content without codeMarkdown + _page.json layouts, themes, print](content-authoring.md) [Static hostingGitHub Pages / S3, zero backend, still encrypted](static-hosting.md)

## Build

[Building vault appsThe project shape, app.json, and the authoring contract](vault-apps.md) [The window.sg bridgeThe runtime API, permissions, and the sovereignty rail](sg-bridge.md)

## Compose & integrate

[Sub-vaultsVaults inside vaults, links, embeds, extract & seed](sub-vaults.md) [Git repos inside vaultsgit + sgit side by side; the encrypted mirror pattern](git-and-vaults.md)

[Building vault apps →](vault-apps.md)



==============================================================================
# Building vault apps, SG/Vault

> How to build apps that live inside encrypted vaults: the project shape, app.json, the authoring contract, and shipping with sgit push.
>
> Page: https://sgit.ai/docs/vault/vault-apps.html

[Home](../../index.md) / [SG/Vault](index.md) / Vault apps

**Surface:** an HTML vault app, inside a vault. [The other surfaces →](../surfaces.md)

# Building vault apps

A vault app is a single `index.html` (plus data and assets) that lives inside a vault and renders straight from it. The experience and the security are the same artifact: the app ships encrypted, the link-holder holds the key, and the server never sees the page you're reading.

## The project shape

```
my-vault/
├── index.html          # the app — self-contained entry point
├── app.json            # auto-launch config (below)
├── content.json        # editable content, separate from the app
├── assets/             # css / js, loaded through the bridge
└── <your data>         # the files the app presents
```

Keep content in data files, not in HTML, so you (or an agent) can edit captions, prose, and structure without touching the app. Then the manifest (preferred location `.vault/app.json`; a legacy root `app.json` is still read):

```
{
  "entry":       "index.html",
  "present":     true,        # boot into App Mode instead of the file browser
  "title":       "My app",
  "permissions": { "fs": { "read": true } },
  "hud":         { "mode": "full" }
}
```

One rule with teeth: **an app cannot write its own manifest**: `.vault/**` and the legacy root `app.json` are a protected floor (`EPROTECTED`). The manifest *is* the grant; letting an app edit it would defeat the model. Edit it via the vault browser or sgit.

## The authoring contract

Vault pages render inside a sandboxed frame, and the browser fetches declarative resources *before* the vault bridge can install. Anything declarative pointing at a vault path will fail. The contract:

- **No** `<link rel="stylesheet" href="../../vault/…">`, `<script src="../../vault/…">`, or `<img src="../../vault/…">` against vault files, inline it, or load it from JS through the bridge (`sg.loadCss` / `sg.loadJs`, or read + inject via `sg.vfs.readText`; set `img.src` from JS).
- **No external resources at all**: no CDNs, fonts, or analytics. A vault app is self-contained by construction; inline SVG is the graphics format.
- **`fetch()` of vault paths does not work**: use `sg.vfs.readText(path)` / `sg.vfs.read(path)`. Plain `fetch` is only useful as a fallback for static hosting.
- **Plain `<a href>` links between vault pages work**: the host intercepts clicks and routes them, so multi-page sites navigate normally (this site is the proof). Hash anchors work too; **query strings don't** (`page.html?x=1` lands on the broken-link overlay), and never assign `location.hash` from JS, the sandboxed frame re-navigates.
- **Signal readiness**: post `{type:'sg-app-ready'}` to the parent when your page has rendered (in the error path too), or users stare at the host's loading overlay. The host also watches for blank apps: ~2.5 s after load with nothing painted, it tells the user so, if you legitimately render late, paint a spinner first.
- **Provide fallbacks**: embed critical styles inline and degrade gracefully, so the page stays readable if the bridge is slow or absent.

## Ship it with sgit

```
$ sgit clone <vault-key> my-app     # or sgit create my-app
# … build index.html, app.json, assets …
$ sgit commit -m "app v1"
$ sgit push                          # deployment == pushing the vault
```

There is no separate hosting step, no build server, no CDN configuration. The vault is the deployment target, the version history, and the rollback mechanism (`sgit history revert`) in one.

## The reference implementation

This website follows every rule on this page and carries its own build system in-vault: a page generator, a validation suite (contract scan, link check, JS parse check), and a versioned release process. Start at [admin & engineering](../../admin/index.md) and read `admin/build/`, cloning this vault gives you a complete working example.

[← SG/Vault & the platform](index.md)[The window.sg bridge →](sg-bridge.md)



==============================================================================
# The window.sg bridge, SG/Vault

> The vault app runtime: sg.* namespaces, the deny-by-default permission model, and the capabilities the host chrome provides for free.
>
> Page: https://sgit.ai/docs/vault/sg-bridge.html

[Home](../../index.md) / [SG/Vault](index.md) / The bridge

**Surface:** an HTML vault app, inside a vault. [The other surfaces →](../surfaces.md)

# The `window.sg` bridge

Inside App Mode, the host injects a bridge object, `window.sg`, that gives your page mediated access to the vault and to host capabilities. It installs synchronously while `<head>` parses, so any inline script can use it. The app frame never holds the vault key: every operation goes through the host, which owns the crypto and the consent UI.

## Namespaces at a glance

| Namespace | What it does | Grant |
|---|---|---|
| `sg.vfs` | `read` / `readText` / `list` / `write` / host-fulfilled `download`. Writes cap at ~3 MB (`EFBIG`); reads have no cap | `fs.read` / `fs.write` |
| `sg.loadCss` / `sg.loadJs` | Top-level functions (not under `vfs`): the sanctioned way to load vault CSS/JS; injects into `<head>` | rides `fs.read`: no separate verb |
| `sg.fs` | `move` (grant needed on both paths) / `delete` / `mkdir` | `fs.*` + first-use consent |
| `sg.vault` | Cross-vault lifecycle: `create(opts)` (options object, `label`, `seedFrom`, `returnKey`, `custody`, `link`), `getKey`, `openApp`, `list`, `unlink`, `mount`, `embed` | `vault.*`; `embed` needs none. The key is the capability |
| `sg.history` | Read-only commit history: `log`, `list`, `read`/`readText` at a commit, works on read-only opens | no |
| `sg.sync` | `status` / `push` / `pull` / `refresh` against the named branch (`sg.git.*` survives as a deprecated alias) | writable vault |
| `sg.auth` | The write gate, the server access token, separate from the encryption key: `hasKey`, `setKey`, `check`, `clear` | no |
| `sg.ui` | Host toasts (`message`), quick-look `preview` (incl. PDFs, in-frame PDF rendering is sandbox-blocked), `requestPermission` | no |
| `sg.state` | Device-local prefs (64 KiB/key, kernel localStorage, survives reload, not a vault write, "a theme toggle shouldn't create a commit") | no |
| `sg.llm` | `available` / `models` / `chat` (streaming, cancel, image parts) / `usage` / voice `listen`, the vault's LLM key stays in the host; your frame never sees it | `llm.chat` / `llm.listen` / … |
| `sg.append` | **Append lanes, the vault-to-vault message transport.**`configure`, `write`, `list`, `fetch`, `markProcessed`, `purge`. A write-only channel addressed by a token, living outside the commit tree, so a stranger can send you an encrypted message without holding your vault key. Worked example: [sending messages between vaults](../vault-messaging.md) | `append.*` |
| `sg.on` / `sg.off` | Host events pushed to the app (e.g. `append.new-messages` on tab focus, the kernel checks; your app does not poll) | `host_events` allowlist (top-level key) |
| `sg.app` | Read-only context: `writable`, `selfPath`, `vaultName`, `vaultId`, `context` | no |

## The permission model

Grants live in `app.json` (preferred location: `.vault/app.json`; a legacy root `app.json` is still read). Each permission is `true | false | string[]`, and path lists are **prefix-based, not glob**: a trailing `/` means "this folder and everything under it"; no slash means an exact file. `"data/**"` is not valid, use `"data/"`.

```
{
  "entry": "index.html",
  "permissions": {
    "fs":    { "read": true, "write": ["data/"], "delete": ["data/"] },
    "vault": { "create": ["runs/"] },
    "llm":   { "chat": true },
    "externalLinks": true,
    "downloads": true
  },
  "host_events": ["append.new-messages"]
}
```

- **Mutations are deny-by-default.** Writes, deletes, vault lifecycle, append and llm all throw `EPERM` without a grant. **Reads are default-allow today**, and are planned to flip to deny-by-default, so declare `fs.read` anyway.
- **Two independent gates on every mutation:** the server access token (is the vault writable at all?) *and* the `app.json` grant. The manifest is a hard ceiling, an app can only ever do what it declares.
- **The floor is never grantable:** `.vault/**` is invisible and untouchable (`EPROTECTED`), which is also why an app cannot edit its own manifest: the manifest *is* the grant.
- **Consent is host chrome.** Grant-gated verbs raise the host's own confirmation, cached per (vault, app, verb); `permissions.consent` can tune (never widen) the prompting. Apps can't fake or suppress it.
- **LLM calls are budgeted:** the host clamps `maxTokens`, filters models, enforces spend caps (`EBUDGET`), call `sg.llm.available()` before rendering any AI UI, and render costs as estimates (`~`), never as a bill. Deliberate design: there is no tool-calling loop, *the LLM never gets ambient authority over the vault*; your app decides what to do with a reply, under its own grants.

## Error codes worth branching on

| Code | Meaning |
|---|---|
| `EPERM` | verb not granted in `app.json` |
| `EPROTECTED` | the floor, `.vault/**` or the manifest itself |
| `ECONSENT` | user declined the consent prompt |
| `ENOENT` | no such file, the usual cause when `loadCss`/`loadJs` "doesn't work" (typo, or written locally but never pushed) |
| `EFBIG` | single write over ~3 MB |
| `EREADONLY` | static host or read-only session |
| `EBUDGET` · `ENOKEY` · `EMODEL` · `EABORT` | llm namespace: spend cap, no key configured, model not allowed, cancelled |

## Host chrome vs API, two different things

**Chrome you configure but never call** (via `app.json`'s `hud` block, `mode: full | minimal | hidden | none` plus per-button `show.*` flags): the nav row, Print, the ✨ AI chat panel (text and voice, entirely at the host origin, your frame never sees the conversation, the key, or the microphone), the file-activity meter, friendly 404 overlays, and the external-link confirm. **API you call, with grants:** `sg.ui.preview`, `sg.vfs.download`, `sg.llm.*`.

And the **sovereignty rail**: three things an app can never suppress, whatever its `hud` config: consent prompts always render; `mode:"hidden"` keeps a corner exit pill; and the user can force the full HUD back on from their side, at a level app code cannot reach. The HUD config is for app *preferences*, not app *authority*.

**Versioning note:** this page is an orientation map, verified against the app-shell bridge (v0.2.x, 2026-08). The authoritative, always-current API reference ships with the app-shell source; where they disagree, the source-side reference wins.

[← Building vault apps](vault-apps.md)[Content authoring →](content-authoring.md)



==============================================================================
# Content authoring, SG/Vault

> Publish documents, galleries and hub pages from a vault with no code: markdown with print-aware extras, and _page.json layouts with eleven component types.
>
> Page: https://sgit.ai/docs/vault/content-authoring.html

[Home](../../index.md) / [SG/Vault](index.md) / Content authoring

**Surface:** `_page.json` and markdown, inside a vault. [The other surfaces →](../surfaces.md)

# Publishing content without code

Not everything needs an app. The vault browser renders two kinds of structured content natively, **markdown documents** and **`_page.json` page layouts**, so a vault full of files becomes a navigable, themed, printable site with no HTML written at all. This is the lighter on-ramp; [vault apps](vault-apps.md) are the heavier one.

## Which one, when

| Reach for markdown | Reach for `_page.json` |
|---|---|
| Prose-first documents, articles, reports, specs, step-by-step guides, linked hierarchies of notes | Designed pages: hero banners, galleries and slideshows, hub pages with clickable cards, decks, embedded PDFs, explicit theme control |

Both can coexist in one folder, `_page.json` takes priority in the browse view. A file named exactly `_page.json` is auto-detected, no registration; one at the vault root renders immediately on open.

## `_page.json` in one screen

```
{
  "title": "Q3 Report",
  "theme": { "mode": "light", "accent": "#0f766e", "font": "serif", "density": "spacious" },
  "navigation": [ { "label": "Overview", "anchor": "overview" } ],
  "components": [
    { "type": "hero",    "title": "Q3 Report", "height": "medium" },
    { "type": "section", "title": "Overview", "layout": "narrow", "children": [
      { "type": "text",     "content": "…" },
      { "type": "gallery",  "images": ["img/a.webp","img/b.webp"], "columns": 3 },
      { "type": "markdown", "file": "notes/summary.md" }
    ]}
  ]
}
```

- **Twelve component types:** `hero`, `section` (the only container, everything else nests in its `children`), `text`, `bullet-points`, `title`, `image`, `gallery` (click-to-lightbox), `slides`, `pdf`, `markdown`, `cards`, `columns`.
- **Themes:** `dark`/`light` shorthand or a full block (mode, accent, font, density, background); six named schemes exist, and all but the dark deck are print-safe.
- **Paths are vault-relative to the folder holding `_page.json`**: `../` allowed but never outside the vault, and **no external URLs**: vault files only, so a page never phones home.
- **Live edit preview:** the browse view has a split JSON-editor with a debounced preview, but it **cannot save**; you copy the JSON out and push it with sgit. (The intended loop, verbatim from the internal skill: paste in JSON suggested by an AI, preview it immediately, then commit.)

## Markdown in vaults, the extras

- **Print-aware front matter** (first line, `---`-delimited): `page_break_before: h1` and a literal `print_css` block, so a markdown file prints like a document, not a web page. Plus `<!-- page-break -->` anywhere for an explicit break.
- **Image sizing with the pipe syntax** (`![caption|400](img.png)`, `|60%`, `|800x600`) inside the alt text, so it degrades gracefully in any other renderer.
- **Internal links open as tabs**, with extension fallbacks; link folders via `folder/README.md`, not `folder/`. The browse view auto-opens the alphabetically first file, name your entry `README.md` or `00-INDEX.md`, or add a root `_page.json`.
- **Editing saves**: unlike the `_page.json` editor, the markdown split-editor persists to the vault (writable vaults only).
- **The traps:** raw HTML is stripped and shows as escaped text; nested lists, task lists, footnotes and anchor-id headings are not supported. Write flat, plain markdown.

**Building this for someone else?** [**The build brief**](../briefs/markdown-and-file-viewers.md) is the decision rather than the syntax, the ladder from zero code to a full app, the markdown rules that actually catch people, the raw-view contract for a file explorer, and a prompt to hand the builder agent.

**The agent angle:** both formats are plain JSON and plain text, which makes them ideal surfaces for AI agents to author. An agent writes `_page.json` or markdown into a vault with `sgit write --json`, a human previews it in the browser, and the whole loop stays end-to-end encrypted.

[← The window.sg bridge](sg-bridge.md)[Sub-vaults →](sub-vaults.md)



==============================================================================
# Sub-vaults, SG/Vault

> Vaults inside vaults: link files, owner records, read-only team access, click-to-load external embeds, and the extract-and-embed workflow.
>
> Page: https://sgit.ai/docs/vault/sub-vaults.html

[Home](../../index.md) / [SG/Vault](index.md) / Sub-vaults

# Sub-vaults: vaults inside vaults

A vault can point at other vaults. A pointed-to vault shows up inline in the file tree, exactly like a folder, expand it and browse. A clinic's parent vault can hold many per-patient vaults; a demos vault can gather live project vaults, **without copying their contents**.

## The mechanism is a convention, like git submodules

Nothing is baked into the vault format. A sub-vault is a small pointer file plus UI behaviour: any file named `*.link.json` is treated as a link, and renders as an expandable folder at its own path. It really is "just create some files", write the pointer, `sgit commit`, `sgit push`.

```
# demos/acme.link.json → renders as folder demos/acme
{ "vault_id": "75f1c88be33d", "ref_id": "lk-37939d3b9b1a", "label": "ACME PoC" }
```

Two levels of setup:

- **Link file only**: the sub-vault appears; each device enters the child's key once.
- **Link file + owner record**: a `.vault/owner/ro-links.json` entry stores the child's **read key only, never its write key**; the child then opens silently, read-only, on any device that has the parent. This is what makes it usable for a team.

The same pointer convention covers **external resources** (a YouTube video, an image, a page), with a privacy default worth advertising: external embeds are **click-to-load**, showing a placeholder until the user acts, so opening a vault never phones home on its own; and external frames get no bridge and a visible "cannot read this vault" banner.

## Apps read across the boundary

To an app, an inner-vault file is just another path: `sg.vfs.readText('patients/alice/score.json')` auto-opens the child read-only with the stored key, no prompt fires during a read, and if no key is available the read simply fails: the zero-knowledge boundary holds. This is the workflow that lets one dashboard read across many per-user vaults without anyone seeing raw vault UI.

## Extract & embed, one primitive, three techniques

The reverse direction: pull a folder out into its own vault (separate lifecycle, separate sharing, separate history) and bring it back into the parent's app. Extraction is one call from inside a vault app:

```
await sg.vault.create({
  label: 'Q3 Report', seedFrom: 'self:reports/q3',
  returnKey: true, custody: true, link: { path: 'sub/q3-report' }
})
```

The new vault gets a strong random passphrase; the seed copy **structurally cannot carry `.vault/**`**, so a child can never inherit the parent's owner secrets or tokens. Then choose how to surface it: a **read-only sub-vault link** (the default, and the recommended one today), a **live embedded app** via `sg.vault.embed` (host-managed key handshake, the key never touches the URL or storage; the frame is sandboxed to scripts only, and the host refuses escape-hatch sandbox tokens even if asked), or a **cross-vault mount** where the child performs operations under its own grants, your app never gains cross-vault write authority itself.

**Honesty notes:** the mount technique's credential resolution is explicitly a trial-only stub in current code, prefer the link or embed forms for real users today. And treat an extract-and-link split as an *organisational* boundary (lifecycle, sharing, history), not a confidentiality boundary from the parent's own readers. Sub-vault access from the sgit CLI is proposed, not shipped, today sub-vaults are a browser-side capability.

[← Content authoring](content-authoring.md)[Git repos inside vaults →](git-and-vaults.md)



==============================================================================
# Git repos inside vaults, SG/Vault

> Run git and sgit side by side: the encrypted store in a git remote, the leak-audit boundary, the GitHub round trip, plus a pure-Python git reader preview.
>
> Page: https://sgit.ai/docs/vault/git-and-vaults.html

[Home](../../index.md) / [SG/Vault](index.md) / Git repos inside vaults

# Git repos inside vaults

Engineering preview. A git repository is, in the end, just files, which means a vault can hold a complete repo, `.git` folder included, giving you an end-to-end-encrypted remote for your full history. The missing piece is *legibility*: making that history readable wherever the vault lands, without assuming a git binary. That piece now exists.

**Worked example, including the ending:** this website ran exactly this way for 76 releases (one folder, both systems, two pushes per release) and then retired the vault mirror in September 2026 because it had no reader and was 91% of the repository. The case study, including the surprise (the encrypted ref always looks modified to git, because AES-GCM re-encrypts with a fresh IV on every write) and the reasons for stopping, is at [one working tree, two remotes](../../case-studies/one-tree-two-remotes.md). The pattern below is still the right one when something actually reads the mirror.

## A pure-Python git reader

The sgit project has a working git reader, ~600 lines of implementation in the same Type_Safe style as sgit itself, that reads the `.git` object store directly: loose objects, packfiles (index v2, including large offsets), delta reconstruction (both OFS and REF deltas), symbolic refs and `packed-refs`. No `git` binary, no gitpython, no dulwich, its only dependency is the same type-safety framework sgit already uses.

Verified against sgit's own development repository (900+ commits) during review:

```
>>> svc = Git_Repo__Reader__Service(repo_path='…/SGit-AI__CLI')
>>> [b.name for b in svc.branches()]
['dev', 'claude/sgit-positioning-proposal…']
>>> svc.head_commit()
HEAD 2e2dd4c · 1 file changed · author + message parsed
>>> len(svc.object_parser.flatten_tree(head.tree_sha))
1161   # every file in HEAD, resolved through packfiles and deltas
```

## Why this matters for vaults

- **Legible encrypted code archives.** Clone a vault containing a repo, and an agent, or a vault app, can render its history, branches, and per-commit file changes anywhere Python runs: sandboxes, Lambdas, CI containers, none of which need git installed.
- **A repo view for SG/Vault.** The same parsing logic, ported to the browser client, would let SG/Vault show commit history for repos stored in vaults, GitHub-style legibility over content the server cannot read.
- **Agent code-analysis on a time budget.** Combine a [sparse clone](../agents.md) with the reader: fetch only `.git`, walk the history, fetch working-tree files on demand.
- **One mental model, twice.** git's object graph (commits → trees → blobs, refs on top) is exactly the model sgit rebuilt over an encrypted content-addressed store. The reader proves the model small enough to reimplement legibly in ~600 typed lines, which is the same bet sgit made, in the other direction.

## Run git and sgit side by side

The integration runs the other way too: the same folder can be a git repository *and* an sgit vault at once, git's ecosystem (remotes, pull requests, CI, GitHub Pages) over the working files, sgit's zero-knowledge sync over the same content, and a git remote that doubles as an **encrypted mirror of the vault itself**.

Why this is safe by construction: the `bare/` store is byte-parity with what the sync server holds, and the server is untrusted *by design*: everything in `bare/` is protected by the vault key, not by where it sits. Git exposure of `bare/` is therefore equivalent to server exposure, which the zero-knowledge model already accepts. A git remote is just a second untrusted server, one that also gives you distribution, replication and history for free.

The boundary reduces to three rules:

```
# .gitignore — the whole of it
.sg_vault/local/   # plaintext tier: vault key, push token, unwrapped private keys
.sg_vault/work/    # scratch area — may hold plaintext transiently
*.pem              # defence in depth: no unwrapped key material anywhere, ever
```

Pair it with a `.gitattributes` that marks `.sg_vault/**` as `binary -diff -merge`: ciphertext has no meaningful line diff, and a textual merge would corrupt it. Everything else is committed, including the **plaintext working tree, which is the point**: the vault's contents readable, searchable and reviewable on GitHub, with blame, PRs and CI on top. That makes repo visibility a *content* decision, not a crypto one: `bare/` is safe either way; your documents are what you are choosing to expose.

### The round trip: edit on GitHub, pull back into the vault

Because the working tree is real files, the flow runs both ways. Edit a file in the GitHub web editor, merge a colleague's pull request, let a CI job rewrite a document, then `git pull` into the local clone, and **sgit sees exactly what changed**, the same way it sees your own edits: `sgit status` reports them, `sgit commit` records them in the vault's history, `sgit push` seals them to the server. Two provenance trails, both kept: git records who proposed and reviewed a change; sgit records it landing in the encrypted vault.

### Before first publication: audit, then keep the discipline

- **Run the leak audit from the vault root** before the first `git add`: the vault-key secret must not appear in the working tree, no `BEGIN PRIVATE KEY` outside `local/`, and `bare/` must contain no greppable filenames or content. (This site's own vault passed all checks before its dotfiles shipped, and the audit is what later caught [the leak](../../case-studies/exposed-vault-key.md).)
- **Write the protection files before the first `git add -A`**: once `local/` is in a commit it is in history, and removing it later means a history rewrite plus key rotation.
- **For CI**, the vault key goes in GitHub Actions Secrets (and a password manager), never in files, commit messages, issues or workflow YAML.
- **Disaster recovery comes free:** a git clone of the repo plus the key reconstitutes everything (content, sgit history, all branches) even if the sync server is gone. Do one restore drill before you need it in anger.

The `.gitignore` / `.gitattributes` pair is reproduced in full on [the case study](../../case-studies/one-tree-two-remotes.md). And once the vault is on GitHub, the same repo can serve the app itself: see [static hosting on GitHub Pages](static-hosting.md).

### What a key rotation does to the mirror

Rotating a vault key (`delete-on-remote` → `rekey` → `push`) re-encrypts every object under a new key, so every content-addressed ID changes and the entire store is replaced. In the git mirror that lands as one large commit, for this site, 336 objects deleted and a fresh set added. Nothing breaks (the `.gitattributes` binary rule means no diff churn), but two consequences are worth knowing before you rotate:

- **Git becomes the history.** A rekey resets the vault's own commit history to a single commit. The git mirror still holds every previous version, which is the side-by-side pattern earning its keep: each remote covers the other's gap. (For this site that mirror has since been purged; the point stands for any vault whose mirror somebody reads.)
- **A rekey protects the server, not the mirror.** Old ciphertext already pushed to git stays in git history, and remains decryptable by the old key. If that key was ever exposed *and* the repo is public, rotating does not un-publish the old content, for public content (like this site) that is a non-issue, but for a private vault, treat a rotation as incomplete until the mirror's history is scrubbed too. Rotate first, then decide about history.

This section exists because it happened here: the passphrase for this site's own vault was written into a tracked build file (an anti-leak regex that became the leak), reached three public commits, and was caught by the audit above. The key was rotated the same hour and the old vault deleted from the server; the exposed content was this public website. Recorded rather than quietly fixed, see the [release history](../../admin/versions.md).

## Status, honestly

- The reader is **in review, not shipped**. It is read-only, follows first parents (no merge traversal), and skips submodules and shallow clones by design.
- Review has already produced fixes: two schemas needed the project's own default-value convention applied, and the string-sanitization rules need loosening so file paths and commit messages round-trip byte-faithfully before this ships.
- When it lands, it lands the way everything here does: typed, tested against real repositories, and documented on this page.

[← Sub-vaults](sub-vaults.md)[Static hosting →](static-hosting.md)



==============================================================================
# Reading one file out of a vault, SG/Vault

> The primitive under every live embed on this site: derive the address from a published read key, fetch ciphertext over CORS, decrypt in the browser, and the sandbox rules for rendering what comes back, including why a PDF is a download and not an embed.
>
> Page: https://sgit.ai/docs/vault/reading-a-vault-file.html

[Home](../../index.md) / [Docs](../index.md) / Reading one file out of a vault

**Surface:** a page on a `*.sgit.ai` site, outside every vault host. [The other surfaces →](../surfaces.md)

# Reading one file out of a vault, from any web page

A published read key plus four browser APIs is enough to pull a single named file (a JSON manifest, a slide source, a screenshot, a PDF) out of an encrypted vault and use it on a page that has no backend, no build step and no copy of the file. This is the primitive underneath [the app embed](../../demos/vault-app-embed.md), [the live docs reader](../../case-studies/live-vault-docs.md) and [the deck viewer](../../demos/vaults/aiuc-1-conformance/index.md#decks), written down on its own because all three are built on it.

**The one-sentence version.** The vault's HTTP API serves ciphertext at a URL you can *compute* from the read key, so a page fetches bytes the server cannot read and decrypts them itself, which means **publishing a file to a web page is the same act as pushing it to the vault**, with nothing in between.

## The four steps

Everything below runs in the browser. The read key is a 64-character hex string and a vault id, and it is the whole credential. There is no account, no token and no session.

|  | What happens | Which API |
|---|---|---|
| **1 · Import the key** | The same 32 bytes are imported twice: once as an AES-GCM key for decryption, once as an HMAC-SHA256 key for deriving ids | `crypto.subtle.importKey` |
| **2 · Derive the address** | HEAD lives at `ref-pid-muw-` plus the first 12 hex characters of `HMAC(key, "sg-vault-v1:file-id:ref:" + vault_id)`. The server never told you this, you computed it | `crypto.subtle.sign` |
| **3 · Fetch the ciphertext** | `GET /api/vault/read/<vault_id>/bare/refs/<id>`, then `bare/data/<object id>`. Plain CORS GETs, no auth header: the bytes are useless without the key | `fetch` |
| **4 · Decrypt and walk** | First 12 bytes are the IV, the rest is the AES-GCM body. Ref → commit → tree → blob; filenames are encrypted inside the trees, so the path index is itself something you decrypt | `crypto.subtle.decrypt` |

The reader that does this is about 90 lines and is on this site twice, deliberately in the open: [`assets/vault-embed.js`](../../admin/index.md) exports it, and `assets/vault-docs.js` is the instrumented version that shows its own cache accounting.

## What may be cached, and the one thing that may not

The object model decides this, not a policy. An id containing `-imm-` is content-addressed and therefore immutable, so it can be cached forever. The ref is the single mutable pointer, and caching it is the one mistake that fails silently, a stale ref renders an *older commit from perfectly valid ciphertext*, so nothing errors and the page is simply wrong. The readers here keep a short freshness window on the ref instead, which is also the worst case delay before a new push is noticed. [The caching contract is part of the API reference.](../../api/vault-objects.md)

## Vault content is not your page's content

A read key lets anyone read the vault, so the interesting question is the other direction: **the vault's bytes arriving in your page are untrusted input**, authored by whoever holds the write key. Rendering them into your own document hands a vault author your origin, your cookies, your storage, your DOM. The rule this site follows is that **the viewer comes from the site and only the data comes from the vault**, and that the data is rendered inside an opaque origin.

| Vault content | Where it is allowed to run | Why |
|---|---|---|
| Static markup, a slide, a document | `<iframe sandbox>` with **no**`allow-scripts`, CSP `default-src 'none'; img-src data:` | It never needed scripting, so scripting is switched off rather than contained. Nothing in it can make a request |
| Executable, an app, a deck that builds its slides in JavaScript | `<iframe sandbox="allow-scripts">`, reads served over `postMessage` | Opaque origin: no cookies, no storage, no reach into the host page. It asks the host for bytes and gets only bytes |
| Images | Decrypted by the host, handed in as `data:` URIs, or blob URLs minted *inside* the frame | A vault path in a `src` resolves against an opaque origin and 404s, so the bytes have to be carried in |
| PDFs | Downloaded, not embedded | Measured, not assumed, see below |

## Why a PDF is a download and not an embed

The obvious move is to decrypt the PDF, wrap it in a blob and point a sandboxed iframe at it. **Chrome refuses.** Tested across every sandbox combination, the console says the same thing each time:

> `Failed to load 'blob:…' as a plugin, because the frame into which the plugin is loading is sandboxed.`

The browser's PDF viewer is a plugin, and plugins do not run in sandboxed frames. That leaves two honest options and one dishonest one. Dropping the sandbox works, and gives vault bytes your origin, which is the thing this whole page is about not doing. Shipping a JavaScript PDF renderer works and costs a megabyte of vendored dependency. **Handing the bytes to the browser's own download works, costs nothing, and is what this site does**: the file is decrypted in the page, wrapped in a blob, and offered through a normal download, while the slides, which are the thing anyone actually wants to read on a web page, are rendered live and are searchable, linkable and legible to an agent in a way a PDF never is.

A download is triggered from the page rather than from inside a frame for the same reason: a sandbox without `allow-downloads` blocks it, and adding that permission to untrusted content would be the wrong way round.

## The worked example: decks

[Four decks on the AIUC-1 page](../../demos/vaults/aiuc-1-conformance/index.md#decks) and [five on the Licence to Operate page](../../demos/vaults/licence-to-operate/index.md#decks) are read this way. The split, concretely:

- **From the vault:** the manifest, each deck's slide source, the speaker notes, the screenshots and the printed PDF.
- **From the site:** the deck tabs, the slide list, prev and next, the notes toggle, the PDF button, the deep links, and the sandbox policy the whole thing runs under.

A deck builds its slides by *running* (it is JavaScript that calls `S.push({t, notes, html})`) so it has to execute somewhere. It executes in a scripted, opaque-origin frame with `default-src 'none'`, which posts back a plain array; the site never evaluates it. Each slide's markup then goes into a second frame with scripting off. The stage is 1600×900 because that is the size the deck's own CSS was written against, and the *element* is scaled rather than the document, so a slide looks the same at any column width with no reflow.

Two published shapes are handled, because vaults differ in what they chose to publish: one ships its deck sources (small, screenshots fetched only when a slide uses one), the other ships only the built decks (large, screenshots already inline). The reader prefers the source and falls back to the built file, truncated at the point where the vault's own viewer starts.

**Doing this yourself?** This page explains the mechanism. [**The build brief**](../briefs/vault-decks-on-a-site.md) is the instructions, the contract a vault must publish, the checks that mean it is done, and a prompt to hand the agent who will build it.

## What this costs a reader

Nothing is installed and nothing is signed into. The first slide of a deck costs the ref, the commit, the trees, the manifest and one slide source; every later slide in that deck is already decrypted; a screenshot is fetched once and reused. The server sees requests for opaque ids and returns ciphertext, which is the entire point: **it is serving a presentation it cannot read.**

Put numbers on it. One object came back in **0.63 s for 59,324 bytes of ciphertext** with no auth header, twenty objects came back in a single POST in 2.79 s, and encryption adds a flat 28 bytes per object rather than a percentage. The address is never looked up: file ids are derived by HMAC from the read key, so the holder computes them locally before making any request at all. [The measurements, and the commands to repeat them](../../demos/fractal-graphs/performance.md#requests).

The credential on those pages is a read key, derived one-way from a vault key that is not published. Read keys can be handed out; vault keys never are. [The publishing method](../../demos/vaults/publishing.md) · [API: vault objects](../../api/vault-objects.md) · [Static hosting](static-hosting.md) · [Performance and cost](../../demos/fractal-graphs/performance.md)



==============================================================================
# Static hosting on GitHub Pages, SG/Vault

> Serve an encrypted vault and its app from GitHub Pages or S3 with zero backend: deterministic GET paths, client-side decryption, clean read-only degradation.
>
> Page: https://sgit.ai/docs/vault/static-hosting.html

[Home](../../index.md) / [SG/Vault](index.md) / Static hosting

# Static hosting, GitHub Pages / S3

The same vault-app HTML runs against the live API **or** a 100% static file host, transparently. The app only talks to `window.sg`; static vs live is a property of the transport, not the app. Shipped, opt-in, default-off.

## Why it works

Everything needed to open and browse a vault is a plain GET to a deterministic path: file IDs (commits, trees, refs, indexes) are content hashes or HMACs of the key, computed client-side, **no discovery or listing call exists**. So a static host that serves those exact paths just works: the browser GETs ciphertext from GitHub Pages or S3 and decrypts locally. No backend, no server, still zero-knowledge, the bytes on the CDN are ciphertext.

```
<!-- on the hosting page, before the host boots -->
<script>
  window.SG_STATIC   = true;                    // batch reads → GETs; writes → EREADONLY
  window.SG_ENDPOINT = 'https://my-org.github.io/my-vault';
</script>
```

## What works statically, and what doesn't

| Call | Static? |
|---|---|
| Open, browse, read files, history, `sg.vfs.read/readText/list` | ✅ plain GETs |
| Large reads | ✅ falls back from presigned to direct GET |
| Batch reads | ✅ fan out to parallel GETs, identical result shape |
| Writes, deletes, `sg.append.*`, vault creation | ❌ rejected cleanly with `EREADONLY` |

A static vault is a **read-only snapshot**: ideal for published docs, reports, dashboards and view-only shares. The app detects it via `sg.app.writable === false` and hides its editing UI; the same HTML runs writable against the live endpoint. *Same app, two backends.*

## The layout, path mirroring is the one hard requirement

The live API serves `GET /api/vault/read/<vaultId>/<filePath>`; the static host must serve the vault's encrypted `bare/` tree at exactly that path under your base:

```
<repo root>/                    → https://my-org.github.io/my-vault/
└── api/vault/read/<vaultId>/
    └── bare/
        ├── data/      obj-cas-imm-*    # immutable — cache forever
        ├── refs/      ref-pid-muw-*    # mutable head — no-store
        ├── indexes/   idx-pid-muw-*
        └── keys/      key-rnd-imm-*
```

If the repo is your vault's own git remote (working tree + `bare/` committed per the [side-by-side pattern](git-and-vaults.md)), the encrypted tree is already in the repo, publishing is just placing it under the right path prefix. Visitors open `https://…/my-vault/#<key>`: the key travels in the URL fragment (never sent to the host), the transport GETs ciphertext, the browser decrypts and renders.

## Honest caveats

- **Read-only and frozen.** The static tree is a snapshot at export time; new live commits appear only when you re-export.
- **Paths must match exactly**, or reads 404. (A configurable read-path template is a proposed follow-on, not shipped.)
- **Cross-origin setups need CORS** on the static host for GETs; same-origin needs nothing.
- **The key is the read capability.** Anyone with the full URL can read the snapshot, that is the point of publishing one, but the host itself only ever holds ciphertext.

[← Git repos inside vaults](git-and-vaults.md)



==============================================================================
# Admin & engineering, sgit.ai

> How the sgit.ai site is built: a vault app with generated pages, bridge-loaded assets, a validation suite, and sgit itself as the deployment pipeline.
>
> Page: https://sgit.ai/admin/index.html

[Home](../index.md) / Admin

# Admin & engineering

How this site is built, shipped, and versioned. sgit.ai is not hosted on a web server. It is a **vault app**: a set of HTML pages living inside an encrypted SG/Send vault, decrypted and rendered in your browser. The site about sgit is delivered by sgit.

## Architecture

```
# published site — one folder per section; root holds only what must live there
├── index.html · index.md                     # the front door + its markdown twin
├── CNAME · app.json · robots.txt · sitemap.xml
├── llms.txt · llms-full.txt                  # machine index; every page in one file
├── why/ · try/ · security/ · skills/ · briefs/
├── use-cases/       # patterns, each with an evidence status + agent brief
├── case-studies/    # things that actually happened, with numbers
├── docs/ · vault/ · deploy/
├── assets/          # site.css, site.js, vault-docs.js, try-setup.py
└── admin/
    ├── content/     # page bodies — one file per page, plus pages.json
    └── build/       # build_pages.py (the engine) + validate.js
```

## Adding a page

Content and machinery are separate, so nothing in the generator grows as the site does. It was 2,709 lines with every page inlined, and is 648 now that bodies live in `admin/content/`. A new page is a file and a row:

```
# 1. write the body — just the <main>, no head, no nav, no footer
$ vim admin/content/case-studies/my-study.html
# 2. register it: { "path", "section", "title", "desc" }
$ vim admin/content/pages.json
# 3. build and check
$ python3 admin/build/build_pages.py && node admin/build/validate.js
```

The build then produces, for free: the page with nav and footer, its `.md` twin with links rewritten to markdown, its row in `llms.txt`, its section in `llms-full.txt`, its entry in `sitemap.xml`, and its canonical, Open Graph and JSON-LD tags. The validator refuses the build if the page is unreachable from anywhere, if a link or a markdown twin is missing, if it carries no structured data, or if it could render invisible without JavaScript.

- **The authoring contract.** Vault pages render inside a sandboxed frame, so declarative references to vault files (`<link>`, `<script src>`, `<img src>`) would 404 before the vault bridge installs. Every page therefore carries only a tiny critical-style block plus a ~20-line bootstrap.
- **Shared assets over the bridge.** The bootstrap waits for the `window.sg` bridge and loads `assets/site.css` / `assets/site.js` through it, trying `sg.loadCss`/`sg.loadJs` first, then `sg.vfs.readText` + inject, then plain `fetch` as a static-hosting fallback. Worst case, pages degrade to readable unstyled HTML.
- **Multi-page navigation.** Plain relative `<a href>` links between pages, the vault host intercepts clicks and routes them, giving normal browser-style navigation (back/forward/history come from the host chrome).
- **Read-only by design.** The app requests no write permissions in `app.json`; reads need no grant. Nothing on this site can modify the vault.

## Build system

Every page is generated from a single Python script holding one shared template (nav, footer, bootstrap, version stamp) plus per-page content. Nothing is hand-edited twice: change the template once, regenerate, and every page updates consistently, including the version badge you can see in the nav.

## Validation before every push

- Every inline script and `site.js` is parse-checked with Node.
- A contract scan proves no `<link href>`, `<script src>`, or `<img src>` references a vault path.
- Every internal link is resolved against the real file tree, broken links fail the build.
- A banned-words scan keeps retired concepts and legacy naming out of the content.

## Release process

```
# 1. bump SITE_VERSION (v0.1.n — n increases on every push) + add a versions row
# 2. regenerate + validate
$ python3 admin/build/build_pages.py && node admin/build/validate.js
# 3. ship — GitHub Pages deploys from the dev branch
$ git add -A && git commit -m "site vX.Y.Z: …" && git push origin dev
# 4. verify live — the release is not done until sgit.ai serves the new version
$ curl -s https://sgit.ai/index.html | grep -o 'v0\.[0-9]*\.[0-9]*' | head -1
```

All four steps are one script, `admin/build/release.sh`, which also pulls the [board vault](../demos/vaults/board/index.md) first so the snapshot the release renders is current, and refuses to push until the validator, including the vault-key leak tripwire, has passed. The repository is `SGit-AI/SGit-AI__Website`; until v0.2.76 the same folder was also an sgit vault pushed on every release, a pattern retired and written up in [one tree, two remotes](../case-studies/one-tree-two-remotes.md). See [release history](versions.md).

## Design & contributions

A standing brief for Claude Code sessions proposing design improvements lives at [admin/brief-design-improvements.md](brief-design-improvements.md), it carries the constraints (authoring contract, self-contained assets, validation suite, version bump) that any change must respect.

[← Home](../index.md)[Release history →](versions.md)



==============================================================================
# Release history, sgit.ai

> Every release of the sgit.ai site: version, date, vault commit, and changes. The version increments on every push.
>
> Page: https://sgit.ai/admin/versions.html

[Home](../index.md) / [Admin](index.md) / Versions

# Release history

The site version (**v0.6.8**, shown in the nav of every page) increments on every release. Each release is one git commit on the `dev` branch of `SGit-AI/SGit-AI__Website`, and the git log is the authoritative audit trail; this page is the human-readable index of it.

| Version | Date | Commit | Changes |
|---|---|---|---|
| v0.6.8 | 2026-09-24 | this release | COMPANY X-RAY: A BUSINESS PLAN, WITH ONE COMPANY X-RAYED. New vault page and a new row in the business plans for founders. The service reads a company's own documents together: the customer drops them into an encrypted vault, agents run a catalogue of twelve analyses, a person reviews, and within five working days the customer gets their questions answered, a one-page board pack, findings that each name the file and row they rest on, and a Claude setup to keep asking. No connectors, no integrations. The vault holds an invented company X-rayed end to end, fourteen findings labelled read, computed or inferred, and a script that re-runs all 46 figures from the documents. Four levels from £50 to £1,500 reuse RiskMandate.ai's pricing pattern. Read key published on purpose; vault key in the gitignored tier; all-zeros control empty. Thirty-six published vaults. |
| v0.6.7 | 2026-09-24 | git 63f3e72c | A BRIEF FOR RISKMANDATE: INTERVIEW PAGES, AND A CHATGPT VOICE PROMPT. New build brief in /docs/briefs/, and an open cross-team ask. It defines a reusable interview page for riskmandate.ai: a link sent to one person, a prompt they paste into ChatGPT and continue in voice mode, about twenty minutes of interview, and a structured written summary they send back. The first page is for a founder strong in UK events, marketing and content that spreads, testing the value proposition, the name, who to reach first, events, content angles and a thirty, sixty and ninety day plan, with candid criticism asked for explicitly. The full prompt is in the brief, describes RiskMandate only in the words riskmandate.ai already uses, and is ready to send today. A later step proposes returning summaries through a write-only append lane instead of email. |
| v0.6.6 | 2026-09-24 | git 23096e71 | LESSON LOOP: A BUSINESS PLAN FOR COACHES. The thirty-fifth vault (3s9q7zl7, 27 files) is a business plan for padel coaches, and any teacher with students: capture the coach's picture of the player at the end of the lesson, when it is most complete, as a voice memo; an agent turns it into a lesson note and three points for the player's next games, in the player's own data vault; the player adds match notes and clips; and the next coach, in any club or country, starts from a two-minute briefing. The app replays one invented player's record across four lessons with three coaches in London and Lisbon, with the raw memos, the notes, the player view, briefings, and a themes matrix showing what each coach saw. The plan sets out four phases (capture first, nothing else until it works), the two-vault architecture with a write-only lane per coach, what exists today, pay-on-demand credits instead of a subscription, new coach income (remote reviews, drill plans, follow-ups, content), the club variant and its tension, other teaching domains, risks (children, other players in clips, undisclosed commissions) and a calculator that shows a small business at 200 coaches. The coach-memo prompt is ready to paste for phase one. Listed on the business plans page. |
| v0.6.5 | 2026-09-24 | git 138dbe4e | EVERY RISK IS ALREADY ACCEPTED, AND A COMPANY TO RUN THE LOOP. A first-person foundation article for readers new to risk acceptance: no deny button; accept, fund or fix, with silence escalating; the interval as the decision (the risks.sgit.ai ladder, 1 hour to 6 months); accepted versus acceptable, with the EU AI Act's Article 9(5) quoted and scoped to providers of high-risk AI systems, which never defines acceptable; every risk with a boss and every path to the board; fractal risk registers from the board to the bytes; established by facts and ended by facts; a vault per material risk as the evidence pack of governance (proposed here); twins as the direction (designs, not built); why executives resist; and why it fits beside every GRC platform. Three new diagrams plus Risk Graph Explorer views. The thirty-fourth vault, Risk Acceptance Office (odn10gfp, 32 files), replays one invented risk over six weeks with a hash-chained decision record verified in the browser and a side-by-side of the register row, and carries the business plan: operating model, the GRC gaps, services priced per material risk, a calculator, go-to-market starting from the resistance, ninety days, risks and open questions. Research found four places where the published method disagrees with itself; the plan picks a position on each and says so. Listed on the business plans page. |
| v0.6.4 | 2026-09-24 | git 9f174c35 | PARTNERSHIPS WITH THE CLOUDS AND THE AI PROVIDERS, AND A BRIEF FOR RISKMANDATE. Sixteen new pages under /partnerships/, written from the vault side and each one forwardable on its own. The cloud platforms hub says what sgit needs from a cloud (mostly storage, a little compute), where it stands on each, honestly (Docker everywhere; AWS templates in beta; Google Cloud planned; Azure deployed by the founder but undocumented; the S3 mode targets Amazon S3 and S3-compatible stores are untested), the two partnerships in one (vaults in the cloud's environment, and services on top of vaults), and one page each for AWS, Azure, Google Cloud, IBM Cloud, the European clouds (OVHcloud, Scaleway, Hetzner, IONOS, STACKIT), DigitalOcean, Rackspace and Netlify. The AI providers hub sets out three meeting points (agents read and write vaults through a connector, vault apps call models without a key, vaults carry the agent's work) and one page each for OpenAI, Anthropic, Mistral AI, Google Gemini, OpenRouter and ElevenLabs. Every provider fact is from the provider's own pages, researched today; credit amounts are left out because several could not be confirmed. Research corrected two first drafts: this site is served from GitHub Pages, not AWS, and the server's S3 mode is only proven on Amazon S3. The brief for RiskMandate.ai, built on a survey of its 79 pages and 16 policy vaults, asks for the risk side of every partnership as two behaviour policies and a delta, and for sgit written up as a control against GDPR Articles 32, 25, 34(3)(a), 28 and 17. |
| v0.6.3 | 2026-09-24 | git ae3f8714 | BEFORE YOU GIVE AN AGENT A CONNECTOR, GIVE THE CONNECTOR A TWIN, AND BUSINESS PLANS GET THEIR OWN PAGE. A first-person article argues that a twin of the connector, a journal of every request and response an agent makes, appended to a write-only lane, processed later and replayed into the inbox and calendar as the agent saw them, is the minimum requirement for deploying an agent with provenance, explanation and undo. Every claim about Gmail and Calendar is Google's own and linked: the API delete 'cannot be undone', Undo Send is an interface feature, trash keeps 30 days, the administrator's bulk restore 25, Vault 'isn't designed to be a backup or archive tool' and keeps one Calendar revision a day. Research corrected two first assumptions (Vault has covered Calendar since November 2023; the admin audit log does record some earlier values) and the text says so. The thirty-third vault, Connector Twin (7tkvspwp, 31 files), opens on a working replay of an invented seventeen-call Gmail and Calendar session: a slider rebuilds the inbox and calendar at any step, before and after for every write, a graded revert plan, what the agent said against what the journal shows, and a hash chain verified in the browser, which ran inside the vault host's sandbox. Behind it, the business plan: facts with sources, architecture, three capture modes, packages per agent, a calculator, go-to-market, ninety days, risks, open questions, the journal specification, revert rules and three prototypes. New page /startups/business-plans.html gives the plans their own home, listed in the Why menu, with Agent as Webmaster and Connector Twin, how to take one, and the offer to build them with partners. |
| v0.6.2 | 2026-09-24 | git 42d40e9f | A CALL FOR COLLABORATION ON VAULT KEY MANAGEMENT. New page in Partnerships, /partnerships/vault-key-management.html, written to be sent to password managers, identity providers and platform credential managers who have never heard of sgit. It opens with the short version, then what we are looking for in order of preference (something that already exists, a joint pilot, an open specification), the requirements in plain terms (browser first, key kinds kept apart, release only on the user's approval, end-to-end sharing, names in plain words that are addresses and never keys, revocation, scoped keys for agents), sgit in two minutes, three new diagrams (keys travelling by hand today, what a vault is and where the key sits, a seven-step share-by-name flow), and then the detail: the key formats, why the word-based share token was removed in August (about thirty bits, recoverable in a tenth of a second on a GPU), why a vault of keys still needs a first key, and what exists against what does not. The partnerships index lists it as an open call. |
| v0.6.1 | 2026-09-23 | git 277b41b1 | THE DSIT AI RISK TOOLKIT PAGE STARTS WITH THE READER'S DECISION, AND PLAYS THE DECK. Rebuilt from a brief: the vault has moved on since 20 September (155 files, a use-case-led journey at v0.2.0 as the home page, reference edition v0.2.3, a decks/v2 deck 'A decision before a risk list'), and the page still opened on four worlds and 617 nodes. Now: an outcome headline, three actions (live vault, eight-slide walkthrough, PDF), the site-owned decks/v2 viewer mounted on the page reading manifest, slide source, styles, five screenshots and the PDF from the vault, a five-step 'what you can try', the vault embed, then the architecture material moved below with the four-world screenshots dated, a status table separating journey v0.2.0, reference v0.2.3, the research graph (941/4,735) and the reference graph (1,051/1,289) without merging them, the licences stated (OGL v3.0 for DSIT text; no licence assigned to the new code), and the read key, derived facts, audit and the dated 20 September snapshot in an expandable provenance section. VIEWER: keyboard navigation (arrows, PageUp/Down, Home, End), a live region announcing the slide, aria-current on the slide list, titled frames, focus-visible outlines, and a counted 'N screenshots could not be read' status instead of a plausible-looking gap. Verified through the mirror: 8 slides walked, 0 unresolved images, PDF bytes match SHA-256 36f9e16c…, parse frame allow-scripts only, render frame no scripts. |
| v0.6.0 | 2026-09-23 | git ec7bcad8 | THIRTY-SECOND VAULT, AND THE FIRST BUSINESS PLAN PUBLISHED FOR SOMEBODY ELSE TO RUN. Agent as Webmaster (ikrqeu5t): give small businesses a website they can change by asking, with an AI agent as the webmaster and GitHub Pages as the host. The vault carries the plan as a single-page app with a unit-economics calculator, the same plan as eleven markdown documents, three drawn diagrams, three invented customer sites and the operator's sales site as standalone mock-ups, and the prototypes to serve the first customer (the agent's playbook, the GitHub Pages setup, six worked change requests). permissions {}. Published under the method: classified, derived one-way, audited from a read-key clone (nothing found), negative control run, facts derived. The startups section gains 'Business plans to build on'. THE PUBLISH FOUND TWO CLI BUGS: the auto transport treated a fresh vault's object 404 as 'no live API' and flipped push to the read-only static transport; and push, pull, fetch, status and delete ignored --transport. Both fixed in the CLI repository with a pinning test. Vault counts across the site move to thirty-two; measured estate figures keep their 21 September date. |
| v0.5.9 | 2026-09-23 | git 62148934 | THE SOVEREIGN AI PAGE SAYS WHAT IT IS IN ITS TITLE. A reader landing from a forwarded link had no way to know this was a proposal from sgit.ai's side. Title is now 'A proposed partnership between sgit.ai, RiskMandate.ai and UK Sovereign AI', the eyebrow names both parties and calls it proposed, the lead opens by saying so and introduces the two products in a clause each before introducing the fund. Index link, page title and About cross-link follow. |
| v0.5.8 | 2026-09-23 | git ff7de798 | THE SOVEREIGN AI CASE GETS ITS ANCHORING, FROM THE FOUNDER'S OWN MEMO. New section on the partnership page, stated in the first person because only the founder can supply it: thirty years in the UK as practitioner, CISO for UK companies and founder; one UK exit; The Cyber Boardroom Limited, UK-registered and trading for almost two years, as the commercial vehicle behind sgit.ai and RiskMandate.ai; the intent to grow more UK companies on the technology. Plus the sovereignty argument: no sovereign AI without open source, because a closed champion is one acquisition away from not being sovereign, while an open substrate cannot be bought out from under the country that runs on it. The honest section now says anchoring is stated first-hand rather than documented here; the lead and the fit table carry the argument; the About page gets the same facts in one row. |
| v0.5.7 | 2026-09-23 | git 3aa131f4 | NEW SECTION: PARTNERSHIPS, THE BUSINESS CASE MADE IN PUBLIC. /partnerships/ states the method (start with what they are trying to do, public material only, evidence not pitch, the fit stated precisely, what is not public marked) and carries the first case: UK Sovereign AI. Their mission in their words (the sovereign edge, five frontiers, the offer beyond investment, the R&D procurement scheme and its four challenge areas, the anchoring test), what sgit.ai and RiskMandate.ai have published, a fit table that maps each stated priority to vaults that can be opened now (Licence to Operate, Agentic Browser Isolation, Risk Mandate, AIUC-1 conformance, the DSIT toolkit, Regulation Graph, the performance page), three concrete partnership shapes sized to their instruments, and a section on what the page cannot tell them (anchoring, certification, stage, the partial fit). Written to be forwarded to anyone who knows somebody there. In the Why menu. |
| v0.5.6 | 2026-09-22 | git b4213542 | THE BYLINE NOW LINKS TO A PROFILE PAGE ON THIS SITE. New /about/index.html, About the author, in the Why menu: the record (the companies, OWASP, the O2 platform), the signed articles here, writing elsewhere (docs.diniscruz.ai, LinkedIn, open-source.sgit.ai's fuller version of the page, wardley-maps, graphs, newsroom, GitHub), interests declared, and how to reach or correct the author. author_url may now be site-root relative; the byline renders it as a relative link and the JSON-LD Person gets the absolute URL. The four signed articles point at the new page instead of LinkedIn. |
| v0.5.5 | 2026-09-22 | git 49aa9407 | ARTICLES GET A BYLINE. The author noticed that the news article is written in the first person and his name appears nowhere on it, on a site whose argument is provenance. New optional frontmatter, author and author_url, rendered as 'By ' with the link first on the date line, emitted as a schema.org Person in the page's JSON-LD, and carried in articles.json. The build refuses an author without a URL, because a byline without a link is a name, not provenance. Applied to the four first-person articles (news, SaaS, startup model, fractal semantic graphs); the site-voice articles stay unsigned. |
| v0.5.4 | 2026-09-22 | git 73408357 | THE NEWS ARTICLE, THIRD PASS: THE FRACTAL SEMANTIC GRAPH WAS MISSING. The author read it halfway and noticed the piece said graph without saying which kind. Two new sections: the graph is fractal and meaning comes from connectivity (edges are verbs, relates_to is banned, every node opens into its own world, bridges not merges, provenance comes free when the leaf is a word tied to a byte range and a hash, corrections propagate, the empty doors are knowledge too), and the ladder stated once: trust through provenance, provenance via evidence, evidence is bytes with a hash, and every rung can be sold because none is asserted. A fourth diagram draws a story zoomed through three altitudes and sideways into a source's identity world. Links to the FSG page and graphs.sgit.ai; summary and executive summary updated to match. |
| v0.5.3 | 2026-09-22 | git 1ddfae52 | THE NEWS ARTICLE, SECOND PASS, ON THE AUTHOR'S NOTES. The first pass described the problem well and the solution thinly. Now: an executive summary section up front with the eight key ideas; a section on why advertising and subscriptions are both bad for the reader (product, hostage); the objective stated once, a commercial model that rewards investigative journalism so usage funds it and it earns the usage, drawn as a third diagram against the race to the bottom; the two clocks compressed, since that part is known; and the five things to sell each given their mechanics (read key, licence to transform, evidence vault per licensee, the cut not the content, the two prices and freshness of the verification API). The word prose is gone from the text and the diagrams, replaced by content or the words, because the readers this is for are the people who write it. |
| v0.5.2 | 2026-09-22 | git fcd0de3a | NEW ARTICLE: THE FUTURE OF NEWS IS THE STORY VAULT, NOT THE PAYWALL. Written from a voice memo, the seven future-of-news pieces on docs.diniscruz.ai (Feb to Jul 2025, dates kept on purpose), newsroom.sgit.ai, subscriptions.sgit.ai and pt.newsroom.sgit.ai, and the published vaults. Two clocks: Google traffic to publishers down 33% in a year and Cloudflare's billion 402s a day; the UK subscription regime brought forward to 1 Jan 2027. Reuters 2026: 17% pay, 71% of non-payers say nothing would persuade them. The counter-arguments to micropayments (Ball 2020, Guay 2026) are quoted and answered: they are about paying for prose. The story is a graph, the article is a projection, five things to sell, 60/25/10/5, x402 rails, and an honest note that no sgit.ai site is wired to any rail. Two drawn diagrams, link-preview card generated, linked from the startups section. |
| v0.5.1 | 2026-09-21 | git a8f931aa | THE GUARD SHIPPED IN v0.5.0 DID NOT GUARD THE CASE THAT MATTERS, AND THE NOTE FOR IT OVERCLAIMED. The author asked the right question: will this work for new articles that have an image? Tested rather than assumed, and the answer was NO. og_card() falls back to og/default.jpg when an article's card is missing, so a new article with a hero, published without running the generator, would build clean, validate clean, and ship with the GENERIC card. The v0.5.0 entry said the validator catches a forgotten generator run. It does not: it only checks that the file an og:image names exists, and the fallback always names a file that exists. Simulated to confirm, and the build printed no complaint while the new article's og:image pointed at the default. NOW THE BUILD REFUSES. After ARTICLES is loaded, any article whose body has a !shot figure but no og/.jpg stops the build, names every offender and prints the command to run. Same shape as the LLMS_SECTIONS check, which is the house pattern: the build refuses rather than guessing. og_card()'s fallback is now documented as safe precisely because that check has already run, so the only pages reaching the default are the ones meant to. AND release.sh RUNS THE GENERATOR, so in practice it is automatic: step 1 calls make_og_cards.mjs before the build when sharp resolves, and says so and skips when it does not, at which point the build's own refusal is what catches it. PROVED BOTH WAYS: a test article with a hero and no card stopped the build with its name and the fix; running the generator produced the card and the same article then built with its own og:image. So the answer to the question is: yes for a new article, automatically via release.sh, and if the generator is ever skipped the build stops instead of quietly shipping the wrong picture. |
| v0.5.0 | 2026-09-21 | git 7403bdaa | SHARED LINKS HAD NO PICTURE, BECAUSE og:image WAS MISSING ENTIRELY. Reported from a LinkedIn compose box: pasting the SaaS article gave a title-and-domain card with no image. The head carried og:type, og:site_name, og:url, og:title and og:description, and NO og:image at all, with twitter:card set to the small 'summary'. So there was nothing for a crawler to show. AND THE OBVIOUS FIX WOULD NOT HAVE WORKED EITHER: every figure on this site is WebP, and LinkedIn's crawler does not read WebP. It drops the image without a word, which is the trap, because the page looks correct and the preview is silently plain. So the cards have to be JPEG. NEW TOOL, admin/build/make_og_cards.mjs, writes 1200x630 JPEGs, the size LinkedIn documents for the large card, below which it can fall back to the small one. Every article's FIRST !shot becomes that article's card, parsed from the same markdown the page is built from so the two cannot disagree. Our heroes are wider than 1.91:1, so they are fitted rather than cropped, on a background sampled from each image's own corner, which makes the letterbox invisible on the cream covers. Eight article cards, 38 to 109 KB each, plus a drawn default card for the other 138 pages, carrying the wordmark, the tagline and pip install sgit-ai. THE HEAD now emits og:image as an ABSOLUTE url, og:image:width, og:image:height, og:image:alt, twitter:image, and twitter:card upgraded from summary to SUMMARY_LARGE_IMAGE, without which the picture is shown small or not at all. AND A GUARD, because the preview is invisible from the page itself and both failure modes are silent: validate.js check 3e fails the build if any page has no og:image, if it points at a .webp, or if the file it names does not exist, which is what would happen when somebody adds an article hero and forgets to run the generator. Proved by deleting the default card: 138 pages failed, and all passed again when it was restored. ALSO, SIXTEEN PAGE TITLES HAD AN UNBALANCED BRACKET, found because og:image:alt is built from the title and the homepage's read 'sgit (the encrypted git for humans and AI agents' with nothing closing it. Same em-dash-rewriter collateral as the article title template in v0.3.9: the paired rule opened a bracket where a dash had been and had no closing dash to convert. All sixteen closed, which fixes the browser tab and the preview alt text together. NOTE FOR SHARING: LinkedIn caches previews hard, so an already-posted link needs a pass through linkedin.com/post-inspector before it picks the image up. |
| v0.4.9 | 2026-09-21 | git e5263c4c | THE PHONE MENU WOULD NOT SCROLL, AND TWO GRIDS OVERFLOWED SIDEWAYS. Reported from an iPhone: opening the top menu, you could not scroll it, unless you first scrolled the whole page, after which the menu moved. REPRODUCED AND MEASURED at iPhone 13, SE and Pixel 5 profiles. The open menu is 42 links and stands 1536px tall against a 664px viewport, with max-height none and overflow-y visible, inside a nav.site that is position:sticky. So the menu had no scroll of its own and the sticky bar pinned it at the top, leaving the last item, Security, 855px BELOW THE FOLD and reachable only by scrolling the page underneath it. Exactly the reported behaviour. THE FIX caps the open menu to the viewport and lets it scroll itself: max-height calc(100dvh - 7rem) with a 100vh line above it as the fallback, overflow-y auto, and overscroll-behavior contain so the gesture stops at the end of the menu instead of chaining to the page. The 7rem is the worst-case closed bar, 92px on an iPhone SE where the row wraps rather than the 55px it takes when it does not, plus this element's own border, padding and margin, another 17px, which on the first attempt left the nav 12px taller than the viewport. MEASURED AFTER: the menu scrolls 913px internally on an iPhone 13, 1009px on an SE, 850px on a Pixel 5; the page does not move at all (scrollY stays 0); the last item is visible; and the nav now fits inside the viewport on every profile. AND A SECOND BUG FOUND WHILE VERIFYING, unrelated to the menu and present with it closed: the homepage ran 28px wide at 320px (iPhone SE). Cause was grid-template-columns repeat(auto-fit, minmax(330px,1fr)) on .jobs, a hard floor wider than the ~285px of content box a 320px phone has, which does not shrink, it overflows. .netpick, the component behind the new fractal band on the home page and the startups section, had the same bug at 310px. Both now use minmax(min(Npx,100%),1fr), which collapses to the container below that width and changes nothing above it: desktop columns are identical at 1280. A comment records the rule, because the next person will reach for a bare minmax again. Four pages checked clean at 320 and 390. |
| v0.4.8 | 2026-09-21 | git 99b37799 | A HERO IMAGE THAT ARGUES THE THESIS, AND THE FOUR WORDS THAT SUMMARISE IT BETTER THAN THE ARTICLE DID. The author made a cover for the inertia piece and revised it after review. The first version put both carts on the same railway track, which said same race, different speed; the revision has the newcomer OFF THE RAILS on chunky tyres with its own tyre tracks curving away across open ground, which is the actual argument, that the newcomers build on ground the incumbent cannot move onto, and it turns the rails into the incumbent's constraint rather than a shared destination. The revision also drops a decorative Mediterranean landscape that carried no meaning, and the rugged tyres remove a reading in which the newcomer looked like a toy. What survives from the first version is the load-bearing choice: BOTH CARTS CARRY THE SAME TEAL AI BLOCK, which is the 'AI is available to both sides' claim made visual, while the difference between them is a stack labelled PAST SUCCESS with a ball and chain attached, which is Wardley's climatic pattern drawn literally. Shipped as the article's first figure, above the Wardley-axis diagram: the picture carries the hook, the diagram carries the mechanism. Re-encoded from 2.26 MB PNG at 1915 wide to 63 KB webp at 1600. AND THE STRAPLINE BECOMES A PULL-QUOTE: 'Same AI. Different inertia.' states the thesis in four words, better than any sentence in the piece, so it now sits as a block quote between the lead and the diagram. |
| v0.4.7 | 2026-09-21 | git 7ec295ce | THE SAAS ARTICLE'S FILE NAME NOW MATCHES ITS TITLE. The slug had stayed at what-saas-refused-to-build through three retitlings so that links already handed out kept working; the author has now asked for the name to follow the title, with no redirect from the old one. The article lives at /articles/saas-apocalypse-decided-by-inertia-not-by-ai.html, the old built page and its markdown twin are deleted rather than left as ghosts, the startups section's link follows, and the old address returns 404 on purpose. |
| v0.4.6 | 2026-09-21 | git c6819b40 | THE SAAS ARTICLE TAKES ITS FINAL TITLE, AND THE ARGUMENT IT IMPLIES. 'The SaaS apocalypse will be decided by inertia, not by AI', chosen by the author from the inertia set, and the reason it is the right one is a claim the piece had not yet made explicitly: AI IS A CONSTANT, AVAILABLE TO BOTH SIDES. The incumbents have the same models as the newcomers, plus more data, more engineers and more money, and if the technology were the deciding factor they would already have won; two and a half years in, they have not. So the variable is inertia, in the Wardley sense: where a company sits on the evolution axis and how much past success it has to protect, which is what decides which side of the Nokia path each SaaS provider ends up on. FOUR PASSAGES CHANGED TO CARRY THAT. The lead now states it outright as the reason for the title. The market section gains a paragraph observing that the February panic and the September recovery were both staring at the wrong variable: the panic said AI would hollow out SaaS, the recovery said it would not, and the same models were available to the largest incumbent and a two-person company on the day the plug-ins shipped. The incumbents section adds that they have the same AI and more data to point it at, and that the constraint is not the models. The closing separates the two: the strategy question is not about AI, which both sides have, but about inertia, which only one side has. Abstract and startups link follow the title. Slug unchanged. |
| v0.4.5 | 2026-09-21 | git 75773920 | OPTIONAL WAS THE WRONG WORD, AND THE AUTHOR SAID WHY. Nokia did not opt into either of its outcomes: the first time it had nothing to protect and moved, the second time it had fifteen years of success to protect and did not, and the mechanism is the climatic pattern Wardley names, success breeds inertia. A title built on choice misdescribed the argument, and so did the three passages in the body that leaned on it. The article is now 'The SaaS apocalypse belongs to whoever has the least inertia', which names the mechanism and makes the newcomers' opportunity immediate, since the incumbents have the most inertia and the newcomers have none. The lead, the abstract and the closing were rewritten around inertia rather than choice: the apocalypse is a forecast about inertia, not technology; it will happen to the companies with the most to protect and belongs to the ones with the least; the fatal version is not a decision anybody takes but the default behaviour of a business with success to protect; and the strategy question it poses is one the newcomers have already answered, because for them there was never anything in the way. The word does not survive anywhere in the piece, checked by the build. Slug unchanged; the startups section's link follows the title. |
| v0.4.4 | 2026-09-21 | git 647938a5 | THE STARTUP ARTICLE TAKES THE TITLE IT WAS GIVEN ON LINKEDIN. When the author republished it there, the title gained a prefix, 'For a startup, the most important question is whether they miss it', which says who the piece is for before it says what it argues, and the two versions should match. Sentence case here, to match every other title on the site. The slug is unchanged, the startups section's link text follows the new title, and nothing else about the article moved. The SaaS article's title is under discussion and stays as it is until the author picks one. |
| v0.4.3 | 2026-09-21 | git ca1e56f8 | THE SAAS ARTICLE GETS ITS REAL TITLE, AND EVERY ARTICLE GETS AN ABSTRACT. Three notes from the author on the two new articles. (1) THE TITLE NEEDED THE WORDS SAAS APOCALYPSE IN IT, with an ironic twist, because the key move in the argument is that it has not happened yet and remains a very strong possibility depending on how the incumbents behave. The article is now 'The SaaS apocalypse is optional', and the twist is carried by Nokia, twice: Nokia met the arrival of the mobile phone by becoming the mobile phone company and dominated for fifteen years; Nokia met the arrival of the iPhone and was gone from the category within seven. Same company, two responses. The apocalypse is optional in exactly that sense, a forecast about behaviour rather than technology, and every company gets to choose which Nokia it is. Added to the summary, the lead and a new closing paragraph; the slug is unchanged so the link already given out still works. (2) THE FIRST PARAGRAPH IS AN ABSTRACT, AND NOW SAYS SO. The author republished the startup article on LinkedIn with the summary prefixed 'Abstract:' and set in italics, which reads better than a bare lead, so the article template now does the same for every article: the summary renders as an italic paragraph with a bold Abstract label, and the markdown twin carries the same emphasis. (3) THE INFOGRAPHIC BECOMES THE HERO. The author made a cover image for the startup article (a hand lifting one app tile out of a grid, leaving an empty slot and a speech bubble asking for it back, over the three pillars) and asked for it on the page, compressed. It is now the first figure of 'The most important question is whether they miss it', re-encoded from 174 KB at 1733 wide to 94 KB at 1600 wide, above the flow diagram rather than instead of it: the picture carries the hook, the diagram carries the mechanism. The startups section's link to the SaaS article was updated to the new title. |
| v0.4.2 | 2026-09-21 | git ef990399 | THE SAAS APOCALYPSE, ARGUED WITH DATA RATHER THAN VIBES. A second article from the author's voice memos, 'What SaaS refused to build is exactly what the agents need', and the brief was to find evidence for the claims about quality, usability, satisfaction and value for money of medium to large SaaS. Every figure was fetched from its source rather than recalled, and each is linked. THE MARKET HAD THIS ARGUMENT ALREADY: in the first week of February 2026, after Anthropic shipped Claude Cowork plug-ins, roughly $285 billion left software stocks in about 48 hours, a Jefferies trader named it the SaaSpocalypse, Thomson Reuters fell 16% in a day, the S&P software index dropped 13% in five sessions, and Forrester titled a piece 'SaaS as we know it is dead'. Then it recovered, about 40% off the April low by September, on the narrative that systems of record and proprietary data are durable moats. The article's reading: that recovery concedes the point, because it says the DATABASE is the moat and stops defending the screen and the seat. J.P. Morgan's Mark Murphy is quoted approvingly: it is 'an illogical leap' to expect every company to write AND MAINTAIN a bespoke product, and the article agrees, because that gap is where the opportunity lives. USERS WERE NEVER HAPPY, MEASURED: Freshworks 2022, 8,698 respondents, 91% frustrated with workplace technology, 57% of the unsatisfied say software makes them less productive, 68% of leaders name hard-to-use apps as the biggest adoption problem. Pendo 2019, 615 instrumented products, 80% of features rarely or never used, up to $29.5 billion spent building them; the older Standish 64% is cited WITH Mike Cohn's caveat that it came from four internal apps in a 2002 keynote and should never have been generalised. Zylo 2025, $21M a year wasted per organisation on idle licences, up 14.2%, $4,830 SaaS spend per employee, 660 apps in a large enterprise, lines of business controlling 70% of spend. And the spreadsheet: Deloitte 73% prepare VAT returns in Excel, YouGov 78% of British companies say spreadsheets support key financial decisions, read as the clearest evidence that SaaS failed its users, since Excel is where they control the shape of the thing. WHY, IN WARDLEY'S WORDS: past success breeds inertia, quoted from the doctrine chapter ('the pre-existing installed base causes inertia to the change'), and the map claim stated so it can be argued, per wardley-maps.sgit.ai's thesis that maps are claims not pictures: the SaaS product has slid right into a substrate of database, message bus and state machine, on which higher-order things now get built. EVERYBODY WAS ALREADY VIBE CODING, SLOWLY: Karpathy's term from February 2025, Collins word of the year by November, described as people writing very good briefs, which product owners always did in an environment with a catastrophically slow loop. WHY INCUMBENTS CANNOT SIMPLY DO IT: non-functional requirements were never funded, with Stripe's Developer Coefficient (17.3 hours a week, 42% of developer time, on maintenance and bad code, $85 billion a year) and DORA 2024 (19% elite, high cluster shrunk 31% to 22%, low cluster grown 17% to 25%, elite deploying 182 times more often) as the evidence, and the line the author stands behind: show me a SaaS company and I will show you a company that is highly inefficient at developing software. THE IRONY IN ONE PARAGRAPH: portability, open schemas, a real API and data you can take out were starved for twenty years as churn risks, and are precisely what a customer's agent turns up needing. THE MISTAKE AND THE MONEY: confusing the brief with a product, because SaaS was bought for being MAINTAINED, and the person who vibe coded the replacement does not want to maintain it, so the future is village and town-planner companies that take the brief and keep it running, paid by consumption, plus the few incumbents who pivot to a platform for exactly that, with sgit and Fractal Semantic Graphs named as one shape it can take. Closes on more engineers not fewer, and on Brooks: the two-pizza limit existed because communication did not scale, and with humans and agents it now can. ONE DIAGRAM: the SaaS product sliding right on the evolution axis into a substrate, the explorer to villager to town planner handover on top, and the mistake drawn in red. Linked from the startups section as the description of the market a founder is building into. |
| v0.4.1 | 2026-09-21 | git 09c06a53 | THREE DISCLAIMERS STOOD BETWEEN A VISITOR AND THE MOST POWERFUL PAGE ON THIS SITE. The author's note: /demos/vaults/ is one of the strongest things here, and a first-time visitor met four boxes of process, policy and incident text before a single openable vault. Measured before the change, the table of 31 vaults began 919 px down at 1280 wide and 2,000 px down at 390. MEASURED AFTER: 492 px and 832 px. A cut of 427 px (46 percent) on desktop and 1,168 px (58 percent) on a phone, and five vault rows now sit above the 900 px fold where previously not even the table header did. No horizontal overflow at either width, and the table's sort still asserted working rather than eyeballed. WHAT CHANGED ON THE PAGE: the lead cut from 86 words to 50 and rewritten to start with the instruction rather than the description ('Open any of these in your browser right now'); the fractal note turned from a box into a component, a new .vt-orient strip carrying the sentence and its two links in one flex row, 95 px down to 38 px at 1280 and 252 px to 127 px at 390, with hidden .hv-sep separators so the markdown twin still reads as prose; and one duplicated pointer to the publishing method deleted outright rather than moved. NOTHING WAS THROWN AWAY, which was the author's actual instruction: the three notes were interesting, they were just in the wrong place. They are now full entries on a new LESSONS LEARNED page at /lessons/, in the Evidence menu beside Case studies, built on the premise that a rule with no origin is only a preference and the first person who finds it inconvenient will drop it. Each entry states THE RULE and WHERE IT CAME FROM: classify a credential before it touches anything (from the submission that was a vault key described as a read key), read keys yes and vault keys never, audit every vault before its key appears anywhere, and write the method down rather than just the outcome. It links to the existing case studies rather than repeating them. AND A COUNT CORRECTED ACROSS THREE PAGES while checking the work: the ladder has NINE vaults on it, counted from the table rather than recalled, but the vaults page said eight and the fractal page's lead said 'seven more' beside the origin vault, which is eight. Both drifted when the DSIT vault became a rung in v0.3.1 and the surrounding prose was not updated. The homepage band added in v0.3.8 already said nine, so the three pages now agree. |
| v0.4.0 | 2026-09-21 | git 5f8da5b0 | A STARTUPS SECTION, BECAUSE A LARGE PART OF WHY SGIT EXISTS IS TO LET OTHER PEOPLE BUILD ON IT. New top-level section at /startups/, in the Why menu beside Investors, and it opens by pointing at the operating model rather than the technology: the article shipped in v0.3.9 is its centrepiece, because a founder's journey starts with the model and only then needs the substrate. WHAT YOU GET ON DAY ONE, framed as the four costs a vault removes: a database to run (none, nothing runs between requests so nothing is billed between requests), hosting for your reader (none, the vault carries its own app and also runs from a plain bucket, so deployment is a copy), an account and an install (neither, a read key is the whole credential), and versioning bolted on later (already there, so you can take something away and put it back). Plus the audit story: the server cannot read it, by default rather than by tier. THE LOOP FROM FIRST VAULT TO FIRST CUSTOMER in five steps, each linked to the page that owns it, ending on the one the stack deliberately does not do: billing. With an honest caveat on step four, that rotating a key ends a trial but REVOCATION IS NOT RETROACTIVE, so anybody who cloned keeps what they cloned. WHAT YOU STILL HAVE TO BRING, which is the section that makes the rest credible: billing and payments (not here, not planned), identity and per-user accounts (a read key is a capability, not a login), server-side search and query (the server cannot read the content so it cannot index it), and the judgement about what to ship. AND THE ARGUMENTS THIS RESTS ON POINT OUTWARDS rather than being restated: open-source.sgit.ai and subscriptions.sgit.ai already own two of the three pillars, and they are linked as sibling cards. The section says outright that it is new, deliberately small, and will become its own site when it outgrows a page, the way nineteen others have. Registered in pages.json, NAV and LLMS_SECTIONS; the build's own guard caught the missing llms.txt section before the validator caught the sitemap, which is the guard working as designed. |
| v0.3.9 | 2026-09-21 | git d856aa88 | A NEW ARTICLE ON THE STARTUP OPERATING AND INVESTING MODEL, FROM THE AUTHOR'S OWN VOICE MEMO. 'The most important question is whether they miss it' states the model in three pillars. ONE, be profitable: a startup is simply a product somebody wants to buy at a price that is profitable to you, and if the PRODUCT is not profitable it does not scale whatever the company's accounts say. The skill that matters is SHIPPING, daily, and not a proof of concept or a demo or a video of a demo but a thing a stranger can use alone and get value from, tape and vibe coding entirely acceptable. Keep the running cost near nothing (serverless, as little live state as you can stand) which is why the file system is the database here, and the performance page is cited for what that costs. THEN THE PART ALMOST NOBODY DOES DELIBERATELY: give it away for a short window, then TAKE IT AWAY, and ask the only question that matters, DO THEY MISS IT. A shrug means no product yet, only something people accept when free, which is a much weaker signal than it feels from the inside. Coming back is the why now, and the moment the model turns on. Then two questions rather than one: is the price inside their value-added zone, AND is it a profit for you, with the honest caveat that it may only be profitable at scale and the gap should stay small enough to self fund. Revenue first; no revenue at all is not a marketing problem. TWO, investors should be calling you: the worst time to raise is before profitability, which is exactly when most companies do it. You bargain from weakness with a clock running, and the worst terms are not the money, they are the CONTROL handed to people whose job is to make money rather than to understand your business, whose opinion now carries weight and is structurally misaligned. Stated as one of the most common and most self-inflicted ways companies fail. The analogy is music: do not get signed before you have the album, write the songs, record them in a bedroom studio, play locally, get people buying, THEN take the deal as somebody who does not need one. Not 'never raise', raise from strength. THREE, open source everything, with five reasons that each stand alone: the technology is not the moat and believing it is shapes every decision badly; code written to be read by strangers has cleaner boundaries; a team that has never deleted a component will defend one too long; it is plainly better for the customer, who can read the thing rather than trust a promise; and it is a better FOUNDER EXIT, because building proprietary accumulates technology, much of it not even specific to the startup, that you cannot take with you. Links out to subscriptions.sgit.ai (a subscription is a discount for regular use, not rent on something ignored) and open-source.sgit.ai (open source is a strategy, not a charity) rather than restating arguments those siblings already own. ONE DIAGRAM, drawn for it: the loop from ship to give away to take away to the miss test, with a red return path for no and the paid path for yes, and the third pillar running underneath. AND A BUG FIXED ON THE WAY, present on EVERY article since v0.3.0: the article title template read '{title} (sgit.ai' with no closing bracket, so nine pages shipped a malformed title tag. It is em-dash-rewriter collateral: the paired-bracket rule opened a bracket in one place and closed it in another, the same failure class caught in table cells at the time but missed in the build script because the validator's prose check does not read .py. Two more orphans from the same pass fixed in comments, and a stale '#25 the newest' in the vaults docstring corrected to #31. |
| v0.3.8 | 2026-09-21 | git e4761f4d | THE FLAGSHIP CONCEPT PAGE WAS NOT ON THE HOMEPAGE AT ALL. Fixing the routes into the performance page in v0.3.7 surfaced a larger omission: FRACTAL SEMANTIC GRAPHS, the idea this site's whole vault collection is evidence for, had no homepage presence whatsoever. It now has its own band, placed after 'What people actually ship' because that is the natural escalation: here are the things people ship, and here is what nine of them turn out to be when you look at them together. THE SECTION states the definition in one paragraph (every node opens into a graph with its OWN ontology, a regulation then its articles then the words they define, each world using vocabulary the one above never agreed to; the grammar is constant, the schema never is; for years we called it graphs of graphs of graphs) and then splits into two routes: the idea and the evidence (the jump test, a ladder of twelve rungs from the text of a law down to one compute instance, nine published vaults openable with a read key) and what it costs, measured (no live database, a 1,051-node graph opening in 94 KB and three requests, 11.2 MB of source down to a 4 KB ontology with nothing discarded). Counts were checked against the pages rather than recalled: nine rows in the open-them table, twelve linked rungs on the ladder. AND A LAYOUT BUG FIXED ON THE WAY: the homepage bands alternate background between band and band alt, and inserting a section would have broken the rhythm for everything below it, so the classes from proof through network were reassigned in order. That also corrected a pre-existing double-alt between network and the articles band. |
| v0.3.7 | 2026-09-21 | git 99f0cbb8 | THE BEST PAGE ON THE SITE WAS ALSO THE HARDEST TO FIND. Six releases of measurement went into /demos/fractal-graphs/performance.html and it was reachable from one nav entry under Vaults plus three content links, none of them on a landing page: the fractal page's closing section, docs/vault/reading-a-vault-file.html, and api/vault-objects.html. The author asked where the link actually was, which was the right question. NOW LINKED FROM FIVE MORE PLACES, all editorial rather than nav: the HOMEPAGE, in the agents card that already mentions sparse clones for fast cold starts, and again in that section's footer line; the DOCS INDEX, under Concepts beside the security model and credentials, where somebody looking for reference material will actually look; COMPARISONS, with a note saying outright that the performance comparison lives on its own page because it needs more measurement behind it than an entry allows, which is also the honest reason it is not an entry there; the VAULTS INDEX, in the note that already points at the fractal ladder; and the FRACTAL PAGE'S OWN LEAD, not just its closing section, since a reader who wants the engineering rather than the concept should not have to reach the bottom of a long page to find out it exists. ALSO ADDED TO THE EVIDENCE MENU beside Comparisons, in addition to its existing place under Vaults beside Fractal graphs. A page about how fast something is and what it costs belongs where people look for evidence, not only where its sibling happens to live. No content changed in this release, only the ways in. |
| v0.3.6 | 2026-09-21 | git f0a8d430 | THE API IS A CONVENIENCE OVER THE STORE, NOT A REQUIREMENT OF IT, AND THE PAGE NOW PROVES IT WITH A NUMBER. The author's point: if performance really matters, expose the objects directly through a CDN and skip the function entirely, which is safe precisely BECAUSE everything is encrypted. MEASURED, same client, same vault, same 106 objects, same decryption, only the path to the bytes changed: full clone through the serverless API 65.4 s; full clone against PLAIN GETS WITH NO API IN THE PATH 2.63 s; straight off a local folder 2.05 s. TWENTY FIVE TIMES FASTER with nothing about the vault changed. Honest caveat on the page: the static host was localhost so the network was free and a real CDN adds edge latency, but the client and the work were identical in both rows, so the difference is the function in the middle. IT ALREADY SHIPS: sgit clone --transport static points at any GET host, sniffs which of two published layouts it uses on the first successful read, fans out EIGHT PARALLEL REQUESTS at a time, and records every URL it touches so a test can assert no request ever carried key material. WHY IT IS SAFE: every object is ciphertext under a key the server never had and every name is a hash of those bytes, so public GETs disclose object sizes and request timing, the same side channel the API already has and which the security model already names, and nothing else. AND THE DIRECT PATH IS ALREADY IN PRODUCTION FOR LARGE FILES: anything over 4 MB (the safe margin under the serverless base64 response limit of ~4.7 MB) is handed out as a presigned URL and fetched STRAIGHT FROM STORAGE, which is also the fallback when a batch 502s. So there are already two paths to every byte and the only reason the small case goes through a function is that nobody has needed it not to. FOUR ORDINARY STORAGE OPTIONS listed: a CDN in front of the bucket, where immutable hash-named objects are the ideal cache key; ranged and parallel GETs, which is how a 100 MB or 500 MB object should be read; lower-latency storage classes such as S3 Express One Zone, named WITHOUT a number because we have not benchmarked one; and another provider entirely, since what is served is opaque bytes at deterministic paths. FINDING THE OBJECT: usually you already know the id because it is pinned in the page, and when you do not the walk is ref to commit to tree to blob, a couple of requests rather than a clone. Counted against the static host, reading one named file out of a sparse clone cost TWO requests, one of which was the client re-probing the host layout, a 404 it could skip. This is the thing git cannot do, because git packs its objects and negotiates its transport, so one file usually means cloning the repository. AND ONE GAP STATED OUTRIGHT: there is NO HISTORY-DEPTH FLAG. --sparse skips content (256 KB, 7.3 s) and --bare skips the working copy, but a full clone still takes every version, 106 blobs where the current tree is 42 files, and a sparse clone still walks all 7 commits and 28 trees. Depth control is the single change that would most improve clone time. |
| v0.3.5 | 2026-09-21 | git 11fafba1 | THE HEADLINE LATENCY WAS A COLD START PRESENTED AS AN ARCHITECTURE COST, AND THE BATCH OPTIMISATIONS WERE MISSING. Both flagged by the author, both wrong on the page, both now measured properly. THE FIXED COST IS NOT ABOUT BYTES: six runs each, best of run, a GET returning 340 bytes took 0.331 s and a GET returning 41 KB took 0.309 s. The same. At 2.3 KB it is 0.347 s. Only at 1.0 MB does transfer appear at all, and then it is 0.300 s of a 0.647 s total. One request in the run returned in 4.8 s, which is what a cold start looks like. So the floor of about a third of a second is THE PER-INVOCATION COST OF RUNNING THIS API SERVERLESS, a deployment choice, not a property of reading encrypted data. SG/API also runs on EC2 with a warm process already listening, where that cost does not exist; not measured here, so the page puts no number on it and says so. The v0.3.4 table said 'cold network fetch 1,210 ms' as though the architecture cost that: it was the CLI figure, and it is now split into 347 ms of fixed overhead plus 300 ms of transfer, with the raw GET of the same object (0.65 s) shown beside the client one (1.21 s). BATCHING, WHICH IS THE ANSWER TO THE FIXED COST, measured on small objects so only the per-object term shows: 1 object 0.590 s, 2 in one batch 0.394 s, 5 in 0.560 s, 10 in 0.872 s, 18 in 1.528 s. That is a straight line, TIME = 0.25 s FIXED + ABOUT 71 ms PER OBJECT + TRANSFER. Eighteen objects one at a time would be roughly 6.3 s; in one batch 1.53 s, FOUR TIMES FASTER, and the saving grows with the count. THE BATCH ENDPOINT DOES MORE THAN READS, which the page had not covered at all: up to 100 operations per request, MIXED READS AND WRITES, authorised per operation, with op types read, write, write-if-match and delete. write-if-match carries the SHA-256 of the content you believe is there and IF ANY MATCH FAILS THE WHOLE BATCH IS REJECTED, which is optimistic concurrency across a set of files in one round trip with no lock anywhere. Large blobs route through presigned URLs rather than the response body. AND THE NEXT OPTIMISATION IS NAMED RATHER THAN GLOSSED: 71 ms per object inside a batch is close to linear, the signature of objects being fetched from storage one after another in the handler; fetching them concurrently would bring a 20-object batch near the cost of a 1-object batch. That, plus chunking by accumulated size rather than file count so the 502 stops happening, are the two changes that would move these numbers most, and both are in the API and the client rather than the design. |
| v0.3.4 | 2026-09-21 | git 2e7f594a | THE BIGGEST PERFORMANCE FACTOR IS THE DESIGN, AND THE PAGE HAD BURIED IT. The author's point: performance here comes from architectural decisions and the design the site promotes, because you start by asking WHAT DATA DO I NEED FOR THE TASK AT HAND. The page now opens on that and gives it a section of its own. STANDING ON GIANTS, three layers that are already fast and are composed rather than replaced: the file system, a high-performance indexed store with the OS page cache in front; a content-addressed hash store on top of it, where a name is a hash so lookup is a path, dedup is free and a cache entry cannot be wrong; and the graph on top of that, which is the part that tells you WHICH BYTES to ask for. AND THE FAIR VERSION OF THE DATABASE COMPARISON: a database is fast largely because it keeps the working set in memory, which is the same insight, not cheating. The difference is who picks the working set. A buffer pool guesses it in advance from access patterns for every reader at once; we pick it per question at the moment the question is asked and throw it away after. MEASURED, BECAUSE THE HABIT ONLY MAKES SENSE IF LOADING IS CHEAP, on the 1.0 MB file holding the whole DSIT graph: cold network fetch 1,210 ms; local disk read 2.5 ms at 418 MB/s; AES-256-GCM DECRYPT 0.351 ms at 2,978 MB/s; JSON parse 3.2 ms. So decryption is 0.03 percent of the cold fetch and about a TENTH OF THE JSON PARSE, and on a 59 KB shard it is 0.025 ms. Encryption is free at these sizes and the network is everything, which puts the question back on how many bytes you asked for. THE DESIGN RULE AS A BUDGET: under 100 KB is an answer, around 1 MB is a whole world, 10 MB and up means you are loading a store rather than an answer, and gigabytes is a design error that no tuning will fix. SAVE IS WHERE THE LOOP COMPOUNDS, the LETS step people skip: saving is not filing the answer away, it is leaving an artefact cut to the shape of the NEXT question. The Article 9 slice exists because somebody asked about Article 9 once, so asking again costs 29 KB instead of a megabyte. Build time replaces query time one question at a time, paid by whoever asked first, with nothing decided in advance. RESTRUCTURING INTO CONTEXT IS COMPRESSION, the fractal property argued as volume rather than meaning, with the measured ladder in the Regulation Graph vault: raw Formex source 11,216,043 bytes; the graph, 1,523 nodes and 1,944 edges, 1,073,915 bytes, 10x smaller; one article's pre-cut slice 29,638, 36x smaller; the ontology 4,217, another 7x. Top to bottom 11.2 MB down to 4.2 KB, a factor of about 2,660, WITH NOTHING THROWN AWAY, because every level keeps the edge down to the one below. Query the small thing, follow the link only when the answer needs it. WHICH IS WHY IT SCALES IN THE DIRECTION THAT BREAKS SCHEMA-FIRST SYSTEMS: there, more data means a bigger index and a bigger machine; here the store can be terabytes while what a question loads stays in megabytes, because the graph is what tells you which bytes matter. Adding a terabyte adds nodes you did not load. ALSO: a real SQL engine comes along wherever the slice lands, and the managed services already work this way, loading a dataset into an in-memory SQLite or MySQL when an instance wakes, so we do explicitly what they do implicitly, chosen per question rather than per instance lifecycle. AND A CORRECTION FOUND BY MEASURING: this page said 617 nodes and 694 edges, quoting the vault's page. The file as cloned today has 1,051 NODES AND 1,289 EDGES across five worlds, because the vault released 0.2.1 on 21 September and the graph grew. Every count on the page is now counted rather than quoted, and the drift is only visible because the vault keeps its versions rather than overwriting them. The vault's own page still carries the figure it was published with. |
| v0.3.3 | 2026-09-21 | git 4b468e61 | THE PERFORMANCE PAGE WAS MISSING THE THREE THINGS THAT MAKE IT FAST. The author read v0.3.2 and named them: reading an encrypted file takes a couple of requests and the site should have the guidance; the append mode has its own performance implications; and the immutability of the data files is what allows client-side caching of ENCRYPTED data, which is what the website and the vault web app already do. Plus a live example to point at, sgraph.ai/en-gb/library/, a high-performance site running entirely from encrypted data. FOUR NEW SECTIONS, all measured or read from published source on 21 September 2026. (1) ONE REQUEST: file ids are derived by HMAC-SHA256 over the read key under named domains (sg-vault-v1:file-id:ref, :branch-ref, :branch-index), identical constants in the CLI and the browser client, so a holder of the read key COMPUTES the address of the ref, the index and the settings before issuing any request. No discovery round trip. Reading is then a plain CORS GET with no auth header: measured 2,364 bytes of ciphertext in 0.86 s and 59,324 in 0.63 s, best of five 0.33 s. One POST to /api/vault/batch/ returned FIVE objects in 0.87 s and TWENTY objects, 3.76 MB, in 2.79 s, all in a single round trip; 42 objects returned 502, the server's response-size limit, which the CLI already handles by splitting the chunk. Encryption costs a FLAT 28 BYTES per object (12-byte nonce, 16-byte tag), confirmed on both measurements, not a percentage. And two ways to address a file, pin the content-addressed id for one GET forever, or resolve HEAD to tree to blob for always current, which is a design choice rather than a default. (2) THE 65 SECOND CLONE IS CORRECTED, because the new numbers disprove the explanation v0.3.2 gave. The clone log shows 7 commits, 28 trees and 106 BLOBS, not 42 files, because a full clone takes the history; then one batch of 50 hit the response-size limit and degraded to 50 individual fetches, which is most of the 65 seconds. The transport moved 3.76 MB in 2.79 s when asked in one request, so this is a client-side chunking bug (chunk by accumulated size, not file count) and not a property of the architecture. Said on the page in those words. (3) APPEND MODE: lanes live at bare/append/{token}/pending/, OUTSIDE the commit tree, so appends never touch a branch and never conflict with a push. A write is one account-less POST with the token in the body: no session, no read-modify-write, no commit, no tree rebuild, no lock. The response is deliberately blind (ok true, no id, no count), so the server does no extra work and leaks nothing by size or timing. Writes never contend with reads because a reader walking the graph never looks at a lane. Several anchors means several lanes, so one flooding sender cannot bury another. (4) CACHING ENCRYPTED DATA, the easy case: the cached bytes are CIPHERTEXT, so a cache is not a trust boundary and the browser cache, IndexedDB, a CDN edge and a corporate proxy can all hold vault objects without widening exposure; and an obj-cas-imm- id is SHA-256 OVER THE CIPHERTEXT, so an entry under that name can never be stale or wrong and no invalidation logic exists anywhere. Mutable refs are the exception and the failure is silent. (5) LIVE EVIDENCE: the sgraph.ai library is a 270 KB static shell (28 KB HTML plus 242 KB of CSS and components, measured) whose every article, nav entry and blog post comes out of two encrypted vaults, decrypted in the tab, with the server unable to read a word of what it serves. Its blog entries pin their content-addressed object ids in the page for a single GET, while its navigation is deliberately NOT pinned and resolves HEAD to tree to blob at runtime so it stays current. Its cache script keeps immutable objects in IndexedDB for later page loads with no network at all, collapses concurrent callers into one request, and labels every response idb-hit, inflight or network. AND A GAP FOUND WHILE MEASURING, reported rather than smoothed over: our own caching contract page says immutable objects are served Cache-Control public, max-age=31536000, immutable, and refs no-store. On 21 September 2026 the read endpoint returned NO Cache-Control header at all for an immutable object and the CDN reported a miss. The mechanism is unaffected because the client cache keys on the id rather than trusting a header, which is the more robust design, but the documented header is not live on that path today and the page now says so. |
| v0.3.2 | 2026-09-21 | git 5cdd3071 | A READER ASKED FOR THE PERFORMANCE NUMBERS, SO THEY WERE MEASURED RATHER THAN ESTIMATED. The question, after the fractal graphs page went out: what is the performance of this against ordinary graph engineering? /demos/fractal-graphs/performance.html answers it, and every figure on it was taken on 21 September 2026 from an ordinary cloud container against two live published vaults, using the read keys printed on their own pages. FROM THE COMMAND LINE, against the 42-file 3.2 MB DSIT vault whose graph is 617 nodes and 694 edges: full clone 65.4 s; sparse clone, meaning every path, size and hash with no content, 7.3 s and 256 KB; one 59 KB file that answers one question 0.49 s; a second file 0.87 s; the entire graph as one 1.0 MB file 1.21 s; an already-fetched file 0.18 s with no network at all. So cloning everything costs 65 seconds and answering a question costs 7.8 seconds and 315 KB. The same sparse call against the 207-file 14.9 MB Regulation Graph took 7.06 s and 360 KB, because the index does not grow with the content. IN THE BROWSER, by instrumenting the page and recording every response, so these are exact byte counts: the landing view of that 617-node graph is 94 KB in 3 requests, guidance 295 KB in 4, the graph view 1.12 MB in 5, data and queries 1.19 MB in 6, against a 3.2 MB vault that no view ever loads whole. The ontology is 2 KB, 4,217 bytes in the Regulation Graph, which is the entire price of arriving in another world and learning its rules, and that is what makes the jump affordable rather than theoretical. The 859 KB query engine loads only if you query. THE ARCHITECTURE IS NAMED: no live database, files in object storage read directly, and LETS, meaning Load, Extract, Transform, Save, where Save writes new immutable files instead of overwriting, which is why every cache in the path is correct forever and why there is no server. THE COST MODEL IS THE OTHER HALF the author asked for: zero instance hours, zero replicas, zero index memory, no separate backup line because every version is already kept, no staging copy because a clone is a clone; storage and egress only; query compute paid by the reader's own device. The whole published estate is 2,662 files and 295 MB. Cost scales with what is read, not with what exists and not with time. RUN EVERYWHERE, on one read key: a browser tab, a terminal, a serverless function, a CI container, a static host with no backend, plus fractal deployment, where the deployment unit is a set of files and a key, so putting a graph inside a regulated environment or an air-gapped machine is a copy rather than a project, and two organisations can join their graphs by exchanging an edge and a read key without either adopting the other's schema. AND SIX PLACES IT IS SLOWER, stated plainly, including the one a graph database wins outright: six hops across a hundred million edges in one schema. The commands to repeat every measurement are on the page. |
| v0.3.1 | 2026-09-20 | git 85f20a76 | VAULT #31, AND IT ARRIVED AT THE SAME CONCLUSION THIS SITE SPENT A WEEK REACHING. An independent reference edition of the UK DSIT AI Risk Management Toolkit, submitted under the sgit_public_read_ prefix, which is the form the credentials page now asks for and the first submission to use it. The vault models the guidance, the official workbook, the risk method and the cited frameworks as FOUR SEPARATE WORLDS with named bridges, 617 nodes and 694 edges, and states as the first of its four declared limits: 'containment alone is not fractality. Cross-world edges make the semantic transitions inspectable.' That is the same correction the author made to the fractal graphs page on 19 September, reached by a different author in a different vocabulary, so the page now cites it and the ladder gains the rung. THE HONESTY IS THE OTHER REASON IT IS HERE: every edge is labelled curated or lexical, with the limit 'lexical mentions are not validated meaning' written down; five source snapshots are retained with their URLs, retrieval dates and SHA-256; two of its eight checks exist only to prove the official XLSX and ODS bytes were not touched; and it publishes six gaps about itself, including a correction of its own earlier count (208 formula cells, not 227), a version contradiction in the source preserved rather than resolved (the filename says v1.1, the Welcome sheet says v1.0), two broken defined names left broken because repairing somebody else's document is an edit, and the refusal to read starter rows as evidence of adoption. AUDIT: no credentials, no personal data, two published DSIT institutional contacts, OGL v3.0 acknowledged, official status disclaimed on the front page and in NOTICE.md, and an all-zeros negative control that produced no clone where the real key produced 42 files. |
| v0.3.0 | 2026-09-20 | git 8b46d285 | TWO SITE-WIDE NORMALISATIONS THE AUTHOR ASKED FOR, AND A GUARD FOR EACH. (1) THE EM-DASH IS GONE FROM PROSE: 3,200 of them, because a good many readers now find the character off-putting. Not a find-and-replace. A rewriter classified every occurrence by context and chose the punctuation the sentence actually wanted: brackets or commas around a parenthetical pair, a colon before an explanation, a full stop with the next word capitalised where the tail was an independent clause, a comma otherwise. Code was left alone by construction, and the same exclusions were written into the validator so the two agree: pre, code, svg, fenced and inline markdown code, inline script, the assets folder, the skills folder (upstream artifacts shipped verbatim) and team/board (rendered from a vault this site does not author). FOUR BUGS FOUND BY CHECKING RATHER THAN ASSUMING: a whitespace tidy reflowed the ASCII diagrams inside pre until it was made mask-aware; the pair rule bridged adjacent table cells and left seven brackets opening in one cell and closing in another, each found by a balance check and fixed by hand; the try page's JavaScript compared against placeholder text the markup no longer had, which would have broken its terminal; and a colon in front of a conjunction reads badly, so 35 became commas. (2) THE LEGACY KEY PREFIX IS GONE: 102 published read keys under sgit_rk1_ and 24 bare ones now carry sgit_public_read_, which declares the intent. The bare ones were bare for a reason worth recording: the prefixed form used to FAIL on the CLI, which is an open brief to the CLI team. Re-running the comparison suite today closed it, all six checks pass on sgit-ai v0.16.2 including prefixed clone succeeded. Only real keys were rewritten, so documentation that names the legacy prefix still names it. |
| v0.2.99 | 2026-09-20 | git 8aadadf9 | THE NEWEST FOUR VAULTS WERE AT THE BOTTOM OF THE TABLE, AND THE MACHINE LIST HAD THEM AT THE TOP. The author asked for the order on the published-vaults page to be fixed. Three bugs behind one symptom. (1) vaults_table() read vaults.json directly, in FILE order, while its own docstring claimed 'the rows ship newest-first in the HTML'. Vaults 27 to 30 had been appended to the end of the file rather than inserted at the top, so they rendered last: the page opened at #26 and ended at #30. (2) The llms.txt generator sorted by ordinal and was therefore correct, which means the human table and the machine list had DISAGREED for four releases, on a page whose own footnote says the two are generated from the same file and cannot drift. (3) Found on the way: the routine that lifts each read key out of its vault page knew sgit_rk1_ and sgit_private_read_ but not sgit_public_read_, so the two keys relabelled in v0.2.98 were being published in llms.txt stripped of the declaration they had just been given. THE FIX IS ONE ORDER FOR THE WHOLE SITE: _vaults() now sorts newest-first and everything reads it, and it asserts what makes that trustworthy, ordinals unique, running 1..N with no gaps, and in the same order as the published dates. Both assertions were tested by breaking the data on purpose: a duplicate ordinal and a date that contradicts its number each fail the build by name. The homepage is untouched because its hero row and its job bands use a hand-curated order, which is why this went unnoticed there. |
| v0.2.98 | 2026-09-20 | git 245934e7 | WE PUBLISHED READ KEYS UNDER A PREFIX THAT DECLARES THEM SECRET, AND AN AGENT CORRECTLY REFUSED TO OPEN THEM. The author sent a screenshot: another agent, asked to inspect the two AIUC-1 vaults, declined because their credentials were labelled private read, and said it would not work around the restriction. It was right and our label was wrong. The CLI defines three current prefixes and says which is which in its own source: the private vault one is a WRITE credential, the private read one is read-only and KEPT SECRET, and the public read one is read-only and DELIBERATELY PUBLISHED. Seven published credentials across the two AIUC-1 pages carried the middle one. Relabelled to the public form, with a dated line on each page saying what changed and that the bytes, the access and the vault are identical. VERIFIED BEFORE RELABELLING, on sgit-ai v0.16.2: bare, legacy rk1, private read and public read all clone the same 699-file vault, an all-zeros key under the same prefix produces nothing, and the SG/Vault web loader strips all five prefixes in its own format module. THE STRUCTURAL FIX MATTERS MORE THAN THE SEVEN STRINGS. The validator now bans both current private prefixes in tracked files, using the same trailing-character rule the write-key tripwire already used, so documentation can still print a prefix as a NAME while a real key fails the build. check_credential.py learned the public prefix (publishable, and the form to use) and now REFUSES the private read one: read-only, leaks no capability, and still not publishable, because the label says the opposite of what publishing it does. NEW PAGE /docs/credentials/ explains the whole thing for the first time: two capabilities with a one-way derivation between them drawn as a diagram, the five prefixes in a table with publish-or-not per row, classification by declaration and never by shape (the CLI's own lesson: guessing from shape is what once misrouted a 64-hex passphrase to a read-only clone), why the word matters when the bytes do not, and what a read key can and cannot do including that revocation is never retroactive. Linked from the docs index, the nav, the gallery intake note and the publishing method. NOT DONE, AND A DECISION FOR THE AUTHOR: 99 published keys across 27 pages still carry the legacy rk1 prefix, which is neutral rather than wrong. |
| v0.2.97 | 2026-09-20 | git d460cd58 | THE ARTICLE THAT INTRODUCES THE TERM, WITH THE PICTURES LINKEDIN CANNOT CARRY. The author had another agent write 'Fractal Semantic Graphs: everything connects to everything, and nobody has to share a schema' from the sgit.ai page, for LinkedIn, and asked whether this site had a place to publish it with the missing images and infographics. It does: /articles/. The text is published as written, in the author's voice, with one italic line added at the top naming it the canonical copy and pointing at the page and the VoiceDebrief vault, and one at the bottom on reuse. Nine figures placed where the prose earns them: the three inline SVG diagrams rendered to images at two times scale (the zoom, the jump, the ladder), the GDPR atlas at altitude zero with its own 'you are at the top of the fractal' panel, the Regulation Graph landing view, the AIUC-1 explorer with two vaults on one canvas, the ThreatModCon zoom ladder, the role risk map, and Article 45's timeline of rulings over an unchanged article, which the article calls its favourite picture in the set. The bare URLs in 'Open them' became links, with the VoiceDebrief vault added to the list. No em-dashes; the article had none and none were introduced. |
| v0.2.96 | 2026-09-20 | git 88f73d67 | THE VAULT NAMED AFTER THE CONCEPT WAS NOT ON THE CONCEPT'S PAGE. Asked whether the GitHub repository VoiceDebrief/VoiceDebrief__Fractal-Semantic-Graphs was in the collection, the answer was yes: it is the plaintext mirror of vault k6xy9z4d, row 11, published on 22 August, and cloning both showed the repository's 90 content files matching the vault's HEAD file for file, both last moved on 10 August. What was missing was the reverse link. The Fractal Semantic Graphs page walked seven graph vaults and never cited the one that carries the name, the fifteen-principle register (P4 everything is a node, P6 fractal descent, P7 the junction rule, P11 altitude, P15 structure points down and meaning radiates out), the leading brief of 6 August whose sentence 'each level is the same operation applied to a larger span, which is what makes the structure fractal rather than merely nested' says in one line what this page took five revisions to reach, and the notation spec's two laws (read aloud as a sentence and decompose into triples; link to the span you compress, because claims from memory are not allowed). A new section, 'where the idea was worked first', quotes all of that with a principle-to-page table, credits the Article 9(2) example in the zoom diagram to the vault that works that provision to exhaustion, and adds the vault to the open-them table. THE VAULT'S OWN PAGE gains a mirror section: the vault practises its own guide, plaintext tree and encrypted store side by side on GitHub, three commits all on 10 August; the consequences stated are that the content is public twice over (the read key adds history and the app, not access), that the repository is a snapshot which will drift if the vault moves, and that the encrypted store is safe in the open for the reason the guide gives. The page's line saying this site 'is built' the same way now says 'was built until v0.2.84'. Counts updated: the concept card and gallery note say eight graph vaults; the graphs.sgit.ai brief asks that site to cite the principles register directly. |
| v0.2.95 | 2026-09-19 | git 2724d757 | THE FOLDER TREE WAS THE WRONG CONTRAST. The fractal graphs page said a hierarchy 'gives you more detail but no new meaning, because the only verb is contains'. The author's objection, in four parts: a single layer's ontology can have a very large number of verbs, each carrying meaning; as long as the links make sense inside that ontology, knowledge is gained one link at a time and it is massive; what the fractal architecture adds is the ability, on one of those links, to jump into another universe with its own rules and definitions; and what makes that fractal is that every such self-contained world is built from the same blocks, nodes, edges, ontologies, taxonomies, triplets. The test section is rewritten on his worked example, given as a voice memo: a risk register (its own rich verbs: gives_rise_to, owned_by, reports_to, mitigates, backs) whose incident fact jumps into security operations (alerts, signals, ATT&CK, attack trees), whose suspicious DNS entry jumps into the DNS estate (zones, records, every logged request; possibly millions of nodes served through an abstraction layer over SQL, a graph database or GraphQL), whose one record jumps into a packet capture. Then the two consequences he drew: every connection followed should teach you something, even 'nothing to see here', with the observer or the query deciding whether value was added; and more granularity means a better representation of reality, chosen per context, with custom views on top being what makes it scale. Plus the upward direction (all of it one node in a bigger graph, graphs composed from graphs treated as a graph all the way up, the schema itself fractal in the Mandelbrot sense). A THIRD DIAGRAM draws the jump: four worlds in a row, each a small graph in its own vocabulary, joined by a jump link on one node each, a bracket above for the bigger graph. Its texts are measured against the viewBox like the other two. The graphs.sgit.ai brief's corresponding bullet and its diagram count are updated to match. |
| v0.2.94 | 2026-09-19 | git f3476af0 | A BRIEF FOR GRAPHS.SGIT.AI, IN PLACE OF A FOOTNOTE. The fractal graphs page carried a small 'one wording to pass upstream' paragraph about the boundaries page on graphs.sgit.ai having the fractal test backwards. The author asked for it to go, and for a proper brief instead, since the sgit.ai page is now the fullest worked application of that site's two theses. The paragraph is gone; /docs/briefs/graphs-sgit-ai-fractal-semantic-graphs/ is the brief. It quotes the boundaries page's four-row table and shows that the page contradicts itself: the Recursion row says 'identical rules, no new format, no special case' while the author's own quote two paragraphs below says an article may be 'so meaty that it requires its own ontology and taxonomy, and that's the power of the fractal element'. Replacement text for the table, the test and llms.txt's sentence nine separates grammar (invariant) from ontology (free). Then: adopt the name and its lineage (already item 1 of their review r001, state 'commented'); lift the precise form of meaning-through-connectivity for the fractal case, 'the deeper you go the more you learn', and 'nobody is forced to conform'; six places to link the page; the two SVG diagrams and the Standards Atlas screenshots to reuse; the four graph vaults their evidence estate does not yet analyse (Standards Atlas GDPR, AIUC-1 conformance, Licence to Operate, ThreatModCon) and the AIUC-1 crosswalk join as a second cross-vault finding; three small corrections found on the way (5 versus 7 stakeholder altitudes in their llms.txt, sentinel.sgit.ai still named where sg-sentinel is the host, the vault count); a section on what not to change; and the prompt to paste, verbatim, at the end. No em-dashes in the brief. |
| v0.2.93 | 2026-09-19 | git 96afb763 | The fractal graphs page description, which the markdown twin prints as its blockquote, had one em-dash left; a colon now. The ', sgit.ai' suffix on every page title is a site-wide convention and stays until the site-wide pass is decided. |
| v0.2.92 | 2026-09-19 | git 44f819a2 | NO EM-DASHES ON THE FRACTAL GRAPHS PAGE. The author asked for the dash to go, since a good many readers now find it off-putting. Eighty-two of them on forty-six lines, each rewritten by hand rather than by substitution: a parenthetical pair becomes commas or brackets, a dash before an explanation becomes a colon, a dash before a new thought becomes a full stop, the section headings go 'Altitude 0: the law', the diagram headers take a colon, and the ladder's header takes a middle dot. The one table cell that was a bare dash now says 'not measured'. Site-wide there are about 3,300 more across 212 source files; that pass is a separate decision and has not been made here. |
| v0.2.91 | 2026-09-19 | git 318e41d6 | 'THE DEEPER YOU GO THE LESS YOU LEARN' WAS WRONG, OR AT LEAST WRONG ENOUGH TO CONFUSE. The author read the folder-tree sentence in the fractal graphs test and asked whether it should not be the MORE you learn, since depth brings connectivity. It should, for a fractal graph, and the sentence was trying to say something narrower about hierarchies: depth adds detail but no new meaning when the only verb is 'contains'. Rewritten to say exactly that for the hierarchy, and then to state the fractal case outright: the deeper you go the more you learn, because every altitude brings its own vocabulary of relationships and connectivity compounds instead of nesting. A new paragraph puts the cross-domain behaviour precisely, in the author's words. It means one thing: the core meaning of a node is supplied by the ontology at the altitude where it sits, and that ontology is free to change between altitudes (Article 9 is a binding provision, a container of paragraphs, and a source of definitions, depending on the level you read it from), and closes with nature as the example nobody finds strange: universe, galaxy, star system, planet, ecosystem, organism, cell, molecule, atom, particle, the vocabulary changing completely at every altitude while each level stays connected to its neighbours. No schema describes a galaxy and a cell; one grammar describes both. |
| v0.2.90 | 2026-09-19 | git 05c3286d | Captions on the zoom diagram shortened: panels two and three overran their columns after the v0.2.89 rewording, and the footer line was a pixel from the edge. Checked by rendering the SVG at two widths, not by eye on the source. |
| v0.2.89 | 2026-09-19 | git e733f91a | THE DEFINITION HAD THE WORD BACKWARDS. v0.2.87 defined a fractal semantic graph as one where 'every node is itself a semantic graph built by the same rules', and stated the test as 'if zooming into a node needs a new format or a special case, the system is hierarchical'. The author's reading of the page caught it: same types, same verbs, same rules at every level IS a hierarchy, a folder tree, one schema all the way down. It becomes fractal at the moment zooming in lands you somewhere different: a node whose inside has its own node types, verbs and taxonomy (a new format, a special case) and that new world is still joined by an edge to the one above. Graphs of graphs, ontologies of ontologies; the plural is the point. What stays constant is the GRAMMAR (edges are verbs with inverses, meaning in connectivity, provenance kept), never the schema, and that is exactly what lets everything connect to everything without anyone being forced to conform: an organisation, a division, a person, a regulator each define their own world and connect by declared edges, not a merged schema; granularity is a per-situation decision, so a paragraph can be a mini-world with more definition than the document around it. REWRITTEN ACCORDINGLY: the lead, the 'what it is' paragraph, the three-panel diagram's captions (panel 2 is now labelled a legal ontology, panel 3 a lexical one, and the footer reads 'the grammar never changes; the ontology does'), the test paragraph, a new bullet under 'why connect everything' on every unit keeping its own world, the four-word table, the how-far lead, the ladder intro ('eleven altitudes, eleven ontologies, one grammar'), and the rule section's heading and consequence paragraph. ONE WORDING TO PASS UPSTREAM: graphs.sgit.ai's boundaries page states the test with the word 'format'; read as 'stops being a semantic graph' it agrees with this page, read as 'schema' it says the opposite, and this page read it the wrong way first. It should say 'grammar'. Recorded on the page with the date rather than silently corrected. |
| v0.2.88 | 2026-09-19 | git e8edf935 | THE LADDER'S RIGHT COLUMN LOOKED LIKE LINKS AND WAS NOT. Second read of the fractal graphs page: the 'why this page exists' note (the LinkedIn back-story) is gone, the page stands without it; and the ladder diagram's right-hand column was long blue monospace text that read as a row of links nobody could click. It is now two lines per rung: the vault's name as a real link (an SVG anchor, underlined, taking you to that vault's page and its read key, the Acceptance rung points at the seven-views page, the Agent rung at abp.sgit.ai) and the detail beneath it in plain grey. Twelve links, each tested by clicking it in a browser and checking the URL it landed on. The rule it re-learns: if it is blue, it must be clickable; if it is not clickable, it must not be blue. |
| v0.2.87 | 2026-09-19 | git bcabde64 | THE FRACTAL GRAPHS PAGE NOW LEADS WITH THE DEFINITION. The author's first read of v0.2.85 made three points: the title should be Fractal Semantic Graphs, since 'how far down does the graph go' is a section; the page must start by defining and visualising the term and the power of connecting everything with everything, down to the smallest node that makes sense for the use case (in most of ours a word, a number or a symbol); and the first screens must work for a visitor who knows graphs, semantic graphs and ontologies but has never met the FSG idea, which the author used to call 'graphs of graphs of graphs' and 'ontologies of ontologies of ontologies'. Done in that order: a lead that defines the term in three sentences; a section on what it is, with a three-panel inline SVG that zooms from a four-node semantic graph into the Law node (articles, paragraphs, an amendment as an edge) and then into one paragraph (the terms it uses, each an edge from the article that defines them), with the rules unchanged at every zoom; the hierarchical-versus-fractal test borrowed from graphs.sgit.ai; a section on why connect everything with everything, every file format is already a graph, so questions cross formats without a join table, corrections propagate instead of being republished, the smallest node is whatever the question needs, and provenance comes free when the leaf is a word tied to a byte range and a hash, with the verb rule as the discipline that keeps it from being noise; and a four-word table (graph, semantic graph, ontology, fractal semantic graph) saying what each adds and where it stops. The former opening became the 'How far down does the graph go?' section, unchanged below its heading. Title, description, nav card, gallery note and the llms.txt START HERE line renamed to match. |
| v0.2.86 | 2026-09-19 | git c80e73cc | THE HISTORY PURGE, DOCUMENTED AS THE SCENARIO IT WAS. Asked to confirm the force push had really happened (it had: '+ e70d582d...b5ae665d dev -> dev (forced update)') and to write down the exact situation (files we no longer want, in every commit, on a repository with more than one branch) a new case study draws it out in ASCII: the working tree with .git and .sg_vault side by side, the remote with dev and a forgotten August branch, the 15,933 files and the 276 MB to 21 MB pack, why git rm leaves every earlier snapshot intact, what filter-repo does to every commit id (not one of 112 survived), why the push is refused as non-fast-forward and how --force-with-lease pinned to the old id turns it into a compare-and-swap. THE PART PEOPLE MISS IS GIVEN ITS OWN SECTION: reachability. The stale branch was fully merged and dated 23 August, and it still pointed at the old chain (68 commits, 6,191 encrypted files in its tree) so a fresh clone after the force push still downloaded the purged objects, old commit URLs still rendered, and one fetch re-imported the lot into a clean clone (verified by doing it). Forks and refs/pull/N/head are named as the two places a branch deletion does not reach. Then what deletion does on three timescales: clones stop receiving the chain immediately; GitHub's garbage collection makes old ids stop resolving on its own schedule, or on request to Support; clones made before keep the objects forever. Recorded plainly: the branch deletion was refused three times by the session's git proxy and is pending in the GitHub UI, so the 'still downloadable' section is true as published. The recipe is written in the order that matters, and the page opens with the rule that this was housekeeping because only ciphertext was purged, for a secret, rotate first, rewrite second. |
| v0.2.85 | 2026-09-19 | git 5ebdd8af | HOW FAR DOWN DOES THE GRAPH GO? A DEDICATED PAGE FOR THE QUESTION THAT GOT THREE BARE URLS ON LINKEDIN. Asked whether the dimensions and layers had been defined 'all the way down to the EA and system configurations', the author answered with links to three vaults. The answer was right and the form was poor, so /demos/fractal-graphs/ now gives it properly: an eleven-rung ladder drawn as inline SVG from law to compute instance, each rung mapped to the published vault where that altitude is a live graph; the one grammar (every edge a verb with an inverse, relates-to banned, properties never carry meaning, supersede never delete) that makes the word fractal a testable claim; and walkthrough rows for seven vaults with their own screenshots and counts, Regulation Graph, Standards Atlas GDPR, AIUC-1 conformance, Risk Graph Explorer, Agentic Browser Isolation, Licence to Operate, ThreatModCon 2025, plus sibling cards for graphs.sgit.ai, standards.sgit.ai and abp.sgit.ai. THE NEW SCREENSHOTS ARE REAL: the GDPR atlas refuses to run outside a vault host, so a read-key clone was served locally behind a shim implementing sg.vfs over fetch, and its graph view was captured at three altitudes; the panel's own text, 'You are at the top of the fractal', is the page's epigraph. The vault's page gained those views too. THE HONEST SECTION IS THE POINT: the bottom four rungs (environment, runtime, compute) are modelled layers rather than imports from a CMDB or IaC; no published vault holds an enterprise-architecture repository as a graph; AIUC-1 crosswalks resolve at article level only; the GDPR atlas is a dated seed pass and uses the banned relates edge six times (counted from graph/edges.json: 6 of 227); standards.sgit.ai models one instrument and has zero crosswalks; abp.sgit.ai's capability grammar is a vocabulary not yet joined to a real grant. Named gaps get filled. ALSO FIXED, FOUND WHILE PURGING THE MIRROR: the footer on every page still said 'this site is itself served from an encrypted SG/Send vault', false since v0.2.76 and in fact never true of the deployed pages, which GitHub Pages has always served. It now says what is true: thirty vaults open in your browser with published read keys; the pages describing them are static files. Nav: Fractal graphs added under Vaults; llms.txt START HERE block points at the page. |
| v0.2.84 | 2026-09-19 | git b5ae665d | THE SITE'S OWN VAULT MIRROR IS GONE, DELETED FROM THE TREE, PURGED FROM EVERY COMMIT, AND THE BRANCH FORCE-PUSHED. Asked whether the mirror was still needed, the answer at v0.2.83 was no: it had no reader (every session that built the site cloned it from GitHub), no published read key (the one vault on this site nobody could open), and it had been dead since v0.2.76 without the site noticing, seven releases went out over git alone and the live pages were correct throughout. It was also 258 MB in 15,933 files against 24 MB of content in about 750: 91% of the repository. The author's call was delete, with a forced push authorised. Done with git filter-repo over all 112 commits; the pack went from 276 MB to 21 MB, and the one other remote branch (fully merged, dated August) was removed so no ref kept the old objects reachable. The purge is safe for the same reason the mirror was: everything removed was ciphertext under a key that was never in the repository, and the vault itself on the server is untouched. EVERY PAGE THAT DESCRIBED THE PATTERN AS CURRENT WAS REWRITTEN: the one-tree-two-remotes case study is now a retrospective with a 'why we stopped' section and the numbers; the why page, the admin page, the git-and-vaults note, the release-engineer role and the release prompt no longer say 'both remotes'. Historical release notes were left as the dated records they are. THE TOOLING FOLLOWED: release.sh no longer requires .sg_vault or pushes sgit (it still pulls the board vault and still refuses to finish until sgit.ai serves the new version); the key-leak tripwire now reads demo vault write keys from a gitignored admin/local/demo-keys/ folder instead of the dead vault's local tier, and check_credential.py and the publishing method point there too. The release history's commit column switches from vault commit ids to git ids from v0.2.77 on, which also filled the seven PREV_UNFILLED rows the missing key had left. THE THREE PAGES IN THE VAULTS MENU WERE STALE: the demos page listed three vaults as 'published' when there were thirty, and pointed at a plan already delivered, it now leads with the gallery and keeps the three walkthroughs as walkthroughs; the catalogue, which renders a vault, turned out to hold nine entries against the gallery's thirty, so the page now says so with the date and names the gallery as the complete list until the catalogue's key holder catches up; the gallery's footer stopped calling the catalogue the place where new entries start, because for twenty-one of them it was not. |
| v0.2.83 | 2026-09-19 | git 45b99758 | THE ROOT LLMS.TXT WAS POINTING AGENTS AT TWO 404s, AND BURYING THE GUIDANCE IT SHOULD LEAD WITH. Asked to check that an agent reading /llms.txt finds the newest guidance, the answer was that COVERAGE was complete and ROUTING was broken. The guidance front door sat at line 149 of 239, as page entry 83 of 138, indistinguishable from installation.md, while the orientation block at the top still sent agents to /use-cases/ for 'task-shaped guidance and agent briefs', which is where that guidance lived before it moved to /docs/guidance/ and /docs/briefs/. None of the six scoped llms.txt files were advertised at all, so an agent reading the root had no way to learn that /docs/guidance/llms.txt or /demos/vaults/llms.txt exist. Fixed with a START HERE, BY WHAT YOU ARE DOING block before the page list (four entry points by intent, plus the list of scoped indexes) and the stale /use-cases/ pointer corrected. TWO BROKEN LINKS FOUND BY THE GUARD, NOT BY READING: the routing block is hand-written prose naming generated files, which is the exact drift this site warns about, so the build now asserts that every path the preamble points at is a file the build produces. It failed immediately on /docs/exposed-vault-key.md, the line telling agents never to write a vault key into a tracked file, pointing at a 404 for six months; the page is at /case-studies/exposed-vault-key.md. Widening the guard to every section then caught /security.md, referenced twice, where the page is /security/index.md. Both were 404 on the live site and the site's own validator had never looked, because it checks links inside pages and llms.txt is not a page. ALSO CORRECTED: the preamble claimed this site 'is itself served from an encrypted vault'. The vault mirror last moved at v0.2.76 and six releases have gone out over git alone, so the claim came out rather than being left to rot. |
| v0.2.82 | 2026-09-18 | git bd8300e2 | VAULT #30: THE SAME PACK, WRITTEN FOR AN ARCHETYPE INSTEAD OF A COMPANY. A sibling of #29 from the same generator one day later (a fractional CISO pack, two days a month on a retainer for a company that is already certified) and the interesting thing is how it solves the publication problem. #29 described a real role and WITHHELD the company, which meant auditing whether an unnamed FTSE 250 client could be inferred from what was said about it. #30 describes A TYPE OF COMPANY in six rows derived from public sources (what it does, who buys it, where the risk sits, what it has, what it lacks, who governs it) and everything after follows from the archetype, so there is nothing to redact. The rule that generalises: a document written for a class can be published; a document written for an instance has to be scrubbed. New in this one: an ENGAGEMENT document with the monthly rhythm, a twelve-month map, and a section headed 'what two days a month is not', not cover, not a DPO, not delivery, not an audit, not a substitute for a full-time hire; a one-page INFOGRAPHIC rendered from content.json rather than drawn separately, which is the page's hero because it is the pitch on one sheet; and the three 2019 decks rendered in the viewer rather than only archived. The HONEST TENSIONS section names how the offer could be misused against the buyer (cheaper than a permanent hire, and that economy can defer a hire the company needs) which a sales document rarely does. Audit run and stated: no company named or implied, no rate or tax status ('retainer' appears as a word with no figure), one public email, no secrets, read key verified against an all-zeros control. The two packs are worth reading as a pair: the same machinery giving two answers to how you publish a document about a job. |
| v0.2.81 | 2026-09-18 | git 866c39dc | THE SUMMIT SHEETS GET A PREVIEW GRID, AND THEIR NUMBERS ARE DATED RATHER THAN CORRECTED. The four Lisbon handouts now appear on the parent page as four A4 previews (page one of each printed sheet, rendered from the PDF at build and shown as a card) so a reader sees all four at a glance and clicks through to the page with the table, the embed and the download. THE AUTHOR'S CALL ON THE STALE VAULT COUNT: the previous release made a point of '26 public vaults' having become 29 during summit week. The author's instruction is that the sheets are a dated record of what was said in September 2026 and should be kept as printed, so the correction became a dating note. The figures are those that were true when printed, the live table is the current answer, and the sheets are the historical one. Which is the right call: a printed artefact that gets silently re-edited to match today stops being a record of anything. |
| v0.2.80 | 2026-09-17 | git 0817be5b | THE LISBON SUMMIT SHEETS, AS PAGES AND AS THE PDFS THEY WERE HANDED OUT AS. Four audience sheets (founders, startups, investors, corporate) written for a startup summit and published here with a parent page, one page each, the capability table rendered as real HTML, and the PDF both embedded and downloadable. THE PDF IS THE DOWNLOAD, NOT THE PAGE, for the reason this site keeps giving: a PDF is invisible to a search engine, to llms-full.txt and to any agent reading the site, so the content is HTML and the handout is an artefact beside it. What makes them worth publishing rather than filing is the WHAT EXISTS TODAY column, which is unflattering on purpose, 'no payment link', 'not yet packaged as its own product', 'research design; implementation not claimed', 'write-only intake built, never sold'. A capability sheet that cannot say which rows are unfinished is a brochure. TWO THINGS THE CHECK TURNED UP, both while the sheets were being handed out: the PDFs are named RiskMandate.ai while every page inside them is branded sgit.ai and every footer points at sgit.ai/network, the copies here are renamed to match their contents; and the printed line '26 public vaults' is now 29, because three vaults were published during the week of the summit. The pages here do not restate the number and link the live table instead, which is the general rule worth extracting: A PRINTED ARTEFACT SHOULD POINT AT A COMPUTED ONE FOR ANYTHING THAT MOVES. |
| v0.2.79 | 2026-09-17 | git 368d47d8 | A JOB APPLICATION AS A VAULT, AND THE PRIVACY AUDIT PUBLISHED BESIDE IT. Vault #29 is an interim CISO candidate pack delivered as an encrypted vault instead of a CV attached to an email. THE IDEA WORTH STEALING is that the pack is the evidence for its own claim: it says the candidate works with a team of agents and ships encrypted versioned artefacts, and it IS one, so a reviewer does not have to believe the claim, the thing in their hands is the test of it. Three routes split at the front door rather than one document compromising between audiences: the recruiter gets a submission summary to copy and answers to screening questions, the company gets eleven sections including BEFORE SIGNING, a conflict disclosure and one titled TENSIONS, and anyone gets the skills map and the history. Four documents each exist as PDF, Word, Markdown AND JSON, the fourth being the one that matters, a CV as structured data so a machine reading the pack gets fields rather than a page to parse. The pack's own build refuses what the vault authoring contract refuses, including a JavaScript syntax check of every inline script, the check that caught a shipped bug on riskmandate.ai the day before. THE AUDIT IS ON THE PAGE, not merely performed: the submitter's position was that the vault holds nothing sensitive, does not identify the company and reuses public material. Checked and it holds, client not named anywhere and described only as FTSE 250, no day rates or off-payroll analysis (removed before publication, with the removal disclosed in the brief's own editor's note), no phone or address, one long-public email, no credentials, read key verified against an all-zeros control. One point stated rather than waved through: thirteen named third parties appear in the recommendations with their 2019 titles, public twice over via LinkedIn and the candidate's own CC BY-SA 2019 deck which ships in the vault, labelled title_2019 throughout, and this site quotes the pack's framing rather than reproducing the individual recommendations. |
| v0.2.78 | 2026-09-16 | git f4e330f6 | THE SYNTHETIC-USER METHOD RUNS A SECOND TIME, AGAINST A SECOND PRODUCT, AND THE SECOND RUN IS THE BETTER ARGUMENT. Vault #28 applies #27's method to riskmandate.ai one day later, which matters because one run is an anecdote and two sites is a method. It is not a repeat: the first vault NARRATED and this one MEASURES, words above the fold, character offsets, scroll positions in pixels and screens. Its headline is that THE PRODUCT IS NEVER NAMED WHERE IT IS SOLD: above the fold the home page says policy six times, insure three times and underwriters once, shows a 5 pound price, and never says Agent Behaviour Policy, which first appears 58% of the way down. Two of five read 'buy one, from 5 pounds' as buying an insurance policy for five pounds, and the one who held that reading longest was the insurance professional, the reader best equipped to recognise the vocabulary and therefore the most confidently wrong. THE CLAIM WAS RE-MEASURED RATHER THAN REPEATED: the live page was fetched, rendered at the same viewport and measured independently, and every structural number reproduces to the character, 9,270 characters, first mention at 5,387, 6,481px and 7.2 screens, zero mentions above the fold. Two count lines differ and the page says why they differ rather than hiding it: a broader insur* pattern and a fold-boundary word. THE MOST USEFUL FINDING IS NOT AN OPINION: the first pass recorded a JavaScript error on EVERY page visited, both shipped, the insurance page broken since launch, and every existing test passed because the HTML still rendered and only the console knew, fixed the same session with a test added that parses every inline script and fails the build. One persona, Priya Raghavan, walks both vaults, which is what turns two studies into a comparison. NOTED, NOT FIXED: the site's sgit vault mirror is behind its git mirror, the container holding the write key was recycled, .sg_vault/local is gitignored by design, and these releases have gone out over git alone. |
| v0.2.77 | 2026-09-15 | git 44323549 | SYNTHETIC USERS, THE 27TH VAULT, AND THE MOST USEFUL ONE HERE THAT CONTAINS NO REAL DATA. Five invented buyers were walked through store.sgit.ai one screenshot at a time, asked what they made of each screen, and interviewed at the end: 43 steps, 15 questions the site did not answer, 10 recorded confusions and 18 findings, THREE OF THEM COSTING A SALE. THE IDEA WORTH STEALING is a deliberate handicap. The agent is handed the SCREENSHOT, never the DOM, because an agent reading the DOM finds the buy button every time and therefore finds no confusion, which is the only thing the exercise is for. The protocol is published inside the vault so two runs a month apart are comparable rather than merely sequential, 'where did you guess' is a required field, and a run with no confusion anywhere is treated as a run done badly rather than a site that passed. READ THE VIEWPORT COLUMN: the persona carrying the largest decision one person makes alone on that site did the whole thing on a 390-wide phone, and produced the most questions and the most confusion of anyone, a finding the vault never states, which falls out of the table once the five runs are counted in one place. Zero page errors across all five runs, so none of the confusion was a bug; it was the copy. Four findings are already marked FIXED and kept rather than deleted, on the stated grounds that a findings list that loses the fixed ones cannot be compared with the next set of runs, and the best fix answered a request for a number with a disclosure instead, saying the duration has never run for a paying buyer so there is no measurement to quote. CREDENTIAL HANDLING: what was submitted was a VAULT KEY, not a read key. It was classified before it touched anything, the read key was derived one-way, only the derived key is published, and the derivation was proved with an all-zeros negative control that produced an empty directory against the same vault id. The one credential-shaped string in the vault is a discount code the store publishes itself. |
| v0.2.76 | 2026-09-10 | git 005361e8 | THE TRANSFER API GETS DOCUMENTED, AND A DANGLING REFERENCE CLOSES. The SG/API team wrote an integration guide for sending an encrypted bundle to SG/Send and asked whether it belonged here. Checking rather than assuming turned up something worse than a missing page: the authentication reference already listed x-sgraph-transfer-delete-auth as one of its six headers, describing it as 'transfer deletion, SG/Send transfers, not vaults', while the API section documented ZERO transfer endpoints. The reference named a header for an API it never described, and the index's lead claimed the section was 'the protocol surface' while covering one of the two families on this host. Both are fixed: a transfers page now exists and the header links to it, and the lead says plainly that two families share the host. WHAT WAS TAKEN AND WHAT WAS NOT: the protocol is canonical and belongs here, the two secrets that must never be confused (an access key authorises YOU to upload and lives in a header; a decryption key authorises ANYONE to read and lives in the URL fragment, which no browser sends to the server), the SGMETA envelope that keeps the filename off the server, the three calls, the two traps in the create body (expires_at is MILLISECONDS, and max_downloads 0 means unlimited rather than none), the download_url that returns 404 so you build the link yourself, revocation that is opt-in at create time and impossible after, and the ~4 MB working limit with the reasoning behind it. The workflow half (credential wiring, node shapes, one product's bundle layout) stays with the product it was written for. The page opens with a TRANSFER OR VAULT decision table, because the useful editorial contribution is not restating their endpoints but saying when not to reach for a vault: a vault is the wrong answer for a handover that happens once. Their verification is attributed rather than adopted, every status code on the page was executed by them against production on 9 September 2026, and we have not re-run it. |
| v0.2.75 | 2026-09-09 | obj-cas-imm-f21130f2246b | A BRIEF FOR THE VAULT MAP INFOGRAPHIC, WHICH SPENDS ITS FIRST HALF ON WHY NOT TO START WITH THE PICTURE. An image-model infographic of the sites was made and is good; the ask was for a companion covering the 26 published vaults, grouped by use case and industry. Two blockers sit upstream of any image, and the brief leads with both. FIRST, THE MODEL IT COPIES HAS ALREADY ROTTED: the network infographic's footer reads '19 sites, 18 published, 1 forthcoming' and its cell for skills.sgit.ai says Forthcoming, the network now lists 27 and skills has been live for some time, so a picture about a week old is wrong in its headline number and in one of its cells. The brief turns that into design constraints rather than an objection: every count computed at generation time, the image stamped with the version and date the way a vault app is, the live table linked beside it, and regeneration on the release checklist as a diff on the vault count. SECOND, NEITHER REQUESTED GROUPING EXISTS: vaults.json carries category on all 26 (which is the vault's SHAPE, not its use case) job on only 6, and no industry field at all. So the first deliverable is two fields, not an image, with closed vocabularies the build enforces and 'cross-industry' as a real answer rather than a fabricated sector. Then the accuracy rules for a model that renders text as shapes: generate the caption list from the data first and treat the image as a rendering of it, read every string back character by character, count the cells, and let no vault appear that is not in the file, a plausible invented name being the most dangerous output the process can produce. Plus the publishing rules this site already imposes: the validator bans img src, so the data-shot pipeline applies; real alt text; and the grouped list in HTML beside the picture so the markdown twin carries substance rather than a reference to pixels. |
| v0.2.74 | 2026-09-09 | obj-cas-imm-0f820c930549 | THE AGENT CHIP BECOMES ONE OBJECT, AND THE NETWORK CATCHES UP WITH THE ORG. The llms.txt chip shipped last release as three loose fragments (a pill, a boxed path and a long sentence) floating in dead space between the nav and the breadcrumb, belonging to neither. Four directions were drawn against the site's real tokens and one was chosen: a SINGLE BORDERED CONTROL with a tinted FOR AGENTS cell, the path in mono as the only emphasised element, and the version and date behind a dashed rule. It reads as one thing you can click rather than three things you cannot. The always-on sentence moved into the link's tooltip, it renders on all 124 pages, and as visible text it was instruction noise sitting above every headline on the site. THE NETWORK LIST WAS EIGHT SITES BEHIND. Checked against the organisation's 31 repositories rather than against memory: games, what-can-it-do.games, providers, ungovr.providers, elevenlabs.providers, teams, threat-modeling and chrome-extensions all had repositories, all answered 200, and none was listed. Each entry is written from what that site says about itself (its own title, description and version, fetched) rather than from a guess. TWO CORRECTIONS FELL OUT OF THE CHECK: skills.sgit.ai was still described here as 'GitHub Pages has not published yet, so there is nothing to read at the address', and it has been live for some time, the entry now carries its real thesis and version; and the ElevenLabs repository describes its domain as elevenlabs.provider.sgit.ai, singular, which does not resolve, the live host is elevenlabs.providers.sgit.ai. The site list is 27. |
| v0.2.73 | 2026-09-09 | obj-cas-imm-5569e595ea36 | THE LLMS.TXT STOPS BEING A URL YOU HAVE TO GUESS. Six llms.txt files are published across this site and the only way to find one was to type it onto the end of an address. Every page now carries a small chip above its title naming the one that covers it, FOR AGENTS, the path, and the version and date it was generated. Resolution is deepest-folder-wins, so a page under /docs/vault/ points at that section's index rather than at /docs/llms.txt, and a page with no closer index falls back to the site-wide one; every page therefore has exactly one, and it is always the most specific one that exists. THE STAMP IS THE POINT, not decoration: these files are regenerated on every release, so the chip says which release produced the index a reader is about to fetch, and an agent editing a page can see at a glance whether the index has caught up with it. The chip is chrome rather than content, emitted between the nav and the page body, so it does not reach the markdown twins and cannot drift from them. A build assertion now fails the build if the chip ever points at a folder no generator actually writes, which is the failure this feature would otherwise introduce quietly. CAUGHT BY BUILDING IT: the guidance page still SAID /guidance/llms.txt in two places after last release moved the file to /docs/guidance/, the href had been rewritten by the move script, the prose had not, so the page displayed a path that 404s while linking correctly. Fixed. A reminder that a link rewriter fixes links and not the sentences around them. |
| v0.2.72 | 2026-09-09 | obj-cas-imm-92130ad84859 | ONE FRONT DOOR FOR VAULT GUIDANCE, AND EVERY DOCUMENT MOVED UNDER /docs/. The guidance had accumulated across three top-level folders (/briefs, /vault and a new /guidance) which is three places to look for one kind of thing. Everything readable now lives under /docs/: /docs/briefs, /docs/vault, /docs/guidance, alongside the existing CLI docs. Fourteen pages moved, links rewritten by resolving each one through the move map rather than by prefixing , a blanket prefix would have broken every link that stayed inside the moved subtree. No redirects, by instruction: the estate is in flux and has few external users. Two hand-written .md briefs that live only in the built output, not in the content tree, were nearly lost to the cleanup and were restored from git into the new location. WORKING ON A VAULT: START HERE is the front door that did not exist, and the first thing on it is the guidance that gets repeated to agents most often: VERSION EVERYTHING, SHOW THE VERSION, LINK WHAT CHANGED. The number belongs in the app chrome, small and always visible, and it must link to that version's OWN details rather than a generic changelog; versions live in the vault as versions/index.json plus one file per version, each naming the commit it was built from and saying whether it was recorded or reconstructed. The AIUC-1 conformance vault is named as the reference implementation because it already does exactly this. Seven more practices follow, each with the failure that produced it. /docs/guidance/llms.txt is the same thing shaped for an agent: five rules, a reading order, the briefs, reference implementations to go and check, and edges out to coding.sgit.ai, nfrs.sgit.ai and graphs.sgit.ai, because a page about vaults should not try to also be the style guide, the resilience argument or the grammar of semantic graphs. The page closes by saying why it is mostly links, quoting graphs.sgit.ai's thesis back at itself: a node is just a node, meaning lives in the edges. |
| v0.2.71 | 2026-09-09 | obj-cas-imm-771aa698c057 | GUIDANCE NOW SPLITS BY SURFACE, AND THE THIRD SURFACE FINALLY HAS ITS OWN BRIEF. The guidance on this site had been organised by TASK (decks, markdown, file viewers) which hid the fact that every one of those questions has three different right answers depending on where the code runs. THREE SURFACES is the new router: _page.json inside a vault, an HTML vault app inside a vault, and a page on a *.sgit.ai site outside every vault host, compared on where they run, who reads the vault, which credential is used, what the reader needs, whether search engines and agents can see them at all, and, the row people get wrong, TRUST DIRECTION. Inside a vault host the host protects the reader and sandboxes the app; on a site page there is no host, you ARE the host, and vault bytes are untrusted input arriving in your origin. A second table does the same job across the three surfaces: markdown, file browsing, decks, PDFs, computing over data, and being findable by someone who has never heard of you, which only one surface does at all. READING A VAULT FROM A SITE PAGE is the brief that did not exist, for the devs coding the estate's sites. It leads with the enabling fact: the vault API answers plain CORS GETs with NO AUTH HEADER from any origin, which the server can afford because it returns ciphertext under a key it never held, so no proxy and no backend. It says do not write the reader and names the four house files to copy instead, states the inverted trust rule with a table of how to render each kind of vault content, covers the ref-caching trap that fails silently by rendering an older commit from valid ciphertext, and says what should NOT go on a site page: duplicated vault prose, a rebuilt vault app, and any arrangement where the site is the only way to read the vault. SIX GUIDANCE PAGES ARE NOW LABELLED with the surface they apply to, so the distinction is visible where someone lands rather than only on the router. |
| v0.2.70 | 2026-09-09 | obj-cas-imm-0a8b264f2c4e | THE SECOND BUILD BRIEF, AND IT MOSTLY SAYS DO NOT BUILD IT. Two of the most common things an agent is asked to add to a vault, a markdown viewer and a file/folder browser with raw views, already exist in the platform, and most requests for them are answered by publishing files in the right shape and writing no code at all. The brief is therefore a DECISION rather than a syntax reference: a four-rung ladder (publish .md and stop; add a _page.json if you need a designed page rather than a document; build an app only when a view must COMPUTE something the host cannot know; build a site viewer only when the content must live outside a vault host) with the instruction to stop at the first rung that works. It names the three surfaces that render markdown natively, and the rules that actually catch people rather than the full syntax: raw HTML is stripped and shows as escaped text, images size through the pipe syntax inside the alt text, folder links must go through folder/README.md because a bare folder link resolves by sort order, nested and task lists are unsupported. THE RAW-VIEW CONTRACT, taken from a vault that already lives by it: the AIUC-1 conformance vault's own source says 'raw is the point, a catalog that asks to be trusted has to be readable in the form it was written', and the brief adopts that whole, raw always available for every file, a reader as an addition and never a replacement, the tree driven by a build-time manifest, files fetched on click. Generalised as the estate's habit: anything rendered should be one click from the thing it was rendered from. CORRECTED WHILE CHECKING THE SCHEMA: the content-authoring page said ELEVEN component types and then listed twelve. It says twelve. |
| v0.2.69 | 2026-09-09 | obj-cas-imm-d896dff05cc1 | THE BUILD BRIEF FOR PUTTING A VAULT'S DECKS ON A WEBSITE. v0.2.67 documented the MECHANISM, reading one file out of a vault, and v0.2.68 built the pages, but there was nothing telling another agent how to do this to THEIR vault. There is now: a build brief in the same shape as the telemetry one, which is the shape that worked when another team's agent built from it. It states the decks/v2 contract a vault must publish (the manifest and where it may live, deck sources pushing t/notes/html onto S, screenshots named symbolically rather than pathed, the CSS in the shell's style block, the PDFs), the rule that governs the whole design, A VAULT MUST BE ABLE TO CHANGE WHAT IS SHOWN AND NEVER WHAT THE PAGE DOES, the two sandboxed frames with their exact CSPs, why the deck source must be handed over by postMessage rather than baked into a srcdoc, and why a decrypted PDF cannot go in an iframe at all. It publishes BOTH BUGS we hit rather than only the finished design: the image-name pattern that excluded underscores and failed silently on fifteen slides, and the unscoped closest() that killed every button on the single-deck pages. It ends with a done-means checklist and a prompt to hand the builder. The reference page now points at the brief for anyone who arrived wanting instructions rather than an explanation. Caught in review: the .md twin rule strips inline code spans but not fenced blocks, so tag names inside the prompt failed the build, rewritten to the site's uppercase-placeholder convention, which is the third time that rule has earned its keep. |
| v0.2.68 | 2026-09-09 | obj-cas-imm-b7b0f80752be | A PAGE PER DECK, A FOCUS MODE, AND SCOPED LLMS.TXT FILES. Eleven new pages: each of the nine published decks now has one of its own (four under the AIUC-1 conformance vault, five under Licence to Operate) plus an index for each vault. A deck page opens that deck alone, with the tab strip gone, and carries what the slides cannot: the level it answers, the vocabulary it introduces, who it is for, where it deliberately stops, the question it ends on and which deck picks that question up. Each has a NOTES ON THIS DECK section that is deliberately empty and says so, that room is the reason a deck deserves a page rather than a tab. FOCUS drops the slide list so the stage takes the full width, for presenting and for screen recording, and the stage is re-fitted rather than merely revealed. A BUG THE PER-DECK PAGES EXPOSED IMMEDIATELY: the mount element carries data-deck on a single-deck page, and the click router used an unscoped closest('[data-deck]'), so it matched the mount for every click inside the viewer, prev, next, notes, focus and the PDF button were all silently dead on exactly the pages just built. Scoped to the tab strip. SCOPED LLMS.TXT: /demos/vaults/llms.txt is the catalogue as an agent index (all 26 vaults with id, category, published date, size, file count and published read key) generated from vaults.json, the same file the table on that page is built from, with each read key lifted from the vault's own page rather than kept in a second list that could disagree. Vault keys appear nowhere, as always. Three more sections got one: /vault, /api and /docs. |
| v0.2.67 | 2026-09-09 | obj-cas-imm-daf0dde2fed2 | DECKS AND PDFS READ STRAIGHT OUT OF A VAULT, WITH THE VIEWER OWNED BY THE SITE. The vaults publish presentations (four on the AIUC-1 conformance page, five on Licence to Operate) and until now the only way to see them was to open the vault's own app. They now play on the vault pages themselves, fetched as ciphertext with the read key already printed at the top of each page and decrypted in the reader's browser. THE SPLIT IS THE POINT: from the vault come the manifest, the slide sources, the speaker notes, the screenshots and the printed PDF; from the site come every control you can click (deck tabs, slide list, prev and next, notes, the PDF button, the deep links) so a vault decides what is SHOWN and never what the page DOES. Vault content reaches the page through two opaque-origin frames: a deck builds its slides by running JavaScript, so it runs in a sandboxed frame with default-src none and posts back a plain array, and the slide markup then renders in a second frame with scripting switched off entirely. WHY THE PDF IS A DOWNLOAD, MEASURED RATHER THAN ASSUMED: Chrome refuses to render a PDF in a sandboxed frame at all ('failed to load as a plugin, because the frame into which the plugin is loading is sandboxed') tested across every sandbox combination, so an inline PDF would mean handing vault bytes this origin. The bytes are decrypted in the page and handed to the browser's own download instead; a 2.1 MB PDF arrives byte-identical. Two published deck shapes are handled, because the two vaults differ: one shipped its sources, the other only its built decks. A REAL BUG FOUND BY WALKING EVERYTHING: the first image-name pattern excluded underscores, so fifteen slides rendered with a silently missing screenshot and no error anywhere, all 113 slides across the nine decks are now walked in the browser test, and the count of missing images is zero. New page: READING ONE FILE OUT OF A VAULT, the primitive under every live embed here, written down on its own with the sandbox rules for what comes back.' |
| v0.2.66 | 2026-09-09 | obj-cas-imm-d2f92005581d | THE SHORTS PAGE REWRITTEN FOR SOMEONE WHO ARRIVES WITH NO CONTEXT. A video page is a landing page whether or not it was designed as one: traffic comes from a feed, lands on it directly, and has never seen the vault, the site or the argument. What sat above the seven players was an apology about missing transcripts and a note explaining why a row number in the table could not go stale, two pieces of internal housekeeping addressed to readers who already knew everything the page had to sell. Both are gone from the top. In their place: FOUR WORDS, AND THE GAP BETWEEN TWO OF THEM, grant, mandate, delta, licence to operate, defined in a table with the counts from the demo beside each (12 capabilities, 4, 8, priced per turn), so the whole model is legible before a single video plays. Then two calls to action, in the order a cold visitor needs them: OPEN THE VAULT, with its read key printed as the whole credential and both routes offered (its page here, or straight into the vault UI); and RISKMANDATE.AI, named as where this goes commercially, the business risk layer for autonomous systems, every autonomous system mapped to its blast radius, given a business owner and driven to a time-bound decision: accept, fund, or fix. The vault is the demonstration; RiskMandate is the product it demonstrates, and the Risk Graph Explorer is the same engine already published as a vault. THE TRANSCRIPT GAP IS NOT HIDDEN, IT IS RIGHT-SIZED: still stated in the footer, in one sentence, with the board card still open. A gap worth disclosing was not worth the first screen. Nothing changed about the seven videos, their order, or the three movements. |
| v0.2.65 | 2026-09-09 | obj-cas-imm-9407711950c8 | SEVEN SHORTS ON THE LICENCE TO OPERATE VAULT, INDEXED AND PUT IN ORDER. The author recorded a vertical-video series walking through vault posrhzp3; none of the seven was on the site. They now have a page under the vault, collected in the order they are meant to be watched rather than the order a feed would show them: THE MECHANISM (1-3: grant against mandate, what a block looks like, who in the organisation accepts which risk), THE ARTEFACT (4: how to find and open the vault, the one to send someone who wants to poke at it), THE MODEL (5-7: the gap as the place risk lives, the insurance framing, then policies, claims and premiums). Each carries the author's own description, lightly edited, plus a line mapping it to what it demonstrates in the vault or the estate, the delta for 5, the AIUC-1 conformance layer's insurability query for 6, risks.sgit.ai's no-deny-button position for 7. WHAT THE PAGE REFUSES TO PRETEND: these are descriptions, NOT transcripts. All four of YouTube's timedtext endpoints return empty for every one of the seven, so there is no caption track to pull and the words spoken are absent from the site, from llms-full.txt and from the chat pane's read_page tool. That is the exact failure the risk-graph-explorer walkthroughs page was built to avoid, so the gap is stated in a box at the top, measured rather than guessed, and opened as board card T12. A NUMBER THAT CANNOT ROT, DEMONSTRATED: video 4 tells the viewer to look for 'Vault #23'. Checked, Licence to Operate is still #23 and always will be, because v0.2.58 made that column a permanent publication ordinal rather than a row position. A recorded video naming a row number would have been stale within a day; naming an identity is safe. Embeds go through youtube-nocookie.com with loading=lazy, so opening the page sets no YouTube cookie until somebody presses play. New portrait 9:16 player CSS, since the existing .vembed is a 16:9 box and a Short in it is two black pillars. |
| v0.2.64 | 2026-09-07 | obj-cas-imm-80636cf90122 | THE BOARD MOVES INTO A VAULT OF ITS OWN, AND ITS READ KEY IS PUBLISHED. Two releases after the board appeared as files in the site repository, it was clear the shape was right and the home was wrong: moving a card from review to done cost a full site release. So the seventeen cards moved into vault pdulwi6i, issues/-.md, a README with the card format, a five-column board app (index.html, permissions {}) that lists issues/ through sg.vfs and falls back to issues/index.json when served outside a host, and tools/reindex.py to regenerate that index. THE VAULT IS THE TRUTH; THE SITE IS A READER: release.sh now pulls the vault before it builds (step 0), the loader reads admin/content/team/issues/issues/, which IS the vault's working tree, cloned in place with its encrypted store gitignored and its card files tracked as the build's input, and the board page labels its columns as a snapshot at the site version, with the read key and one open-live button above them. Moving a card is now sgit push, and the board is live the moment it lands; the site catches up at its next release. PUBLISHED AS ROW #26 on the vaults table with its own page, following the method: the write key escrowed in the gitignored tier, the audit run (nothing secret-shaped beyond the read key in its own README), the app screenshotted by driving it, permissions stated. The Sherpa's board prompt and the team page's 'where things are' now point at the vault. One design note: the app works in two places on purpose (under a vault host it reads the files directly and needs no index, served flat it reads the index) because a board that only renders inside one host is a board nobody can screenshot, test or read from a script. |
| v0.2.63 | 2026-09-07 | obj-cas-imm-d523226f4c7a | A CHAT PANE ON EVERY PAGE WHOSE MODEL CALLS TOOLS OVER THIS SITE'S OWN CONTENT. Asked for the pane the sibling sites have; built the stronger version of it. 'Ask this site', bottom right of every page, three tiers like the network chooser. TIER 0, no key: seven tools run directly in the page, type words to search everything (pages, vaults, sibling sites, release notes, board cards), or /vaults, /sites, /updates, /board, /read PATH, /here, instant, private, no network after the index loads. TIER 1, bring-your-own OpenRouter key: the model is handed the same seven tools as OpenAI-style function definitions (search_site, read_page, list_vaults, list_sites, latest_updates, get_board, current_page) and calls them; every call executes HERE over the build-emitted index and the .md twin of any page, so the model can only say what a tool returned, and THE PANE SHOWS EVERY CALL IT MADE as a trace line. Up to six tool rounds, then a plain-prose answer ending in the paths it used, as links. TIER 2, sg.llm inside a vault, is detected-not-wired and on the board as T11, blocked on one fact about the bridge's tool contract. THE INDEX is assets/site-index.json, written beside llms.txt from the same data as the vaults table, the network directory, the feed and the board, one derived file, so an answer in the pane is an answer the site already gives somewhere. LOADED THROUGH THE BOOT BLOCK after site.js, by the same vfs-or-fetch loader, with the loader exposed as window.__sgitBoot so the module resolves the index and the twins the same way on a blob: origin; never a script src. The key goes to openrouter.ai and nowhere else and the pane says so in the same words the chooser uses. Model output is escaped and links are allowed only to http(s) or paths on this site. The validator now parses the chat modules too. The chat-on-a-static-site article gains an addendum and its 'shared component: not started' row becomes 'partly': one site's copy, not yet the versioned module the other eighteen could load. |
| v0.2.62 | 2026-09-07 | obj-cas-imm-e27526f11c99 | TWO SECTIONS: THE TEAM, FOR THE AGENTS; AND INVESTORS, IN THE OPEN. Asked for a full agentic section briefing agents on how to work on this site, with roles and pages like the sibling sites, a board like the ones done before, and the starting prompts for the regular work, plus an investor section on the same open-materials model the founder's other companies use, for an event next week. THE TEAM (team/): nine roles, each a file under admin/content/team/roles/ with mission, what it owns, what it must not touch, the files it works in, the checks it runs, the rules it enforces WITH THE MISTAKE THAT PRODUCED EACH, and a starting prompt; the grid and the nine pages derive. The roles mirror the Explorer team in the CLI repo, specialised for running a site: Sherpa, Publisher, Auditor, Journalist, Cartographer, Ambassador, Designer, Release engineer, Historian, the Publisher and Auditor exist because this site publishes read keys on purpose. TWELVE STARTING PROMPTS (team/prompts.html) for the work that recurs, publish, audit, update, article, sibling site, inbound brief, release, phone bug, markup-to-data, correction, board, read-key sweep, each written to be pasted into a fresh agent, each ending before the release step on purpose. THE BOARD (team/board.html): issues as files under admin/content/team/issues/, five columns rendered from a status line, Needs (only the author can supply) kept apart from Tasks, in the spirit of issues-fs.sgit.ai and the comms board on open-source.sgit.ai; seeded with sixteen real items including the six things only the author can answer. INVESTORS (investors/): the structure of investor.myfeeds.ai, problem, what it is, architecture, traction, business model, market, the ask, use of funds, what could go wrong, materials, with traction COMPUTED from the site and THE ASK LEFT VISIBLY OPEN in a dashed box tracked as board item N1, because nothing on that page may be a number the founder has not supplied; the business-model section quotes the founder's published open-source position through a sibling-site card rather than restating it. NAV: Try folds into Docs; Why becomes a group (Why, Investors); Team is a new group (overview, roles, prompts, board), eight top-level items, as before. TWO BUILD LESSONS: the content loader gained a generic one-file-per-thing reader (roles and issues are three lines each); and angle-bracket placeholders inside code spans broke the markdown twin twice while being regex-wrapped, so the whole team section uses UPPERCASE placeholders with no angle brackets, one convention, every renderer. Verified: 105 pages, validator clean, no overflow at 390 on any new page. |
| v0.2.61 | 2026-09-07 | obj-cas-imm-595486afe042 | A CORRECTION TO THE RELEASE BEFORE IT, CAUGHT BY COUNTING. v0.2.60's article, its update post and its version-log entry all said the homepage went from nine bands to eight. It did not: git show of the previous content file counts nine sections, the new one counts nine, three were cut (features folded into the walkthrough, the abstract use cases, the three doors) and three were added (the hero vaults, what people ship, the team). What changed is the ORDER and the first screen, not the length; words went 1,370 to 1,332. The claim was written from memory of the plan rather than from the file, which is exactly the failure this site says it does not permit, so all three places now carry the corrected count and the article says in its own text that it was corrected and why. Second catch, same class: the update post restated the team band's four numbers in prose and was off by one within the hour, because a release had happened; the prose now names the numbers without repeating them. Nothing else changes. |
| v0.2.60 | 2026-09-07 | obj-cas-imm-19a2bbeb1375 | THE HOMEPAGE REBUILT: PROOF BEFORE MECHANISM. Follows the diagnosis published in v0.2.59 rather than a fresh opinion, so the two can be compared, and the 'after' article puts each new band beside the screenshot of what it replaced. HERO: the sentence changed from 'the encrypted git for humans and AI agents' to 'a vault is a unit of work: data, app, history and sources, shipped as one string' (encryption becomes the subordinate clause, which is where a property nobody can look at belongs) and FOUR REAL VAULTS sit directly under it, screenshot each, one click from open, chosen by a hero field in vaults.json so changing the front door is a data edit. NEW BAND 'what people actually ship': six vaults chosen by the JOB they do (hand over a report, publish a standard as data, give a talk, pitch an investor, ship a game that reports back, give an agent a workspace), each with one line on why it is hard any other way, and none of those lines is about encryption. NEW BAND 'one human, a team of agents': four numbers COMPUTED at build (releases from the version log, vaults from the data, sites from the network directory, briefs by counting the briefs page) and the collaboration loop told in three beats with the artefacts linked. CUT: the abstract use-case band (the pages remain, in the nav), and the 'three doors' band (now one pill in the trust strip pointing at the page that already explained it). MOVED DOWN: the terminal walkthrough, under a heading ('under the hood, it is git') because for a visitor who has just opened a real vault, how is now the question; it gained the feature card 'apps live inside the data', which was never on the list. The band count did NOT change (nine before, nine after; three cut, three added) so what changed is the order and the first screen, not the length; bytes went UP because ten screenshots replaced paragraphs, words went down 1,370 to 1,332. IMAGES GO THROUGH shots.js, never a static image src attribute: the validator refuses a static src because a relative one does not resolve inside a vault, and the build injects the loader wherever data-shot appears. Card text carries hidden separators so the .md twin reads 'Reference, name, line, open it' instead of one run-on. ONE CORRECTION CAUGHT BY THE COMPUTED NUMBER: the network heading had been retyped as 'Twenty sites' while the tile said 19. The tile was right (nineteen siblings; twenty with this one). THE GAP STANDS: no published vault yet shows two agents on one vault with a human merge, and the team band is written not to pretend otherwise. Verified at 1400 and 390 wide: 10 figures loaded, 0 failed, no horizontal overflow. |
| v0.2.59 | 2026-09-07 | obj-cas-imm-ddba86527bec | THE DIAGNOSIS BEFORE THE REBUILD, PUBLISHED AS AN ARTICLE, AND A CARD FOR POINTING AT THE SIBLING SITES. Asked to step back and say how the site should present the twenty-five vaults, the answer was a diagnosis before a redesign: the homepage leads with encryption, which cannot be looked at, and a terminal walkthrough of commands every git user has seen; the twenty-five artefacts a stranger can open in one click sit two clicks away as a table; the use cases are categories while concrete examples of each exist one level down; and the strongest story, agents building for agents, a brief published here turned into a vault the same day and reviewed by the team that owns the API, is filed under Docs as a log. One gap named plainly: the homepage's strongest multi-agent claim, a branch per agent and a human merge, has NO published vault behind it. The article carries the evidence as screenshots of the current site, captured before anything changed so the 'after' article can be compared against them honestly, and sets out the fix in order: proof before mechanism, reorder and cut rather than add. NEW DIRECTIVE, !site, a card for referencing a page on another *.sgit.ai site. Author writes host | path | title [| line]; the card pulls that site's category and thesis from its entry in the network directory, so it describes the site the way the site describes itself, and carries a 'part of the sgit.ai network' cue a bare link cannot. The whole card is the pointer target via the title anchor's ::after, so the markup stays a plain link for the .md twin and for screen readers. Debuts in the article pointing at open-source.sgit.ai/about, which is also the decision recorded there: this site gets an About page about sgit, and links to the fuller record rather than duplicating it. An unknown host degrades to host + title with no lookup. |
| v0.2.58 | 2026-09-07 | obj-cas-imm-b61899966f9d | THE SG/API TEAM REVIEWED OUR BUILD BRIEF AND FOUND IT WRONG, SO THE CORRECTION IS NOW MORE PROMINENT THAN THE MISTAKE. Two days after v0.2.55 published the telemetry brief, an agent built the games vault from it and could not get events out. The team that owns the append code read it against the brief and returned a line-referenced review. Both of the things this brief told a builder to VERIFY, it had already answered wrongly. (1) We said sg.append.write fails closed in a read-only session: it does not, there is NO read-only gate on append anywhere, and permissions.append.write is the entire requirement. (2) We steered to a direct fetch instead, which is blocked by the frame's default connect-src blob: data: escapable only by permissions.network, which the reviewer notes appears 'zero times' in the authoring guide and zero times here, and which is the WRONG fix because it reopens every egress from a frame holding decrypted vault content. The brief now recommends the bridge, carries the correction in a box above the original section, and its hand-to-the-builder prompt is reversed. THIS RESOLVED AN OPEN FINDING: the games vault's telemetry is built and never sent, because its app.json declares no permissions at all, which matches the author's report that nothing arrived, and replaces the 'unresolved' note we published rather than guess. Its page now leads with that status instead of claiming it phones home. THREE FACTS THAT EXISTED NOWHERE PUBLIC are now on the API reference: only write takes a vault_id while the other five verbs bind to the currently open vault, so cross-vault listing is impossible by design; fetch maps to append.read, not append.fetch; and the inbox field in a listing is the lane folder, which today is the raw append token while config stores its hash. A follow-up of seven questions went back, which hosts serve the append routes, whether the enum-key derivation is stable enough to publish as a spec, and whether any non-destructive way exists to tell an append token from a read key, since they are the same shape and confusing them would be a serious leak. THE # COLUMN IS NOW AN IDENTITY, NOT A ROW POSITION: it was renumbering 1..25 on every sort, which said nothing. It is a permanent publication ordinal, 1 is the first vault ever published here, so it never changes, and sorting by it is by construction the same order as sorting by date. Asserted in the check rather than eyeballed. |
| v0.2.57 | 2026-09-06 | obj-cas-imm-27f13ad369ff | THE VAULTS TABLE STOPS BEING A KEY DUMP AND BECOMES SOMETHING YOU CAN SORT. Reported from an iPad, where the failure was obvious in a way it never is on a desktop: the read-key column is a 64-hex string, and giving it room squeezed the vault id down to ONE CHARACTER PER LINE, 'ookq4mn4' rendered as a vertical stack. The fix was not narrower columns, it was noticing that the two widest columns were the two nobody needs on an index: the read key and the 'open live' link are both already on each vault's own page, one click away. So the index now answers 'which of these do I want' and the vault page answers 'how do I open it'. GONE: read key, open live, and the dense contents blob. NEW: a # column, a one-line WHAT IT IS, a CATEGORY pill (8 categories over 25 vaults), files and size as separate numeric columns, and a PUBLISHED date. CLICK ANY HEADING TO SORT, default newest-first because the recent ones are the interesting ones. The count line states the total and the category breakdown, which is worth seeing on its own. GENERATED, NOT HAND-WRITTEN: 25 hand-written table rows could not be sorted, counted or kept consistent, so the table comes from admin/content/vaults.json through a VAULTS comment marker, the same mechanism the homepage articles band uses. The published date is NOT a date anybody typed. It is the commit date on which each vault's page first appeared in git, recovered with git log --diff-filter=A, after two weaker sources were tried and rejected: update posts missed ten vaults and false-matched health-score against a later release that merely mentioned it, and the version log had no line for two of them at all. SORTING IS PROGRESSIVE ENHANCEMENT: rows ship newest-first in the HTML, so with JavaScript off the table is still correct and still in the most useful order; the headings are keyboard-operable. On a narrow viewport the 'what it is' column drops out rather than wrapping to nothing, because that sentence is on the vault's page too. Verified at 1280 and 390 wide: 25 rows, zero 64-hex strings on the page, zero 'open live' links, no horizontal overflow, and sorting checked by asserting the order actually flips. |
| v0.2.56 | 2026-09-06 | obj-cas-imm-dd4f74725ece | THE BRIEF CAME BACK AS A VAULT, AND IT IS THE FIRST ONE PUBLISHED HERE THAT PHONES HOME. Two days after v0.2.55 published the build brief on telemetry from a published vault, another agent read it and shipped the thing: two deterministic games about grants, permissions and mandates, sending anonymous usage events over an append lane to a separate private vault. That makes this the first end-to-end test of whether a brief written for an agent produces what it describes, and the answer is yes, including the part the brief was least sure about: it took the FALLBACK path, a direct fetch to the account-less write endpoint with credentials:'omit' and keepalive on the final flush, rather than sg.append through the bridge, which is what the brief said to do if a read-only session fails closed, and app.json declaring no permissions key at all is consistent with that. CREDENTIAL AUDIT, run against the brief's own claims rather than the vault's self-description: no private keys, no enum/write/vault/read key fields, no third-party secrets, no personal data, and EXACTLY ONE 64-hex string in the whole vault, the append token, in five places. It was tested rather than trusted, because an append token and a read key are both 64 hex and a mistake between them would be invisible: cloning the telemetry vault with it yields no clone_mode.json and decrypts nothing. A METHOD CORRECTION THAT COST NOTHING ONLY BECAUSE THE CONTROL WAS RUN: the first version of that test called a LEAK on the strength of sgit clone creating a directory, then an all-zeros key produced the identical result, proving the directory is created regardless and the test discriminated nothing. The marker that actually discriminates is .sg_vault/local/clone_mode.json. Any credential test that has no negative control is not a test; this now goes in the publishing method. TWO FINDINGS PUBLISHED RATHER THAN FILED: (1) two of the four pages still tell the player 'nothing sent', what-can-it-do was fixed to say 'nothing stored', the home page and which-agent-is-it were missed, and the latter contradicts itself on a single screen; nothing leaks, but the subject of the vault is informed consent, which raises the stakes on leftover copy. (2) The write endpoint could not be confirmed from this container, 404 on both hosts under both the append and inbox names, while inbox/list returns 403 on production, which our own API page says is gone. One data point, recorded as unresolved rather than dressed as a conclusion. Screenshots were captured with the telemetry aborted at the network layer so photographing the games did not put junk in somebody's real lane. |
| v0.2.55 | 2026-09-06 | obj-cas-imm-5e5e76eaf7d0 | BRIEFS BECOMES A SECTION WITH TWO KINDS IN IT, AND MOVES FROM EVIDENCE TO DOCS. The /briefs page has been a single scroll of cross-team asks since v0.1.13, each addressed to another team, each with a status, each closing when answered. A brief arrived that is a different species: not a request to anybody, but a durable reference an agent executes, on how one vault sends messages to another and how a vault whose read key is public reports anonymous usage back to its author. Filing it as another ask would have been wrong, so the page now declares the two kinds and separates them: BUILD BRIEFS (executed, never close) above CROSS-TEAM ASKS (addressed, status-tracked), with the seven existing asks untouched and demoted one heading level. The new group starts with two entries rather than one, because demos/vaults/publishing.html was already a build brief, 'written to be followed by another site's agent', misfiled in the vaults section where nobody looking for a method would find it, the same misfiling that created case-studies/ in v0.1.14. It stays at its URL and is listed from both places. NAV: Briefs moves out of the Evidence group and into Docs, beside Skills, the section's centre of gravity is now agent-facing documentation rather than a collaboration record, and Docs is where an agent looks. Evidence keeps comparisons, case studies and use cases. ONE EDITORIAL CALL WORTH RECORDING: the source brief opened by answering 'is there a doctor/patient case study for this?'. There is not; the health-score vault is one vault with three audiences, not two vaults messaging. In the repo brief that section earned its place because the question was asked. On a published page the reader never asked it, and listing that vault among the pages to read implies it is a source for cross-vault messaging, which would send the next reader somewhere useless. Cut from the reading list, kept as one line of signposting, because the health-score vault is exactly where somebody will go looking, and a named absence beats a hidden one. |
| v0.2.54 | 2026-09-05 | obj-cas-imm-f56c7c51361e | THE AIUC-1 VAULT, FORKED AND LAYERED, AND TWO PAGES FOR TWO ARTEFACTS, ONE ROW ON THE LIST. Vault 2wzct4k7 arrived as an updated version of the AIUC-1 catalogue (hq21tlqu) and the first instinct was to replace the page. Reading its own CONFORMANCE.md changed the shape: it copies every byte of the catalogue and adds one directory above it, answering a DIFFERENT question, not 'what does the standard say' (evidenced_by) but 'does this subject do it' (attested_by), and then what would be insurable on a given date. Two artefacts, not two versions. So the catalogue page stays exactly as it was, carrying a note that names the fork; the fork gets its own page; and the vaults table carries ONE row , the fork, whose description links back to the catalogue page, because a table of published vaults is a list of things to open, not a changelog. VERIFIED RATHER THAN REPEATED: the fork's claim is that it did not edit what it copied, so before publishing we ran both suites in the clone, the catalogue's tests/run.py reports 21/21 passed, including the one that rebuilds every source document to the word, and the layer's tests/test_conformance.py reports 19 tests, 0 failed. Neither opens the network. That is the difference between quoting a vault's self-description and checking it. Audit clean: no vault keys, no third-party secrets, no personal data; the two sgit read keys inside it are both already published here by design (regulation graph, Risk Graph Explorer). Four screenshots captured against a local clone rather than the live host. One correction to a claim we nearly made: this is NOT the first vault here to ask for a permission, the VoiceDebrief pitch and Licence to Operate got there first, but it IS the first to ask for a WRITE grant (fs.write scoped to chat/ and nothing else) and the first to ask for the sg.llm bridge, which is the more interesting claim anyway. |
| v0.2.53 | 2026-08-27 | obj-cas-imm-d889737f4500 | ONE OPEN BUTTON PER VAULT PAGE, NOT THREE. Reported from a phone, which is where it actually hurt: the three pages carrying the open-in-a-new-tab button (AIUC-1, VoiceDebrief pitch, Licence to Operate) placed one under the lead, one above the embed and one at the foot. On a narrow viewport the first two sat within a single scroll, separated only by the read-key note, two identical full-width buttons doing the same thing, which reads as a layout bug rather than an offer. Reduced to ONE per page, positioned immediately above the embed, because that is the only point where the reader is genuinely choosing between the frame and a tab; the caption there now carries the REASON that had been sitting on the button removed above it ('a full application', 'a presenter app', 'an interactive simulation'), so nothing was lost by deleting two thirds of the buttons. The early exit is still available and always was: all 24 vault pages carry 'open it read-only in a new tab' as a text link inside the read-key note, which is what made the button under the lead redundant twice over. Verified at 390x844 with a mobile user agent rather than by eyeballing a desktop render: one button per page, no horizontal overflow, text link present. The general lesson, since this will recur as more vaults arrive: repeating a call to action is only helpful when the repetitions are far enough apart that a reader has forgotten the first one, at one scroll's distance it is just clutter. |
| v0.2.52 | 2026-08-27 | obj-cas-imm-618e386c76b0 | LICENCE TO OPERATE, an insurance policy for an agent, simulated, and the 24th published vault. THE IDEA WORTH STEALING IS THE DELTA: the grant is what the agent CAN do (12 capabilities), the mandate is what the user expects and the only thing the policy insures (4, crm:read, kb:search, llm:generate, mail:draft), and the delta is the 8 that sit inside the agent's reach and outside its authority with no policy covering them, including crm:write, crm:export, mail:send and shell:exec. The mandate is 'answer a customer's question from their own record and the help centre, and draft, never send, a reply'; the grant includes shell:exec. That is nhi.sgit.ai's blast-radius argument made COUNTABLE, and priced rather than described. The simulation makes a reader spend it: three replies per turn, each showing its cost before commitment (in band, claims against the pool, or outside cover) over a live rate table with a normal band, an ask-above threshold, an untouchable reserve and customer records marked uninsurable above 20. ARCHITECTURE PROVED BY THE GRANT: the vault holds the terms and the browser holds the run, and app.json requests fs.read plus downloads (READ, NO WRITE, AT ANY PATH) so an app that simulates spending against a policy is structurally incapable of editing the policy it spends against. INTAKE: the credential submitted was a VAULT KEY in the legacy passphrase form, not the read key the handover was written for, the classifier refused it, the read key was derived, and only that is published. PROCESS NOTE WORTH KEEPING: the authoring agent supplied its own audit of all 16 commits, and it was accurate, but it was CHECKED rather than accepted. Three claims re-verified against a fresh read-key clone: no credentials or third-party secrets (confirmed), the /home/claude/ build paths baked into the PDF are gone (confirmed, zero occurrences, fixed upstream in v0.3.1), and the single full-length credential in the vault is the vault's OWN read key, established by deriving it independently and matching it byte for byte rather than by trusting the label on it. That check briefly looked like a finding, which is the argument for running it: a supplied audit is evidence, not a substitute for the check. |
| v0.2.51 | 2026-08-27 | obj-cas-imm-a13b6654c800 | A PITCH DELIVERED FROM A VAULT, and the first non-empty permission grant on the site. The VoiceDebrief pitch to Founder Institute (2 Sep 2026) is the 23rd published vault and the first that is a live presentation rather than a document set: opening it launches a presenter app with twelve timed slides, a 3:00 countdown, speaker notes, Focus and Fullscreen, five backup Q&A slides, one of which is titled 'WhatsApp / ChatGPT already does this', the obvious objection answered rather than avoided, and a Materials view over everything else. What makes it a vault rather than an export is that the WORKING ships with the conclusion: the approved outline and its claims-to-keep-exact list, the spoken script per slide with timings, the fifteen-part pitch pack, the research notes, the product screenshots and the PDF/PPTX exports, with the deck itself generated from deck/src/deck.template.html by a script in the vault rather than hand-maintained. THE PERMISSION STORY IS THE REASON IT EARNS A PAGE: every other vault here declares permissions {}, and this one declares downloads:true and externalLinks:true, it offers PDF and PPTX buttons so it asks for downloads, it links to the live product so it asks for external links, and that is the entire request, with NO FILESYSTEM ACCESS AT ALL at any path. One readable line that maps one-to-one onto two visible affordances is the permission model working as intended, and it reads better against the Risk Graph Explorer's empty grant than any amount of explanation. AUDIT: credentials and third-party secrets clean. Three disclosures are named on the page rather than left to be found, since a fundraising deck is a different category from the rest of the estate, the unit economics and commercial terms, the author's contact address on the closing slide, and the THREE NAMED JUDGES of the session with their affiliations. That last one was checked before publishing rather than after: the sources were read for tactical notes about the named individuals and contain none, only names, roles and affiliations, which is the difference between publishing a fact about a public event and publishing research about people. |
| v0.2.50 | 2026-08-27 | obj-cas-imm-2de78eaae20b | OPEN THE VAULT IN A NEW TAB, and a path that sent a reader to a 404. The AIUC-1 catalog is a full application and has far more room in its own tab than in the embedded frame, so the page now carries a prominent button at the three points where a reader is actually deciding whether to leave: under the lead, at the embed, and at the end. All three open in a new tab with rel=noopener, verified in a browser rather than assumed. THE 404: the page referred to `NOTICE.md` and `docs/source-policy.md` as bare filenames, and a reader reasonably went looking for them in a GitHub repository, where they do not exist, checked, the CLI repo has no docs/ directory at all and zero matches for source-policy. Those files live INSIDE THE VAULT and nowhere else, which is the whole point of the vault, and the page now says so at the point of reference. Worth recording because the site itself was not at fault: sgit.ai renders both as plain `, never as links, in the HTML and in the .md twin, the failure was that a filename with no stated home invites a reader to guess one, and a guess against a repository is the obvious guess. Naming the container is part of naming the file. |
| v0.2.49 | 2026-08-27 | obj-cas-imm-133059705000 | AIUC-1 AS A CITABLE GRAPH, an unofficial, derivative machine-readable catalog of the public AIUC-1 agent standard, and the twenty-second published vault. 53 controls, 144 requirements, 1,126 crosswalks to 13 external frameworks, 1,238 nodes and 3,526 edges over five releases, with every field naming the official page or commit it was read from, the SHA-256 of the retrieved bytes and the retrieval time. A control renders as its EDGES rather than a property bag (has_requirement, maps_to, evidenced_by, applies_to_capability) which is the graphs.sgit.ai grammar applied to a compliance standard. THE BEST THING IN IT IS A REFUSAL: it publishes the five places where the official website and the official changelog repository disagree, classifies each as presentation rather than meaning, and declines to resolve them, 'resolving one means choosing a source, and that is not this build's to choose'. A derived artefact that silently picks a winner has stopped being derived and become an opinion the reader cannot detect. Also: a release AIUC names but which carries no commit is recorded as UNBUILT rather than dropped, and 194 derived change events are kept separate from the 104 change rows AIUC publishes itself. Collection policy is explicit and worth copying, identifying user agent, one request per second, no auth, no slug guessing, every page reached from a page already fetched, and robots.txt fetched first (404 at capture time, with the manifest recording that observation verbatim rather than the conclusion alone). INTAKE NOTE: the credential arrived as a sgit_private_read_ READ key inside a vault URL, the first submission in that form since the classifier learned the prefix, and it classified correctly as publishable rather than coming back 'unrecognised'. Nothing had to be derived. THE HOLD THAT WAS RAISED AND THEN CLEARED BY THE AUTHOR: the vault's own NOTICE.md and docs/source-policy.md state that reuse rights for the full AIUC-1 control text have NOT been confirmed with AIUC and that anyone republishing publicly should confirm them first. Publishing a read key is exactly that republication, so the work stopped and asked rather than proceeding past a warning the vault carries about itself; the author chose to publish as-is. The page therefore reproduces the vault's disclaimers in full above the fold instead of summarising them away, and repeats its removal undertaking. Audit otherwise clean: no sgit credentials, no third-party API keys, no private keys; permissions {}. |
| v0.2.48 | 2026-08-27 | obj-cas-imm-2d922c5fe406 | BOTH PRESENTATION VAULTS NOW LINK THEIR PUBLIC SOURCE. Confirmed by the author that the-cyber-boardroom/Presentation__BlackHat-EU__Dec-2025 and DinisCruz/Presentation-Threat-Mod-Con-2025 are public repositories. This settles a question left open when the Black Hat vault shipped: the branding note was written without being able to establish whether the material was already in the open, because github.com returns 403 to this container's proxy for any repo outside the session's scope, the same 403 for both repos, which is a proxy behaviour and not a signal about either. The consequence is worth stating precisely: the vault is a SECOND copy of material that already sits in public, not the thing that first exposes it, and the Black Hat speaker-template assets in particular are therefore not published here for the first time. The branding note itself is unchanged and still stands, the deck uses the official template because it is a talk that was given there, published as the speaker's own material and not as anything endorsed by or affiliated with the conference. On the ThreatModCon page the link earns its place for a different reason: that vault repairs two upstream files that are invalid JSON, and a repair expressed as a proof (four stray brackets removed, one `],` added, multiset of content lines unchanged) is only auditable if a reader can fetch the broken originals, so the link sits in the repair section rather than in a footer. Both URLs were taken verbatim from each vault's own README rather than retyped. |
| v0.2.47 | 2026-08-27 | obj-cas-imm-dac438a3ef81 | THE DIRECTORY ANSWERS QUESTIONS, and a second conference vault. Nineteen sibling sites is past the point where a list helps, so /network/ now carries a chat panel whose only job is routing, which of these is mine. THE DEFAULT TIER NEEDS NO KEY, NO ACCOUNT AND NO NETWORK CALL, a deterministic scorer running in the browser over a catalogue emitted at build time from admin/content/sites/*.md, the same data the cards and the table are built from, so the answers cannot drift from the directory underneath them. It also SHOWS ITS WORKING: a hit in a site's thesis or domain outweighs one in its summary, and the reply names the matched terms, which an LLM answer does not give you. Tier 1 is opt-in BYOK against OpenRouter, streaming, reusing the pattern already proven in the SG/Vault workbench vault (same endpoint, same versioned sg-llm-request module on dev.tools.sgraph.ai) rather than inventing a client; on failure it falls back to the local matcher and says so. The cost is stated on the panel, not buried: with no host there is no permission floor, so the key sits in the page's origin, never sent to sgit.ai, which has no server to send it to. Tier 2 (the vault-app build, where sg.llm.chat keeps the credential in .vault/llm/config.json below the permission floor) is NOT BUILT and is scoped in a new article including the rows that are not started. ONE REAL MISS FIXED: the matcher routed 'I need to cite a regulation precisely' to wardley-maps, because it knew only each site's own vocabulary, standards.sgit.ai says 'provision' and the reader types 'regulation'. Site entries gained an `aliases` field for the words readers actually arrive with; five real questions now give five correct first hits, and nonsense still returns nothing rather than a confident wrong answer. TWO BUILD RULES CAUGHT ME on the way, both correctly: the validator refused a forward link to the unwritten plan article, and then refused a script tag with a src attribute outright, these pages must also render inside a vault on a blob: origin where a relative src does not resolve, so the loader is fetch+eval like every other component here. ALSO PUBLISHED: ThreatModCon 2025 Barcelona, 'Scaling Threat Modeling with Semantic Knowledge Graphs', eleven linked threat models from customer to compute instance (51 nodes, 179 threats, 3 critical), five interactive views and five Wardley walkthroughs, libraries inlined at identical versions so no page touches the network. Two of its layer files are INVALID JSON UPSTREAM and are repaired in the vault, with the repair expressed as a proof rather than a changelog entry: four stray closing brackets removed, one `],` added, multiset of content lines unchanged, originals kept alongside. Its explorer screenshot was CAPTURED AND THEN DISCARDED, outside the vault host there is no sg.vfs.readText() to answer it, so the page sits on a loading spinner, and a screenshot of a spinner would have misrepresented the vault. |
| v0.2.46 | 2026-08-26 | obj-cas-imm-057b0451154a | A CONFERENCE KEYNOTE AS A VAULT, the twentieth published vault and the first that is a TALK rather than a document set or an app. AI vs. AI: Building Resilient Enterprises in the Age of Autonomous Threats, Black Hat Europe 2025, AI Security Summit, ExCeL London, 9 December 2025. What makes it a good demonstration is that the whole chain travels together under one credential: the deck as presented (26 slides, ~976 KB self-contained app), six PDF exports v0.1.1 to v0.2.0, the eight research papers the talk was built from, and the slide system's own source at ten versions v0.1.0 to v0.1.9. A deck emailed as a PDF is a snapshot with its working removed; this is the working. The load-bearing design detail is that SLIDE CONTENT IS DATA: deck/blackhat-eu-2025.json is read through the vault bridge at load time, so editing a slide is a commit and needs no rebuild, which is also why ten renderer versions can sit beside one deck without either owning the other. permissions {} with present:true. INTAKE: the submitted credential carried the sgit_private_vault_ prefix and was refused as a WRITE credential by the classifier, the prefix family added in the v0.2.40 batch, working as intended on its first real submission since. Read key derived one-way, vault key to the gitignored tier. AUDIT clean across all four passes: no sgit credentials, no third-party API keys (the broadened sweep added after the OpenRouter miss), no private keys, no emails, no external company or client. AWS, Azure, Cloudflare and CrowdStrike appear cited for publicly documented outages, which is the subject of the slide. One judgement recorded rather than buried: the deck uses Black Hat Europe's OFFICIAL SPEAKER TEMPLATE, logo and trademark included, because it is a talk that was given there, published as the speaker's own material with the page stating plainly that it is not endorsed by or affiliated with the conference. Screenshots were captured by serving the cloned vault locally and driving the deck with its own arrow-key bindings, after keypresses sent to the hosted surface failed to reach the deck through the shadow DOM; the first three captures were also named one slide out of step with what they showed and were renamed to match rather than shipped with captions that did not describe the picture. |
| v0.2.45 | 2026-08-26 | obj-cas-imm-598b21e85f91 | ARTICLES GET A HOMEPAGE BAND, A NEW ARTICLE ON THE SPLIT, AND A LAYOUT BUG FIXED FROM YESTERDAY. The network band shipped in v0.2.44 ran the FULL VIEWPORT WIDTH: the homepage bands each carry their own measure on the component (.eco is max-width:1100px itself, there is no wrapper convention here) and the new band had none, so it stretched edge to edge on a wide screen while every other band stayed in the column. Reported from a screenshot rather than caught by the validator, which has no opinion about layout. Fixed and MEASURED: .eco, .netpick and the new .artcards all report exactly 1100px at a 1440px viewport with scrollWidth == innerWidth, and the five area cards now lay out 3+2 instead of 4+1 so the last card does not sit alone. NEW ARTICLE, 'Twenty sites in fifteen days, and what that did to the writing': the repositories were created between 11 and 26 August, fifteen of the twenty in the final five days, and the piece is about what that did to the writing rather than the count, what forced the split (an argument needs its own version history; nineteen arguments through one changelog produces a record nobody can read), what it cost (discovery got worse before it got better; consistency became discipline rather than construction; cross-site links became claims that can rot, as the sentinel.sgit.ai typo showed), and why the directory now opens with a question. ARTICLES BAND on the homepage, DERIVED from the articles list via an marker the build fills, a new article appears there by being written, no list to maintain, the same one-file rule as updates and sites. Also: influences.sgit.ai went live mid-session and is now a full entry with its hero screenshot, taking the family to 18 live of 19; skills.sgit.ai still has DNS and a repository with nothing published and is still listed as such. |
| v0.2.44 | 2026-08-26 | obj-cas-imm-d629c8d66421 | THE NETWORK BECOMES A DIRECTORY. The sibling-site section was built for four entries and there are now NINETEEN, 17 live, 2 with repository and DNS in place but GitHub Pages not yet published (skills, influences), enumerated from the SGit-AI org and probed one by one for DNS, HTTP status and their own stated thesis. At four, a list of cards was the right shape; at nineteen it is a directory a reader has to read before it helps them. So the page now LEADS WITH THE QUESTION: seventeen lines, each one something somebody actually arrives with ('I need to give an AI agent an identity', 'I have to sign off a risk and I do not want to rubber-stamp it', 'I want an issue tracker with no database'), mapped to the site that takes it seriously. Under it, five thematic groups (Agents & AI, Risk & governance, Graphs & method, Security & infrastructure, Business & publishing) then a full scannable table of all nineteen. Every thesis is the SITE'S OWN WORDS, quoted from its H1 or lede rather than paraphrased here, so an entry cannot drift into describing a site that no longer says that. Engine: the sites content type gained `listing: true` (a directory row with no page of its own), plus `category`, `stage` and `thesis`; the four sites with a full write-up keep their pages and the other fifteen are one short markdown file each. Network promoted from the third child of Updates to a top-level nav group, and the homepage gained a network band with five doors in by area, a reader who does not know these sites cannot pick one from a list of domains. Thirteen new hero screenshots captured from the live sites through the local mirror. The two unpublished sites are listed AS unpublished, linking their repositories, rather than omitted. One engine bug found and fixed on the way: the first attempt to add the new fields landed in load_articles instead of load_sites, because the `'status': ...` + `'body': body` pair appears in both loaders and the articles one matched first, caught immediately by a KeyError at build, which is the argument for the build failing loudly rather than defaulting a missing field. |
| v0.2.43 | 2026-08-25 | obj-cas-imm-48fd5df1d329 | SIX VAULTS PUBLISHED, THREE HELD, and one audit gap found the hard way. Nine credentials were submitted; intake classified seven as WRITE keys and two as read keys, the seven read keys were derived one-way, and all nine were cloned and audited with the credential that would actually appear on the page. New pages: PENETRATION TEST REPORT (a pentest as a vault not a PDF, eight audience-specific views over one engagement, and a retest script per finding that exits 0 if fixed and 1 if not; entirely fictional and badged SIMULATED DEMO on its own front page), STANDARDS ATLAS GDPR ('the standard is the graph', rulings, guidance and per-country variation as first-class nodes, corrections scoped to feedback/ so a reviewer can never alter the graph under review), RISKMANDATE FILE SECURITY (risk acceptance moved from end-of-flow rubber stamp to the centre, over versioned JSON queried live by SQLite in the browser), CONTENT-TRANSFORMATION PROXY, SG COMMERCIALISATION (whose most credible artefact is an engagement register with no rows) and the SG/PAYMENTS BRIEF PACK (ten documents stamped PROPOSED). HELD: one vault carrying two live vault keys in plaintext INCLUDING ITS OWN WRITE KEY (publishing its read key would have handed out write access, defeating the entire read/write split) and one private working log. THE THIRD HOLD IS THE FINDING: a vault whose app reads an LLM key from a file passed the first credential pass CLEAN, and was caught only because a screenshot of it showed a chip reading 'key: vault key.json'. The file held a live OpenRouter API key. The scan had looked for vault-key shapes, sgit_ prefixes, PRIVATE KEY blocks and the literal string api_key; the field was named openrouter_key and matched none of them. This is a genuine gap in the tooling, not a near miss to be reframed, the credential checks were built for sgit credentials and had no opinion about third-party API keys, which leak just as expensively. A broader sweep (OpenAI/Anthropic/GitHub/AWS/Google/Slack/JWT shapes, placeholders filtered) now runs over every candidate; across all nine it found exactly one further hit, a forged alg:none token in the pentest vault that IS the finding it documents. Content checks answered two specific questions asked at submission: the commercialisation vault holds no real data (empty register, no emails, no rates, and its 'team' files are agent role definitions, not people), and the proxy vault names no external company or project, verified in text and BY EYE across 120 slide and diagram images a text scan cannot read. The GDPR atlas does name real companies, and correctly so: they are published CJEU and FTC case records. Article updated: nineteen vaults, 1,389 files re-cloned and verified, plus the LinkedIn republication link. |
| v0.2.42 | 2026-08-25 | obj-cas-imm-75af1686df3e | AN INTRODUCTION ARTICLE, and the first CLI imagery on the site. /articles/what-sgit-is.html is the piece to hand somebody who has never heard of this: the category of file that has nowhere good to live, the vault key as address+auth+encryption in one string, the one-way read key that makes sharing possible, and then the proof rather than the claim. Two new terminal screenshots carry that proof and are the first of their kind here, every one of the 73 existing screenshots was of a browser. Both were captured from real runs, not mocked: a clone of the published EU AI Act vault (273 objects, 207 files) and the same vault's stored object rendered as a hexdump, 786 bytes of AES-256-GCM ciphertext whose name is a SHA-256 of those encrypted bytes. Also written up: apps in vaults running under permissions {}, capability without credential, and the four-site network. VERIFIED BEFORE PUBLISHING: all eleven published read keys were cloned from scratch, 781 files total, zero failures. That check first reported the opposite. Every clone failed with 'no named ref on the server', which looked like every vault page on this site instructing readers to run a command that could not work, and the real cause was a stale CLI in the authoring container, v0.15.0, where sgit clone cannot reach these vaults. v0.16.0 clones all eleven. The finding was retracted rather than shipped, which is the whole reason the check exists: an intro article is exactly the page that must not repeat an instruction nobody re-ran. A LinkedIn-newsletter edition of the same piece was produced alongside it as plain text with image placement markers, since that editor renders no markdown and asterisks would paste literally. |
| v0.2.41 | 2026-08-22 | obj-cas-imm-f401ef7115e0 | GRAPHS.SGIT.AI RESOLVES, the CNAME landed hours after v0.2.39 shipped the entry, so the `url:` override comes back out and the card links the subdomain directly. Deleting one frontmatter line was the entire change, which was the point of adding the field: a site finished before its DNS should be linked at the address that answers, and should not need rewriting when the real one starts working. The DNS-pending chip and the note both disappear on their own because they were derived from url != domain rather than written into the page. Verified before and after: graphs.sgit.ai returned nothing from a resolver on 21 August and answers 200 today. The sentinel.sgit.ai correction on that entry was re-checked rather than carried forward on trust and still stands, the graphs site links to a host that does not resolve, and the site is sg-sentinel.sgit.ai. Also settled this release, for the record: the 34 historical tags CI could never push (v0.1.9-v0.2.16, blocked because GITHUB_TOKEN cannot push a ref at a commit carrying a different workflow blob) are now on the remote, pushed from a workflows-scoped credential. The first attempt was a plain `git push --tags`, which reported 'Everything up-to-date' and did nothing: the tags only ever existed inside destroyed CI runners, so no clone had them to push. They had to be recreated locally from the commit subjects first. All 58 release commits are now tagged, each verified to point at the commit whose subject names it, and the backfill loop is a no-op from here. |
| v0.2.40 | 2026-08-22 | obj-cas-imm-550fd7d8bac2 | THE TAG GATE TOOK THE SITE DOWN, and this release fixes the gate and publishes what it held back. Two good commits landed on dev after v0.2.39, the VoiceDebrief vault (the ninth published vault, ten screenshots driven from its published read key) and a check_credential fix, and sgit.ai served neither for a day. Nothing was wrong with either commit. The CI tag job read SITE_VERSION, found v0.2.39 already tagged on the EARLIER commit, and failed with 'SITE_VERSION was not bumped for this release', when the truth was that this was not a release at all. Because the deploy job needs tag-release to be success OR skipped, and a FAILURE is neither, the publish never ran. Re-running could not help: the check is deterministic, and attempt 2 failed identically. THE FIX: what makes a push a release is now its commit subject, which is where release.sh already writes the version. A commit carrying no 'site vR.M.N:' subject is an ordinary push, tagged nothing, published anyway. A commit that DOES claim a version is held to the full contract, and to a stricter one than before: the subject and SITE_VERSION must agree (previously only inferred, via whether the backfill loop had produced the tag), the version must not already have shipped, and it must be the next minor. The reasoning behind the asymmetry is recorded in the workflow: a missing tag is a bookkeeping gap, a blocked deploy is an outage. Verified before shipping by extracting the job's script and running it over five cases in a throwaway clone, the exact commit that failed today now exits 0; a proper release tags; subject/SITE_VERSION disagreement, a reused version and a skipped minor all still fail, each with a message that names what is actually wrong. SECOND CONSEQUENCE, less visible and worth recording: those commits went to git only, so the vault remote never received them and the two stores had drifted, sgit status showed all fifteen VoiceDebrief files as uncommitted. That is the invariant release.sh exists to hold and the reason CI does not author commits itself. This release carries them across. Also in: the VoiceDebrief vault page goes live, check_credential now recognises sgit_private_vault_/sgit_private_read_ (the prefixes the CLI actually prints on init and clone, where the classifier previously called a good read key 'unrecognised', fail-closed, but the kind of refusal that tempts an operator to reach for the vault key instead), and validate.js skips node_modules. |
| v0.2.39 | 2026-08-21 | obj-cas-imm-3d8cf0d26b96 | Fourth site in the network: GRAPHS.SGIT.AI, a grammar for semantic graphs argued in increasing depth, five rules you can apply tomorrow, a working edge set with numbered gaps, then a full positioning against schemas and vector search. Its opening move is to disown the category a reader arrives expecting: 'this is not a graph database pitch… there is no graph database anywhere in the work behind this site'. The thesis is that two nodes both holding 8080 differ not in the value but in the connectivity, and the strongest argument on the site needs no technical background at all: 10,000 hours was an AVERAGE in a 1993 violinist study, not a threshold, half the top group had not reached it, and the author spent his career correcting the popularisation, but the correction never attached, because by then the claim had been carried through 242 papers and 200,000+ citation paths. A document cannot fix that; a graph can mark a claim superseded and turn 'what did we build on this?' into a query. Grammar highlights: every edge is a verb with a distinct inverse, the test being 'would a person in this business say this sentence?', and relates-to is BANNED for a mechanical reason, an edge with no verb carries no constraint, so it cannot narrow a traversal; it costs fan-out and buys nothing. Relevant here because the one indisputably shipped item on that site is sgit's own object model: a content-addressed commit DAG (SHA-256 over CIPHERTEXT, multi-parent, wave-BFS merge-base) plus *.link.json commit-pinned cross-vault edges and the sg.history read-only query API exposed to untrusted sandboxed apps. The grammar argument and the vault are not neighbours by theme; they share a data structure. It is also the FIRST SIBLING WITH A RECIPROCAL LINK, an '↗ part of sgit.ai' chip in its nav and a footer pointing back at /network/, so the index stops being one-way. Engine change: a site entry may now carry a `url:` that differs from its `domain:`. graphs.sgit.ai does not resolve yet (verified: no DNS), and a finished site should be linked at the address that answers rather than held back for a CNAME, so the page states which one it is instead of shipping a dead link and needing a rewrite later. The network audit also found a broken link on the new site itself: it points at sentinel.sgit.ai, which does not resolve. The site is sg-sentinel.sgit.ai. Recorded on the entry for upstream. |
| v0.2.38 | 2026-08-20 | obj-cas-imm-b270f3424691 | Third site in the network: SG-SENTINEL.SGIT.AI, a design for an app-coupled edge guard replacing rented AWS WAF + CloudWatch/Firehose with a layer you own. Its central inversion is that a generic WAF is blind to the app it protects and must denylist, whereas an edge that knows the valid request space can ALLOWLIST, no invalid request reaches the origin. Two things make it worth a page rather than a link. First, a governing correction stated as a constraint: 'Layer 1 never acts and never writes, it only decides and signals; Layer 2 is the sole actor and the sole I/O owner', because a CloudFront Function physically has no network and no filesystem, and the site names its own earlier design, where L1 blocked inline, as a category error. Second, rules are the engine rather than configuration on it: six deterministic rules, each a pure function mapped to an ATT&CK technique, run first-block-wins, with a prototype exercise running the same engine across three targets under a parity matrix asserting identical decisions. It also carries the most honest status language on the network. The pill reads NOT BUILT, and where the prototype's 149 passing tests are cited the site immediately bounds them as 'not deployed anywhere, not in production use, not maintained, not packaged for you to install'. Adding it cost one markdown file and three screenshots, which is what the content type was built for. One engine gap surfaced doing it: the markdown renderer had no TABLE support, so the six-rule core rendered as a paragraph of vertical bars. Pipe tables now parse (header, separator, body) and emit into the site's own .tablewrap, so they scroll on a phone and survive print like every other table here. Caught by looking at the output rather than trusting the validator, which had nothing to object to: badly rendered markdown is still valid HTML. |
| v0.2.37 | 2026-08-20 | obj-cas-imm-1b229ee71709 | REGULATION GRAPH, the EU AI Act as a citable graph, and the first vault here whose publication the audit STOPPED rather than cleared. Regulation (EU) 2024/1689 parsed from official Formex XML retrieved from CELLAR, hash-verified to the source bytes: 113 articles, 500 paragraphs, 180 recitals, 68 definitions, resolving to 1,523 nodes and 1,944 edges across eleven views, browse, Cytoscape citation graph, in-browser SQLite over sql.js, RDF via rdflib, concepts, external instruments, and an experimental Art 9 lab as the declared entry point. WHAT HAPPENED: the submitted credential was a VAULT KEY, not a read key, the fourth time, caught by the intake check. The read key was derived and the audit run with it across 204 text files, which is when it found a LIVE VAULT KEY IN PLAINTEXT inside a handoff document, granting write access to a DIFFERENT vault. Publishing our read key would have handed that away. No page was written; the finding was reported first. Deleting the file would not have been enough, because vault objects are content-addressed and immutable, so a credential committed once may stay reachable from history, the only clean remedy is history that never held it. So this is a REDACTED REPUBLICATION into a new vault: same 206 files, two credentials replaced in place with visible and markers rather than silent deletions, a PUBLIC.md stating the rules and the removals, and a re-audit from a fresh read-key clone: 205 files, zero findings. The second removal was a judgement call, a read key is publishable by its OWNER, and that one belonged to a third vault, so it goes and the decision stays with a human. RULE 3 VERIFIED RATHER THAN ASSUMED: the Graph REPL is an LLM chat, and repl.js looks for an OpenRouter key at /key.json INSIDE THE VAULT before falling back to device storage, so a shipped key would be an open tab on somebody else's budget. No key.json exists, confirmed in the read-key clone rather than in our working copy. The 370-plus bare 64-hex strings the scan flagged were all sha256 provenance hashes, checked individually, a scan that never produces a false positive is not scanning hard enough. The rule that caught all of this came from Risk Graph Explorer's own PUBLIC.md, not from us; it has now paid for itself. |
| v0.2.36 | 2026-08-19 | obj-cas-imm-18bcdab6db5d | A NETWORK section for the sibling *.sgit.ai sites, built as a content type rather than as two pages, because many more are coming. nhi.sgit.ai argues that 'how do I give my agents an identity' splits into agents you RUN and agents you RENT, and that the industry answers only the first, SPIFFE for workloads you can attest, an open feature request for the agents anyone actually names. pki.sgit.ai designs a key registry from the 2019 keyserver failure and publishes four rules BEFORE the registry exists, reaching a resolution worth borrowing: append-only is safe when a writer appends only to objects it owns and fatal when anyone may append to somebody else's, so the rule to carry is not 'append-only' but 'the writer owns what it writes', which is append lanes, already shipped. Six screenshots captured from the live sites through the curl mirror the sandbox needs, since Chromium cannot egress here. Adding the next site is ONE markdown file plus its screenshots: the index, the cards and the per-site page are derived, same contract as updates and articles. Two engine fixes fell out of building it. The generator now WIRES THE SCREENSHOT COMPONENT AUTOMATICALLY for any page containing figures, a markdown author has no place to put a script tag, and the views page had already shipped once with figures and no loader, which errors nowhere and simply shows nothing. The first version of that check matched on 'figure class="shot"' and missed 'class="shot net-shot"', leaving the new index in exactly the state the check existed to prevent; it now matches on data-shot=, the attribute the component actually selects on. Detect on what the consumer looks for, not on how it happened to be written. |
| v0.2.35 | 2026-08-19 | obj-cas-imm-1f3ce8d32a28 | Two new sections and the navigation restructure they forced. UPDATES and ARTICLES, both built on the VoiceDebrief journalist pipeline's central rule, which was worth adopting verbatim: PUBLISHING IS ADDING ONE FILE. No index to update, no manifest to hand-edit, no decision about where a post goes, ordering, permalinks, updates.json and feed.xml are all derived. That is not tidiness, it is the property that makes an unattended journalist agent safe: two agents publishing on the same day touch two different files and cannot conflict. Frontmatter is flat key: value with no YAML parser, the folder path must agree with the date, and slugs must be unique or the build fails. ONE DELIBERATE DIVERGENCE from their contract: they author root-relative links because their site sits at a domain root; ours must also render INSIDE A VAULT at an arbitrary mount path, where a leading slash escapes the app, so posts are still authored root-relative and the build rewrites each to a depth-relative path. Authors keep the simple rule; the vault still works. Updates are one entry per STORY rather than per release, which is the whole reason this is not the version log with a nicer stylesheet, v0.2.31 alone carried three separate stories. Five seeded from recent releases; the version log stays the complete technical record behind them. Articles carry two anti-rot rules stated on the page: never restate a fact you do not own (link to the page that does, so it cannot start lying when the fact changes), and link the test behind any testable claim. Two to open: GREEN DOES NOT MEAN LIVE on the deploy that reported success twice while serving a two-release-old page, and SEVEN VAULTS, ONE METHOD on what publishing seven vaults taught, including the three vault keys submitted as read keys. NAVIGATION: 14 flat items became 7 groups with a second level. The old bar wrapped to THREE ROWS on an iPhone before the page began, measured on a real screenshot, not guessed. Every group label is itself a link to that section's index, so nothing is reachable only by opening a menu. Desktop opens on hover and :focus-within in CSS alone; the phone collapses behind one button. The first mobile attempt made every submenu inline and measured 498px of navigation before the content, worse than what it replaced, so it was rebuilt as a collapsed menu: 91px, against 54px on desktop. Also adds an RSS feed and a JSON manifest, the first machine surfaces here aimed at a human follower rather than an agent. |
| v0.2.34 | 2026-08-18 | obj-cas-imm-97c957112852 | Acts on an inbound fix pack from the SG/API team, who audited this site against their route tables at v0.33.54 after an agent asked how to send a message between vaults and could not find the answer here. Their central finding was right: the site documented the TRANSPORT (sg.append) and the CRYPTO (sgit pki) on pages that never referenced each other, and never wrote the sentence saying they compose into vault-to-vault messaging. There was also no HTTP API reference anywhere, which is awkward for a project whose argument is that the API is the whole surface. SEVEN NEW PAGES: /docs/vault-messaging (the keystone, append lanes composed with PKI, worked end to end in CLI, curl and sg.append), /docs/pki (keypair lifecycle), and a /api/ section: index, authentication, vault-objects, append-lanes, errors. The security page gains the asymmetric layer it never had; sg.append is retitled as the message transport and cross-linked; limitations gains what PKI does NOT do; the skills page flags that the shipped agent skill still has both halves and no join. THREE OF THE PACK'S FINDINGS DID NOT SURVIVE CHECKING, which is the part worth recording. (1) It reported that the security page 'actively denies PKI'. It did not, a sweep for symmetric, asymmetric, public key, PKI and keypair returned zero occurrences. The page was SILENT, not wrong; publishing a correction for a claim we never made would have put a false statement in this log. (2) It asked us to hunt stale 'inbox' naming; there is none, two hits, both ordinary English, and no /api/vault/inbox/* path anywhere. (3) It described X25519 sealing throughout. Running sgit pki keygen on v0.15.0 prints RSA-OAEP 4096 and ECDSA P-256. Publishing the draft as written would have told integrators to build against the wrong primitive. Two further corrections came from running the CLI rather than reading about it: export emits a JSON BUNDLE of two PEM blocks, not a .pem file, so the draft's sha256sum-the-pem derivation of the lane address is not well defined; and keygen requires a passphrase, which no draft step mentioned. The one genuinely unshipped step , append_token = H(public key), is labelled PROPOSED with an interim recipe rather than quietly documented as working, and the two endpoints their audit could not resolve (/api/vault/zip, /join/*) are listed as unresolved rather than described. The pack's own acceptance test, give a fresh agent only llms.txt and ask how to send an encrypted message from vault A to vault B, now passes, including the lane-address fact and its PROPOSED caveat, answered in the preamble so it survives an agent that cannot follow a link. |
| v0.2.33 | 2026-08-17 | obj-cas-imm-ab458fd8611d | A release now ends by asking the live site what version it is serving, because 'both remotes in sync' turned out not to mean 'published'. v0.2.31 and v0.2.32 both pushed cleanly, both reported success, and NEITHER reached sgit.ai: GitHub Pages failed to deploy them because codeload returned 429 (Too Many Requests) for actions/configure-pages@v5, and the deploy job died in 'Set up job' before running a single step. Validation passed, tagging passed, the push was verified against both remotes, and the site served a two-release-old page for forty minutes, which is how long it took a human on a phone to notice the version pill still said v0.2.30. The failure was invisible to every check the release ran, because it happened in a job neither remote knows about. So release.sh gained a sixth step: poll the live URL with a cache-buster until the version pill matches this release, up to eight minutes, and ABORT LOUDLY if it does not, naming the Actions page and the fact that a 429 on the action download is transient and just needs a re-run. The cost is up to eight minutes of waiting per release. The alternative, demonstrated twice in one afternoon, is telling somebody a fix is live when it is not. Same principle as the orphan-page rule and the llms.txt guard: a page nothing links to, a page the index omits, and a page the deploy never published are all equally unpublished, so the build refuses all three. Ships the content of v0.2.31 and v0.2.32, which had been written but never served. |
| v0.2.32 | 2026-08-17 | obj-cas-imm-7f84b9ee6727 | The walkthroughs page becomes a document rather than a list of links. Each of the three videos now carries the recording at the top and THE SAME SESSION READ BACK underneath it: fifteen moments, each one a timestamp that deep-links into the video, the frame the screen was showing at that moment, and an explanation of what is happening in it. The transcripts are still there, folded away at the foot of each. The reason for the format is the one thing a transcript structurally cannot do: these recordings are full of 'this guy here' and 'look at this', and the words alone name neither end of what is being pointed at. Pairing each phrase with its frame is what makes the argument survive being read instead of watched. TWO SOURCES OF FRAMES, and the page says which is which. The Graph Browser moments are frames of the recording, from a narrated-review export the author produced with tools.sgraph.ai, nine timestamped stills paired with the narration spoken over each. Risk Chains and Role risk map have no such export, so their six frames were captured from the LIVE VAULT with the published read key, driven to the exact state being described, including the entry he names out loud ('you have risk 6'). What the frames turned up is most of the value, because none of it is audible: negative answers produce NAMED EDGES (never-exercised-on, never-timed-for, absent-for) rather than silence; 'no egress' draws a single assurance-coloured edge in a field of amber, so a good answer is a finding rather than the absence of one; one selection can carry two fact ids; and every risk ships with a CEASES WHEN ANY OF THESE HOLD list, its own falsification condition, cited to facts. The role dashboard also separates three arrival routes where the video describes two: held, arrives by the risk chain, and arrives by the org chart. TOOLING: the capture rig gained appProbe (ask the running app what its elements are called instead of guessing and burning a capture run per guess, it found g.cnode for chain entries and g.role for roles) and appClickMatch (substring match plus a real MouseEvent, because the graph nodes are SVG). Videos print with the player hidden and the moments intact. |
| v0.2.31 | 2026-08-17 | obj-cas-imm-17f0b2693daf | Corrects v0.2.30 on three counts, two of them reported and one of them the reason the report was possible at all. (1) THE LAZY-LOAD BYPASS IS NOW ONLY ON PRINT. v0.2.30 prefetched every screenshot once the page went idle, which fixed printing by making every reader pay for images they never scrolled to, the wrong trade, and correctly rejected. It is now driven entirely by the print itself, and it works because of a change one layer down: on the ordinary web the loader no longer fetches bytes and builds a blob: URL, it just sets img.src. That makes each screenshot an ordinary pending document resource, which the print pipeline knows to wait for, where a fetch-and-blob is invisible to it. Cmd/Ctrl-P is caught on keydown as well as beforeprint, because the keystroke lands a few hundred milliseconds before the dialog does and that head start is what removes the race. Measured on a page that was never scrolled: 1 image loaded while reading, 9 of 9 in the PDF. The blob path remains for pages served from inside a vault, where it is the only option. (2) THE PRINT-ONLY SOURCE LINE AND LANDSCAPE HINT ARE GONE, printing these pages is an uncommon case and did not warrant instructions on the page. (3) ASSETS ARE NOW CACHE-BUSTED PER RELEASE. GitHub Pages serves them with max-age=600, and the bootstrap fetched them by bare path, so for ten minutes after every release a returning reader ran the NEW html against the OLD css and js. That is not a hypothetical: it is exactly what produced the v0.2.30 bug report, new markup whose print-only elements the cached stylesheet did not know to hide, and a cached loader without the print handler. Every fetched asset now carries ?v=; the in-vault sg.vfs path stays unversioned, since a vault lookup is by path, not URL. |
| v0.2.30 | 2026-08-17 | obj-cas-imm-81dc22613ddf | Print and save-as-PDF, prompted by an export of the seven views page that came out wrong. TWO DEFECTS, one reported and one found while looking at it. (1) The top nav is position:sticky; Chrome paints a sticky box ONCE, wherever it happens to fall in the paginated flow, so the whole nav landed across the middle of page 2, translucent, with the prose showing through it. It is static in print now and flows once, at the top of page 1, as a masthead with the link list dropped. (2) WORSE, AND NOT REPORTED: screenshots are lazy, a figure starts at opacity:0 and its img is only created when an IntersectionObserver fires, so printing a page without first scrolling to the foot of it exported blank gaps where the pictures should be. Nothing errored; the img simply never existed. beforeprint cannot fix that alone (it is synchronous and will not wait for a fetch and decode), so the figures are now prefetched once the page goes idle, with beforeprint kept as the backstop. The export that prompted this was only correct by luck: it was taken after reading the whole page. Beyond the fixes: @page margins so Chrome's Default is ours rather than its own; print-color-adjust:exact, because on this site the tints carry meaning (amber exposure, green assurance) and Chrome drops backgrounds unless asked; break-inside:avoid on walkthrough rows, figures, notes, tables and transcripts, which fixes captions stranded on the page after their picture; orphan/widow control; live vault embeds hidden and labelled rather than exported as empty boxes; and a print-only source line carrying the canonical URL, since Chrome's own header and footer are frequently switched off. Finally, any page containing walkthrough rows now asks for LANDSCAPE, in portrait the two-column grid falls below the 820px breakpoint and collapses, which loses the alternating left-right rhythm that is the entire design of those pages. The reader can still override it. None of this was tested before; all of it is now. |
| v0.2.29 | 2026-08-17 | obj-cas-imm-8a68f249bd9f | The first vault to get depth rather than a page. Risk Graph Explorer now has three: the overview, THE SEVEN VIEWS EXPLAINED, and THE AUTHOR'S WALKTHROUGHS. The views page captures each of the seven tabs from the live vault under the Exposed preset (the estate, context, role risk map, risk chains, the register, acceptance, what happens next) and explains the mechanism behind each, matched to how the author describes it in his own recorded demos. Highlights the screenshots alone would not carry: 'assigned' versus 'through' on the role map (what you personally hold, versus what arrives because the graph says it must), so that no risk is orphaned and every path terminates at the board; risk chains running inherent-to-corporate left to right, clickable in both directions ('leads to' navigates up, 'led by' walks back to the answers that caused it), with cycles drawn as dashed edges because the cycles are real; and acceptance as the place where the register stops being a document, with the author on camera disagreeing with his own tool, which resolves into WHICH FACT IS WRONG rather than whose judgement wins. Also captures the same organisation under the Typical and Governed presets, because that comparison is the whole argument: the org chart does not change, only what is true about the agent. The walkthroughs page carries all three videos with FULL TRANSCRIPTS, a video is invisible to a search engine, to llms-full.txt and to any agent reading this site as documentation, so the transcript is the content and the video is one rendering of it. Tooling: the shots component gained a data-dir override so deeper pages under a vault share ONE image folder; the site now runs to 53 pages. Three bugs caught by testing rather than assumption, a malformed selector expression that silently created no images at all, escape sequences leaking as literal text, and a page that never loaded the component it depended on. |
| v0.2.28 | 2026-08-17 | obj-cas-imm-6008b0bdfe27 | Seventh vault, and the method written down. RISK GRAPH EXPLORER (3simlnqe) is the fact-to-risk explorer extracted out of the risk-mandate work into a vault of its own, answer questions on the left, seven views recompute on the right, nothing leaves the page. Its argument is visible in two screenshots: empty at 0 facts / 0 risks, then 18 / 37 / 14 under the Exposed preset, because a register that produces the same output for a scratch service and a payments platform is a checklist, not a register. Unanswered relationships are drawn as ghosts, recording absence as information rather than as an implicit pass. It is the first vault here PUBLIC BY DESIGN: it carries its own PUBLIC.md whose three rules its build enforces, nothing private committed (the gate scans every file, not just the artefact), no write token, and NO METERED CAPABILITY, because a published read key in front of an LLM config is an open tab on somebody else's budget. That third rule is not in our guidance and is the one to adopt. It also sent us back to re-audit ourselves: risk-mandate does carry an LLM config, so we took its sealed credential and attempted to open it with the read key we had published, AES-GCM refused (InvalidTag), so no budget was exposed; the rule is satisfied there by sealing and here, more conservatively, by absence. Checked rather than assumed, and recorded either way. Its app.json is `permissions: {}`, the floor of a scale the catalogue now spans end to end. Zero audit findings, the cleanest yet. NEW PAGE: /demos/vaults/publishing.html, the seven steps behind every vault published here, written to be followed by another site's agent: classify the credential before it touches anything, derive rather than refuse, audit with the read key across every file, derive the facts, capture evidence by driving the real product, write the page (describe, show, then admit), and record what outlives it. It names the five tools and, more usefully, the five mistakes that produced each rule. |
| v0.2.27 | 2026-08-17 | obj-cas-imm-6f1decd85ad3 | Sixth vault: AGENTIC BROWSER ISOLATION (0610gsp9), a living risk graph for one decision, does an AI agent browse inside the user's browser with their logged-in sessions, or inside an isolated browser with a scoped identity of its own. It is this site's own ambient-authority argument made by somebody else and in much more detail, so it is linked from the AI-agents use case. Seventeen app entry points, the most in the catalogue: a numbered narrative spine, one page per stakeholder altitude (IT · CISO · DPO · CFO · COO · CEO · Board), an explorer, two graph views and the raw data, over ~70 JSON files with RDF tooling vendored in so graph exploration works offline. The mechanism is the part worth copying: every altitude has one named owner, a risk stays PENDING until that owner accepts it personally, only an accepted risk escalates, and there is no deny button, the screenshots show IT holding five pending while every altitude above reads 'waiting', because nothing has been passed up. Its app.json declares fs.write: [], an app that requests no write capability at all, which with supplement-stack (one folder) and risk-mandate (LLM use without the key) gives the catalogue three distinct points on the permissions scale, each declared in the vault rather than configured on a server. The intake check earned its keep on arrival: the submitted credential was again a vault key, refused for publication by shape, and only the one-way derivation published. Audit clean across 104 files, the six scanner hits were all digit runs inside a minified RDF library matching a phone-number pattern, recorded because ruling hits out by reading them is what an audit actually is. Also: upgraded the CLI to v0.15.0 (latest) specifically to re-test the prefix gap; it still derives the wrong ref from the canonical read-key prefix while the bare form clones correctly on the same binary, so the brief now says 'confirmed on latest' rather than 'may be a stale install', and the machine-verified check updated its own evidence from v0.14.27 to v0.15.0 with nobody editing the claim. |
| v0.2.26 | 2026-08-17 | obj-cas-imm-6958c20644d8 | Credential intake becomes a check rather than a habit, prompted by yesterday's near-miss: a vault key was submitted for publication described as a read key, caught by shape, and only its derived read key published. The catch depended on somebody looking. New admin/build/check_credential.py classifies a credential BEFORE it touches a page, a catalogue entry or a commit, exit 0 means read-only and publishable, exit 1 means a write credential and stop. It works two ways because the problem has two eras: by PREFIX for vaults new enough to emit one (the canonical write prefix, which is exactly the change being rolled out, and the reason it is worth rolling out), and by SHAPE for everything older, where a read key is 64 hex characters and anything else before the colon is a passphrase. Verified against all eight real forms we have handled, including the actual key from yesterday, which it refuses with no prefix to help it. If a submission IS a vault key the entry is not blocked, the documented one-way derivation is printed instead. The rule is now in the catalogue vault's SCHEMA, so it renders on /catalogue/ with no site deploy, and summarised on the vaults index. Also: the release tripwire got more precise rather than more strict. Banning the bare write prefix outright had caught its own author three times, each time writing it in prose, and guidance that cannot show a reader what a write credential looks like cannot teach them to spot one. It now fires on the prefix followed by a CREDENTIAL character, so documentation may name it while every real key still fails the build; the bare passphrase:vault_id shape catches the body independently. Both directions proven before shipping (\S was tried first and failed, because in documentation the prefix is followed by markup). |
| v0.2.25 | 2026-08-17 | obj-cas-imm-8b39926aadb1 | Risk Mandate joins the catalogue, the most complete project ever published here, and the first to demonstrate CAPABILITY WITHOUT CREDENTIAL. It is a Black Hat field demo (hand someone an iPad, answer eight questions, a risk register assembles) built AS a vault app: 124 files, 98 commits, eight entry points, a test suite, build tooling, releases pinned to commit ids and offered as a live selector in the app chrome, and offline operation after one cached load. Its app.json grants llm:chat/models/usage/listen and fs.write over field/workspace/ and nothing else, while the OpenRouter credential itself is SEALED under the vault key in .vault/llm/config.json, so the host decrypts and calls and the app frame is handed results, never a secret. Auditing with the published read key, that field is ciphertext we cannot open, which is the claim demonstrating itself. The /compare/ privilege vocabulary gains the shape this revealed: ops and bearer come apart, so ops:llm-chat can be granted while bearer of the key is withheld, something most sharing models cannot express, because handing over the capability and handing over the credential are the same act. IMPORTANT PROCESS NOTE: the credential submitted for this vault was a VAULT KEY (format 3, passphrase:vault_id), not a read key, it matched this site's own banned-shape tripwire exactly. It was not published. It was stored in the gitignored local tier and the read key was derived from it one-way via the library's own Vault__Crypto.derive_read_key; only that derivation appears on the site, in the catalogue, and in the capture rig. The independent audit across all 124 files was clean, with two findings of the good kind recorded publicly: the sealed LLM key, and a single secret-scanner hit that turned out to be a deliberately fake sk-test- key inside a test asserting that a reachable API key IS caught. |
| v0.2.24 | 2026-08-17 | obj-cas-imm-244c5ecdeecf | Comparisons, built as reproducible tests rather than as claims, the concrete proposal answering the 16 Aug comparison brief. New /compare/ section carrying (1) the entry format: task, steps, prerequisites, privileges granted, where it runs, survives-the-vendor, verified date, and how to re-run; (2) a PRIVILEGE VOCABULARY, which is the part most likely to be argued with and the reason it is published first, seven properties that make two grants comparable (scope, operations, bearer, mediation, duration, withdrawal, observability), under which a published read key reads scope:vault · ops:read · bearer:any-holder · mediation:key · duration:forever · withdrawal:future-only · observability:none, three of them WORSE than a mainstream sharing link; (3) three worked entries, printing a markdown file (small, checkable in a minute, we win), taking access back after sharing (WE LOSE, plainly: rotation protects future commits and reaches nothing already fetched, while a server-mediated platform simply refuses the next request), and letting a program record data without letting it alter records (the differentiator, where step counts tie and privileges separate). Behind it: admin/build/compare_tests.py executes the our-side claims against the live service with published read keys only, and writes compare/results.json, six checks, each stating what would make it FAIL. Five hold; one records an ABSENT capability and is kept until it stops reproducing: the installed CLI v0.14.27 does not strip the canonical sgit_rk1_ prefix the web loader now accepts, deriving the wrong ref id, while the bare form works on the same version, now also filed as a brief to the CLI team. The freshness mechanism is real rather than a date in small print: results carry an expiry threshold and a past-threshold result renders as UNVERIFIED instead of as fact, proven by forcing the dates old and watching all six rows flip. The page states its own asymmetry up front (our rows are machine-verified, rows about anyone else's product are hand-checked on a date) and lists what is deliberately absent, including the deployment comparison, which waits until our own portable-artefact/hosted-viewer caveat is resolved. |
| v0.2.23 | 2026-08-16 | obj-cas-imm-8af209891454 | Structure for scale, and the most interesting vault yet. (1) Every published vault is now a self-contained folder, demos/vaults//index.html with its screenshots in demos/vaults//images/, so adding the hundredth vault is adding a folder, and a vault's page and pictures move together. The old flat /vaults/ section is gone (URLs lived one day). Two engine changes made it possible: the root-prefix was computed as 'one ../ if nested at all', which silently pointed the nav, stylesheet and every asset at the wrong level once pages nested three deep, now it is ../ times the depth, the same formula the markdown twins already used; and the screenshot rig writes per-vault, with a --vault filter. Image paths in the walkthrough are page-relative for the same reason. (2) New vault: SUPPLEMENT STACK (r7zes477), and it is the strongest healthcare demonstration on the site. Its idea: every label describes one product, nothing describes the sum, so the model extracts (fuzzy, with every amount traceable to the label photograph it was read from) and the code adds up (deterministic, rules stated in the open, a missing value flagged and never guessed), producing a briefing for somebody qualified and never a verdict. It is also the first vault here to use SCOPED WRITE PERMISSIONS: app.json grants write over adherence/ only, so the app that logs what was taken cannot alter the regimen, the labels or the references, least authority as a property of the vault rather than a server setting. Five walkthrough rows captured from the live vault, including its app.json permission block. The healthcare use case now opens with this as a worked example: who holds the data, how it reaches a clinician (a read key, not an account or a PDF), where AI fits safely, and why the reference set is UK RNI/EFSA rather than US Daily Values. The published audit: clean on credentials, no personal identifiers found, but it publishes a real regimen and the health context inferable from it, deliberately, and revocation is not retroactive. |
| v0.2.22 | 2026-08-16 | obj-cas-imm-b1d27e3295cf | The walkthrough: six alternating rows at the foot of the Algarve page that explain what a live embed cannot say for itself. The app is real HTML (not a viewer template); clicking a photo opens the vault's own lightbox with captions from gallery.json; the debug pane's Vault tab times the decryption step by step; its REPL tab is a console over the sg.* bridge where vfs.write is refused because no write capability exists in a read key; the vault browser shows photos/originals and the app's own SOURCE; and the SGit tab carries 36 commits, because the history IS the storage. New tool behind it: admin/build/capture_shots.mjs drives the real product with only a published read key, performs each row's navigation (scroll to a chapter, click a photograph, open the debug pane through the HUD's shadow root, type vfs.list into the REPL, expand a folder, switch to the SGit view), crops the result and writes WebP, so the pictures are of the actual vault and regenerate when it changes. Getting there needed four fixes worth recording: the app frame must be identified by a selector it contains (the shell frame also has text and was winning the race), the REPL input sits two shadow roots deep and is reached with a shadow-piercing locator typed into for real, the file tree rows are .sb-tree__folder-name, and the slow test mirror needs navigation timeouts well past the 30s default. Images load through assets/shots.js, lazily, and via fetch-or-sg.vfs rather than , because the authoring contract forbids declarative refs so every page survives being served from inside a vault. Also adds a direct 'open the gallery app in its own window' link using the read-key fragment the UI now accepts. |
| v0.2.21 | 2026-08-16 | obj-cas-imm-10164a7a31ab | Two reader reports from an iPhone, both fixed with the cause named. (1) The vault pages now open both surfaces ON LOAD, the reader lands on the vault, not on a row of buttons. The opens are sequential by design: the browser surface starts once App Mode reports vault-ready (grace-capped), so its objects come out of the client's encrypted-object cache and the second open mostly decrypts rather than fetches, the caching architecture demonstrating itself on every page view. Buttons are gone; each frame carries a label and its own status line, and a failed handshake leaves a retry control instead of a dead page. (2) The landscape-iPhone report, site and iframe not using the full width after a pinch-zoom, was hunted down empirically rather than guessed at: one unbreakable 702px token (the sgit clone command with its 90-character credential) on a 393px viewport made the page 743px wide, which drops Safari's fit-to-width scale below 1; pinch out and the entire site sits narrow with a white gutter. Fixed with overflow-wrap:anywhere on inline code (breaks only when a token would overflow) plus the html canvas painted the site colour so any zoomed-out or overscrolled area reads as the site rather than as white margin. Verified at iPhone viewports: every checked page now measures exactly the viewport width, and the auto-open completes with zero clicks. |
| v0.2.20 | 2026-08-16 | obj-cas-imm-23e6ea08a77d | Both surfaces at once, reader-requested: on the vault pages, App Mode and the vault browser now each open in their OWN frame, stacked (the app first, the FILES/SGIT/SETTINGS browser under it) instead of one frame the buttons fought over. The second open is fast by design and the component says so: the encrypted objects are already in the client's cache from the first surface, so the second mostly decrypts rather than fetches, the caching story demonstrating itself. Each frame carries its own status line from its own handshake (one listener, replies routed by which frame sent them). The Full screen button is gone from these pages, with each surface getting a full-width, viewport-height frame of its own, it earned nothing. Verified headless: both surfaces open (5.0s through the slow test mirror, faster live), app above browser, two independent vault-ready events. |
| v0.2.19 | 2026-08-16 | obj-cas-imm-2773e0dfba35 | The site starts doing the thing it was building toward: publishing vaults. New /vaults/ section, an index of every read key this site has deliberately published, and one page per vault (five at launch: Field Notes, Strategy Maps, Deploy Docs, the Catalogue itself, and, new, Algarve · May 2026) with a real description, the features that vault exercises, what the shape is good for, the derived facts, the key as a copyable sgit_rk1_ credential with a CLI command and an open-in-the-official-UI link, and the vault RUNNING LIVE in the page via the reusable embed component (assets/vault-ui-embed.js, the two-surface embed-protocol host from the demo page, now attribute-driven; App Mode hidden for vaults without an app). Pages load the component contract-compliantly (fetch+eval, no script src, every page must survive being served from inside a vault). The Algarve vault is the first entry processed through the catalogue's submission queue as designed: read key supplied in chat, everything else derived, 71 files, 29 MB (60 WebP photos in originals/web/thumbs), 36 commits, auto-opening gallery app with a chaptered narrative. Its pre-publication audit is published on the page per the rules: one finding (a live delete_auth token in public-preview bookkeeping, narrow scope, the owner advised to rotate) and one counterpoint worth showcasing (the same vault's readonly-tokens bookkeeping decrypts to further ciphertext: owner secrets double-encrypted, the pattern that fixes the finding class). Catalogue vault updated in the same breath (new entry, trip-gallery-1 ticked off the awaiting list (7 remain)) and /catalogue/ picked it up with no site deploy, which is that design working. |
| v0.2.18 | 2026-08-16 | obj-cas-imm-68578f7b1bf4 | The tag pipeline's first contact with a real GitHub rule, fixed within the hour. v0.2.17's run DID tag itself, the first CI-authored tag, but the historical backfill push was rejected wholesale: a workflow's GITHUB_TOKEN cannot push any ref pointing at a commit whose tree carries a different version of a workflow file, and the `workflows` permission that would allow it is not grantable to that token. Every pre-v0.2.17 release predates the current deploy-pages.yml, so all 33 backfill tags bounced, and because the tag job failed, the deploy was skipped and v0.2.17 never reached the live site (this release carries its changes out). The fix splits the pushes by what they are: THIS release's tag at HEAD is load-bearing and fails the job if rejected (it never should be, HEAD's workflow blob matches the branch, which is why v0.2.17's own tag went through); the historical backfill is best-effort per tag, warns per rejection, and emits one notice with the single human command that completes the set, `git push origin --tags` from any workflows-scoped credential. Once a human has done that once, the backfill loop becomes a chain of no-ops. Lesson recorded for the case-studies pile: the same both-remotes discipline that made CI verify-and-tag instead of commit-and-tag also meant the failure cost nothing but a skipped deploy, no bump commit was stranded on one side of the two-VCS split. |
| v0.2.17 | 2026-08-16 | obj-cas-imm-24876be44e37 | Two reader-driven fixes and the release pipeline grows tags. (1) Layout: the embed buttons and their status line sit back in the text column where they belong, only the vault surface itself breaks out wide, since it is the thing with the big UX. (2) CI tagging, ported from the VoiceDebrief website pipeline (validate → tag → publish, every push to dev a minor release tagged v{release}.{major}.{minor}) with one deliberate adaptation: the upstream OSBot action has CI commit a version-file bump, but this repo is simultaneously an sgit vault, and a CI-authored commit would exist only on the git side, breaking the both-remotes-in-sync invariant release.sh enforces. Here CI verifies-and-tags instead of owning: SITE_VERSION (bumped once per release by release.sh) must match the release commit's subject and be the next minor after the latest tag, then the commit is tagged. No CI commits, no drift, same discipline, and a forgotten bump now fails the pipeline loudly instead of shipping quietly. The first run backfills tags for every historical release by parsing the commit subjects, so the whole v0.1.9→now history becomes navigable by tag. Also: validate.js now runs in CI as the gate before tagging and publishing, which puts the key-leak tripwire on the deployment path as well as the release path. (Tags could not be pushed from the authoring session, the session's git proxy authorizes branch pushes only, which settled the design question of who owns tags: CI does.) |
| v0.2.16 | 2026-08-16 | obj-cas-imm-34ed83dd03e6 | The embed grows up: both official surfaces, one click each, over the UI's new embed protocol. Reading the deployed bundle found what the addendum's Phase 3 had shipped, embed-protocol.js and a shared embed-receiver on BOTH shells: the host page loads ?embed=1&parent=, the frame proves itself with vault-embed-ready, and only then is the key sent by postMessage with the targetOrigin pinned. Strictly better than the URL-fragment flow shipped yesterday: the key never appears in any URL, is never written to the frame's storage (verified, sessionStorage and localStorage empty after open, memory-only as the protocol promises), and the host gets structured vault-ready/vault-error events instead of guessing from load timings. The demo page now has two buttons: App Mode, and, new, the vault browser with the FILES/SGIT/SETTINGS rail, which previously needed a two-step trick because /en-gb/vault deliberately strips URL hashes and root is the only inbox. Headless-verified both: App Mode ready in 2.7s, browser in 9.7s, rail present, R1 W0 badge, no horizontal scroll. The embed area breaks out of the text column (94vw up to 1680px, height tracking the viewport) because the vault browser is a full working surface, plus a full-screen button, both asked for by a reader with big-UX vaults. What is still not possible is stated precisely on the page: vault-open carries {key, mode, deepLink} where deepLink is a file path, so a host can select a SURFACE but not a VIEW, SGIT and SETTINGS remain in-page events. The briefing gains an addendum thanking the UI team, recording the verification, and sharpening the last ask to one optional field: view:'files'|'sgit'|'settings' on vault-open, applied after mount. Also fixes a stale paragraph v0.2.15 left behind (a silent curly-quote replace failure), the page no longer promises a swap that already happened. |
| v0.2.15 | 2026-08-15 | obj-cas-imm-576ba8a1a09f | The gap closed: the official SG/Vault interface now opens from a published read key, and this site embeds it. Our v0.2.7 experiment had isolated the blocker to exactly one thing, the loader documented a read-only credential but rejected it, and the CLI shorthand was parsed as a passphrase and PBKDF2'd into the wrong ref id. The UI team shipped the fix: a read-key credential is now its own format (<64-hex>:, the shape sgit clone already accepted) and is tested BEFORE the passphrase formats, which was the precise ordering bug; canonical CLI key prefixes are stripped first. Re-running the same experiment against the deployed build, read key only, no vault key anywhere: all three credential forms parse; App Mode boots the Field Notes demo under full chrome with its six studies rendered and the bridge live; the vault browser opens with the FILES/SGIT/SETTINGS rail over the real decrypted tree; and the SGit view lists both commits with real object ids, all inside a cross-origin iframe, with an explicit R1 W0 / Read-only badge. So /demos/vault-app-embed.html now carries TWO hosts and keeps both on purpose: the ~170-line minimal host that shows the protocol with nothing hidden, and the official UI opened with the same published key. One ask stays open and is stated as such, no URL selects a view, so the SGit inspector cannot yet be framed in isolation. Also: the release tripwire learned the CLI's canonical WRITE-key prefix (its read-only sibling is deliberately exempt, we publish one), proven by making it fail before trusting it; it promptly caught this very release note's first draft, which had spelled the banned prefix out while explaining it. The hub capability audit is updated with verified evidence, row 1, the entry point for everything, flips from partial to present, which settles the spec's assembly-not-construction question for the forge's read-only tier. |
| v0.2.14 | 2026-08-15 | obj-cas-imm-2f3c360b2de1 | Ask B of the 14 Aug pack begins: the hub.sgit.ai briefing-pack plan lands in admin/plans/, and, per the spec's central instruction, the capability audit comes before any architecture. The audit table is already 13 rows deep, seeded entirely from evidence this project has produced: verified present (open-from-read-key in our readers, single-object decrypt, the app runtime under a sandboxed iframe, sparse per-object fetch, cross-session caching with the 120s ref window, frameability), verified partial with the exact gap named (the official UI parses but rejects its own documented read-only credential format), and honestly unknown (client-side merge, the in-UI diff and history views, enumerated in the bundle, never driven). The partial rows are flagged as the dangerous ones, because a partial capability gets assumed complete. The plan also fixes the pack's shape: six parts in order, the four absences stated up front, surfacing/adding/absent applied per feature (blame is adding, not surfacing), permissions as worked key topologies, and the private-vault key-handling flow named as the one needing a considered position. The crawler question is closed as answered: full text in the served HTML, noscript reveal since v0.1.26, and Google indexing confirmed. |
| v0.2.13 | 2026-08-15 | obj-cas-imm-35d4e3e3a906 | Fix: the catalogue page shipped without the vault debug panel markup that the shared reader wires unconditionally, so the reader threw on two missing elements and the first document never rendered (navigation and clicked entries worked; the initial body stalled at the fetching message). The panel is now on the page (which it should have been anyway, since watching the ciphertext arrive is half the point) and the headless check confirms the README renders on load with zero page errors. |
| v0.2.12 | 2026-08-15 | obj-cas-imm-15dbcf053020 | The catalogue: a vault indexing vaults, including itself. The 14 Aug briefing pack's Ask A lands as designed, a submission queue whose per-entry cost is a read key and one line, with everything else derived by opening the vault. The deriver (admin/build/catalogue_derive.py, ~120 lines, read-only, no token) turns a read key into file count, plaintext size, commit depth, HEAD, top-level layout, file types, app entries and browser-renderability; proven on all three published-key vaults (Field Notes 4bshby5n, the strategy/maps vault ookq4mn4, both app entry points detected, and the deploy-docs vault fyofmkvr, markdown-only). The catalogue itself lives in a new vault (kc67yhgw) published with its own read key and listed in itself: README (how to submit), SCHEMA (supplied-vs-derived, and the two rules, read keys yes, vault keys never; escrow the write key BEFORE publishing, because a frozen vault can never be corrected), three processed entries, and the two public to-do lists the brief asked for, awaiting-a-read-key (seeded with eight vaults named in the memos, each carrying the pre-publish audit instruction the strategy-maps case taught) and awaiting-processing (the agent's queue, currently empty). /catalogue/ renders it live via the same reader as the deploy docs, updated by pushing to the vault, no site deploy. Write-key status is a first-class field: 'known and escrowed' or 'lost', stated publicly per entry. |
| v0.2.11 | 2026-08-15 | obj-cas-imm-1f8635c410ef | sgit gets its own Wardley map analysis, six maps starting with git at full strength, because a map that flatters its author is not a map: version control today (git's moat is the platform layer, resting on readable storage), the files that cannot follow (a hole in the map where their foundation should be), sgit's move (no new verbs, invert the bottom layer), the boundary on one map (two chains from one team, split by 'may the store read this?'), agents as the new user (the serialised diff versus ambient authority), and the strategy (commoditise private version control). The maps are drawn as inline SVG by a ~90-line renderer (no images, no dependencies) and the analysis ships as a SECOND app inside the same vault as the SG/Send strategy essay (ookq4mn4): one encrypted store, two entry points, one published read key; the embed opens it by passing entry to the same host. The embed shim gained link handling, in-page anchors scroll manually (assigning location.hash re-navigates a srcdoc frame) and relative .html links remount the frame on the new entry, so the two apps cross-link inside the embed; verified headless: 6 maps, 42 nodes, 12 evolve arrows, and clicking the companion link lands on the strategy essay. Linked from the Why page's boundary section. Also: Google has confirmed indexing sgit.ai, which unblocks the component registry when its turn comes. |
| v0.2.10 | 2026-08-15 | obj-cas-imm-cedfb3d06f6a | Plan bookkeeping: the why-expansion plan's status table now reflects reality, Why reframe done, serialised PR done with its CLI brief, two of three demo vaults live, embed at the minimal-host stage pending the UI team's credential fix. |
| v0.2.9 | 2026-08-15 | obj-cas-imm-2ce42cfd214e | The two remaining pieces of the briefing-pack plan land. (1) The Why page is reframed from rebuttal to boundary map: it now opens with where git wins, then draws the boundary precisely. The operations are not the gap (commit through merge all exist; proposing reviewable changes without write access is present, as a serialised diff, and is a differentiator); what is absent is the hosted review interface and the ecosystem above the protocol; and git is also client-side, so the real difference is that the objects are encrypted there, with the losses stated as a given-up/in-exchange-for table. New protocol section: the six-step read path verbatim, the two keys named explicitly, the three modes (Local/API/Web), and the two-implementations proof point. The LinkedIn comment and the market answer move below the boundary, kept whole. (2) New lead use case: the serialised pull request, no credential issued at all, grounded in the 5 Aug Black Hat disclosure, with an honest shipped-vs-pattern table (emit exists as history diff --json; import is not first-class) and evidence status PARTIAL. The matching brief to the CLI team asks for sgit diff export/apply, a published diff format, and ignore-file support, the latter now a prerequisite for the one-folder-two-VCS pattern the site publishes. |
| v0.2.8 | 2026-08-15 | obj-cas-imm-4060eca3121d | Second demo, and the first with real content: The Strategy in Seven Maps (the actual SG/Send strategy, published on LinkedIn in May 2026) served live from a vault with a published read key. The page also publishes the audit that made this interesting: the original vault could NOT publish its read key, because its own read-write credential was written inside its content (a production briefing quoted the clone command verbatim), server-side bookkeeping under .vault/owner/ carried live delete_auth tokens, and the vault's keys derive from a legacy low-entropy token. The fix is the pattern the page teaches: republish, don't retrofit, sanitised copy, credentials redacted with a visible note, fresh full-entropy vault (ookq4mn4), and only then a published read key; a republish also sheds the history you cannot publish. The embed host gained vault-path image support (a MutationObserver swaps img.src vault paths for blob: URLs read over the bridge, the same job the real host's interceptor does), verified: all eight Wardley Map PNGs travelled as ciphertext and rendered. |
| v0.2.7 | 2026-08-15 | obj-cas-imm-1b9cd77fb6d7 | The full-UI embed experiment, run and published. Driving the real SG/Vault interface framed inside a page: the UI is frameable (no X-Frame-Options, no frame-ancestors), and App Mode works completely inside a cross-origin iframe, with a valid credential the official app-shell booted the Field Notes demo under the full HUD chrome. The one gap is the credential: the loader documents a read-only format (vault_id + 64-hex read key) but the client rejects it, and the CLI's 64hex:vault_id shorthand gets PBKDF2'd as a passphrase and derives the wrong file ids. No URL selects the SGit view, either. Both are now precise, evidence-backed asks in the UI-team briefing, honour the documented format (which alone makes the official UI embeddable with only the published read key) and add a |view:sgit deep-link. The demo page carries the findings table. |
| v0.2.6 | 2026-08-15 | obj-cas-imm-966aed3bd862 | The first demo ships: a vault app running live inside a sgit.ai page from a published read-only key. A new vault (Field Notes, 4bshby5n) was created from scratch for it (a self-contained app following the authoring contract, generative SVG art, content in content.json read over the bridge) and /demos/vault-app-embed.html is the complete walkthrough: init, commit, push, derive the read key, publish it deliberately, embed. The embed host is assets/vault-embed.js (~170 lines): HMAC-derived ids, ciphertext over CORS, Web Crypto decryption, the app booted in a sandbox=allow-scripts iframe with an opaque origin, and its sg.vfs/loadCss/loadJs calls answered over postMessage, the same shape as SG/Vault's vault-in-vault, minimal by design until the UI team answers the reuse briefing. Also rewrites the one-tree-two-remotes ordering section as a clean rule (the discovery narrative is gone), adds the Demos nav section, and extends the key-leak tripwire to scan for every demo vault's passphrase, not only the site's own. Verified end to end in headless Chromium: bridge live (the app's status line reads content via sg.vfs.readText from the vault), six tiles rendered, frame origin opaque, mutations impossible by construction. |
| v0.2.5 | 2026-08-14 | obj-cas-imm-fedcfbd348c0 | Corrects the one-tree-two-remotes case study, prompted by a reader question: if sgit pushes first and git commits after, don't the files match? They do, tested rather than argued. With that ordering git captures the freshly written ref every time and a clean tree is the normal end state of a release; reads (ls, history, status, vault info), no-op commits and pushes, pull and fetch were all tried and none rewrites the ref. The section is now a rule about ordering rather than a claim of permanent drift, keeping the part that is true and useful: when the ref IS dirty, the bytes tell you nothing, because a rewritten ref never byte-matches even when it decrypts to the same commit. |
| v0.2.4 | 2026-08-14 | obj-cas-imm-854db222f8cb | Wider layout across the site. The reading column was a classic 720px prose measure, which squeezed the content into the middle of a modern display and made every page longer than it needed to be. The measure is now 960px and the wide container 1360px, with the body type up a step (.93rem to .98rem) so the longer line keeps a comfortable character count; the home-page sections (hero, terminal, feature grid, cards) scaled in proportion, and the deploy-section nav column widened with them. Verified at 1600px (no overflow, content fills the frame) and at 390px (no horizontal scroll). |
| v0.2.3 | 2026-08-14 | obj-cas-imm-6deb6376d9bd | Plans and briefs from the 14 Aug briefing pack. Publishes the implementation plan for the Why reframe (boundary map), the serialised-pull-request lead example (with one honesty gap found while planning: the diff emit exists as history diff --json, but the CLI has no apply/import command, so the page will ship as PARTIAL and a brief goes to the CLI team asking for sgit diff export/apply plus a published diff format), three end-to-end demo vaults with deliberately published read keys, the embed-reuse work, and the component registry (components, never plugins, plugin stays reserved for capability grants; registry gated on indexing being observed). Files a briefing to the SG/Vault UI team with six concrete questions about reusing their app-iframe host code inside sgit.ai pages, linked from the briefs page. |
| v0.2.2 | 2026-08-14 | obj-cas-imm-29aa935bd44a | New case study: one working tree, two version control systems, the workflow this site is actually developed with. One folder is both an sgit vault and a git repository; a release is two pushes of the same tree. The page covers what each remote carries, the one-file .gitignore boundary that makes it safe (everything encrypted is committed; only the plaintext local/ tier is excluded), and the finding that surprised us: the encrypted ref always looks modified to git because AES-GCM uses a fresh IV per write, so for that one file git status cannot detect staleness, proved by decrypting both sides to the same commit id. Ships admin/build/release.sh, which makes the discipline mechanical: build, validate (the key-leak tripwire gates BOTH pushes, not just the deployed one), push sgit, push git, and refuse to finish unless both remotes report in sync. The script deliberately never invokes commands that echo the vault key. |
| v0.2.1 | 2026-08-14 | obj-cas-imm-49cf3a524b0c | Fixes a gap the v0.2.0 restructure opened: llms.txt is generated by walking a list of known sections, and the new case-studies section was not in it, so all three of those pages were silently absent from the machine index, present on the site, invisible to any agent reading llms.txt. The section is added, and the generator now refuses to build if any page would be omitted, which is the same guard as the orphan-page rule and for the same reason: a page nothing links to and a page the index does not list are both unpublished. |
| v0.2.0 | 2026-08-14 | obj-cas-imm-d8f580db4d0f | Structural release, the middle digit moves, as the numbering note below promised it would. Two changes. (1) The root held 19 files and every page body was inlined in a 2,709-line generator; bodies now live one-per-file in admin/content/ with a pages.json manifest, and the generator is a 648-line engine that does not grow as the site does. Adding a page is a content file plus a manifest row; the build then produces the HTML, the markdown twin, the llms.txt row, the llms-full.txt section, the sitemap entry and the canonical/OG/JSON-LD tags. The refactor was verified output-preserving before any page moved: all 31 pages byte-identical. (2) Sections became folders (why/, try/, security/, skills/, briefs/) leaving 9 files in the root, all of them ones that must be there. New case-studies/ section, which is where the leaked-key incident and the live-vault architecture now live; they were filed under docs/ and deploy/ where nobody looking for a case study would find them. Links were rewritten mechanically by resolving each href against the old path and re-expressing it from the new one, then verified by crawling every internal URL from the homepage: 29 URLs, zero broken. |
| v0.1.27 | 2026-08-14 | obj-cas-imm-87daa0751f0d | Entity disambiguation, after checking what search actually returns. Google's AI Overview for the bare query already knows this project, and sources it from PyPI, because the PyPI page never linked here and this site was not in the index. "sgit" is also an Android Git client, an Indian engineering college and a class of shell shortcut, so the job is not only being indexed but being resolved to the right thing. Every page now carries JSON-LD: a SoftwareApplication node with sameAs pointing at the PyPI and GitHub identifiers that already rank, an explicit disambiguatingDescription naming the collisions, and a per-page TechArticle node. Google's own 2026 guidance says structured data is not required for generative-AI features. This is here for entity resolution, not ranking. The validator now fails the build if a page has no structured data or if any JSON-LD block does not parse. |
| v0.1.26 | 2026-08-14 | obj-cas-imm-5da2eb791bb2 | Acts on an inbound brief from an agent that tried to use this site as documentation and could not. It reported that the site did not rank for its own positioning language and guessed the pages might be client-side rendered. They are not, the full text is in the served HTML, but the fade-in that hides the unstyled flash left body{opacity:0} until a JavaScript bootstrap ran, so any client applying our CSS without running that bootstrap rendered a complete but entirely invisible page (measured: 15,733 characters at opacity 0), which is also a hidden-text signal to an indexer. Fixed with a noscript override and a CSS-only reveal failsafe, both now enforced by the validator. Adds the crawler surface that never existed: robots.txt, a generated sitemap.xml covering every page, and canonical plus Open Graph tags. Adds llms-full.txt, every page in one document, for the very common agent harness that will not follow a link out of a fetched file, and makes llms.txt self-sufficient: inline answers to the common questions (including exactly which git operations exist and which do not) and per-page key facts, on the brief's observation that for such an agent the descriptions are the only content it will ever see. The brief and what changed are published on the briefs page. |
| v0.1.25 | 2026-08-14 | obj-cas-imm-1861dd16dd11 | Three changes that go together. (1) Every page now has a .md twin at the same path, generated from the same content so the two cannot drift, with internal links rewritten to point at markdown, an agent can traverse the whole site without parsing HTML, and llms.txt is now generated from the page registry rather than hand-maintained. (2) A git-and-sgit comparison on the Why page that says plainly where git is better (performance at scale, ecosystem, bisect/blame/rebase, partial commits) and how the two run side by side, as they do on this site. (3) Use cases moved to /use-cases/ with a page per situation: the problem, a working recipe on shipped commands, an honest evidence status (proven / partial / pattern), and a brief you can hand to an agent. Validator gained three rules: every page has a markdown twin, markdown links resolve, and no raw HTML leaks into the markdown. |
| v0.1.24 | 2026-08-14 | obj-cas-imm-3c426ddbe9e9 | Why page rewritten around the right question. The first version answered "is there a market" with verticals and a comparison table; the sharper answer is what sgit makes possible that was not possible before, so that is now the headline: six capabilities running on this site, a live site its host cannot read, read access as a publishable capability, two agents sharing a workspace neither host can read, private data with CDN economics, storage as untrusted commodity, and transit security that does not rest on the CA system (including where that goes next: the read key never leaving the client, or PKI with a client-only private key). The page now assumes the reader knows git and only covers the delta. Also corrects the business-model answer: the client being open source IS the distribution strategy, with services built on top, not "no revenue attached". |
| v0.1.23 | 2026-08-14 | obj-cas-imm-89a142ee3598 | A freshness window on the mutable HEAD pointer. The ref was the last per-page-view network request left; it is now checked at most once every ref_ttl_s seconds (120 by default, configurable in deploy/vault.json), so reading inside the window costs zero requests and server load scales with readers rather than page views. The cost is a bounded propagation delay, a new commit appears within the window at worst, and "check for new commit" forces a fetch that ignores it. The vault panel logs the reused ref as TTL and counts down live to the next check. |
| v0.1.22 | 2026-08-14 | obj-cas-imm-d9ac70d78c31 | Kills the load-time flicker of the vault panel. The panel's remembered width and open state were restored by the reader script, which loads asynchronously, so the panel painted at its CSS default width, then jumped and slid open a beat later. Restoration now happens synchronously, before the first paint, and the slide transition is suppressed until state has settled. Opening and closing the panel by hand still animates; restoring it never does. |
| v0.1.21 | 2026-08-14 | obj-cas-imm-5a60bc3bf25b | Object bodies in the vault panel are now syntax-coloured like an editor (keys, strings, numbers, literals and punctuation each get their own colour) and word wrapping is off, so structure survives and long values (base64 ciphertext, object ids) scroll horizontally instead of folding into a wall of text. Highlighting is applied only when the decrypted object actually parses as JSON, so markdown blobs stay plain. |
| v0.1.20 | 2026-08-14 | obj-cas-imm-78146d2f4f86 | The vault panel now links to the page that explains it. There is a compact “how this works” link in the panel header (always visible) and a fuller card at the foot of the panel pointing at deploy/how-this-works.html. The panel is where you are when the question occurs to you, so it is where the answer should be offered. |
| v0.1.19 | 2026-08-14 | obj-cas-imm-fe67d9589a2e | Fixes the resize grip, which shipped in v0.1.18 but was unusable: it was absolutely positioned inside the panel's scrolling area, so it scrolled out of reach as soon as you moved down the object list, and at 6px fully transparent it was invisible anyway. The panel is now a flex shell (a fixed 12px drag rail with a visible handle, plus a separately scrolling body) and dragging uses pointer events with capture (mouse, pen and touch). Double-click the rail to reset the width. |
| v0.1.18 | 2026-08-14 | obj-cas-imm-6eded1c95732 | Vault panel becomes an object inspector: every row now shows what the object IS (ref/commit/tree/blob), WHY it was read, and, on click, its decrypted contents, pretty-printed for JSON. The panel is width-resizable (dragged from its left edge, remembered). Plus a real optimisation the panel made obvious: the path→blob index is a pure function of the commit id, so it is now memoised in localStorage, a first visit walks every tree to learn the encrypted filenames, but subsequent visits to an unchanged commit read zero tree objects. |
| v0.1.17 | 2026-08-14 | obj-cas-imm-9d5b50f68679 | Vault panel: a "clear list" button that resets the request log and counters without touching the caches (so you can see exactly which objects one page needs); the panel's open/closed state now persists across navigation and reloads; cached objects record when they were stored and the panel shows their age. Navigation now scrolls to the top of the content rather than the top of the document. New page: deploy/how-this-works.html, the full architecture with hand-drawn SVG diagrams of the two-session publishing pipeline and the client-side read path. |
| v0.1.16 | 2026-08-12 | obj-cas-imm-34684a789fe6 | New /why page answering the sharpest public criticism of the project ("I see no market or value whatsoever") directly and without marketing: who actually has the problem, why git-crypt/Dropbox/S3+KMS do not cover it, the market question answered plainly (the CLI has no revenue attached; hosting is the commercial layer; no TAM claims), where the criticism is right, and a twelve-question FAQ pre-answering the promised follow-ups. |
| v0.1.15 | 2026-08-12 | obj-cas-imm-0959988dd4fe | New Deploy section: self-hosting guidance rendered LIVE in the browser from an encrypted SG/Send vault, using a published read-only key, ciphertext over CORS, AES-256-GCM decryption via Web Crypto, no copy stored on this site and no rebuild when the SG/Send team pushes. Includes a three-tier cache (session memory, permanent Cache API for immutable objects, always-fresh ref) and a vault debug panel showing the HEAD commit, per-object request log, and cache hit/miss stats. |
| v0.1.14 | 2026-08-12 | obj-cas-imm-3b54c02dbb96 | Two new pages, both linked this time: docs/exposed-vault-key.html (the rotation runbook plus the case study of this site's own key leak) and briefs.html (cross-team briefs, which v0.1.13 built but never registered, so nothing linked to it). New validator rule: every generated page must be reachable from another page, or the build fails. Added a fourth CLI-team ask: history-preserving rekey. |
| v0.1.13 | 2026-08-12 | obj-cas-imm-5168ef3fe1a7 | SECURITY: the vault passphrase had been written into admin/build/validate.js as an anti-leak tripwire regex, which put the literal secret into a tracked, public file (present in 3 commits). Removed; the tripwire now reads the secret from the gitignored local/ tier and scans for it, so it can never be hardcoded again. The key must be treated as compromised and rotated. Also: a /briefs page collecting the cross-team briefs (multi-agent collaboration log), and a "contacting the server" notice before network commands in the browser terminal. |
| v0.1.12 | 2026-08-11 | obj-cas-imm-e8ceb3fc2239 | In-browser clone completes: serial-executor shim for Pyodide (WebAssembly cannot spawn threads, so all parallel blob transfers run sequentially in the browser), validated natively against the live server with thread creation disabled: full 225-blob clone of this site vault. A serial/auto-detect mode is proposed upstream to the sgit CLI. |
| v0.1.11 | 2026-08-11 | obj-cas-imm-c9afa76a79cb | Browser-transport fix for in-browser clone: drop the redundant X-API-Key header (the servers CORS-allow x-sgraph-access-token but not x-api-key, and one disallowed header fails the whole preflight, diagnosed live from the first user clone attempt); CORS/network failures now surface as readable HTTP 599 errors instead of a Pyodide SystemError. |
| v0.1.10 | 2026-08-11 | obj-cas-imm-deac6363bff9 | In-browser terminal on /try: the real sgit CLI in-process (init, commit, status, history, and network commands via a browser XHR transport: clone/push/pull straight to the SG/Send servers), plus a busybox of file commands over the in-memory filesystem. Key hygiene: every example key on the site is now an obviously-invalid placeholder (format-valid example keys are squattable namespaces), enforced by a new validator rule. |
| v0.1.9 | 2026-08-11 | obj-cas-imm-83b8c23a1baa | "Try sgit in your browser" page: the real sgit-ai wheel running client-side under Pyodide (verified in headless Chromium first), key derivation, encrypt/decrypt, an in-memory vault round trip, and a Python REPL. Plus: bootstrap fast-path for static hosting (no 2.5s bridge wait on GitHub Pages), CNAME for sgit.ai, and GitHub Pages deployment via Actions in the SGit-AI__Website repo. |
| v0.1.8 | 2026-08-11 | obj-cas-imm-775783f31110 | Skills promoted to a top-level nav item with a new /skills page and the three agent skills shipped in the vault (latest versions, verbatim); llms.txt added at the vault root, encrypted for key-holders today, a standard public llms.txt when the site deploys to GitHub Pages; Home nav link retired (the brand mark covers it). |
| v0.1.7 | 2026-08-11 | obj-cas-imm-c226a3aff160 | SG/Vault section rebuilt from the official docs bundle: corrected security-page structure-key claim to current reality, git page aligned with the publishing guide (three-rule boundary, leak audit, GitHub round trip, restore drill), new pages for static hosting on GitHub Pages, sub-vaults, and no-code content authoring; .gitignore extended with work/ and *.pem rules. |
| v0.1.6 | 2026-08-11 | obj-cas-imm-f62d9bd2d0d4 | Corrected git integration to the side-by-side design: git now tracks the encrypted .sg_vault store (only the plaintext local/ folder is excluded), so a git remote doubles as a zero-knowledge mirror of the vault. Pattern documented on the git-and-vaults page. |
| v0.1.5 | 2026-08-11 | obj-cas-imm-353038cc3e56 | Git integration: .gitignore (keeps .sg_vault/, above all local/ keys and token, plus git metadata and build noise out of git and out of vault snapshots) and .gitattributes (raw sgit store files marked binary/-diff/-merge; generated *.html marked linguist-generated). |
| v0.1.4 | 2026-08-11 | obj-cas-imm-90254d9591ff | New SG/Vault section, for now the official sgraph platform documentation: SG/Vault & the platform, building vault apps, the window.sg bridge & host capabilities, and "git repos inside vaults" (engineering preview of the pure-Python git reader, verified against a real 906-commit repo). |
| v0.1.3 | 2026-08-11 | obj-cas-imm-46a8b14d4fca | Beta status (in production use), light theme, admin & engineering section, per-push version badge on every page, SG/Vault & SG/Send now link to sgraph.ai, design-improvements brief for Claude Code. |
| v0.1.2 | 2026-08-11 | obj-cas-imm-c3084abbba8c | Replaced the proposal app with the sgit.ai MVP site: 12 individually-navigable pages, shared CSS/JS loaded through the SG bridge, full-strength keys in all examples. |
| v0.1.1 | 2026-08-11 | obj-cas-imm-7f1fbacf0485 | Initial vault app: the positioning & messaging proposal microsite with an embedded landing-page prototype. |

Numbering: v0.1.n while the site is in its first structure; the middle digit will bump on structural redesigns. The commit of the newest row reads "this release" because the id only exists once the release is committed. It is recorded here retroactively by the next release. Rows up to v0.2.76 carry the id of the sgit commit in the site's own vault, which was pushed alongside git until the mirror was [retired](../case-studies/one-tree-two-remotes.md); from v0.2.77 the id is the git commit, prefixed `git`. Commit ids before v0.2.84 are those of the history as rewritten on 19 September 2026 to purge the mirror.

[← Admin & engineering](index.md)



==============================================================================
# The HTTP API, sgit.ai

> The protocol surface behind sgit: base URL, the capability model, and the reference for vault objects, append lanes, authentication headers and error codes. Built from a code-verified audit at v0.33.54, with unresolved endpoints labelled rather than guessed at.
>
> Page: https://sgit.ai/api/index.html

[Home](../index.md) / API

# The HTTP API

Everything sgit does, it does over this API. The CLI is a client; so is the browser bridge; so is anything you write. This section is the protocol surface, endpoints, headers, gates, limits and the error codes you will actually hit. **Two families share this host**: [vaults](vault-objects.md), which are versioned trees you clone and push, and [transfers](transfers.md), which are single encrypted handovers.

**Where this came from, and how far to trust it.** This section is built from a code-verified audit supplied by the SG/API team, read out of the route tables and constants at **v0.33.54** rather than recalled. It is *their* verification, not ours: this site has not independently exercised every endpoint. Where their audit and the shipped client disagreed we checked and said so; where something is registered but unconfirmed it is labelled **PROPOSED** and you should not build on it yet. Same rule as the rest of this site, if it is not verified, it says so.

## Base URL

`https://send.sgraph.ai` for the hosted service, or your own host if you [run it yourself](../deploy/index.md). All request and response bodies are JSON unless stated otherwise.

## The one idea worth reading first

The server is a **capability-checked ciphertext store**, and every access-control decision it makes is a hash comparison. It stores `SHA-256` of each capability key and checks `H(presented) == stored`. It never holds a raw key, and it never holds a private key at all.

That is what makes the rest of the design possible: a vault ID is an address rather than an account, reads are public by default because the bytes are useless without a key, and a stranger can write to your vault without ever having a credential on the platform.

## The reference

| Page | What is in it |
|---|---|
| [Authentication](authentication.md) | The six headers, what each gates, and the hash-comparison model |
| [Vault objects](vault-objects.md) | The pointer store (read, write, batch, destroy) plus the caching contract and storage layout |
| [Append lanes](append-lanes.md) | The six append endpoints: the vault-to-vault message transport |
| [Transfers](transfers.md) | The other family on this host: one encrypted payload, uploaded once, handed over as a single link, the SGMETA envelope, the three calls, and when to reach for this instead of a vault |
| [Errors and limits](errors.md) | 400, 403, 413, 507, what each actually means, and the ceilings that produce them |

## Four capabilities

Most of the API surface is one of four capability tiers. They are separated so that holding one tells you nothing about the others:

| Capability | Presented as | Grants |
|---|---|---|
| `append_token` | a field in the request body | Write to one append lane. Nothing else, not even listing it |
| `enum_key` | `x-sgraph-vault-enum-key` | List, fetch and mark-processed on append lanes |
| `write_key` | `x-sgraph-vault-write-key` | Write and delete objects; configure and purge lanes |
| private key | *never presented* | Decryption, client-side only |

The fourth row is the point of the design rather than a footnote: the server cannot decrypt anything it stores, so the strongest capability in the system is the one it never sees.

## Where to start

- Sending an encrypted message between two vaults → [Vault messaging](../docs/vault-messaging.md), which composes [append lanes](append-lanes.md) with [PKI](../docs/pki.md).
- Reading or writing files → [Vault objects](vault-objects.md).
- Building a vault app in the browser → the [SG bridge](../docs/vault/sg-bridge.md) wraps this API so you never write HTTP.
- Using the CLI instead → [Quickstart](../docs/quickstart.md).

## Open questions we will not guess at

Three items came through the audit unresolved. They are listed rather than documented, because a confident page about an endpoint that does not exist is worse than no page:

| Item | Status |
|---|---|
| `GET /api/vault/zip/{vault_id}` | **UNRESOLVED**: registered in the route table, marked PROPOSED in the team’s reality document. Not documented either way until that is reconciled |
| `/join/*` | **UNRESOLVED**: the reality document lists three live endpoints, but the routes are not registered in the deployed app. Not documented |
| Client-side lane addressing | **PROPOSED**: `append_token = H(public key)` is the intended model; no shipped command emits it. See the [addressing note](../docs/vault-messaging.md#addressing) for what to do meanwhile |



==============================================================================
# API authentication, sgit.ai

> The six authentication headers, what each one gates, and the hash-comparison model: the server stores SHA-256 of every capability key and never holds a raw key or a private key. Includes why vault reads are open by default.
>
> Page: https://sgit.ai/api/authentication.html

[Home](../index.md) / [API](index.md) / Authentication

# Authentication

Six headers exist. Which apply depends on the endpoint and on how the server is deployed. None of them is a password, and none of them is stored: the server keeps `SHA-256` hashes and compares.

## The headers

| Header | What it gates |
|---|---|
| `x-sgraph-access-token` | The SGraph account or deployment. In a **single-key self-hosted deployment** this gates *every* route, including reads |
| `x-sgraph-vault-write-key` | Vault write capability: writes, deletes, destroy, and append `configure` / `purge` |
| `x-sgraph-vault-enum-key` | Append lane enumeration: `list`, `fetch`, `mark-processed` |
| `x-vault-read-key` | Read key, for public-vault routing |
| `x-vault-public` | Public-vault routing flag |
| `x-sgraph-transfer-delete-auth` | [Transfer deletion](transfers.md), SG/Send transfers, not vaults. Carries the *secret*, never the hash, and only works if a `delete_auth_hash` was set at create time |

One capability is **not** a header: `append_token` travels in the request body of `/append/write`. That is deliberate, see [append lanes](append-lanes.md).

## The hash-comparison model

The server never stores a capability key. It stores `SHA-256(key)` and, on each request, hashes what you presented and compares. Two consequences worth designing around:

- **A server compromise yields hashes and ciphertext**, not keys and not plaintext. An attacker with the whole database still cannot read a vault.
- **There is no recovery path.** The server cannot email you your key, because it has never had it. Same property as the vault key itself, for the same reason.

## Why reads are open by default

`GET /api/vault/read/{vault_id}/{file_id}` requires no authentication on the shared host, which surprises people. It follows from the encryption model rather than being a gap in it: the bytes are AES-256-GCM ciphertext under a key the server has never seen, and the file IDs are HMAC-derived opaque identifiers that reveal no filename. Serving them to an anonymous caller discloses nothing a reader could use.

It is also the property that makes a [published read key](../demos/vaults/index.md) work at all, and what lets vault content sit behind an ordinary CDN. If that trade is wrong for your deployment, run in single-key mode, where the access token gates reads too.

What an unauthenticated reader *can* learn is covered honestly on the [security page](../security/index.md#server-sees): object sizes, timing, and approximate activity volume.

## See also

- [Errors](errors.md), what a 403 means as against a 400
- [Security model](../security/index.md), the crypto these capabilities sit on



==============================================================================
# API: vault objects, sgit.ai

> The pointer store: read, write, batch, destroy and presigned endpoints, the caching contract that separates immutable content-addressed objects from mutable refs, and the storage layout behind every vault.
>
> Page: https://sgit.ai/api/vault-objects.html

[Home](../index.md) / [API](index.md) / Vault objects

# Vault objects

The pointer store: the ciphertext objects a vault is made of, addressed by opaque identifiers the server cannot interpret. This is what `sgit push` and `sgit pull` are doing underneath.

## Endpoints

| Method | Path | Auth | Notes |
|---|---|---|---|
| PUT | `/api/vault/write/{vault_id}/{file_id}` | access token + write key | Body is raw ciphertext |
| GET | `/api/vault/read/{vault_id}/{file_id}` | none | Raw bytes. [Reads are public by default](authentication.md#reads) on the shared host |
| GET | `/api/vault/read-base64/{vault_id}/{file_id}` | none | Base64 in JSON, MCP-safe. Around 3.75 MB ceiling |
| DELETE | `/api/vault/delete/{vault_id}/{file_id}` | access token + write key |  |
| POST | `/api/vault/batch/{vault_id}` | per operation | Mixed reads and writes, **max 100** per request |
| POST | `/api/vault/list/{vault_id}` | none |  |
| GET | `/api/vault/health/{vault_id}` | none |  |
| GET | `/api/vault/public-info/{vault_id}` | none |  |
| DELETE | `/api/vault/destroy/{vault_id}` | write key | Body `{vault_id, purge?}`. Without `purge` it writes a tombstone that blocks reuse of the ID |

Large blobs go through presigned URLs rather than the request body: `POST /api/vault/presigned/initiate|complete|cancel/{vault_id}` and `GET /api/vault/presigned/read-url/{vault_id}/{file_id}`.

`GET /api/vault/zip/{vault_id}` is registered in the route table but marked PROPOSED upstream. It is deliberately [not documented](index.md#unresolved) until that is reconciled.

## Destroy, and why the tombstone matters

`destroy` without `purge:true` leaves a tombstone that prevents the vault ID being registered again. That is a security property, not bookkeeping: vault IDs are short and a released ID is a squattable namespace. If somebody still holds a read key pointing at that ID, a new vault claiming it would be answering reads meant for the old one. `purge:true` skips the tombstone and frees the ID, use it only when you are sure no credential survives.

## The caching contract

Anyone writing a client needs this, and getting it wrong produces a bug that looks like corruption:

| Object | Response header |
|---|---|
| File ID containing `-imm-`, immutable, content-addressed | `Cache-Control: public, max-age=31536000, immutable` |
| Refs and indexes, mutable | `Cache-Control: no-store` |

Immutable objects are content-addressed, so their bytes can never change and a year-long cache is safe, which is what lets a vault sit behind a CDN. Mutable refs must never be cached: a stale ref renders a previous commit’s tree from ciphertext that is itself perfectly valid, so nothing errors and the reader simply sees the wrong version of the vault.

**Measured 21 September 2026: the immutable header is not currently being sent.** A GET of an `obj-cas-imm-` object on `/api/vault/read/` returned **no `Cache-Control` header at all**, and the CDN reported a miss. The table above is the contract, not a description of what is served on that path today. Build as though the header may be absent: cache on the id, which is a hash of the ciphertext and therefore cannot be stale, rather than on a header you were sent. That is what the client-side caches in this estate already do, and [why caching ciphertext is the easy case](../demos/fractal-graphs/performance.md#caching).

## Storage layout

```
bare/data/obj-cas-imm-{hex}     blobs, trees, commits — content-addressed, immutable
bare/keys/key-rnd-imm-{hex}     PKI public keys — immutable
bare/refs/                      branch refs — mutable
bare/indexes/                   branch index — mutable
bare/append/                    append lanes — managed, outside the commit DAG
```

The prefixes are load-bearing. `obj-cas-imm-` is SHA-256 over the *ciphertext*, which gives deduplication without the server knowing any plaintext, and makes the caching rule above derivable from the ID alone. Append lanes sit outside the commit DAG on purpose, a message arriving does not rewrite your history.

This site is itself served from a vault, so these are the objects behind the page you are reading. The [live-vault case study](../case-studies/live-vault-docs.md) shows the fetch sequence.

## See also

- [Append lanes](append-lanes.md), the write-only channel that does not touch the commit tree
- [Errors and limits](errors.md)



==============================================================================
# API: append lanes (sgit.ai)

> The six append endpoints) the write-only vault-to-vault message transport. Four separated capabilities, the blind write response, server-assigned sortable filenames, idempotent mark-processed, and the limits.
>
> Page: https://sgit.ai/api/append-lanes.html

[Home](../index.md) / [API](index.md) / Append lanes

# Append lanes

A write-only channel attached to a vault, gated by a token the writer holds and nothing else. This is the transport behind [vault-to-vault messaging](../docs/vault-messaging.md) and behind [`sg.append`](../docs/vault/sg-bridge.md) in the browser bridge, and it is deliberately generic: the same primitive carries messages, logs, signals, control messages and state flows.

**Naming.** This API was called **inbox** before v0.32.7. Every `/api/vault/inbox/*` URL is gone, and `purge` takes `folder:"pending"` or `"processed"`, the old `"inbox"` value returns **400**. If you are reading older material, translate.

## The six endpoints

All **POST**, all under `/api/vault/append/`.

| Path | Gate | Does |
|---|---|---|
| `configure/{vault_id}` | `x-sgraph-vault-write-key` | Registers `append_anchors`, hashes of accepted senders, and `enum_key_hash` |
| `write/{vault_id}` | `append_token`**in the body** | Appends a payload. **Account-less**: no access token required |
| `list/{vault_id}` | `x-sgraph-vault-enum-key` | Paginated listing, optionally with inline content |
| `fetch/{vault_id}` | enum key | Fetch specific file IDs, batched |
| `mark-processed/{vault_id}` | enum key | Moves pending → processed. Idempotent |
| `purge/{vault_id}` | write key | Deletes. `folder: "pending" | "processed"` |

## Why the gates are split this way

Four capabilities, and the split is the whole design:

| Capability | Holder | Can | Cannot |
|---|---|---|---|
| `append_token` | the sender | write | list, fetch, read anything |
| `enum_key` | the vault owner | list, fetch, mark-processed | write, purge |
| `write_key` | the vault owner | configure, purge | none |
| private key | the vault owner | **decrypt** | *never sent to the server* |

A sender can put something into your vault and learn nothing at all, not the contents, not the volume, not whether anyone else writes there. The server stores `SHA-256` of the first three capabilities and compares hashes; the fourth it never sees.

## Four contracts worth relying on

- **The write response is blind.** `/write` returns exactly `{"ok": true}`, no file ID, no count, no metadata. This is a security property, not an oversight: a returned ID would leak lane state to a party who is only allowed to write.
- **Filenames are server-assigned** as `{epoch_ms:013d}_{24-hex}.enc`. Being chronologically sortable is what makes cursor pagination stable, pass the last file ID you saw as `after_file_id`.
- **Metadata-only listing is free.** `include_content: false` reads **zero** payloads. Poll with it, then fetch on demand; polling with content is the common way to hit the 3 MB ceiling for no reason.
- **mark-processed is idempotent.** An already-moved file comes back in `missing` rather than as an error, so retrying a batch after a timeout is safe.

## From a vault app: one verb crosses vaults, five do not

This is the constraint to understand before designing anything that spans two vaults, and it was undocumented until the SG/API team's review of 6 September 2026 (quoted here CC BY 4.0). The bridge builds **one** client bound to the **currently open vault**, with the enum key derived from that vault's read key. So:

| Verb | Which vault it acts on | Bridge permission |
|---|---|---|
| `write` | **Any**: it takes an explicit `vault_id` and posts with no headers at all | `append.write` |
| `list` | Always the open vault. There is no way to address a remote vault with these from an app | `append.list` |
| `fetch` | `append.read`, **not**`append.fetch` |
| `markProcessed` | `append.markProcessed` |
| `purge` | `append.purge` |
| `configure` | `append.configure` |

All six are plain booleans, **default-deny**, not path-scoped. The asymmetry is deliberate rather than a gap: listing a remote lane needs the recipient's enum key, and shipping that inside a published app *"would give every visitor read access to the whole lane."*

**Two things that are *not* gates on `append`, despite appearances.** There is **no read-only check** anywhere in the append handler, `sg.app.writable` is irrelevant to it, and a read-key session can write to a lane given the grant. And the CSP is not an append rule: the frame ships `connect-src blob: data:`, so a *direct* `fetch` to these endpoints is blocked unless the app declares `permissions.network: true`, which reopens all egress and is the worse choice. Use the bridge. See [the build brief](../docs/briefs/vault-telemetry-append-lanes.md), which had both of these wrong until the review corrected it.

## The `inbox` field is the lane id, and today it is the token

A `list` response labels each entry with an `inbox` value. That value is the storage folder name, and the folder is named by the **raw append token**, byte for byte, while `config.append_anchors` stores `sha256(token)`. So the design hashes the token in config and then writes the plaintext token into the object key.

The disclosure is bounded: `list` is gated by the enum key, so it reaches only the vault owner, who already holds every credential in play; and the token is a **write-only lane address**, closer to an email address than a password. The residual risk is storage rather than API, the raw token becomes an object key, so it lands in access logs, inventory reports and backups, *"surfaces with a very different audience from the enum-key holder."* The team intends to fold the folder name to `sha256(token)`, which is a breaking change needing a migration. **Documented here now so that nobody has to discover it from a debrief.**

Lanes live at `bare/append/{token}/pending/` and `…/processed/`, **outside the version-controlled commit tree**: appends never touch a branch and never conflict with a push.

## Several senders on one vault

Register several `append_anchors` and each sender writes into their own lane, distinguished by their token. A listing can be scoped to one lane, so one correspondent flooding you does not bury another, and revoking one sender is removing one anchor, with no effect on the rest.

## Limits and codes

| Limit | Value | On breach |
|---|---|---|
| Payload per write | 5 MB | 413 |
| Pending files per token | 1000 | 507 |
| File IDs per batch | 100 | 400 |
| Inline content when listing | 3 MB cumulative | 413 |
| Page size | 50 default, 200 max | clamped silently |

The `append_token` pattern is `^[0-9a-f]{16,128}$`, hex only. A prefixed token returns **400**, not 403; see [errors](errors.md) for why that distinction saves time.

## See also

- [Vault messaging](../docs/vault-messaging.md), this API composed with PKI into a worked example
- [`sg.append`](../docs/vault/sg-bridge.md), the same six operations from a vault app
- [Errors and limits](errors.md)



==============================================================================
# API: transfers, one encrypted handover, one link

> The other API family on this host: a single encrypted payload uploaded once and shared as one link. The two secrets that must not be confused, the SGMETA envelope that keeps the filename off the server, the three calls, revocation that is opt-in at create time only, and when a transfer beats a vault.
>
> Page: https://sgit.ai/api/transfers.html

[Home](../index.md) / [HTTP API](index.md) / Transfers

# The transfer API, one encrypted handover, one link

The other half of the API on this host. A **vault** is a versioned encrypted tree you clone, pull and push; a **transfer** is a single encrypted payload uploaded once and handed over as one link. Same server, same zero-knowledge property, different job, and until now this site documented a transfer *header* without documenting a single transfer *endpoint*.

**Provenance.** This page is derived from an integration guide written by the team that owns the SG/Send API, who executed **every request, response, status code and byte layout in it against the production user API on 9 September 2026**. That run is theirs, not ours. We have not re-executed it here, and the date is the one to check it against. Their guide is released under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

## Transfer or vault?

Pick this first; it decides everything after it.

|  | Transfer | [Vault](vault-objects.md) |
|---|---|---|
| **Shape** | One payload, uploaded once | A versioned tree of files |
| **History** | None. There is no second version | Commits, branches, merges |
| **The reader gets** | The whole payload, or nothing | Any single file, without fetching the rest |
| **Lifecycle** | Expires, caps downloads, can be revoked | Lives until you delete it |
| **The credential** | A decryption key in the URL fragment | A [read key](../docs/vault/reading-a-vault-file.md), derived one-way |
| **Reach for it when** | An agent finishes a job and hands the result over **once**: a bundle, a report, a dated export | The thing is read repeatedly, browsed, updated, or rendered as an app |

The SG/API team's own guidance, for a workflow that ships one bundle per voice memo, is that the transfer API is *“the simpler and better fit”*. That is the right instinct in general: **a vault is the wrong answer for a handover that happens once.**

## Two secrets that must never be confused

This is the part that goes wrong first, and it goes wrong silently, a leaked access key does not throw.

|  | What it authorises | Where it goes |
|---|---|---|
| **The access key** `x-sgraph-access-token` | *You*, to upload | A request **header**. Never a URL, never a share link, never a log |
| **The decryption key** | *Anyone*, to read | The URL **fragment**: everything after `#`, which no browser sends to the server |

They are unrelated values. The fragment is what makes a share link both shareable and private: the key reaches the recipient's client and never the origin serving the page. The API also accepts `?access_token=` as a query fallback and it works, **do not use it**; query strings land in proxy logs, browser history and workflow execution records.

What the server can see: ciphertext size, a hashed sender IP, a creation timestamp, and the `content_type_hint` you supply. What it cannot see: the filename, the contents, or the key.

## The payload format, two layers, in this order

The filename must not reach the server, so it is wrapped *inside* the plaintext before encryption. Getting the order wrong produces a corrupt download with no name.

**Inner, the SGMETA envelope:**

```
"SGMETA\0"          7 bytes    53 47 4D 45 54 41 00
meta_len            4 bytes    uint32, big-endian
metadata JSON       meta_len   {"filename":"…"}  UTF-8
file bytes          rest       your payload
```

**Outer, AES-256-GCM over that whole buffer:**

```
IV                 12 bytes    random, fresh per upload, prepended
ciphertext + tag   rest        GCM appends its own 16-byte tag
```

- **Key:** 32 random bytes, shared as **base64url, unpadded**: 43 characters.
- **IV:** 12 random bytes, never reused with the same key.
- **Overhead:** the uploaded payload is exactly **28 bytes larger** than the plaintext (12 + 16).

Same primitive as everything else here: AES-256-GCM, done client-side, with the server holding ciphertext under a key it never had. [The security page](../security/index.md) covers why that is the whole product rather than a feature of it.

## The three calls

| Call | Endpoint | Notes |
|---|---|---|
| **1 · create** | `POST /api/transfers/create` | Returns `transfer_id`. Body carries `file_size_bytes` (the *plaintext* length, display metadata only), `content_type_hint` (stored in the clear, keep it generic), `max_downloads`, `auto_delete`, `expires_at` |
| **2 · upload** | `POST /api/transfers/upload/{id}` | **Raw bytes**: not base64, not multipart. `Content-Type: application/octet-stream` |
| **3 · complete** | `POST /api/transfers/complete/{id}` | Nothing is downloadable until this call lands |

Only those three need the access key. `info` and `download` are **public by design**: the decryption key is the gate, which is exactly why a share link works for someone with no account.

**Two traps in the create body.** `expires_at` is in **milliseconds** since epoch, not seconds; `0` means never. And `max_downloads: 0` means *unlimited*, not zero, once a finite allowance is exhausted, downloads return **410**.

### Build the share link yourself

`complete` returns a `download_url` of `/d/{id}`. **Ignore it**: verified as a 404; it is not a live route. The link to hand out is:

```
https://send.sgraph.ai/en-gb/download/#{transfer_id}/{key_base64url}
```

Omit `/{key}` for a link-only form when the key travels through a second channel. The fragment parser splits on the **first** `/` and truncates at a `|`, so `|` is reserved, base64url never produces one, so following the format above keeps you clear.

## What a receiving agent has to do

This is the payoff, and it is two calls with no account and no browser: `GET /api/transfers/download/{id}` needs no auth, and the key from the fragment does the rest, split the IV off the first 12 bytes, AES-GCM decrypt, check the `SGMETA\0` magic, read the big-endian length, and the filename and payload fall out. For a JSON-only transport such as an MCP tool, `GET /api/transfers/download-base64/{id}` returns the same bytes wrapped in JSON.

**Downloads are counted.** An agent retrying a failed run burns the allowance. For agent-facing links prefer `max_downloads: 0` with a short `expires_at`, time-bounded rather than attempt-bounded, because a retry is not a reader.

## Expiry, caps and revocation

Revocation is opt-in **at create time and only then**: set `delete_auth_hash` to `sha256(secret)` in hex and store the secret beside the transfer id. Without it, deletion is disabled for that transfer forever. To revoke, `DELETE /api/transfers/delete/{id}` carrying the access key and `x-sgraph-transfer-delete-auth: <the secret, not the hash>`, the one header [the authentication page](authentication.md) already listed before this page existed to explain it.

**410 and 404 are both normal end states, not errors to retry:** 410 is gone-as-expected (expired or exhausted), 404 is never-existed-or-deleted.

## Size

| Path | Ceiling | When |
|---|---|---|
| **Direct upload** | keep the encrypted payload under **~4 MB** | The normal case |
| Multipart / presigned | Larger | Needs the S3 backend, check `GET /api/presigned/capabilities` first |

The ~4 MB figure is a working limit rather than a published one: the Lambda URL caps a request body at 6 MB and the browser client switches to presigned at 5 MB. Text bundles compress far below it; **audio does not**, and is usually the most sensitive part of a bundle as well as the largest.

## Verified behaviour

The SG/API team's run, 9 September 2026, reproduced here as they reported it:

| Case | Result |
|---|---|
| Header `x-sgraph-access-token` | **200** |
| Header `x-sgraph-send-access-token` | **401**: that name does not work |
| No token, or a wrong one | **401** |
| `download` / `info` with no token | **200**: public by design |
| Round trip: wrap → encrypt → create → upload → complete → download → decrypt → unwrap | **Byte-identical** payload recovered, filename intact |
| Download #3 against `max_downloads: 2` | **410** |
| Download of an expired transfer | **410** |
| `DELETE` with wrong / correct delete-auth | **403** / **200**, then **404** |
| `GET /d/{transfer_id}` | **404**: not a route |
| Key length | 32 bytes → 43 base64url characters |
| Encrypted payload overhead | plaintext + 28 bytes |

## The rules worth holding to

1. **Never log or return the decryption key** outside the share link. It is not an identifier, anyone holding it reads the payload. In a workflow engine that means keeping it out of node output that gets persisted.
2. **Never put the access key in a URL.** Header only.
3. **Never reuse an IV.** Twelve fresh random bytes per upload.
4. **Keep the filename inside the envelope.** `content_type_hint` is in the clear; the name is not, and that is the reason the envelope exists.
5. **Always set an expiry.** A link pasted into a chat lives as long as the chat does; the transfer should not.
6. **Bundle for a reader who is an agent**: a `manifest.json` saying what each file is, and an `llms.txt`, cost nothing and are the difference between a payload that can be used and one that has to be opened by a person first.

Adapted with attribution from the SG/API team's integration guide of 9 September 2026 (CC BY 4.0); the workflow-specific half of that document (credential wiring, node shapes, the bundle layout for one product) stays with the product it was written for. [API reference](index.md) · [Vault objects](vault-objects.md) · [Append lanes](append-lanes.md) · [Working on a vault](../docs/guidance/index.md)



==============================================================================
# API errors and limits, sgit.ai

> 400, 403, 413 and 507: what each means, why a malformed token returns 400 rather than 403, the input patterns enforced before storage is reached, and every documented ceiling.
>
> Page: https://sgit.ai/api/errors.html

[Home](../index.md) / [API](index.md) / Errors and limits

# Errors and limits

Four status codes carry almost all the failures, and telling them apart saves real debugging time, particularly 400 versus 403, which fail for opposite reasons.

## Status codes

| Code | Means | What to do |
|---|---|---|
| **400** | Invalid input, the value never reached a gate. Malformed token, malformed file ID, batch too large, unknown `folder` value | Fix the *shape* of what you sent. Your credential may be perfectly valid |
| **403** | Gate failure, well-formed input, wrong capability | Fix the *credential*. The request shape was fine |
| **413** | Too large, payload over 5 MB, or an inline-content listing over the 3 MB ceiling | Split the payload, or list without inline content and fetch on demand |
| **507** | Lane full, 1000 pending files for that token | Fetch and `mark-processed`, then `purge` the processed folder |

**The 400 that looks like a 403.** Path and token components are validated by typed primitives *before* they reach storage, which is how path traversal is blocked at the type level. A prefixed token such as `tok_abc…` (or a CLI fingerprint pasted straight in, `sha256:a461…`) fails the hex-only pattern and returns **400**. It reads like a rejected credential; it is a rejected string. Use raw hex.

## Input patterns

| Input | Pattern |
|---|---|
| `append_token` | `^[0-9a-f]{16,128}$`: hex only, no prefix |
| `file_id` (append) | `^\d{13}_[0-9a-f]{24}\.enc$`) server-assigned, so you should be echoing one back |
| `vault_id` | lowercase alphanumeric, 8–24 characters, no hyphens |

## Limits

| Limit | Value | On breach |
|---|---|---|
| Payload per append write | 5 MB | 413 |
| Pending files per append token | 1000 | 507 |
| File IDs per batch (fetch / mark / purge) | 100 | 400 |
| Operations per `/vault/batch` request | 100 | 400 |
| Inline content when listing | 3 MB cumulative | 413 |
| Append list page size | 50 default, 200 max | clamped silently |
| `read-base64` response | ~3.75 MB | use [presigned reads](vault-objects.md) above this |

The page-size clamp is silent: ask for 500 and you get 200 with no warning. Page with `after_file_id` rather than assuming your requested size was honoured.



==============================================================================
# Sending messages between vaults, sgit.ai

> How two vaults exchange encrypted messages without sharing a vault key and without the sender holding an account: append lanes addressed by a token, composed with PKI. Worked example in CLI, curl and sg.append, with the one step that is not yet wired marked PROPOSED.
>
> Page: https://sgit.ai/docs/vault-messaging.html

[Home](../index.md) / [Docs](index.md) / Vault messaging

# Sending messages between vaults

Two vaults can exchange encrypted messages without sharing a vault key, without the sender having an account, and without the server ever being able to read anything. The mechanism is an **append lane**: a write-only channel attached to a vault, addressed by the hash of a public key.

**Why this page exists.** Both halves of this capability were already documented, the transport as [`sg.append`](vault/sg-bridge.md), the crypto as [`sgit pki`](pki.md), on pages that never referenced each other. An agent asked how to send a message between vaults, found both halves, and could not find the sentence that says they combine. This is that sentence, written out.

## The shape of it

```
   SENDER                        SERVER                      RECIPIENT
   ──────                        ──────                      ─────────
   has: your public key          stores: ciphertext          has: private key
                                         + hashes of keys          + enum_key

   encrypt(msg, your_pubkey)
   append_token = H(pubkey)
        │
        │  POST /api/vault/append/write/{vault_id}
        │  { append_token, payload }
        ├────────────────────────▶  gate: H(append_token) ∈ append_anchors?
        ◀────────────────────────  { "ok": true }   ← blind: no id, no count
                                          │
                                          │   POST /append/list      (enum_key)
                                          ◀──────────────────────────┤
                                          │   POST /append/fetch     │
                                          ├─────────────────────────▶│ decrypt locally
                                          │   POST /append/mark-processed
                                          ◀──────────────────────────┤
```

**What the server can see:** that a lane received something, how big it was, and when. **What it cannot see:** the content, or the recipient’s private key, which never leaves their machine.

## Four capabilities, deliberately separated

This is the part worth understanding, because it is why a sender cannot read the lane they write to:

| Capability | Who holds it | Can | Cannot |
|---|---|---|---|
| `append_token` | the sender | write | list, fetch, read anything |
| `enum_key` | the vault owner | list, fetch, mark-processed | write, purge |
| `write_key` | the vault owner | configure, purge | none |
| private key | the vault owner | **decrypt** | *never sent to the server* |

The server stores `SHA-256` hashes of the first three and checks `H(presented) == stored`. It never holds a raw capability key, and never holds a private key at all. Compromising the server yields hashes and ciphertext.

Read in the [privilege vocabulary](../compare/index.md) the comparison pages use: the sender’s capability is **scoped** to one operation on one lane, **bearer**-held, and **observable** to the owner but not to the sender. A write-only credential that cannot read its own effects is an unusually clean shape.

## Setting up a lane recipient, one-time

Have a keypair and publish the public half ([full lifecycle here](pki.md)):

```
$ sgit pki keygen --label "My Vault Identity"
$ sgit pki export sha256:a4615402a0bc23ac > my-identity.json
```

Then register, against your vault, the hash of the sender’s lane address and the hash of your enumeration key:

```
$ curl -X POST https://send.sgraph.ai/api/vault/append/configure/$VAULT_ID \
    -H "x-sgraph-vault-write-key: $WRITE_KEY" \
    -H "Content-Type: application/json" \
    -d '{"append_anchors":["<sha256 of the append_token>"],
         "enum_key_hash":"<sha256 of your enum_key>"}'
```

`configure` patches an existing vault manifest. It does not create a vault. A 403 means the vault ID or the write key is wrong.

## Deriving the lane address read this before writing code

**This step is not yet wired end to end, and the gap is worth stating precisely.**
 The design is `append_token = H(recipient public key)`, so a sender can compute your lane address from the public bundle you gave them, with no extra coordination. That is an elegant property and it is the intended model.

 What ships today on **sgit v0.15.0**: `sgit pki export` emits a **JSON bundle** containing two PEM blocks, a label and two fingerprints, *not* a bare public key. No shipped command emits the append token, and hashing the bundle file is not a defined derivation (field order and whitespace would change the answer). The **server** side of append lanes is code-verified and shipped; the **client** derivation that turns a public key into a lane address is **PROPOSED**.

**What to do meanwhile:** treat `append_token` as an opaque 64-hex secret you agree out of band, generate one, hand it to your sender, register its SHA-256 as an `append_anchor`. Everything else on this page works today. When the derivation lands, the token stops needing to be exchanged; nothing else changes.

Two format rules that cause avoidable failures:

- The token pattern is `^[0-9a-f]{16,128}$`, **hex only**. A prefixed token like `tok_abc…` returns **400**, not 403, because it fails input validation before it reaches any gate.
- CLI fingerprints are printed as `sha256:a4615402a0bc23ac`. That `sha256:` prefix is part of the CLI identifier and is **not** part of a token. Pasting a fingerprint straight in is the most likely way to hit that 400.

## Sending

```
# 1. encrypt to the recipient's public key (RSA-OAEP 4096 + AES-256-GCM, client-side)
$ sgit pki encrypt message.txt --recipient sha256:a4615402a0bc23ac
Encrypted to message.txt.enc

# 2. append it to their lane
$ curl -X POST https://send.sgraph.ai/api/vault/append/write/$THEIR_VAULT_ID \
    -H "Content-Type: application/json" \
    -d '{"append_token":"'$APPEND_TOKEN'","payload":"'$(base64 -w0 message.txt.enc)'"}'
{"ok": true}
```

**No account is needed to send.** The write endpoint requires no access token, the `append_token` is the whole gate. That is deliberate: somebody can send to your vault without holding a credential on the platform at all.

The response is **blind by design**: exactly `{"ok": true}`, with no file ID, no count and no metadata. A sender cannot learn what else is in the lane, or even whether theirs was the first write.

## Receiving

Poll cheaply first, a metadata-only listing reads **zero** payloads:

```
$ curl -X POST https://send.sgraph.ai/api/vault/append/list/$VAULT_ID \
    -H "x-sgraph-vault-enum-key: $ENUM_KEY" \
    -H "Content-Type: application/json" \
    -d '{"include_content": false}'
```

Filenames are server-assigned as `{epoch_ms}_{24-hex}.enc`, so they sort chronologically, which is what makes cursor pagination stable. Page with `after_file_id` set to the last ID you saw.

```
$ curl -X POST .../append/fetch/$VAULT_ID -H "x-sgraph-vault-enum-key: $ENUM_KEY" \
    -d '{"file_ids":["1755302400000_a3f8….enc"]}'

$ sgit pki decrypt message.txt.enc --fingerprint sha256:a4615402a0bc23ac

$ curl -X POST .../append/mark-processed/$VAULT_ID -H "x-sgraph-vault-enum-key: $ENUM_KEY" \
    -d '{"file_ids":["1755302400000_a3f8….enc"]}'
```

`mark-processed` is idempotent, a file already moved comes back in `missing` rather than as an error, so a retried batch is safe.

## From inside a vault app

The same transport through the browser bridge, with no HTTP of your own (see [`sg.append`](vault/sg-bridge.md)):

```
await sg.append.configure({ appendAnchors: [anchorHash], enumKeyHash });
await sg.append.write({ appendToken, payload });            // blind
const { entries } = await sg.append.list({ includeContent: false });
const { files }   = await sg.append.fetch({ fileIds });
await sg.append.markProcessed({ fileIds });
await sg.append.purge({ folder: 'processed' });
```

## Practical notes

- **Limits.** 5 MB per message (**413**) · 1000 pending files per token (**507**) · 100 file IDs per batch (**400**) · 3 MB inline-content ceiling when listing with content (**413**) · list page size 50 by default, 200 max, clamped silently.
- **Several senders.** Register several `append_anchors`. Each sender writes to their own lane, so a listing can be scoped to one of them.
- **Housekeeping.** `purge` with `folder:"processed"` and no file IDs clears a whole lane’s processed set in one call. It takes `"pending"` or `"processed"`, the older `"inbox"` value now returns 400.
- **The API was renamed.** `inbox` became `append` in v0.32.7; any `/api/vault/inbox/*` URL is gone.

## What this is not

Not a chat protocol, not a queue with delivery guarantees, and not anonymous, the server sees lane activity and timing even though it cannot read content. It is a **generic append-only transport**: the same primitive carries logs, signals, control messages and state flows between agents. The client decides what the bytes mean.

## See also

- [API, append lanes](../api/append-lanes.md): the six endpoints, gates, limits and status codes
- [PKI](pki.md): keypair lifecycle, verified against the shipped CLI
- [`sg.append`](vault/sg-bridge.md): the same transport from a vault app
- [Security model](../security/index.md#pki): where the keypair sits relative to the symmetric vault key



==============================================================================
# Vault credentials: what each one can do, and what its prefix declares, sgit.ai

> Two capabilities, a vault key that reads and writes and a read key derived from it one way, plus the five prefixes that declare which you are holding and whether it was meant to be published. Why sgit_public_read_ is the form for an open vault, why publishing one under sgit_private_read_ is a mislabel that an agent will correctly refuse, and why the word matters when the bytes are identical.
>
> Page: https://sgit.ai/docs/credentials.html

[Home](../index.md) / [Docs](index.md) / Vault credentials

# Vault credentials: what each one can do, and what its prefix declares

A vault credential is the whole thing you need: the address, the capability and the decryption key, in one string. There are two capabilities, **write** and **read**, and five prefixes in circulation that declare which one you are holding and whether it was meant to be published. The prefix is a **declaration, not cryptography**: strip it and the bytes are identical. It still matters, and this page is why.

**Why this page exists, with the date on it.** On 20 September 2026 an agent was asked to open two vaults published on this site and refused, because their read keys were labelled `sgit_private_read_`. It was right to refuse and our label was wrong: those keys are deliberately public, and the prefix that says so is `sgit_public_read_`. The keys were relabelled the same day, the build now refuses a private-prefixed credential in any tracked file, and this page is the explanation that was missing.

## Two capabilities, and one is derived from the other

A vault key carries read *and* write. A read key carries read only, and is derived from the vault key by a one-way function, so a read key can never be turned back into write access. That derivation is the whole publishing model on this site: [thirty vaults](../demos/vaults/index.md) hand out read keys on purpose, and not one of them can be used to change anything.

*[diagram]*

## The five prefixes

Three are current and emitted by the CLI today. Two are legacy, released briefly in v0.15.5, accepted on input forever and never emitted again.

| Prefix | Declares | Capability | Publish it? |
|---|---|---|---|
| `sgit_private_vault_` | A vault key, kept secret | **Read and write** | **Never.** Not in a page, a repository, a commit message, an issue or a release log |
| `sgit_private_read_` | A read key, **kept secret** | Read only | **No.** Publishing it leaks no write capability, but the label says the opposite of what you are doing. Re-derive the string with the public prefix first |
| `sgit_public_read_` | A read key, **deliberately published** | Read only | **Yes.** This is the form every open vault on this site should carry |
| `sgit_vk1_`legacy | A vault key | Read and write | Never |
| `sgit_rk1_`legacy | A read key, intent unstated | Read only | Safe, and says nothing about intent. Most pages on this site still carry this form; the bytes are the same |

A credential with no prefix at all is the oldest form and still circulates. It is read as **unknown** and resolved by context, which is exactly the ambiguity the prefixes were introduced to end.

## Classification is by declaration, never by shape

This is the rule the CLI states in its own source, and it was learned the hard way: *"guessing from shape is what once misrouted a 64-hex passphrase to a read-only clone."* A surface that accepts read credentials must refuse a vault key because the string *says* it is one, not because it looks long enough to be a passphrase.

Shape is still the backstop for the years of keys created before prefixes existed: a read key is 64 hexadecimal characters, and anything else before the colon is a passphrase, which means write. [The publishing method](../demos/vaults/publishing.md) runs both checks on every credential submitted to this site, and the front stop is one command:

```
$ python3 admin/build/check_credential.py '<credential>'
  form      : read key (public, prefixed)
  publish?  : YES — read-only, declared public
  why       : the sgit_public_read_ prefix marks a key meant to be published
```

## Why the word matters when the bytes do not

Relabelling a key changes nothing an attacker can use. It changes three things that people and machines rely on.

- **One scanner rule covers every secret credential.** `sgit_private_` matches the vault key, the private read key, and any private credential type invented later. Publishing keys under a private prefix trains that alarm into noise, which is the failure mode where a real leak goes unnoticed because the alert fires every day.
- **Public and private differ by a word, not a character.** That is deliberate. A tired reviewer can misread `rk1` for `vk1`; nobody misreads *public* for *private*.
- **An agent reads the label and acts on it.** The refusal that produced this page was correct behaviour on a wrong label. An agent that ignores a *private* marker because the content happened to be on a public page is an agent that will ignore the next one too.

## What a read key can and cannot do

| **Can** | Clone the vault, read every file, read **every commit in its history**, and run the vault's app in a browser with no account and nothing installed |
|---|---|
| **Cannot** | Commit, push, delete, rotate the key, or reach any other vault. There is no privilege inside it to escalate |
| **Costs** | Nothing to issue, and nothing to the server, which stores ciphertext either way |
| **Does not do** | **Revocation is not retroactive.** Anyone who has fetched the objects keeps them; rotating protects future commits only. Publish a read key the way you would publish the content itself, because that is what you are doing |

## What this site publishes

Every vault in [the gallery](../demos/vaults/index.md) carries a read key published on purpose, and no vault key appears anywhere: the release refuses to push if a write credential reaches a tracked file, and since 20 September it refuses a `sgit_private_` credential of any kind. New pages use `sgit_public_read_`. Older pages carry the legacy `sgit_rk1_` form or a bare key, which are the same bytes and open the same way, in the CLI and in the browser.

Checked against sgit-ai v0.16.2 and the SG/Vault web loader on 20 September 2026: all five prefixes plus the bare form strip to the same value and clone the same vault, verified with an all-zeros negative control that produces nothing.

[← Keys and signatures](pki.md)[Publishing a vault →](../demos/vaults/publishing.md)



==============================================================================
# Keys, signatures and encrypting to someone else, sgit.ai

> The keypair lifecycle run end to end on the shipped CLI: RSA-OAEP 4096 encryption, ECDSA P-256 signing, the JSON public-key bundle, the hybrid envelope format, and what PKI does not do yet.
>
> Page: https://sgit.ai/docs/pki.html

[Home](../index.md) / [Docs](index.md) / PKI

# Keys, signatures and encrypting to someone else

The vault key is symmetric and opens the whole vault. A keypair does the two things it cannot: prove *who* wrote something, and encrypt to somebody who holds no vault key at all. This page is the lifecycle, run end to end on the shipped CLI.

**Everything below was executed, not recalled.** Every command, every output shape and every construction on this page came from running `sgit pki` on **v0.15.0** in a throwaway home directory. Where the behaviour differs from what you might expect, and in two places it does, the page says so.

## What sgit actually generates

`sgit pki keygen` creates **two** pairs at once, and prints two fingerprints:

| Purpose | Construction | Identifier |
|---|---|---|
| Encryption | **RSA-OAEP, 4096-bit** | `fingerprint` |
| Signing | **ECDSA P-256** | `signing_fingerprint` |

Encryption is **hybrid**, which is what makes it usable on files of any size: a fresh AES-256-GCM content key encrypts the payload, and RSA-OAEP wraps that content key. The same AES-256-GCM primitive as the rest of the vault, the keypair only changes how the content key gets to the recipient.

Note for anyone integrating against a spec rather than the binary: this is **RSA-OAEP and ECDSA**, not X25519/Ed25519. Draft material describing an X25519 sealing layer describes a design, not what v0.15.0 ships.

## The lifecycle

### 1 · Generate

```
$ sgit pki keygen --label "My Vault Identity"
Enter passphrase to protect private keys:

Generating RSA-4096 encryption key... done

Key pair created:
  Label:                My Vault Identity
  Encryption:           RSA-OAEP 4096-bit
  Signing:              ECDSA P-256
  Fingerprint:          sha256:a4615402a0bc23ac
  Signing fingerprint:  sha256:69d9b4835ccf790c
```

**Keygen prompts for a passphrase** and will not proceed without one, private keys are encrypted at rest. In a script, feed it on stdin; with no terminal at all it exits with an `EOFError` rather than silently generating an unprotected key, which is the right failure.

RSA-4096 generation is not instant. Expect a pause.

### 2 · Publish the public half

```
$ sgit pki list
  sha256:a4615402a0bc23ac  My Vault Identity  (RSA-OAEP 4096)

$ sgit pki export sha256:a4615402a0bc23ac > my-identity.json
```

**Export produces a JSON bundle, not a PEM file.** It carries both public keys, both fingerprints and the label:

```
{
  "v": 1,
  "encrypt": "-----BEGIN PUBLIC KEY-----\nMIICIjANBgkq…",
  "sign":    "-----BEGIN PUBLIC KEY-----\nMFkwEwYHKoZIzj0CAQ…",
  "label":   "My Vault Identity",
  "fingerprint":         "sha256:a4615402a0bc23ac",
  "signing_fingerprint": "sha256:69d9b4835ccf790c"
}
```

The bundle contains no private material. Publish it, mail it, commit it, put it on your website.

### 3 · Import someone else’s

```
$ sgit pki import their-identity.json
Imported contact: Their Label
  Fingerprint: sha256:…

$ sgit pki contacts
  sha256:…  Their Label
```

### 4 · Encrypt to them, and decrypt what they send you

```
$ sgit pki encrypt message.txt --recipient sha256:a4615402a0bc23ac
Encrypted to message.txt.enc

$ sgit pki decrypt message.txt.enc --fingerprint sha256:a4615402a0bc23ac
Enter passphrase:
Decrypted to message.txt
```

Round trip verified. Two argument details that will bite you once each: `encrypt` takes `--recipient` (a contact’s fingerprint) and an optional `--fingerprint` for *your* signing key; `decrypt` requires `--fingerprint`. It will not guess which of your keys to try.

### 5 · Sign and verify

```
$ sgit pki sign report.pdf --fingerprint sha256:69d9b4835ccf790c
$ sgit pki verify report.pdf report.pdf.sig
```

Detached signatures, so the signed file is unchanged. Signing uses the *signing* fingerprint, which is the second one keygen printed.

## The envelope on the wire

An encrypted file is base64 over a small JSON object, worth knowing if you are writing an interoperable client:

| Field | Contents | Observed size |
|---|---|---|
| `v` | Envelope version, `2` on v0.15.0 | none |
| `w` | The AES content key, wrapped with RSA-OAEP to the recipient | 512 bytes (4096-bit) |
| `i` | AES-GCM IV | 12 bytes |
| `c` | Ciphertext with its GCM tag | plaintext + 16 |

A 37-byte plaintext produced a 1,076-byte file: the RSA-wrapped key dominates, so this is efficient for large payloads and heavy for tiny ones.

## Where public keys live in a vault

Vaults carry public PKI keys as immutable objects at `bare/keys/key-rnd-imm-*`, alongside the content store at `bare/data/obj-cas-imm-*`. They are public by construction, so nothing there needs protecting, which is exactly why a lane addressed by a public key can be written to by a stranger.

## What this is for

Signing and encrypting files is useful on its own. The larger use is [**vault-to-vault messaging**](vault-messaging.md): your public key becomes an address a stranger can write to, and your private key is the only thing that can read what arrives. That page composes this one with [append lanes](../api/append-lanes.md).

## What this does not do yet

- **No key revocation or rotation workflow.** There is no CRL, no expiry, no `sgit pki revoke`. If a private key is compromised, you generate a new pair and redistribute the bundle out of band.
- **No web of trust and no directory.** Fingerprint verification is your problem, compare out of band, exactly as with SSH host keys.
- **Fingerprints carry a `sha256:` prefix.** That prefix is part of the CLI identifier, not part of any hash you might need elsewhere. See the [addressing note](vault-messaging.md#addressing). It is a live source of confusion.
- **Signing and encryption are separate keys.** Passing the wrong fingerprint to the wrong verb fails; it does not fall back.

Honest edges belong on [the limitations page](limitations.md) too, and these are listed there.



==============================================================================
# Updates (sgit.ai)

> What changed on sgit and on this site, as it happens) one entry per story rather than per release, each linked to the release that carries it. RSS and JSON feeds included.
>
> Page: https://sgit.ai/updates/index.html

# Updates

What changed on sgit and on this site, as it happens, one entry per story rather than per release. The [version log](../admin/versions.md) is the complete technical record; this is the readable one.

Follow along: [RSS](feed.xml) · [JSON](updates.json). Every entry links to the release that carries it.

## 2026-09-21

### [The design is the performance, and the crypto is free](#the-design-is-the-performance) [v0.3.4](../admin/versions.md)

architectureperformancegraphsmethod

Two releases of [the performance page](../demos/fractal-graphs/performance.md) covered the mechanisms and buried the thing that actually does the work. Performance here comes from an architectural habit, and the habit is one question: **what data do I need for the task at hand?**

Not what the system holds. Not what the schema allows. What *this* question needs. Once that is the first question, most performance work stops being necessary, because the expensive thing was never the engine. It was loading data nobody was going to look at.

## Standing on three giants, none of them ours

The second half of the habit is refusing to reinvent what is underneath.

The **file system** is a high-performance indexed store with decades of tuning and the operating system's page cache in front of it. A **content-addressed hash store** sits on top: a name is a hash of the bytes, so a lookup is a path, deduplication is free, and a cache entry cannot be wrong. The **graph** sits on top of that, and it is the only part that is ours. It is also the part that decides how much a question costs, because it tells you which bytes to ask for.

And the fair version of the database comparison, which usually gets told unfairly in our favour: **a database is fast largely because it keeps the working set in memory.** That is not cheating, it is the same insight. The difference is who picks the working set. A buffer pool guesses it in advance, from access patterns, for every reader at once. We pick it per question, at the moment the question is asked, and throw it away afterwards.

## Measured, because the habit only works if loading is cheap

On the 1.0 MB file that holds the whole DSIT graph:

| Step | Time | Rate |
|---|---|---|
| Fetch over the network, cold | **1,210 ms** | the only number that matters |
| Read from local disk | **2.5 ms** | 418 MB/s |
| **Decrypt, AES-256-GCM** | **0.351 ms** | **2,978 MB/s** |
| Parse the JSON | 3.2 ms | the largest local cost |

**Decryption is 0.03% of the cold fetch and about a tenth of the JSON parse.** On a 59 KB shard it is 0.025 ms. Whenever somebody assumes encrypting the data must have cost something in speed, that is the answer: at these sizes, on ordinary compute, encryption is free and the network is everything. Which puts the question back where it belongs, on how many bytes you decided to ask for.

So the design rule, as a budget. Under 100 KB is an answer. Around 1 MB is a whole world. **10 MB and up means you are loading a store rather than an answer.** Gigabytes is a design error, not a performance problem, and no tuning will fix it.

## Save is where the loop compounds

The step people skip in LETS. Saving is not filing the answer away, it is leaving behind an artefact cut to the shape of the **next** question. The Article 9 slice in the Regulation Graph exists because somebody answered a question about Article 9 once and saved it in a form that makes asking again cost 29 KB instead of a megabyte. Do that a few times and the expensive queries have all been pre-answered, each by the run that first needed them, with nothing decided in advance.

## Restructuring into context is the compression

The fractal property is usually argued as a point about meaning. It is also a point about volume. Measured in the Regulation Graph vault:

| Altitude | Bytes | Against the level below |
|---|---|---|
| Raw Formex source, the law as published | 11,216,043 |  |
| The graph: 1,523 nodes, 1,944 edges | 1,073,915 | **10x smaller** |
| One article's pre-cut slice | 29,638 | **36x smaller** |
| The ontology, the rules of this world | 4,217 | **7x smaller** |

**11.2 MB down to 4.2 KB, a factor of about 2,660, with nothing thrown away**, because every level keeps the edge down to the one below. You query the small thing and follow the link only when the answer requires it.

Which is why this scales in the direction that usually breaks things. In a schema-first system, more data means a bigger index, more memory and a bigger machine. Here the store can be gigabytes or terabytes while **what a question loads stays in the megabytes, because the graph is what tells you which bytes matter.** Adding a terabyte adds nodes you did not load.

## A correction the measuring turned up

This page said 617 nodes and 694 edges, quoting the vault's page. The file as cloned today has **1,051 nodes and 1,289 edges** across five worlds, because the vault released 0.2.1 today and the graph grew. Every count on the page is now counted rather than quoted, and the drift was only visible because the vault keeps its versions instead of overwriting them.

### [That was a cold start, not an architecture cost](#that-was-a-cold-start-not-an-architecture-cost) [v0.3.5](../admin/versions.md)

architectureperformanceapimethod

Yesterday's [performance page](../demos/fractal-graphs/performance.md) put "cold network fetch, 1,210 ms" at the top of a table and let it stand as the cost of reading encrypted data. It is not. It is mostly the cost of a serverless invocation, which is a deployment choice with a known fix, and the page now says so.

## The fixed cost has nothing to do with bytes

Six runs each, best of run:

| One GET returning | Best | Median |
|---|---|---|
| 340 bytes | 0.331 s | 0.381 s |
| 41 KB | **0.309 s** | 0.390 s |
| 2.3 KB | 0.347 s | 0.530 s |
| 1.0 MB | 0.647 s | 0.992 s |

**A 340-byte response and a 41 KB response take the same time.** Only at a megabyte does transfer become visible, and then it is 0.300 s of the 0.647 s. One request in the run came back in 4.8 s, which is what a cold start looks like when you catch one.

So the floor of roughly a third of a second is the **per-invocation cost of running this API serverless**. SG/API also runs on EC2, where a warm process is already listening and that cost does not exist. We have not measured that deployment, so the page puts no number on it, but it no longer lets the invocation model be read as an architecture cost. Where the API runs is a deployment decision, and it is the right lever when a workload is request-heavy rather than byte-heavy.

## Batching is the answer, and the page was missing most of it

`POST /api/vault/batch/{vault_id}` takes **up to 100 operations in one request**. Measured on small objects so that only the per-object term shows:

| Objects in one batch | Best | Per object |
|---|---|---|
| 1 | 0.590 s | 590 ms |
| 2 | 0.394 s | 197 ms |
| 10 | 0.872 s | 87 ms |
| **18** | **1.528 s** | **85 ms** |

That is a straight line, and the line is the cost model worth carrying:

**time ≈ 0.25 s fixed + about 71 ms per object + transfer**

Eighteen objects fetched one at a time would be about 6.3 seconds. In one batch, **1.53 seconds, a little over four times faster**, and the saving grows with the count.

The endpoint also does more than reads, which the page had not covered at all. Operations are `read`, `write`, `write-if-match` and `delete`, authorised per operation, so a read-then-write cycle can be one round trip. And `write-if-match` carries the SHA-256 of the content you believe is there: **if any match fails, the entire batch is rejected.** That is optimistic concurrency across a set of files, in one request, with no lock anywhere.

## The next optimisation, named rather than glossed

71 ms per object inside a batch is server-side, and it is close to linear. That is the signature of objects being fetched from storage one after another inside the handler. Fetching them concurrently would bring a twenty-object batch close to the cost of a one-object batch.

That, and chunking by accumulated size rather than by file count so the 502 stops happening, are the two changes that would move these numbers most. Both are in the API and the client rather than in the design.

### [Take the API out of the path, and the same clone is 25 times faster](#take-the-api-out-of-the-path) [v0.3.6](../admin/versions.md)

architectureperformanceapistorage

The [performance page](../demos/fractal-graphs/performance.md) has been measuring the API and calling it the architecture. Worth saying plainly what that API is: **a convenience over a store, not a requirement of it.** The store is cloud storage holding encrypted objects whose names are hashes. Nothing stops a reader going straight to the bucket, or to a CDN in front of it, with no function in the path at all.

## The measurement

Same client, same vault, same 106 objects, same decryption. Only the path to the bytes changed.

| Path to the bytes | Full clone |
|---|---|
| Through the serverless API | **65.4 s** |
| **Plain GETs, no API in the path** | **2.63 s** |
| Straight off a local folder | 2.05 s |

**Twenty five times faster, with nothing about the vault changed.** The honest caveat: that static host was on localhost, so the network was free, and a real CDN adds edge latency. But the client, the objects and the work were identical in both rows, so what the comparison isolates is the function in the middle.

## It already ships

`sgit clone --transport static` points at any host that answers GETs. It sniffs which of two published layouts the host uses on the first successful read, then fans out **eight parallel requests at a time**. It also records every URL it touches, so a test can assert that no request ever carried key material, which proves the property rather than asserting it.

## Why it is safe to serve the bytes directly

Because there is nothing in them. Every object is ciphertext under a key the server never had, and every name is a hash of those bytes. Exposing them as ordinary public GETs discloses object sizes and request timing, which is the same exposure the API already has and which [the security model](../security/index.md) already names as an acknowledged side channel. It discloses nothing else. That is why reads need no auth header today, and why a bucket behind a CDN is a legitimate deployment rather than a hole.

## And the direct path is already in production

Anything over **4 MB** already takes it, because that is the safe margin under the serverless base64 response limit of about 4.7 MB. The client asks for a presigned URL and fetches the bytes straight from storage. The same route is the fallback when a batch returns 502.

So there are already two paths to every byte, and the only reason the small case goes through a function is that nobody has needed it not to. What follows from there is ordinary storage engineering: a CDN in front of the bucket, where immutable hash-named objects are the ideal cache key; ranged and parallel GETs, which is how a 100 MB or 500 MB object should be read; lower-latency storage classes such as S3 Express One Zone, which we have not benchmarked so there is no number on the page; or another provider entirely, since what is being served is opaque bytes at deterministic paths.

## Finding the object you want

Usually you already know the id, because it is pinned in the page. When you do not, the walk is short: the branch ref gives you the commit, which gives you a tree, which gives you the file or the next tree down. **A couple of requests, not a clone.**

Counted against the static host: reading one named file out of a sparse clone cost **two requests**, and one of those was the client re-probing which layout the host uses, a 404 it could skip by remembering the answer.

This is the thing git cannot do. Pulling one file out of a git repository generally means cloning it, because the objects are packed and the transport is negotiated. Here every object is individually addressable at a deterministic path, so one file is one request against a plain web server.

## One gap, stated outright

**There is no history-depth flag.** `--sparse` skips the content (256 KB, 7.3 s) and `--bare` skips the working copy, but a full clone still takes every version of every file: 106 blobs where the current tree is 42 files, and a sparse clone still walks all seven commits and twenty eight trees. Depth control is the single change that would most improve clone time.

### [Graph engineering versus fractal graph, the measured answer](#performance-and-cost) [v0.3.2](../admin/versions.md)

graphsarchitectureperformancecost

A reader of [the Fractal Semantic Graphs page](../demos/fractal-graphs/index.md) asked the follow-up that page had coming: what is the **performance** of this against ordinary graph engineering?

[Performance, cost, and running everywhere](../demos/fractal-graphs/performance.md) is the answer, and every figure on it was measured on 21 September 2026 from an ordinary cloud container against live published vaults, using the read keys printed on their own pages. Anyone can repeat the commands.

## The architecture the numbers come from

We run with **no live database**. A graph is a set of encrypted files in object storage, read directly. The engine that answers a question is created when the question is asked and destroyed when it is answered, either in the reader's browser tab or in a serverless function that exists for one request. The cycle is **LETS**: Load the bytes, Extract the slice and the ontology that explains it, Transform in a disposable engine, Save the answer as new immutable files.

Save never overwrites, and that one property carries the rest. Because every object is immutable, every cache in the path is correct forever, which is why there is no server: the hardest thing a database does for you, keeping one mutable truth consistent across readers, is a problem this architecture never creates.

## What it costs, measured

Against the [DSIT AI Risk Toolkit](../demos/vaults/dsit-ai-risk-toolkit/index.md) vault, 42 files, 3.2 MB, a semantic graph of 617 nodes and 694 edges:

| Operation | Time |
|---|---|
| Full clone, every file and the whole history | **65.4 s** |
| Sparse clone: every path, size and hash, no content | **7.3 s**, 256 KB |
| Fetch one file that answers one question | **0.49 s**, 59 KB |
| Fetch the entire graph as one file | **1.21 s**, 1.0 MB |
| Ask again for something already fetched | **0.18 s**, no network |

Cloning everything costs 65 seconds. **Answering a question costs 7.8 seconds and 315 KB**, and the second question costs under a second. Nothing was indexed in advance and no service was running before the command was typed.

In the browser, measured by recording every response, so these are exact byte counts: the landing view of that 617-node graph is **94 KB in three requests**. The graph view is 1.12 MB in five. No view loads the whole vault, because no question needs it. The ontology is **2 KB**, and 4,217 bytes in the larger Regulation Graph, which is the entire price of arriving in a new world and learning its rules. That is what makes the jump between worlds affordable rather than theoretical.

## The cost model, which is where the decision usually gets made

Zero instance hours. Zero replicas. Zero index memory. No separate backup line, because every version is already kept. No staging copy, because a clone is a clone. Storage and egress only, and query compute paid by the reader's own device.

The entire published estate on this site, thirty one vaults, is **2,662 files and 295 MB** of object storage. **Cost scales with what is read, not with what exists, and not with time.** Scale to zero is normally a property you give back the moment you attach a database, because the database is holding the state. Here the state is in files, so the zero is real.

## Running everywhere, including inside somebody else's boundary

The same artefact runs in a browser tab, a terminal, a serverless function, a CI container and a static host with no backend, on one read key and nothing installed. That is also the fractal deployment story: the deployment unit is a set of files and a key, so putting a graph inside a regulated environment or an air-gapped machine is a copy rather than a project, and two organisations can join their graphs by exchanging an edge and a read key without either one adopting the other's schema.

## And six places it is slower

The page would not be worth sending if it only listed wins. Full clones are slow. There is no server-side query, so whatever the client needs, the client downloads. Cutting good slices is real work that moves query time to build time. Writes are single writer per branch. Revocation is not retroactive.

And one a graph database wins outright: six hops across a hundred million edges in a single schema is exactly what it was built for. The fractal argument is about the case where those hundred million edges were never going to live in one schema in the first place.

### [One request, an append lane, and a cache full of ciphertext](#one-request-append-and-ciphertext-caching) [v0.3.3](../admin/versions.md)

architectureperformancecryptocaching

Yesterday's [performance page](../demos/fractal-graphs/performance.md) answered the question it was asked and left out the three things that make the architecture fast in the first place. They have been measured and added.

## Reading an encrypted file takes one request

The property most people do not expect, because encryption usually implies a lookup. It does not here.

**The address is derived, not discovered.** Every file id is produced by HMAC-SHA256 over the read key under a named domain, `sg-vault-v1:file-id:ref`, `:branch-ref`, `:branch-index`, from the same constants in the CLI and in the browser client. A client holding the read key computes the address of the ref, the index and the settings **before issuing any request at all**. There is no discovery round trip, which is the cost that usually dominates a small read.

Reading is then a plain CORS GET with no auth header, because the bytes are useless without the key. Measured against a live vault:

|  |  |
|---|---|
| One object, no headers | 2,364 bytes of ciphertext, **0.86 s** |
| A larger object | 59,324 bytes, **0.63 s**, best of five 0.33 s |
| Five objects, one POST | **0.87 s**, one round trip |
| **Twenty objects, one POST** | **3.76 MB in 2.79 s**, one round trip |

Encryption costs a flat **28 bytes per object**, a 12-byte nonce and a 16-byte tag, the same whether the file is two kilobytes or two megabytes. No percentage overhead to budget for.

### Which corrects yesterday's clone number

The transport returned 3.76 MB in 2.79 seconds, so the 65-second clone needed a better explanation than the one v0.3.2 gave. The clone log has it: seven commits, twenty eight trees and **106 blobs** rather than 42 files, because a full clone takes the history too, and then one batch of fifty hit the server's response-size limit and fell back to fetching those fifty one at a time. That is a client-side chunking bug, chunk by accumulated size rather than by file count, and not a property of the architecture. The page now says so.

## Append mode: writes that never touch the graph

A lane lives at `bare/append/{token}/pending/`, **outside the version-controlled commit tree**. A write is one account-less POST with the token in the body: no session, no read-modify-write, no commit, no tree rebuild, no lock, no merge. It never conflicts with a push, and it never contends with a read, because a reader walking the graph never looks at a lane. The response is deliberately blind, so the server does no extra work composing it and leaks nothing by size or timing. Several anchors means several lanes, so one flooding sender cannot bury another.

## Caching encrypted data, which is the easy case

Two reasons, and they are the same reason.

**The cached bytes are ciphertext**, so a cache is not a trust boundary. The browser cache, IndexedDB, a CDN edge, a corporate proxy and a local clone can all hold vault objects without widening exposure by one byte. **And the name proves the bytes**: an `obj-cas-imm-` id is SHA-256 over the ciphertext, so an entry under that name can never be stale and can never be wrong, which is why no invalidation logic exists anywhere. Mutable refs are the exception, and their failure is silent: a stale ref renders an old commit from ciphertext that is itself perfectly valid.

## A high-performance site running on exactly this

[sgraph.ai/en-gb/library/](https://sgraph.ai/en-gb/library/) is a public knowledge base whose content does not exist on its web server. A **270 KB static shell**, 28 KB of HTML plus 242 KB of CSS and components, and every article, nav entry and blog post comes out of two encrypted vaults and is decrypted in the visitor's tab. The server cannot read a word of what it serves.

Its blog entries pin their content-addressed object ids in the page source, so opening one is a single GET straight to the bytes. Its navigation is deliberately **not** pinned and resolves HEAD to tree to blob at runtime, so it stays current. Both choices are in its source with the reasoning attached. Its cache script keeps immutable objects in IndexedDB so later page loads need no network at all, collapses concurrent callers for the same URL into one request, and labels every response it serves.

## And a gap found while measuring

Our own [caching contract](../api/vault-objects.md) says an immutable object is served with `Cache-Control: public, max-age=31536000, immutable` and a ref with `no-store`. Today the read endpoint returned **no `Cache-Control` header at all** for an immutable object, and the CDN reported a miss.

The mechanism is unaffected, because a client cache that keys on the id rather than trusting a header is the more robust design and is exactly what the library site ships. But the documented header is not live on that path, and the page that documents it should not be read as describing what is currently served.

## 2026-09-20

### [The newest vaults were at the bottom of the table, and at the top of the machine list](#vault-table-order) [v0.2.99](../admin/versions.md)

vaultsbuildmethod

[The published-vaults table](../demos/vaults/index.md) opened at #26 and ended at #30. Three bugs behind one symptom.

**The table read file order.** Its own docstring claimed *"the rows ship newest-first in the HTML"*, but the generator loaded `vaults.json` directly and rendered it as written. The four most recent vaults had been appended to the end of the file rather than inserted at the top, so they rendered last.

**The machine list was right, which is worse.** The generator for [`/demos/vaults/llms.txt`](../demos/vaults/llms.txt) sorted by ordinal. So the human table and the machine list have disagreed for four releases, on a page whose own footnote says the two are generated from the same file and therefore cannot drift.

**And one found on the way.** The routine that lifts each read key out of its vault page knew the legacy prefix and the private one, but not `sgit_public_read_`. The two keys [relabelled yesterday](../updates/index.md) were being republished in the machine list stripped of the declaration they had just been given.

## One order for the whole site

`_vaults()` now sorts newest-first and every caller reads it, so there is one ordering rather than one per consumer. It also asserts what makes the ordinal trustworthy as a sort key: unique, running 1 to N with no gaps, and in the same order as the published dates. Both assertions were tested by breaking the data on purpose, and each fails the build by name.

The homepage is untouched: its hero row and its job bands use a hand-curated order, which is exactly why nobody noticed this there.

### [The vault named after the concept was not on the concept's page](#the-vault-named-after-the-concept) [v0.2.96](../admin/versions.md)

graphsvaultsmethod

Asked whether the GitHub repository `VoiceDebrief/VoiceDebrief__Fractal-Semantic-Graphs` was in the collection, the answer was yes. It is the plaintext mirror of [vault #11](../demos/vaults/voice-debrief/index.md), `k6xy9z4d`, published here on 22 August. Cloning both and comparing showed the repository's 90 content files matching the vault's HEAD file for file, and both last moved on 10 August.

What was missing was the reverse link. [Fractal Semantic Graphs](../demos/fractal-graphs/index.md) walked seven graph vaults and never cited the one that carries the name. That vault holds the fifteen-principle register the definition comes from (P4 *everything is a node*, P6 *fractal descent*, P7 *the junction rule*, P11 *altitude*, P15 *structure points down; meaning radiates out*), the leading brief of 6 August whose one sentence says what the page took five revisions to reach (*"each level is the same operation applied to a larger span, which is what makes the structure fractal rather than merely nested"*), and a notation spec with two laws worth carrying everywhere: every statement must read aloud as a sentence and decompose into triples, and every statement must link to the span it compresses, because *"claims from memory are not allowed anywhere in this system."*

A new section, **where the idea was worked first**, quotes all of that in a principle-to-page table, credits the Article 9(2) example in the zoom diagram to the vault that works that provision to exhaustion, and adds the vault to the table of vaults to open.

**The vault's own page gains a mirror section.** The vault practises its own guide: plaintext tree and encrypted store side by side on GitHub, `local/` gitignored. Three consequences are stated. The content is public twice over, so the read key adds the history and the app, not access. The repository is a snapshot, not a live mirror, and will drift if the vault moves and it does not, which is the failure this site's own mirror had before it was retired. And the encrypted store is safe in the open for the reason the guide gives.

### [We published read keys under a prefix that declares them secret, and an agent refused to open them](#the-prefix-said-private) [v0.2.98](../admin/versions.md)

keyssecuritydocsagents

An agent asked to inspect the two AIUC-1 vaults declined, and said so plainly: their credentials are labelled private read, despite being published on sgit.ai, and it would not work around that restriction.

**It was right. Our label was wrong.** The sgit CLI defines three current prefixes and states which is which in its own source: `sgit_private_vault_` is a write credential, `sgit_private_read_` is read-only and *kept secret*, and `sgit_public_read_` is read-only and *deliberately published*. Seven published credentials across [the AIUC-1 conformance layer](../demos/vaults/aiuc-1-conformance/index.md) and [the AIUC-1 catalogue](../demos/vaults/aiuc-1-graph/index.md) carried the middle one. They now carry the right one, with a dated line on each page saying what changed and that the bytes, the access and the vault are identical.

**Verified before relabelling**, on sgit-ai v0.16.2: the bare form, the legacy prefix, the private read prefix and the public read prefix all clone the same 699-file vault; an all-zeros key under the same prefix produces nothing; and the SG/Vault web loader strips all five prefixes in its own format module.

## The structural fix matters more than the seven strings

The validator now **bans both current private prefixes in tracked files**, using the same trailing-character rule the write-key tripwire already used: documentation can print a prefix as a name, a real key fails the build. And `check_credential.py` learned the public prefix and now **refuses** the private read one. That credential is read-only and leaks no capability, and it is still not publishable, because the label says the opposite of what publishing it does.

## The page that was missing

[Vault credentials](../docs/credentials.md) explains this for the first time: the two capabilities and the one-way derivation between them, drawn; the five prefixes in a table with publish-or-not on each row; why classification is by declaration and never by shape, which is the CLI's own hard-won lesson; why the word matters when the bytes do not; and what a read key can and cannot do, including that revocation is never retroactive.

**Not done, and a decision to make:** 99 published keys across 27 pages still carry the legacy `sgit_rk1_` prefix. That one is neutral rather than wrong, so normalising it is a consistency call, not a correction.

### [The em-dash is gone from the prose, and so is the legacy key prefix](#no-more-em-dashes) [v0.3.0](../admin/versions.md)

writingkeysbuildmethod

Two site-wide normalisations, each with a guard so they stay done.

## 3,200 em-dashes, rewritten rather than deleted

A good many readers now find the character off-putting, so it is gone from every sentence on the site. This was not a find-and-replace. A rewriter classified each occurrence by its context and chose the punctuation the sentence actually wanted: brackets or commas around a parenthetical pair, a colon before an explanation, a full stop with the next word capitalised where the tail was an independent clause, and a comma otherwise.

Code was left alone by construction, and the same exclusions are now written into the validator so the two agree: `pre`, `code`, `svg`, fenced and inline markdown code, inline script, the assets folder, the skills folder (upstream artifacts shipped verbatim) and the board, which is rendered from a vault this site does not author.

**Four bugs, found by checking rather than assuming.** A whitespace tidy reflowed the ASCII diagrams inside `pre` until it was made mask-aware. The pair rule bridged adjacent table cells, leaving seven brackets that opened in one cell and closed in another, each caught by a balance check and fixed by hand. The try page's JavaScript compared against placeholder text the markup no longer had, which would have broken its terminal. And a colon reads badly in front of a conjunction, so 35 of them became commas.

## The legacy key prefix, and a brief that closed itself

102 published read keys carried `sgit_rk1_` and 24 carried no prefix at all. All of them now carry `sgit_public_read_`, which declares the intent rather than leaving it unstated. Only real keys were rewritten, so the documentation that names the legacy prefix still names it.

The bare ones were bare for a reason worth recording: the prefixed form used to **fail on the CLI**, which has been an open brief to the CLI team since August. Re-running [the comparison suite](../compare/index.md) today closed it. All six checks pass on sgit-ai v0.16.2, including *prefixed clone succeeded*.

### [The article that introduces Fractal Semantic Graphs, published here with its pictures](#introducing-fsg-article) [v0.2.97](../admin/versions.md)

graphsarticlesfractal-semantic-graphs

[Fractal Semantic Graphs: everything connects to everything, and nobody has to share a schema](../articles/introducing-fractal-semantic-graphs.md) is the introduction to the term, written for LinkedIn from [the page that defines it](../demos/fractal-graphs/index.md). LinkedIn cannot carry the diagrams, so this is the canonical copy: the same text, with nine figures placed where the prose earns them.

The three diagrams from the page are rendered as images (the zoom, the jump, the ladder). Beside them sit the screenshots the argument rests on: the GDPR atlas at altitude zero with its own *you are at the top of the fractal* panel, the Regulation Graph's hash-verified landing view, the AIUC-1 explorer with two vaults on one canvas, the ThreatModCon zoom ladder, the role risk map, and Article 45's timeline of rulings over an article that has not changed a word since 2016.

The bare URLs at the end became links, and the vault where the idea was first worked, [VoiceDebrief · Fractal Semantic Graphs](../demos/vaults/voice-debrief/index.md), joins the list. The article is CC BY 4.0, as written.

### [Vault #31 reaches the same conclusion about fractality, in its own words](#dsit-ai-risk-toolkit) [v0.3.1](../admin/versions.md)

vaultsgraphsgovernmentmethod

[The DSIT AI Risk Toolkit](../demos/vaults/dsit-ai-risk-toolkit/index.md) is an independent reference edition of the UK government's AI Risk Management Toolkit, and it is the first vault submitted under the `sgit_public_read_` prefix that [the credentials page](../docs/credentials.md) now asks for.

It models the guidance, the official workbook, the risk method and the cited frameworks as **four separate worlds with named bridges**: 617 nodes, 694 edges, eight predicates, every one of which declares an inverse. And the first of its four declared limits is this:

"Containment alone is not fractality. Cross-world edges make the semantic transitions inspectable."

That is the correction [the fractal graphs page](../demos/fractal-graphs/index.md) made yesterday, reached independently by another author in another vocabulary. The page now cites it, and the ladder gains a rung.

## The honesty is the other reason it is here

Every edge is labelled **curated** or **lexical**, with the limit written down: *"lexical mentions are not validated meaning."* Five source snapshots are retained with their URLs, retrieval dates and SHA-256, and two of its eight checks exist only to prove the official spreadsheet's bytes were not touched.

It publishes six gaps about itself. It corrects its own earlier count, to 208 formula cells from 227, and keeps the earlier briefing rather than overwriting it. It preserves a contradiction in the source instead of resolving it: the official file is named v1.1 and its own Welcome sheet says v1.0, so both labels stay. It leaves two broken defined names broken, because repairing somebody else's document is an edit. And it declines the flattering reading, stating that starter rows are not evidence of adoption.

**Audited before the key was published:** no credentials, no personal data, two published DSIT institutional contacts, the Open Government Licence acknowledged, official status disclaimed, and an all-zeros negative control that produced no clone where the real key produced 42 files.

## 2026-09-19

### [The site's own vault mirror is gone, deleted, purged from history, force-pushed](#the-mirror-is-gone) [v0.2.84](../admin/versions.md)

workflowgitmethodvaults

For 76 releases this site was one folder that was both an sgit vault and a git repository, and every release pushed both. Today the vault mirror was **removed from the tree, purged from all 112 commits with `git filter-repo`, and the branch force-pushed.** The repository went from 276 MB to 21 MB.

The question that led here was asked at v0.2.83: *do we still need it?* The honest answer was no, on four counts.

- **It had no reader.** Every session that built the site cloned it from GitHub. Not one release was ever produced from a vault clone.
- **It had no published read key.** The site publishes read keys for thirty vaults; its own was the one nobody could open. A zero-knowledge mirror of public content that nobody can read is storage, not publication.
- **It had been dead since v0.2.76, and nothing noticed.** The container holding the write key was recycled, `.sg_vault/local/` is gitignored by design, and seven releases went out over git alone with the live site correct throughout.
- **It was 91% of the repository.** 258 MB in 15,933 files, against 24 MB of content in about 750.

The purge is safe for the same reason the mirror was: everything removed was ciphertext under a key that was never in the repository. The vault itself, on the server, is untouched.

## What changed on the site

[The case study](../case-studies/one-tree-two-remotes.md) is now a retrospective, the workflow as it ran, the boundary that made it safe, the ordering rule, and a *why we stopped* section with the numbers. Every other page that described the pattern as current was rewritten: [why](../why/index.md), [admin](../admin/index.md), the [git-and-vaults](../docs/vault/git-and-vaults.md) note, the release-engineer role and prompt. Historical release notes stay as the dated records they are.

The tooling followed. `release.sh` no longer requires `.sg_vault` or pushes sgit, it still pulls the board vault first, and still refuses to call a release done until sgit.ai serves the new version. The key-leak tripwire now reads demo vault write keys from a gitignored `admin/local/demo-keys/` folder instead of the dead vault's local tier. And the [release history](../admin/versions.md) switches its commit column to git ids from v0.2.77 onward, which filled the seven rows the missing key had left blank.

## The three Vaults-menu pages were stale too

- [Demos](../demos/index.md) listed three vaults as *published* when there were thirty, and its *coming next* pointed at a plan already delivered. It now leads with the gallery and keeps the three original walkthroughs as what they are.
- [The catalogue](../catalogue/index.md) renders a vault live, and that vault holds **nine** entries against the gallery's thirty. The page now says so, with the date, and names [the gallery](../demos/vaults/index.md) as the complete list until the catalogue's key holder catches up. This is a write-key problem, not a publishing one: the twenty-one missing vaults are live on their own pages.
- The gallery's footer stopped calling the catalogue the place *new entries start*, because for twenty-one of them it was not.

**The rule that came out of it:** give a mirror a reader before giving it a remote. The board vault earns its place because the release pulls it and a page renders it. The site's own vault never did.

### [The jump, what the fractal property actually adds](#the-jump) [v0.2.95](../admin/versions.md)

graphsmethodcorrection

The Fractal Semantic Graphs page said that in a hierarchy *depth gives you more detail but no new meaning, because the only verb is "contains"*. The author's objection came in four parts, and all four are right.

A single layer's ontology can have a very large number of verbs, each carrying meaning. As long as the links make sense inside that ontology, knowledge is gained one link at a time, and it is a great deal of knowledge; a risk register with ten thousand well-named edges is not a hierarchy and not yet a fractal. **What the fractal architecture adds is the ability, on one of those links, to jump into another universe** with its own rules and definitions. And what makes that fractal is that every such self-contained world is built from the same blocks: nodes, edges, ontologies, taxonomies, triplets, provenance.

[The test section](../demos/fractal-graphs/index.md#what) is rewritten on the worked example he gave: a risk register whose incident fact jumps into security operations (alerts, signals, ATT&CK techniques, attack trees), whose suspicious DNS entry jumps into the DNS estate (zones, records, every request the resolvers logged, possibly millions of nodes served through an abstraction layer over SQL, a graph database or GraphQL), whose one record jumps into a packet capture. Four worlds, four ontologies, one path of named edges. A third diagram draws it.

Two consequences follow, in his words. **Every connection you follow should teach you something**, even when the answer is *nothing to see here*; whether a link added value is for the observer, or the query, to decide. And **more granularity means a better representation of reality**, chosen per context, with custom views on top of the whole being what makes it scale. It also runs upward: all four worlds are one node in a bigger graph, and the schema itself can be fractal in the Mandelbrot sense.

### [The root llms.txt was pointing agents at two 404s, and burying the guidance it should lead with](#llms-txt-routing) [v0.2.83](../admin/versions.md)

llmsagentsdocsmethod

Asked to check that an agent reading [`/llms.txt`](../llms.txt) finds the newest guidance, the answer was that **coverage was complete and routing was broken**.

Everything was in the file, the generator adds every page. But [the guidance front door](../docs/guidance/index.md) sat at line 149 of 239, as page entry 83 of 138, indistinguishable from `installation.md`. Meanwhile the orientation block at the top still said *"task-shaped guidance with recipes and agent briefs lives under /use-cases/"*, which is where that guidance lived **before** it moved to `/docs/guidance/` and `/docs/briefs/`. And none of the six scoped `llms.txt` files were advertised, so an agent reading the root had no way to learn that `/docs/guidance/llms.txt` or `/demos/vaults/llms.txt` exist.

Fixed with a **START HERE, BY WHAT YOU ARE DOING** block before the page list: four entry points by intent (building a vault, choosing a surface, writing a viewer, looking for a worked example) plus the list of scoped indexes.

## Two broken links, found by the guard rather than by reading

The routing block is hand-written prose naming generated files, which is exactly the drift this site keeps warning about. So the build now asserts that **every path the preamble points at is a file the build actually produces.**

It failed on the first run, and on the most important line in the file:

*"Never write a vault key into a tracked file. See `/docs/exposed-vault-key.md` for what that costs."*

That page is at `/case-studies/exposed-vault-key.md`. The advice about the costliest mistake in the product had been pointing at a 404. Widening the guard to every section then caught `/security.md`, referenced twice, where the page is `/security/index.md`.

Both were 404 on the live site, and the site's own validator had never looked, it checks links *inside pages*, and `llms.txt` is not a page. A file that exists to be read by machines had never been link-checked by one.

**Also corrected:** the preamble claimed this site *"is itself served from an encrypted vault."* The vault mirror last moved at v0.2.76 and six releases have gone out over git alone, so the claim came out rather than being left to rot.

### [The ladder's right column looked like links and was not, now it is](#ladder-links) [v0.2.88](../admin/versions.md)

graphsdesign

Second read of [Fractal Semantic Graphs](../demos/fractal-graphs/index.md), two fixes.

The *why this page exists* note, the LinkedIn back-story, is gone. The page stands without it.

The ladder diagram's right-hand column was long blue monospace text that read as a row of links nobody could click. Each rung now has two lines: the vault's name as a **real link** to that vault's page, where its read key is, and the detail beneath it in plain grey. Twelve links, each tested by clicking it in a browser and checking where it landed. The rule it re-learns: if it is blue, it must be clickable; if it is not clickable, it must not be blue.

### [How far down does the graph go? A page for the question that got three bare URLs](#how-far-down-does-the-graph-go) [v0.2.85](../admin/versions.md)

graphsvaultsmethodnetwork

Asked on LinkedIn whether we had *"defined the dimensions/layers needed to map this all the way down to say the EA and system configurations"*, the author answered with three links. The answer was right and the form was poor. [How far down does the graph go?](../demos/fractal-graphs/index.md) is the same answer with the pictures.

**The ladder.** Eleven altitudes from the text of a law to a compute instance, drawn as one diagram, each rung mapped to the published vault where that altitude is a live graph you can open: the [Regulation Graph](../demos/vaults/regulation-graph/index.md) for the law, the [Standards Atlas](../demos/vaults/standards-atlas-gdpr/index.md) for the layer the text omits, the [AIUC-1 conformance layer](../demos/vaults/aiuc-1-conformance/index.md) for the standard, its evidence and the policy it computes, the [Risk Graph Explorer](../demos/vaults/risk-graph-explorer/index.md) and [Agentic Browser Isolation](../demos/vaults/agentic-browser-isolation/index.md) for fact, risk, owner and acceptance, and [ThreatModCon 2025](../demos/vaults/threatmodcon-2025/index.md) for the eleven linked threat models that reach a method, a source file and a runtime.

**The rule.** One grammar at every rung, every edge a verb with a named inverse, `relates-to` banned, properties carrying data and never meaning, supersede rather than delete, which is what makes *fractal* a testable claim rather than an adjective. The GDPR atlas says it in its own graph view: *"You are at the top of the fractal."*

## The screenshots are new, and real

The atlas refuses to run outside a vault host. So a read-key clone was served locally behind a shim that implements `sg.vfs` over `fetch`, and its graph view was captured at three altitudes: the Regulation and its eight domains, then *Principles* and Article 5's seven, then one principle with its provenance. Nothing about the rendering changes between the levels; only the question does. [The vault's page](../demos/vaults/standards-atlas-gdpr/index.md) gained those views too.

## The honest section

The bottom four rungs (environment, runtime, compute) are modelled layers, not imports from a CMDB or an infrastructure repository. No published vault holds an enterprise-architecture repository as a graph joined upward to obligations; that is the rung the page cannot yet point at. The AIUC-1 crosswalks resolve at article level only. The GDPR atlas is a dated seed pass and uses the banned `relates` edge six times, counted from its own `graph/edges.json`. standards.sgit.ai models one instrument and has zero crosswalks. abp.sgit.ai's 23 capability primitives are the right shape to attach to a real permission set, and nothing published yet does. Named gaps get filled.

## Also fixed

The footer on every page still read *"this site is itself served from an encrypted SG/Send vault."* It has been false since the mirror died at v0.2.76, and was never true of the deployed pages, which GitHub Pages has always served. It now says what is true: thirty vaults open in your browser with published read keys, and the pages that describe them are static files.

### [Fractal Semantic Graphs, the page now leads with the definition](#fractal-semantic-graphs-defined) [v0.2.87](../admin/versions.md)

graphsmethoddocs

The author's first read of yesterday's page made three points, and all three were right. *How far down does the graph go?* is a section, not a title. The page must start by defining and visualising the term. And the first screens must work for a visitor who knows graphs, semantic graphs and ontologies but has never met the idea of a **Fractal Semantic Graph**, which for a while went by *graphs of graphs of graphs* and *ontologies of ontologies of ontologies*.

[The page](../demos/fractal-graphs/index.md) is now titled **Fractal Semantic Graphs** and opens with the definition in three sentences: a semantic graph is nodes joined by verbs with named inverses; a fractal one is a graph where every node is itself a semantic graph built by the same rules, down to the smallest thing that still matters to the question, in most of our work a word, a number or a symbol.

**The diagram.** Three panels of inline SVG: a four-node semantic graph; the Law node zoomed into articles and paragraphs, with an amendment drawn as an edge rather than a footnote; one paragraph zoomed into the terms it uses, each one edge from the article that defines it. The rules are the same in all three, which is the whole point, and the test for the word follows: *if zooming into a node needs a new format or a special case, the system is hierarchical, not fractal.*

**Why connect everything with everything.** Because every file format is already a graph (a PDF, a spreadsheet, a codebase, a JSON document) and only needs its edges named. Then questions cross formats without a join table, a correction propagates instead of being republished, the smallest node is whatever the question needs rather than what the format offers, and provenance comes free when the leaf is a word tied to a byte range and a hash. The discipline that keeps this from being noise: the edge has to be a verb.

A four-word table closes the opening (graph, semantic graph, ontology, fractal semantic graph) with what each adds and where it stops. Everything from *How far down does the graph go?* onward is unchanged.

### [Fractal means the inside is different, not the same. The definition had it backwards](#fractal-means-different-not-same) [v0.2.89](../admin/versions.md)

graphsmethodcorrection

Two releases ago [Fractal Semantic Graphs](../demos/fractal-graphs/index.md) defined the term as a graph where *every node is itself a semantic graph built by the same rules*, and gave the test as *if zooming into a node needs a new format or a special case, the system is hierarchical*. The author's read of the page caught that this is the wrong way round.

**Same types, same verbs, same rules at every level is a hierarchy.** A folder tree is the clean case: folders inside folders inside folders, one schema all the way down, and the deeper you go the less you learn. **It becomes fractal at the moment zooming in lands you somewhere different** (a node whose inside has its own node types, its own verbs, its own taxonomy, a new format or a special case) and that new world is still joined by an edge to the one above. Graphs of graphs, ontologies of ontologies. The plural is the point.

What stays constant is the **grammar**, never the schema: edges are verbs with named inverses, meaning lives in connectivity, every claim keeps its provenance. That is exactly what lets everything connect to everything without anyone being forced to conform. An organisation, a division, a single person, a regulator can each define their own world in their own vocabulary and connect to everyone else's by declaring edges, not by adopting a shared schema. And granularity becomes a decision per situation: a paragraph can be a mini-world with more definition than the document around it, because somebody needed it there and nowhere else.

The page is rewritten accordingly, lead, definition, the diagram's captions (panel two is now a legal ontology, panel three a lexical one, and the footer reads *the grammar never changes; the ontology does*), the test, the four-word table, and the ladder's intro: *eleven altitudes, eleven ontologies, one grammar.*

**One wording to pass upstream.** graphs.sgit.ai's boundaries page states the test with the word *format*. Read as "stops being a semantic graph and becomes JSON-plus-prose" it agrees with this page; read as "schema" it says the opposite, and this page read it the wrong way first. It should say *grammar*. Recorded on the page with the date rather than silently corrected.

### [Deleting files from git history, the exact scenario, drawn out](#deleting-files-from-history) [v0.2.86](../admin/versions.md)

gitworkflowmethodsecurity

Yesterday's purge of the vault mirror raised the right question: *did the force push actually happen, and what exactly did it do?* It did, git reported `+ e70d582d...b5ae665d dev -> dev (forced update)`, and [the new case study](../case-studies/purging-history.md) writes the whole scenario down with diagrams.

**The setup.** One folder that was both an sgit vault and a git repository; a remote with two branches, `dev` and a working branch from August that had been merged and forgotten. **What we wanted gone:** everything under `.sg_vault/`, 15,933 files, 91% of the repository, in every one of 112 commits.

**Why `git rm` is not deletion.** Every commit is a full snapshot, and a blob lives as long as any commit points at it. Removing the folder at the tip leaves 111 snapshots that still carry it; a clone downloads them all. **What the rewrite does:** `git filter-repo` rebuilds every commit without the path, and because a commit's id hashes its tree and its parent, not one of the 112 ids survived. **Why the push had to be forced:** the remote's tip is not an ancestor of the new tip, so a normal push is refused; `--force-with-lease` pinned to the old id makes the overwrite a compare-and-swap rather than a stomp.

## The part people miss

Git keeps every object reachable from *any* ref. The forgotten branch still pointed at the old chain (68 commits with 6,191 encrypted files in its tree) so after the force push a fresh clone still downloaded the purged objects, old commit URLs still rendered, and a single `git fetch` re-imported the lot into a clean clone. We verified that by doing it. Forks and `refs/pull/N/head` are the two places a branch deletion does not reach.

**When the branch is deleted,** three things happen on three timescales: fresh clones stop receiving the chain immediately; old ids stop resolving when GitHub's garbage collection runs, on its schedule or on request to Support; and clones made before the deletion keep the objects forever. That last one is why a history rewrite is never the first step for a leaked secret. Rotate, then rewrite.

**Recorded plainly:** the branch deletion was refused three times by the session's git proxy and is pending in the GitHub UI. Until it is done, the "still downloadable" section of the page is true as published. Everything purged was ciphertext under a key that was never in the repository, which is what makes this housekeeping rather than an incident.

### [A brief for graphs.sgit.ai, in place of a footnote](#brief-for-graphs-sgit-ai) [v0.2.94](../admin/versions.md)

graphsnetworkbriefs

The Fractal Semantic Graphs page carried a small footnote saying that graphs.sgit.ai had the fractal test backwards. The author asked for the footnote to go and for a proper brief in its place, since the sgit.ai page is now the fullest worked application of that site's two theses, *meaning through connectivity* and *thinking in graphs*.

[The brief](../docs/briefs/graphs-sgit-ai-fractal-semantic-graphs.md) quotes the boundaries page's own table and shows it contradicts itself: the Recursion row says *identical rules, no new format, no special case*, while the author's quote two paragraphs below says an article may be *so meaty that it requires its own ontology and taxonomy, and that's the power of the fractal element*. The quote is the side to keep. Replacement text separates the grammar, which survives every zoom, from the ontology, which is free to change at each.

It then lists what to adopt (the name and its lineage, the precise form of the thesis for the fractal case, *the deeper you go the more you learn*, *nobody is forced to conform*), where to link the page, what to reuse (both diagrams, the Standards Atlas screenshots), the four graph vaults missing from their evidence estate, a second cross-vault finding, three small corrections, and what not to change. The prompt to paste is at the end.

## 2026-09-18

### [Vault #30, the same pack, written for an archetype instead of a company](#the-same-pack-for-an-archetype) [v0.2.82](../admin/versions.md)

vaultsmethodprivacy

[Vault #30](../demos/vaults/fractional-ciso-pack/index.md) is a sibling of [#29](../demos/vaults/interim-ciso-pack/index.md) from the same generator, one day later, a fractional CISO pack: two days a month, on a retainer, for a company that is already certified. The interesting thing is how it solves the publication problem.

**#29 described a real role and withheld the company.** That meant auditing whether an unnamed FTSE 250 client could be inferred from what was said about it. **#30 describes a type of company instead**: six rows derived from public sources: what it does, who buys it, where the risk sits, what it already has, what it usually lacks, who governs it, and everything after follows from the archetype. There is nothing to redact, because nothing was ever about an instance.

The rule that generalises past hiring: **a document written for a class can be published; a document written for an instance has to be scrubbed.**

Three things are new. An **engagement document** with the monthly rhythm, a twelve-month map, and a section headed *what two days a month is not*, not cover, not a DPO, not delivery, not an audit, and not a substitute for a full-time CISO once the company needs one, *"part of the job is saying when that point arrives."* A **one-page infographic** rendered from `content.json` rather than drawn separately, which is the page's hero because it is the pitch on one sheet. And the three 2019 decks, now rendered in the viewer rather than only archived.

The *Honest tensions* section does something a sales document rarely does, it names how the offer could be misused against the buyer: a fractional CISO is cheaper than a permanent one, *"and that same economy can be used to defer a hire the company genuinely needs. Naming the trigger early is the only honest defence."*

Audit run and stated on the page: no company named or implied, no rate or tax status (*retainer* appears as a word with no figure attached), one public email, no secrets, read key verified against an all-zeros control. The two packs are worth reading as a pair, the same machinery giving two answers to *how do you publish a document about a job*.

### [The summit sheets get a preview grid, and their numbers are dated rather than corrected](#summit-sheets-preview-grid) [v0.2.81](../admin/versions.md)

publishingmethod

[The four Lisbon handouts](../summit/index.md) now appear on the parent page as four A4 previews (page one of each printed sheet, rendered from the PDF at build time and shown as a card) so a reader sees all four at a glance and clicks through to the page with the table, the embed and the download.

**The author's call on the stale vault count.** Yesterday's release made a point of *"26 public vaults"* having become 29 during summit week. The author's instruction is that the sheets are a dated record of what was said in September 2026 and should be kept as printed. So the correction became a dating note: the figures are those that were true when printed, [the live table](../demos/vaults/index.md) is the current answer, and the sheets are the historical one.

That is the right call, and the reason is worth writing down: **a printed artefact that gets silently re-edited to match today stops being a record of anything.** Date it, keep it, and point at the computed thing beside it.

## 2026-09-17

### [The Lisbon summit sheets, as pages, and as the PDFs they were handed out as](#the-lisbon-summit-sheets) [v0.2.80](../admin/versions.md)

publishingmethodnetwork

Four audience sheets written for a startup summit in Lisbon, [founders](../summit/founders.md), [startups](../summit/startups.md), [investors](../summit/investors.md), [corporate](../summit/corporate.md), are now [on the site](../summit/index.md), with a parent page, one page each, and the PDF both embedded and downloadable.

**The PDF is the download, not the page.** The capability table is rendered as real HTML, because a PDF is invisible to a search engine, to `llms-full.txt` and to any agent reading this site, the same argument [the deck viewer](../docs/briefs/vault-decks-on-a-site.md) makes. The handout stays a handout; the content is a page.

**What makes them worth publishing rather than filing** is the *what exists today* column, which is unflattering on purpose: *"no payment link"*, *"not yet packaged as its own product"*, *"research design; implementation not claimed"*, *"write-only intake built, never sold"*. A capability sheet that cannot say which rows are unfinished is a brochure.

Two things the check turned up, both while the sheets were still being handed out:

- **The filenames say RiskMandate.ai; the contents say sgit.ai.** Every page inside is branded sgit.ai and every footer points at `sgit.ai/network`. The copies here are renamed to match what is in them.
- **"26 public vaults" is now 29.** True when printed; three vaults were published during the week of the summit. The pages here do not restate the number and link [the live table](../demos/vaults/index.md) instead.

Which is the rule worth extracting from a stale line on a printed sheet: **a printed artefact should point at a computed one for anything that moves.**

### [A job application as a vault, and the privacy audit published beside it](#a-job-application-as-a-vault) [v0.2.79](../admin/versions.md)

vaultsmethodprivacy

[Vault #29](../demos/vaults/interim-ciso-pack/index.md) is an interim CISO candidate pack delivered as an encrypted vault instead of a CV attached to an email.

**The idea worth stealing is that the pack is the evidence for its own claim.** It says the candidate works with a team of AI agents and ships encrypted, versioned artefacts, and it *is* one. A reviewer does not have to believe the claim; the thing in their hands is the test of it. That idea is portable and has nothing to do with hiring.

Three structural choices are worth copying:

- **Split at the front door, not inside the document.** The recruiter gets a submission summary to copy and answers to screening questions, the things they actually have to paste into a form. The company gets eleven sections, two of them *Before signing* and *Tensions*. Anyone else gets the skills map and the history. Three readers, three routes, none of them a compromise.
- **Ship the machine-readable copy beside the human one.** Each of the four documents exists as PDF, Word, Markdown **and JSON**. The JSON is the one that matters: a CV as structured data, so a machine reading the pack gets fields rather than a page to parse. Same instinct as an `llms.txt`.
- **Let the build enforce the contract.** The pipeline fails if the page declares a vault resource, uses `fetch()`, writes `location.hash`, references a missing file, or contains a JavaScript syntax error, the last being exactly the check that [caught a shipped bug on riskmandate.ai](../demos/vaults/synthetic-users-riskmandate/index.md) the day before.

## The audit is on the page, not merely performed

The pack was submitted with a stated position: nothing sensitive, the company not identified, material already public. That is exactly the kind of claim that should be checked rather than accepted, so it was, and **it holds**.

The client is not named anywhere, described only as a FTSE 250 company, with regulatory applicability raised as open questions rather than answered. Day rates and the off-payroll analysis are absent, removed before publication, and the removal is **disclosed in the brief's own editor's note**, which is the harder and better choice. No phone, no address, one long-public email, no credentials. The read key was verified against an all-zeros negative control.

One point is stated rather than waved through: **thirteen named third parties** appear in the recommendations with their 2019 job titles. They are public twice over, LinkedIn recommendations, republished in the candidate's own CC BY-SA 2019 deck, which ships inside the vault so the source can be checked. They are labelled `title_2019` throughout. This site quotes the pack's own framing and does not reproduce the individual recommendations, which stay where their provenance is stated.

## 2026-09-16

### [The synthetic-user method runs a second time, and the second run is the better argument](#synthetic-users-second-run) [v0.2.78](../admin/versions.md)

vaultstestingagentsmethod

[Vault #28](../demos/vaults/synthetic-users-riskmandate/index.md) applies [#27's method](../demos/vaults/synthetic-users/index.md) to riskmandate.ai, one day later. That is the point: **one run is an anecdote, two sites is a method.**

It is not a repeat. The first vault **narrated**; this one **measures**: words above the fold, character offsets, scroll positions in pixels and screens. And more confusion from fewer steps (12 from 30, against 10 from 43) is the number to look at: the first site lost people slowly, this one lost them on the first screen.

**The headline finding is that the product is never named where it is sold.** Above the fold the home page says *policy* six times, *insure* three times and *underwriters* once, shows a £5 price, and never says **Agent Behaviour Policy**, which first appears **58% of the way down**. Two of the five read *"Buy one, from £5"* as buying an insurance policy for five pounds. The one who held that reading longest was the insurance professional: the reader best equipped to recognise the vocabulary, and therefore the most confidently wrong.

**A claim that specific is checkable, so it was checked.** The live page was fetched, rendered at the same 1440×900, and measured independently of the vault. Every structural number reproduces to the character: 9,270 characters of page text, first mention at 5,387, 6,481px and 7.2 screens, zero mentions of the product's name above the fold. Two count lines differ, and the page says *why* rather than hiding it: a broader `insur*` pattern that also catches "insurance", and one word at the fold boundary.

**The most useful finding in it is not an opinion.** The first pass recorded a JavaScript error on *every page it visited*. Both had shipped; the insurance page had been broken since it launched. As the vault puts it: *"every existing test passed, because the HTML still rendered and only the console knew."* Fixed in the same session, with a test added that parses every inline script on every page and fails the build if one does not. A study justified by its qualitative output paid for itself on a defect that has nothing to do with users, because the method happens to require driving a real browser and recording what it throws.

One persona, **Priya Raghavan**, walks both vaults. A persona reused across products is what turns two separate studies into a comparison, and it costs nothing but keeping the records in the same shape.

**Noted, not fixed:** the site's sgit vault mirror is behind its git mirror. The container holding the write key was recycled, `.sg_vault/local/` is gitignored by design, and the last two releases have gone out over git alone, which is what deploys the site, so the live pages are correct. The vault copy needs one `sgit push` from someone holding the key.

## 2026-09-15

### [Synthetic users, five people who do not exist, shopping](#synthetic-users) [v0.2.77](../admin/versions.md)

vaultstestingagentsmethod

[The 27th vault](../demos/vaults/synthetic-users/index.md) is the most useful one published here that contains no real data at all. Five invented buyers were walked through store.sgit.ai one screenshot at a time, asked what they made of each screen, and interviewed at the end: **43 steps, 15 questions the site did not answer, 10 recorded confusions, and 18 findings, three of them costing a sale.**

**The idea worth stealing is a deliberate handicap.** The agent is handed the *screenshot*, never the DOM, and the vault says why in one sentence: *"an agent that drives a store by reading the DOM finds the buy button every time, and therefore finds no confusion, which is the only thing worth running this for."* Competence at finding the button is the thing standing between you and the finding, so it is removed on purpose.

Three more things make it a method rather than an anecdote. The protocol is published **inside** the vault, so two runs a month apart are comparable rather than merely sequential. *Where did you guess* is a required field. And a run with no confusion anywhere is treated as a run done badly, not a site that passed.

**Read the viewport column.** The persona carrying the largest decision a single person makes alone on that site did the whole thing on a **390-wide phone**, and produced the most questions and the most confusion of anyone. The vault never states that. It falls out of the table once all five runs are counted in one place, which is the argument for putting runs in a vault instead of a document.

Zero page errors across all five runs, which is worth saying because it means none of the confusion was a bug in the store's code. It was the copy.

**Four findings are already marked fixed and kept rather than deleted**, on the stated grounds that *"a findings list that loses the fixed ones cannot be compared with the next set of runs."* The best of those fixes answered a request for a number with a disclosure instead: the page now says the time from a buyer's reply has never run for a paying buyer, so there is no measurement to quote. A synthetic user asked for a figure and got the harder, more honest answer.

**On the credential.** What was submitted was a **vault key**, not a read key. It was classified before it touched anything, the read key was derived one-way from it, and only the derived key is published, the vault key is not on this site and will not be. The derivation was proved rather than assumed: the derived key produced 67 files and a `clone_mode.json`, and an all-zeros key against the same vault id produced an empty directory. [That control exists](../demos/vaults/publishing.md) because we once called a leak on a directory an invalid key had created identically.

## 2026-09-10

### [The transfer API gets documented, and a dangling reference closes](#the-transfer-api-gets-documented) [v0.2.76](../admin/versions.md)

apitransferssecuritymethod

The team that owns the SG/Send API wrote an integration guide for sending an encrypted bundle to SG/Send from an agent workflow, and asked whether it belonged on this site. Checking rather than assuming turned up something worse than a missing page.

**The reference named a header for an API it never described.** [The authentication page](../api/authentication.md) has always listed `x-sgraph-transfer-delete-auth` among its six headers, *"transfer deletion, SG/Send transfers, not vaults"*, while the API section documented **zero transfer endpoints**. And the section's own lead called it *"the protocol surface"* while covering one of the two families that share this host. A reader following that header had nowhere to go, and a reader trusting that lead was being told something untrue.

[**The transfers page now exists**](../api/transfers.md), the header links to it, and the lead says plainly that two families share the host.

## What was taken, and what was not

The protocol is canonical and belongs here:

- **The two secrets that must never be confused.** An *access key* authorises **you to upload** and lives in a header. A *decryption key* authorises **anyone to read** and lives in the URL fragment, everything after `#`, which no browser sends to the server. They are unrelated values, and that distinction is the whole reason a share link can be both shareable and private.
- **The SGMETA envelope**, which exists so the filename never reaches the server: magic bytes, a big-endian length, the metadata JSON, then the file, wrapped *before* encryption, because the other order produces a corrupt download with no name.
- **The two traps in the create body**: `expires_at` is in **milliseconds**, not seconds; and `max_downloads: 0` means **unlimited**, not none.
- **The `download_url` that returns 404.** `complete` hands back `/d/{id}`, which is not a live route, build the share link yourself.
- **Revocation is opt-in at create time and impossible afterwards.** No `delete_auth_hash` when the transfer was created means that transfer can never be deleted.

The workflow half (credential wiring, node shapes, one product's bundle layout) stays with the product it was written for. It is good material; it is not protocol.

## The editorial contribution is knowing when not to use a vault

The page opens with a **transfer or vault** decision table, because restating someone else's endpoints adds nothing. What this site can usefully say is the other thing: a transfer has no history, hands over the whole payload or nothing, expires, and can be revoked. **A vault is the wrong answer for a handover that happens once**, and the API team reached the same conclusion independently for their own flow, which is worth more than either of us asserting it alone.

**Their verification is attributed, not adopted.** Every status code on that page was executed by them against production on 9 September 2026. We have not re-run it, the page says so, and the date is the thing to check it against.

## 2026-09-09

### [The shorts page rewritten for someone who arrives with no context](#the-shorts-page-rewritten-for-a-cold-arrival) [v0.2.66](../admin/versions.md)

vaultsvideoriskmandatemethod

A page of videos is a landing page whether or not it was designed as one. Traffic reaches [the seven shorts](../demos/vaults/licence-to-operate/videos/index.md) from a feed, lands on it directly, and has never seen the vault, this site, or the argument. What sat above the seven players yesterday was an apology about missing transcripts and a note explaining why a row number in the vaults table could not go stale, two pieces of internal housekeeping, both written for a reader who already knew everything the page had to sell.

Both are gone from the first screen. In their place, in the order a cold visitor needs them:

- **Four words, and the gap between two of them.** Grant, mandate, delta, licence to operate, defined in a table with the counts from the demo beside each: **12** capabilities in the grant, **4** in the mandate, **8** in the delta, and a licence priced per turn. The whole model is now legible before a single video plays.
- **Open the thing the videos are showing.** [The Licence to Operate vault](../demos/vaults/licence-to-operate/index.md), with its read key printed as the complete credential and both routes offered, its page here, or straight into the vault UI.
- **Where this goes commercially.** [RiskMandate.ai](https://riskmandate.ai/) named on the page: the business risk layer for autonomous systems, every autonomous system mapped to its blast radius, given a business owner, and driven to a time-bound decision, *accept, fund, or fix*. The vault is the demonstration; RiskMandate is the product it demonstrates; [the Risk Graph Explorer](../demos/vaults/risk-graph-explorer/index.md) is the same engine already published as a vault.

**The transcript gap is not hidden, it is right-sized.** It is still stated, in one sentence in the footer, and [board card T12](../team/board.md) is still open. A gap worth disclosing was not worth the first screen. The page was leading with what it lacks instead of what it shows.

Nothing changed about the seven videos, their order, or the three movements they fall into.

### [The llms.txt stops being a URL you have to guess](#the-llms-txt-stops-being-a-url-you-guess) [v0.2.73](../admin/versions.md)

llmsdocsagentsmethod

Six `llms.txt` files are published across this site, [the site-wide map](../llms.txt), [the vault catalogue](../demos/vaults/llms.txt), [the guidance entry point](../docs/guidance/llms.txt), and one each for [`/docs`](../docs/llms.txt), [`/docs/vault`](../docs/vault/llms.txt) and [`/api`](../api/llms.txt). Until now the only way to find one was to type it onto the end of an address and hope.

**Every page now carries a chip above its title** naming the one that covers it: *for agents*, the path, and the version and date it was generated.

Resolution is deepest-folder-wins. A page under `/docs/vault/` points at that section's index rather than at `/docs/llms.txt`; a page with no closer index falls back to the site-wide one. So every page has exactly one, and it is always the most specific one that exists.

**The stamp is the point, not decoration.** These files are regenerated on every release, so the chip says which release produced the index a reader is about to fetch. An agent editing a page can see at a glance whether the index has caught up with the page, if the page changed and the stamp did not, it has not.

Two details worth recording. The chip is **chrome, not content**, emitted between the nav and the page body, so it never reaches the markdown twins and cannot drift from them. And a **build assertion** now fails the build if the chip ever points at a folder no generator actually writes, which is precisely the failure this feature would otherwise have introduced quietly.

**Caught by building it.** The guidance page still *said* `/guidance/llms.txt` in two places, because [yesterday's move](../updates/index.md) relocated the file to `/docs/guidance/` and the rewriter fixed the `href` but not the prose around it. The page linked correctly while displaying a path that 404s. Fixed, and a reminder that a link rewriter fixes links, not sentences.

### [The build brief for putting a vault's decks on a website](#the-build-brief-for-decks-on-a-site) [v0.2.69](../admin/versions.md)

briefsvaultsdecksagents

Two releases documented this from the inside: [reading one file out of a vault](../docs/vault/reading-a-vault-file.md) explains the mechanism, and the deck pages demonstrate it. Neither told another agent how to do it to *their* vault. [**That brief now exists.**](../docs/briefs/vault-decks-on-a-site.md)

It follows the shape of [the telemetry brief](../docs/briefs/vault-telemetry-append-lanes.md), the shape that worked, because another team's agent built a vault from it and then sent back a review that corrected it.

- **The contract a vault must publish.** Where the manifest may live, deck sources pushing `t` / `notes` / `html` onto `S`, screenshots named symbolically rather than pathed, the CSS in the shell's style block, the PDFs. Plus the fallback for a vault that published only its built decks.
- **The rule that governs the design**, stated as a test anyone can apply: *a vault must be able to change what is shown and never what the page does.* If a vault can add a button, change where a link goes, or read anything belonging to the host page, the split is wrong.
- **The two frames, with their exact CSPs**, and the detail that a deck source must be handed to the parse frame over `postMessage` rather than baked into a `srcdoc`, or a deck containing the characters that close a script tag breaks out of the bootstrap running it.
- **Why a decrypted PDF cannot go in an iframe at all**, with the console message Chrome actually emits.

**It publishes both bugs, not just the finished design.** The image-name pattern that excluded underscores and failed silently on fifteen slides; the unscoped `closest()` that killed every button on exactly the pages it was written for. A brief that only describes the working version teaches less than one that names the two places a careful implementer will still go wrong.

It ends with a done-means checklist, walk every slide and assert zero unresolved images, byte-count a downloaded PDF against the vault, grep the built site for vault-key shapes, and a prompt to hand the builder agent.

One thing caught in review, worth recording because it is the third time: the `.md` twin rule strips inline code spans but not fenced blocks, so tag names inside the prompt failed the build. Rewritten to the site's uppercase-placeholder convention.

### [The agent chip becomes one object, and the network list catches up with the org](#the-agent-chip-and-the-network-catches-up) [v0.2.74](../admin/versions.md)

designnetworkllmsagents

**The chip.** [Last release](../updates/index.md) put an `llms.txt` link on every page, and it worked but looked like three loose fragments (a pill, a boxed path, and a long sentence) floating in the dead space between the nav and the breadcrumb, belonging to neither. Four directions were drawn against the site's own tokens and one was chosen: **a single bordered control** with a tinted *for agents* cell, the path in mono as the only emphasised element, and the version and date behind a dashed rule. It now reads as one thing you can click rather than three things you cannot.

The always-on sentence moved into the link's tooltip. It renders on all 124 pages, and as visible text it was instruction noise sitting above every headline on the site, the stamp beside it already carries the point.

**The network list was eight sites behind.** Checked against the organisation's 31 repositories rather than against memory: **games**, **what-can-it-do.games**, **providers**, **ungovr.providers**, **elevenlabs.providers**, **teams**, **threat-modeling** and **chrome-extensions** all had repositories, all answered 200, and none of them was listed here. Each new entry is written from what that site says about itself (its own title, description and version, fetched) rather than from a guess about what it probably contains. [The network](../network/index.md) now lists 27.

Two corrections fell out of the same check:

- **skills.sgit.ai** was still described here as *"the repository and subdomain exist; GitHub Pages has not published yet, so there is nothing to read at the address."* It has been live for some time. The entry now carries its real thesis (*skills are software packages, and here is the proof*) and its version.
- **The ElevenLabs repository describes its domain as `elevenlabs.provider.sgit.ai`**, singular. That does not resolve; the live host is `elevenlabs.providers.sgit.ai`, plural. The listing uses the one that answers.

A list of sites maintained by hand drifts from the sites that exist. This one drifted by eight in about a week, worth a check against the org on every release rather than when somebody notices.

### [Seven shorts on the Licence to Operate vault, indexed, and put in the right order](#seven-shorts-on-the-licence-to-operate) [v0.2.65](../admin/versions.md)

vaultsvideoagentsrisk

The author recorded seven vertical videos walking through [the Licence to Operate vault](../demos/vaults/licence-to-operate/index.md). None of them was on the site. [They now have a page](../demos/vaults/licence-to-operate/videos/index.md), collected in the order they are meant to be watched rather than the order a feed shows them:

- **The mechanism** (1–3), grant against mandate, what a block looks like when an agent exceeds its mandate, and how risk cascades from the support team to the CFO.
- **The artefact** (4), how to find and open the vault. The shortest one, and the one to send someone who wants to poke at it themselves.
- **The model** (5–7), why the grant/mandate gap is where risk lives, the insurance framing that governs it, and the policy, claim and premium mechanics underneath.

Each carries the author's own description plus a line mapping it to what it demonstrates: the **delta** for 5, [the AIUC-1 conformance layer's](../demos/vaults/aiuc-1-conformance/index.md) insurability query for 6, and risks.sgit.ai's *there is no deny button* for 7.

**What the page refuses to pretend.** These are descriptions, **not transcripts**. All four of YouTube's `timedtext` endpoints return empty for every one of the seven, so there is no caption track to pull, and the words actually spoken are absent from this site, from `llms-full.txt`, and from the chat pane's `read_page` tool. That is precisely the failure [the Risk Graph Explorer walkthroughs](../demos/vaults/risk-graph-explorer/videos/index.md) page was built to avoid, so the gap is stated in a box at the top, measured rather than guessed, and opened as board card T12.

**A number that cannot rot, demonstrated by accident.** Video 4 tells the viewer to look for *"Vault #23"*. Checked against the table: Licence to Operate is still #23, and always will be, v0.2.58 made that column a permanent publication ordinal rather than a row position. A recorded video naming a row number would have been wrong within a day. Naming an identity is safe, and this is the first time that decision has paid for itself.

Embeds go through `youtube-nocookie.com` with `loading="lazy"`, so opening the page sets no YouTube cookie until somebody presses play. The players needed new 9:16 CSS, the existing embed box is 16:9, and a Short in it is two black pillars.

### [One front door for vault guidance, and every document moved under /docs/](#one-front-door-for-vault-guidance) [v0.2.72](../admin/versions.md)

docsguidancevaultsmethod

The guidance here had accumulated across three top-level folders, `/briefs`, `/vault`, and a `/guidance` page written this morning. That is three places to look for one kind of thing. **Everything readable now lives under `/docs/`**: [`/docs/briefs`](../docs/briefs/index.md), [`/docs/vault`](../docs/vault/index.md), [`/docs/guidance`](../docs/guidance/index.md), beside the CLI docs that were already there.

Fourteen pages moved. The links were rewritten by resolving each one through the move map rather than by prefixing `../`, a blanket prefix would have broken every link that stayed *inside* the moved subtree, which was most of them. No redirects, by instruction: the estate is in flux and has few external users. One thing nearly went missing: two hand-written `.md` briefs live only in the built output and not in the content tree, so the cleanup deleted them; they were restored from git into the new location before anything was pushed.

## The front door

[**Working on a vault: start here**](../docs/guidance/index.md) is the page that did not exist. The first thing on it is the guidance that gets repeated to agents more than any other:

**Version everything, show the version, link what changed.**

The number belongs in the app chrome (small, always visible, not in a footer or an About box) and it must link to *that version's own details*, not to a generic changelog. A reader who clicks `v0.1.7` wants to know what v0.1.7 was. Versions live in the vault as `versions/index.json` plus one file per version, each naming the commit it was built from and saying whether it was recorded or reconstructed. [The AIUC-1 conformance vault](../demos/vaults/aiuc-1-conformance/index.md) is named as the reference implementation, because it already does exactly this.

Seven more practices follow, each stated with the failure that produced it, including the one about negative controls, which exists because `sgit clone` creates a directory whether or not the key is valid, and we once called a leak on a directory an all-zeros key produced identically.

## The agent-shaped twin

[`/docs/guidance/llms.txt`](../docs/guidance/llms.txt) is the same thing for an agent: five rules, a reading order, the briefs, and reference implementations to go and check rather than take our word for. It ends with edges out to **coding.sgit.ai**, **nfrs.sgit.ai** and **graphs.sgit.ai**, because a page about vaults should not also try to be the style guide, the resilience argument, or the grammar of semantic graphs. Each of those has a site with room to do it properly, and an agent that stops at this domain gives a worse answer than one that follows the edge.

The page closes by saying why it is mostly links, which is graphs.sgit.ai's own thesis applied to the thing you are reading:

"A node is just a node. **Meaning lives in the edges.**"

Three properties keep that working, and they are worth preserving in anything built here: every page is reachable and has a `.md` twin, with the build failing on an orphan; indexes are generated from the data they index, so [the vault catalogue](../demos/vaults/llms.txt) cannot disagree with the table it comes from; and each site says one thing properly and links out rather than summarising the rest badly.

### [The second build brief, and it mostly says don't build it](#markdown-and-file-viewers-what-not-to-build) [v0.2.70](../admin/versions.md)

briefsvaultsagentsmethod

Two of the most common things an agent is asked to add to a vault are a **markdown viewer** and a **file/folder browser with raw views**. Both already exist in the vault platform, and most requests for them are answered by publishing files in the right shape and writing no code at all. [**The brief now says so.**](../docs/briefs/markdown-and-file-viewers.md)

It is a decision rather than a syntax reference, [the syntax reference already existed](../docs/vault/content-authoring.md). A four-rung ladder, with the instruction to stop at the first rung that works:

1. **Publish `.md` files.** The browse view renders them and its file tree *is* the folder viewer.
2. **Add a `_page.json`** if you need a designed page rather than a document, and use its `markdown` component to pull in the `.md` files you already wrote, so the prose exists once.
3. **Build an app** only when a view has to *compute* something the host cannot know.
4. **Build a site viewer** only when the content must live outside a vault host, [the decks brief](../docs/briefs/vault-decks-on-a-site.md) covers that case.

It names the markdown rules that actually catch people, rather than the full syntax: raw HTML is stripped and shows as escaped text, images size through the pipe syntax inside the alt text, folder links must go through `folder/README.md` because a bare folder link resolves by sort order, and nested and task lists are unsupported.

**The raw-view contract comes from a vault that already lives by it.** [The AIUC-1 conformance vault](../demos/vaults/aiuc-1-conformance/index.md) has a file explorer, and its own source states the principle better than a brief could:

"Raw is the point, a catalog that asks to be trusted has to be readable in the form it was written."

The brief adopts that whole: raw always available for every file, a reader as an addition and never a replacement, the tree driven by a build-time manifest rather than a runtime walk, files fetched on click. Generalised, it is a habit that runs through the whole estate, `_page.json` has its `{ } Source` toggle, every page on this website has a `.md` twin, the deck viewer offers the printed PDF beside the rendered slides. **Anything rendered should be one click from the thing it was rendered from.**

One correction made while checking the schema: the content-authoring page said *eleven* component types and then listed twelve. It says twelve.

### [Guidance now splits by surface, and the third surface finally has its own brief](#guidance-splits-by-surface) [v0.2.71](../admin/versions.md)

briefsdocsvaultsmethod

The guidance here had been organised by **task**: decks, markdown, file viewers. That hid something: every one of those questions has three different right answers depending on *where the code runs*.

[**Three surfaces**](../docs/surfaces.md) is the router. `_page.json` inside a vault, an HTML vault app inside a vault, and a page on a `*.sgit.ai` site outside every vault host, compared on where they run, who reads the vault, which credential is used, what the reader needs, whether search engines and agents can see them at all, and the row people get wrong:

**Trust direction.** Inside a vault host, the host protects the reader: it sandboxes the app, gates permissions, keeps a sovereignty rail the app cannot suppress. On a site page there is no host, *you* are the host, and vault bytes are untrusted input arriving in your origin. The same content, the opposite posture.

A second table does the same job the other way round: markdown, file browsing, decks, PDFs, computing over data, and being findable by someone who has never heard of you, which only one of the three surfaces does at all.

**[Reading a vault from a site page](../docs/briefs/sgit-ai-site-pages.md)** is the brief that did not exist, for whoever is coding the estate's sites. It leads with the enabling fact, which is easy to miss: the vault API answers **plain CORS GETs with no auth header, from any origin**. The server can afford that because what it returns is ciphertext under a key it has never held, so a page on `graphs.sgit.ai` or `risks.sgit.ai` reads a published vault directly, with no proxy and no backend.

It then says **do not write the reader** and names the four house files to copy instead, `vault-embed.js` exports the reader so nothing has to reimplement the derivations, `vault-docs.js` is the instrumented version, `vault-deck.js` a worked viewer, `vault-ui-embed.js` frames the official UI. It states the inverted trust rule with a table of how to render each kind of vault content, covers the ref-caching trap that fails *silently* by rendering an older commit from perfectly valid ciphertext, and says what should not go on a site page at all: duplicated vault prose, a rebuilt vault app, and any arrangement where the site is the only way to read the vault.

Six guidance pages now carry a **surface label** above their title, so the distinction is visible where someone actually lands rather than only on the router. Unlabelled pages apply to all three.

### [Decks and PDFs read straight out of a vault, with the viewer owned by the site](#decks-read-straight-out-of-a-vault) [v0.2.67](../admin/versions.md)

vaultsdeckssecuritymethod

The vaults publish presentations. Four of them sit in [the AIUC-1 conformance vault](../demos/vaults/aiuc-1-conformance/index.md#decks) and five in [Licence to Operate](../demos/vaults/licence-to-operate/index.md#decks), and until this release the only way to see one was to open the vault's own app and drive it. They now play on the vault pages themselves, fetched as ciphertext with the read key already printed at the top of each page and decrypted in the reader's browser.

**The split is the whole point.** From the vault come the manifest, the slide sources, the speaker notes, the screenshots and the printed PDF. From the site comes every control you can click, the deck tabs, the slide list, prev and next, the notes toggle, the PDF button, the deep links. A vault decides what is *shown*; it never decides what the page *does*.

That matters because a read key is public, but the bytes behind it were written by whoever holds the write key, so vault content arriving in a page is untrusted input. It reaches these pages through two opaque-origin frames and nothing else:

- **A deck has to run.** It builds its slides by calling `S.push({t, notes, html})`, so it executes in a sandboxed frame with `default-src 'none'` and posts back a plain array. The site never evaluates it.
- **A slide does not.** Its markup renders in a second frame with `allow-scripts` withheld entirely and a CSP whose only permitted load is a `data:` image the host decrypted itself. Nothing in a slide can phone home.

**Why the PDF is a download and not an embed, measured, not assumed.** The obvious move is to decrypt the PDF, wrap it in a blob and point a sandboxed iframe at it. Chrome refuses, in every sandbox combination tested: *"failed to load as a plugin, because the frame into which the plugin is loading is sandboxed."* The browser's PDF viewer is a plugin and plugins do not run in sandboxed frames. Dropping the sandbox would work and would hand vault bytes this origin, which is the one thing the design exists to prevent. So the bytes are decrypted in the page and handed to the browser's own download instead, a 2.1 MB deck arrives byte-identical, while the slides, the thing anyone actually wants to read on a web page, render live.

**A real bug, found by walking everything.** The first pattern for image names excluded underscores. Fifteen slides in the Licence to Operate decks therefore rendered with a silently missing screenshot: no error in the console, no gap in the layout, just an absence nobody would notice by clicking through a few slides. The browser test now walks all 113 slides across all nine decks and counts missing images; the count is zero.

Two published deck shapes are handled, because the two vaults genuinely differ (one shipped its deck sources, the other only its built decks) so the reader prefers the source and falls back to the built file, truncated where the vault's own viewer begins.

New page: [**Reading one file out of a vault**](../docs/vault/reading-a-vault-file.md), which is the primitive underneath every live embed on this site, written down on its own for the first time, with the sandbox rules for what comes back.

### [A page per deck, a focus mode, and a vault catalogue an agent can read](#a-page-per-deck-and-a-catalogue-agents-can-read) [v0.2.68](../admin/versions.md)

vaultsdecksllmsmethod

Yesterday's release put the decks on the vault pages. Three things were missing, and this release adds them.

**A page per deck.** Each of the nine published decks now has one, [four under the AIUC-1 conformance vault](../demos/vaults/aiuc-1-conformance/decks/index.md), [five under Licence to Operate](../demos/vaults/licence-to-operate/decks/index.md). A deck page opens that deck alone, tab strip gone, and carries what the slides cannot: the level it answers, the vocabulary it introduces, who it is for, where it deliberately stops, the question it ends on, and which deck picks that question up. Each also has a **Notes on this deck** section that is deliberately empty and says so, that room is the whole reason a deck deserves a page rather than a tab, and it is where a narrated recording will be linked once one is mapped to a deck.

**Focus.** A button that drops the slide list so the stage takes the full width, for presenting, and for recording a screen capture where the chrome is just noise. The stage is re-fitted rather than merely revealed, so the slide actually gets bigger.

**A bug the new pages exposed within a minute of existing.** The mount element carries `data-deck` on a single-deck page, and the click router used an unscoped `closest('[data-deck]')`, so it matched the mount element for every click inside the viewer and returned early. Prev, next, notes, focus and the PDF button were all silently dead, on exactly the pages just built. Nothing threw; the buttons simply did nothing. Scoped to the tab strip, and caught because the browser test asserts on the *effect* of clicking rather than on the click landing.

**A catalogue an agent can read.** [`/demos/vaults/llms.txt`](../demos/vaults/llms.txt) is the published-vault catalogue as an agent index: all 26 vaults with id, category, published date, size, file count and published read key. It is generated from `vaults.json`, the same file [the vaults table](../demos/vaults/index.md) is built from, and each read key is lifted from the vault's own page rather than kept in a second list that could disagree with the first. Read keys are the whole credential for reading and are published deliberately; vault keys appear nowhere, here or anywhere else.

Three more sections got their own: [`/vault/llms.txt`](../docs/vault/llms.txt), [`/api/llms.txt`](../api/llms.txt) and [`/docs/llms.txt`](../docs/llms.txt). An agent pointed at one part of the site now gets that part's index instead of the whole map.

### [A brief for the vault map infographic, which spends its first half on why not to start with the picture](#a-brief-for-the-vault-map-infographic) [v0.2.75](../admin/versions.md)

briefsvaultsdesignmethod

An image model produced an infographic of the `*.sgit.ai` sites, one shared foundation, five numbered columns, a band of conceptual links, a footer of counts. It is good. The ask was for a companion covering the **26 published vaults**, grouped by use case and industry. [The brief now exists](../docs/briefs/vault-map-infographic.md), and it leads with the two things that sit upstream of any image being generated at all.

**The picture it copies has already gone stale.** The network infographic's footer reads *"19 sites · 18 published · 1 forthcoming"*, and its cell for `skills.sgit.ai` says *Forthcoming*. [The network](../network/index.md) now lists **27**, and skills.sgit.ai has been live for some time. A picture roughly a week old is wrong in its headline number and in one of its cells.

That is not an argument against making one. It is the constraint to design around. So: every count computed from the data at generation time; the image stamped with the version and date, the same way [every vault app should carry its version](../docs/guidance/index.md#versions); the live table linked beside it, because the infographic is the overview and [the table](../demos/vaults/index.md) is the truth; and regeneration on the release checklist as a diff, if the vault count changed, the image is stale.

**Neither requested grouping exists in the data.** Checked rather than assumed: `vaults.json` carries `category` on all 26 (but that is the vault's *shape* (Application, Analysis, Record, Reference…), not its use case) `job` on only **6 of 26**, and **no `industry` field at all**. So the first deliverable is two fields, not an image: `use_case` and `industry`, written from each vault rather than from its title, with closed vocabularies the build enforces, and `cross-industry` treated as a real answer rather than a sector invented because a vault mentions money.

That is the same rule the rest of the estate runs on, indexes are generated from the data they index, because one maintained by hand becomes a lie on a schedule.

**Then the rules for a model that renders text as shapes.** Generate the caption list from the data first and treat the image as a rendering of it; read every string back against `vaults.json`, character by character on the names; count the cells; and let no vault appear that is not in the file, a plausible invented name is the most dangerous output this process can produce, because nothing throws.

And the publishing rules this site already imposes: the validator bans `img src`, so the `data-shot` pipeline applies; alt text is the accessible equivalent, not a caption; and the grouped list goes on the page as HTML beside the picture, so the markdown twin carries the substance instead of a reference to pixels.

## 2026-09-07

### [Two new sections, the team, written for the agents; and investors, in the open](#the-team-for-the-agents-and-investors-in-the-open) [v0.2.62](../admin/versions.md)

teamagentsinvestorsboardmethod

**[The team](../team/index.md)** is the agentic section: how this site is run by one person and a team of AI agents, written for the agents. A new agent should be able to read that page and one role page and begin.

- **Nine roles, each a file.** Sherpa, Publisher, Auditor, Journalist, Cartographer, Ambassador, Designer, Release engineer, Historian, mirroring the Explorer team in the CLI repository, specialised for running a site rather than building a tool. Each page carries the role's mission, what it owns and must not touch, the files it works in, the checks it runs, **the rules it enforces with the mistake that produced each one**, and the prompt that starts it from nothing. The Publisher and Auditor exist because this site publishes read keys on purpose and has to be certain what they reach.
- **[Twelve starting prompts](../team/prompts.md)** for the work that recurs, publish a vault, audit it, write the update, write an article, add a sibling site, handle an inbound brief, cut a release, fix a phone bug, turn markup into data, correct a claim, update the board, re-verify the read keys. Each is written to be pasted into a fresh agent, and each ends before the release step on purpose: the release engineer's prompt is the one that ships, and the Sherpa decides when it runs.
- **[The board](../team/board.md)** is a kanban of files. Each card is a markdown file with a `status` line; the five columns are those lines rendered. **Needs**, items only the author can supply, are kept apart from tasks and never discovered late. This follows issues-fs.sgit.ai's *issues are files* and the open comms board on open-source.sgit.ai. It is seeded with the real open work, including six things only the author can answer.

**[Investors](../investors/index.md)** follows the founder's practice of publishing investor material in the open, and the structure of the pitch his other companies publish: the problem, what it is, the open-source zero-knowledge architecture, traction, business model, the beachhead market, what could go wrong, and the materials. Two rules hold it honest:

- **Traction is computed from the site**, with the same generator the homepage team band uses. If a number is wrong, the site is wrong somewhere else too.
- **The ask is left visibly open.** Round size, instrument and use of funds are the founder's to state; the page has a dashed box saying so and tracks it as board item N1, rather than a number nobody supplied.

The business-model section does not restate the founder's position on open source; it points at it through the new sibling-site card, so the argument is read in its own words.

**Nav:** *Try* folds into Docs; *Why* becomes a group with Investors; *Team* is new. Eight top-level items, as before.

One build lesson, recorded because it bit twice: angle-bracket placeholders inside code spans broke the markdown twin while being regex-wrapped. The whole team section now uses `UPPERCASE` placeholders with no angle brackets, one convention that survives every renderer this site has.

### [The proof moved up, the homepage, rebuilt to show vaults before it explains them](#the-proof-moved-up) [v0.2.60](../admin/versions.md)

homepagepositioningvaultsagents

The homepage is rebuilt, following [the diagnosis published this morning](../articles/proof-behind-the-claim.md) rather than a fresh opinion, and [the "after" article](../articles/proof-moved-up.md) puts each new band beside a screenshot of what it replaced, so the comparison is honest rather than flattering.

**The first screen now shows vaults.** The headline changed from *"the encrypted git for humans and AI agents"* to *"a vault is a unit of work: data, app, history and sources, shipped as one string."* Encryption did not leave, it became the subordinate clause, which is where a property nobody can look at belongs. Under it: **four real published vaults**, a screenshot each, one click from open. Which four is a field in the vault data, so changing the front door is a data edit.

**The use cases became things.** A new band, *what people actually ship*, replaces five category cards with six vaults chosen by the job they do, hand over a report, publish a standard as data, give a talk, pitch an investor, ship a game that reports back, give an agent a workspace, each with one line on why it is hard any other way. None of those lines is about encryption.

**The collaboration story got a front door.** *One human, a team of agents*: four numbers computed at build time (releases, vaults, sibling sites, cross-team briefs) and the loop told in three beats with the artefacts linked. The numbers are not typed here or on the page, and this sentence deliberately does not repeat them: the first draft did, and was off by one within the hour because a release had happened. The tile cannot drift; prose can.

**Cut:** the abstract use-case band (the pages remain, in the nav) and the *three doors* band (now one pill in the trust strip). **Moved down:** the terminal walkthrough, under *Under the hood, it is git*, because for a visitor who has just opened a real vault, *how* is now the question. The band count is unchanged (nine before, nine after; three cut, three added) so what changed is the order and the first screen. The page got longer in bytes, because ten screenshots replaced paragraphs, and shorter in words.

**One thing the computed number caught.** The network heading had been retyped as "Twenty sites" while the tile beside it said 19. The tile was right (nineteen siblings, twenty with this one) and it is the tile that cannot drift.

**The gap stands.** No published vault yet shows two agents on one vault with a human merging their branches. The band tells the story of agents building *for* each other, which is evidenced, and is written so as not to pretend it shows more.

### [The diagnosis before the rebuild, and a card for pointing at the sibling sites](#the-diagnosis-before-the-rebuild) [v0.2.59](../admin/versions.md)

homepagearticlesnetworkmethod

Asked to step back and say how this site should present its twenty-five published vaults, the answer was a diagnosis rather than a redesign, and it is published first, as [an article with screenshots of the current site](../articles/proof-behind-the-claim.md), so the rebuild that follows can be compared against it honestly.

The short version: **the proof is two clicks behind the claim.**

- The homepage leads with encryption, which cannot be looked at, and a terminal walkthrough of `create`, `commit`, `history` and `clone`, commands every git user has watched a thousand times. The word *vault* appears three times in the hero and the visitor is never shown one.
- The twenty-five artefacts a stranger can open in one click, with no account, sit under a dropdown as a table. A good table now, but a table is the right shape for *finding* a vault and the wrong shape for being *convinced* by one.
- The use-case cards are categories. Concrete examples of every one of them exist one level down.
- The strongest story, agents building for agents; a brief published here turned into a vault the same day, then reviewed by the team that owns the API, is filed under Docs, as a log.

One gap named plainly: the homepage's strongest multi-agent claim, *a branch per agent and a human reviews the merge*, has **no published vault behind it**. Every vault here was built by one agent, or by one agent on another's finished work.

The fix is set out in order (proof before mechanism; reorder and cut rather than add) and is the next release.

**Also new: a card for pointing at the sibling sites.** The `*.sgit.ai` sites exist so each topic gets the depth a section here could not give it, which only pays off if this site points at them constantly, and a bare link does not say *this continues elsewhere, on purpose*. A one-line `!site` directive now renders a card that pulls the target site's own category and thesis from the network directory, so it describes that site the way the site describes itself. It debuts in the article pointing at [open-source.sgit.ai/about](https://open-source.sgit.ai/about/index.html), which is also a decision recorded there: this site will get an About page about **sgit**, and link to the fuller record rather than duplicate it.

### [The board moves into a vault of its own, and its read key is published](#the-board-moves-into-a-vault) [v0.2.64](../admin/versions.md)

boardvaultsteammethod

Two releases after [the board](../team/board.md) appeared as files in the site repository, the shape was right and the home was wrong: moving a card from *review* to *done* cost a full site release, build, validate, two pushes, and a wait for the deploy to verify. A board should be cheaper to update than the thing it tracks.

So the cards moved into [a vault of their own](../demos/vaults/board/index.md), `pdulwi6i`, and its read key is published, because every task, bug and need on it is public, and a read key is the complete credential for reading them.

- **The vault is the truth; the site is a reader.** The release script pulls the vault before it builds, and the columns on the board page are labelled as a snapshot at the site version. Between releases the vault is ahead, and opening it shows the live board.
- **Moving a card is `sgit push`.** Edit one `status` line, regenerate the index, commit, push. No site release.
- **A board app that asks for nothing.** `index.html` lists `issues/` through `sg.vfs` and draws five columns; `app.json` declares `permissions: {}`. Served outside a vault host it falls back to `issues/index.json`, so it can be screenshotted, tested and read from a script, a board that only renders inside one host is a board nobody can check.
- **Cloned in place.** The site's `admin/content/team/issues/` *is* the vault's working tree: its encrypted store is gitignored, its card files are tracked as the build's input. If the two ever disagree, the vault is right.

Published as row #26 on the [vaults table](../demos/vaults/index.md), following the method: write key escrowed, audit run (nothing secret-shaped beyond the read key in its own README), the app screenshotted by driving it, permissions stated. The Sherpa's [board prompt](../team/prompts.md#board) now ends with a push rather than a build.

### [Our build brief was wrong, and the team that owns the code said so precisely](#our-brief-was-wrong-and-the-team-that-owns-the-code-said-so) [v0.2.58](../admin/versions.md)

briefsapicorrectionagents

Two days ago v0.2.55 published a [build brief](../docs/briefs/vault-telemetry-append-lanes.md) on getting telemetry out of a vault whose read key is public. An agent [built a vault from it](../demos/vaults/agent-permission-games/index.md) and could not get events out. The SG/API team read the append-lane code against our page and returned a line-referenced review.

**Both of the things the brief told a builder to *verify*, it had already answered wrongly.**

- We said `sg.append.write` fails closed in a read-only session. **It does not.** There is no read-only gate on append anywhere; `permissions.append.write: true` is the entire requirement, and `sg.app.writable` is irrelevant to it. The `EREADONLY` we cited belongs to `sg.vfs.write`, a different code path that happens to deny with the same string, which is exactly how the misdiagnosis propagated.
- We steered readers to a direct `fetch` instead. That path is **blocked by default**: the frame ships `connect-src blob: data:`. The escape hatch is `permissions.network: true`, which the reviewer notes appears *"zero times"* in the authoring guide and zero times on our page, *"discoverable only by reading `app-permissions.js`."* It is also the wrong fix, since it reopens every egress from a frame holding decrypted vault content.

The brief now recommends the bridge, and the correction sits in a box **above** the section it corrects rather than being edited in quietly. The prompt at the bottom, the part written to be pasted to a builder, is reversed.

**It also resolved an open finding.** When the games vault was published we could not confirm the write endpoint and said so rather than guessing. The answer is that its telemetry is *built and never sent*: the vault declares no permissions at all, so the CSP blocks its sender. That matches the author's report that nothing arrived, and [its page](../demos/vaults/agent-permission-games/index.md) now leads with that status instead of claiming it phones home.

**Three facts that existed nowhere public** are now on [the API reference](../api/append-lanes.md): only `write` takes a `vault_id` while the other five verbs bind to the currently open vault, so listing a remote lane is impossible by design; `fetch` maps to `append.read`, not `append.fetch`; and the `inbox` field in a listing is the lane folder, which today is the **raw append token** while config stores only its hash.

Seven questions went back, including the two we most want to publish: whether the enum-key derivation is stable enough to document as a spec, and whether any non-destructive way exists to tell an append token from a read key. They are the same 64-hex shape, and confusing them would be a serious leak.

Also in this release: the `#` column on [the vaults table](../demos/vaults/index.md) was renumbering 1–25 on every sort, which said nothing. It is now a permanent publication ordinal, `#1` is the first vault ever published here, so it never changes, and sorting by it is by construction the same order as sorting by date.

### [Ask this site, a pane on every page whose model calls tools over the site's own content](#ask-this-site) [v0.2.63](../admin/versions.md)

chatllmtoolsbyokagents

Every page now carries a pane, bottom right: **Ask this site**. It follows the three tiers the [network chooser](../articles/chat-on-a-static-site.md) set out, with one difference that matters. The model does not read a catalogue pasted into its prompt. It is given **seven tools** and calls them.

| Tool | What it does |
|---|---|
| `search_site` | keyword search over pages, vaults, sibling sites, release notes, articles, roles and board cards |
| `read_page` | the markdown twin of any page, up to 6,000 characters, so the model quotes rather than paraphrases |
| `list_vaults` · `list_sites` | the vaults table and the network directory, filterable by category |
| `latest_updates` · `get_board` | the feed and the kanban |
| `current_page` | what the reader is looking at, for "this page" questions |

- **No key:** the tools run directly. Type words to search everything, or `/vaults`, `/sites`, `/updates`, `/board`, `/read PATH`, `/here`. Instant, private, no network once the index has loaded.
- **Your own OpenRouter key:** the model gets the seven tools as function definitions, calls them, and **every call is shown** as a trace line above the answer. Each call executes in the page over a build-emitted index and the `.md` twins, so the model can only say what a tool returned. It ends with the paths it used, as links.
- **Inside a vault:** the host could hold the key below the permission floor through `sg.llm`. Not wired yet, blocked on whether the bridge's chat contract carries tool calls, and on [the board as T11](../team/board.md#T11).

The index the tools read, `assets/site-index.json`, is written beside `llms.txt` from the same data as the vaults table, the directory, the feed and the board. One derived file: an answer given in the pane is an answer the site already gives somewhere.

The key goes to openrouter.ai and nowhere else, sgit.ai has no server to send it to, and the pane says so in the same words the chooser uses. Model output is escaped, and links are allowed only to `http(s)` or to paths on this site.

The [chat article](../articles/chat-on-a-static-site.md) gains an addendum, and its *shared component: not started* row becomes *partly*: this is one site's copy, not yet the versioned module the other eighteen could load.

## 2026-09-06

### [The vaults table stops being a key dump, sortable, categorised, newest first](#the-vaults-table-you-can-sort) [v0.2.57](../admin/versions.md)

vaultsuxmobile

Reported from an iPad, where the failure was obvious in a way it never is on a desktop. The read key is a 64-hex string; giving it room squeezed the vault id down to **one character per line**: `ookq4mn4` rendered as a vertical stack.

The fix was not narrower columns. It was noticing that the two widest columns were the two nobody needs on an index: the read key and the *open live* link are both already on each vault's own page, one click away. So [the index](../demos/vaults/index.md) now answers *which of these do I want*, and the vault's page answers *how do I open it*.

**Gone:** the read key, the open-live link, and the dense contents blob. **New:** a `#` column, a one-line **what it is**, a **category** pill, files and size as separate numeric columns, and a **published** date. **Click any heading to sort**: default newest first, because the recent ones tend to be the interesting ones. The count line carries the total and the breakdown: 25 vaults across 8 categories.

**Generated, not hand-written.** Twenty-five hand-written table rows could not be sorted, counted, or kept consistent, so the table now comes from `admin/content/vaults.json` through a `VAULTS` comment marker, the same mechanism the homepage articles band uses.

**The published date is not a date anybody typed.** It is the commit on which each vault's page first appeared in git, recovered with `git log --diff-filter=A`. Two weaker sources were tried and rejected first: update posts missed ten vaults and false-matched `health-score` against a later release that merely mentioned it in passing, and the version log had no line for two of them at all.

**Sorting is progressive enhancement.** The rows ship newest-first in the HTML, so with JavaScript off the table is still correct and still in the most useful order; the headings are keyboard-operable. On a narrow viewport the *what it is* column drops out rather than wrapping to nothing, since that sentence is on the vault's page anyway.

Verified at 1280 and 390 wide: 25 rows, **zero** 64-hex strings on the page, zero open-live links, no horizontal overflow, and the sorting checked by asserting the order actually flips rather than by looking at it.

### [The brief came back as a vault, and it is the first one here that phones home](#the-brief-came-back-as-a-vault) [v0.2.56](../admin/versions.md)

vaultstelemetryagentsauditbriefs

v0.2.55 published a [build brief](../docs/briefs/vault-telemetry-append-lanes.md) on getting telemetry out of a vault whose read key is public. Another agent read it and shipped the thing, so [two games about agent permissions](../demos/vaults/agent-permission-games/index.md) now joins the published vaults, two deterministic games about grants, permissions and mandates, sending anonymous usage events over an append lane to a separate private vault.

It is the first vault published here that **sends anything anywhere**, and the first end-to-end test of whether a brief written for an agent produces what it describes.

- **It took the fallback path**, which is the part the brief was least sure about. Not `sg.append` through the bridge, a direct `fetch` to the account-less write endpoint, `credentials: 'omit'`, `keepalive` on the final flush, payload in the `sgit pki` v2 envelope. `app.json` declares no `permissions` key at all, which is consistent: it does not need the host for this.
- **Exactly one 64-hex string exists in the whole vault**: the append token, in five places. No private keys, no enum/write/vault/read key fields, no third-party secrets, no personal data. One credential, and it is the write-only one.
- **The disclosure page is the model.** `telemetry.html` opens by naming the default it breaks, *"Opening a vault does not normally send anything anywhere. This one does"*, publishes the event schema, and then writes the sentence most analytics pages never do: *"What it proves. Nothing about anyone. Anyone holding this vault's read key holds that token and could forge or flood the lane."*

**A method correction that cost nothing only because the control was run.** The first version of the token test called a leak on the strength of `sgit clone` creating a directory. Then an all-zeros key produced the identical result. The directory is created regardless, and the test discriminated nothing. The marker that actually works is `.sg_vault/local/clone_mode.json`. A credential test with no negative control is not a test, and that now belongs in [the publishing method](../demos/vaults/publishing.md).

**Two findings, published rather than filed.** Two of the four pages still tell the player *"nothing sent"*, `what-can-it-do` was corrected to *"nothing stored"*, the home page and `which-agent-is-it` were missed, and the latter contradicts itself on a single screen. Nothing leaks; but the subject of this vault is informed consent, which raises the stakes on leftover copy. And the write endpoint could not be confirmed from this container, 404 on both hosts under both names, so that is recorded as unresolved rather than dressed up as a conclusion.

### [Briefs gets a second kind, references written to be executed, not asks waiting on a reply](#briefs-gets-a-second-kind) [v0.2.55](../admin/versions.md)

briefsagentsdocsmulti-agent

[Briefs](../docs/briefs/index.md) has been a single scroll of cross-team asks since v0.1.13, each addressed to another team, each carrying a status, each closing when it is answered. A brief arrived this week that is a different species, so the page now says so and separates them.

- **Build briefs**: a durable reference an agent executes: the mechanism, the traps, what to verify first, and the prompt to paste. It never closes.
- **Cross-team asks**: the seven that were already there, untouched, addressed to the sgit CLI, SG/Send API and SG/Vault UI teams.

The first build brief is [**telemetry from a published vault**](../docs/briefs/vault-telemetry-append-lanes.md): how one vault sends messages to another, and how a vault whose read key is public reports anonymous usage back to its author. The mechanism is an **append lane**, and it works for one reason worth stating plainly, the sender's `append_token` grants **write only**. A visitor who extracts it from the published vault (and they can, because a read key decrypts everything) cannot list the lane, cannot fetch anything, and cannot read another reader's events. The write response is blind by design: exactly `{"ok": true}`.

It is the only credential shape that survives being published inside a public vault. What it does not buy is authenticity: events can be forged, and the real failure mode is **1000 pending files per token → 507**, not a confidentiality breach.

The new group starts with two entries rather than one, because [publishing a vault](../demos/vaults/publishing.md) was already a build brief, *"written to be followed by another site's agent"*, filed in the vaults section where nobody looking for a method would find it. That is the same misfiling that created `case-studies/` in v0.1.14.

**Briefs also moves in the nav**, out of Evidence and into Docs beside Skills. The section's centre of gravity is now agent-facing documentation rather than a record of conversations, and Docs is where an agent looks. Evidence keeps comparisons, case studies and use cases.

One editorial call, recorded because it went the other way from the obvious. The source brief opened by answering *"is there a doctor/patient case study for this?"*. There is not; the [health-score vault](../demos/vaults/health-score/index.md) is one vault with three audiences, not two vaults exchanging messages. In the repo copy that section earned its place because the question was asked. On a published page nobody asked it, and listing that vault among the pages to read implies it is a source for cross-vault messaging. So it is cut from the reading list and kept as a single line of signposting, because that vault is exactly where the next reader will go looking, and a named absence beats a hidden one.

## 2026-09-05

### [Provenance is not conformance, the AIUC-1 vault, forked and layered](#provenance-is-not-conformance) [v0.2.54](../admin/versions.md)

vaultsstandardsconformancegraphspermissions

[Provenance is not conformance](../demos/vaults/aiuc-1-conformance/index.md) joins the published vaults. It is a **fork** of the [AIUC-1 catalogue vault](../demos/vaults/aiuc-1-graph/index.md) that keeps every byte of it and adds one directory above it, 649 files against the catalogue's 135. Both vaults stay published, and the catalogue page now says what it is and links to the fork.

The distinction the whole thing rests on is two edges that are never allowed to touch:

| edge | answers | absent means |
|---|---|---|
| `evidenced_by` | does the standard say this? | a build defect |
| `attested_by` | does **this subject** do this? | the control is unevidenced, **which is the finding** |

- **Unevidenced is a state, and it is the default.** Every control in scope gets a row whether or not anybody has looked at it, so an absent row is never read as compliance. The first build across all 53 controls comes out 2 evidenced, 48 unevidenced, 3 contradicted, the designed answer, not an unfinished one.
- **Insurability is computed, not asserted.** Conformance states become conditions and exclusions on a `policy/v1`: 1 condition met, 52 exclusions, 0 of 5 consequences covered. Move the `as_of` date to 2027-01-15 with nothing edited by anybody and the condition has expired, leaving 53 exclusions.
- **A crosswalk becomes a join between two vaults.** 62 of AIUC-1's 1,126 crosswalks resolve into article nodes in the published [regulation graph](../demos/vaults/regulation-graph/index.md), with CELEX and a hash on each edge; the other 1,064 are reported unresolved rather than forced. The join then finds something neither vault knew alone: **8 of the 27 target articles are amended by Regulation (EU) 2026/1744**, so the crosswalk was published against the text before amendment.
- **The first vault here to ask for a write grant**: `fs.write` scoped to `["chat/"]` and nothing else, plus `sg.llm.*`. The chat is stored in the vault; the authored terms the query depends on cannot be written by the app at all.

The claim that makes a fork readable is that it did not edit what it copied, and that claim is checkable rather than decorative. Run from the clone before publishing: the catalogue's own tests report **21/21 passed**, including the one that rebuilds every source document to the word, and the added layer's report **19 tests, 0 failed**.

It remains unofficial and derivative, not approved, certified, endorsed or reviewed by AIUC, and not a substitute for the standard. The subjects it measures are invented for the demonstration. The catalogue's open question about reuse rights applies here too, doubled, and is stated on the page rather than tidied away.

## 2026-08-27

### [The directory answers questions now, and the default tier needs no key](#the-directory-answers-questions-now) [v0.2.47](../admin/versions.md)

chatllmnetworkvaults

Two things: [the network directory](../network/index.md) grew a chat box, and a second conference vault went up.

**Ask it which of the nineteen sites is yours.** Type *"I have to sign off a risk"* and it points at risks.sgit.ai, and shows you the words it matched on. It runs in your browser against the catalogue generated from the same files the cards and the table come from, so it cannot drift from the directory underneath it.

- **No key, no account, no network call** in the default tier. A reader should not have to hold a credential to use an index.
- **It tells you why it chose.** A hit in a site's thesis or domain outweighs one in its summary, and the answer names the matched terms. An LLM answer does not give you that for free.
- **Bring your own key if you want prose.** Opt-in, OpenRouter, streaming, reusing the pattern already proven in the workbench vault. The cost is stated on the panel rather than buried: with no host there is no permission floor, so the key lives in the page's origin. If the call fails it falls back to the local matcher and says so.
- **[The plan](../articles/chat-on-a-static-site.md)** covers the third tier, serving the directory as a vault app, where `sg.llm.chat` keeps the key below the permission floor and the app never sees it. Not built; scoped honestly, including the parts that are not started.

One fix worth recording. The matcher first sent *"I need to cite a regulation precisely"* to **wardley-maps**, because it only knew each site's own vocabulary, standards.sgit.ai says *provision*, and the reader typed *regulation*. Site entries now carry an `aliases` field holding the words readers actually arrive with. Five real questions, five correct first hits; nonsense still returns nothing rather than a confident wrong answer.

Also live: **[Scaling Threat Modeling with Semantic Knowledge Graphs](../demos/vaults/threatmodcon-2025/index.md)**: ThreatModCon 2025, Barcelona. Eleven linked threat models from customer to compute instance, so a vulnerability in a line of code traces up to the revenue it risks. 51 nodes, 179 threats, five interactive views and five Wardley walkthroughs, all running offline in the vault. Two of its data files are **invalid JSON upstream** and are repaired here, with the repair proved rather than asserted: the only differences are four stray brackets removed and one `],` added, and the multiset of content lines is unchanged.

### [An insurance policy for an agent, and the delta is the risk](#the-delta-is-the-risk) [v0.2.52](../admin/versions.md)

vaultsagentspermissionsrisk

[Licence to Operate](../demos/vaults/licence-to-operate/index.md) joins the published vaults, one agent, its policy, and a simulated conversation where every reply carries its price.

**The idea worth stealing is the delta.** Three sets:

- **CAN DO**: the grant. 12 capabilities.
- **MAY DO**: the mandate. 4, and the only thing the policy insures: `crm:read`, `kb:search`, `llm:generate`, `mail:draft`.
- **THE DELTA**: 8 capabilities inside the agent's reach and outside its authority, including `crm:write`, `crm:export`, `mail:send` and `shell:exec`. **No policy covers these.**

The mandate is *"answer a customer's question from their own record and the help centre, and draft, never send, a reply."* The grant includes `shell:exec`. Nobody asked for it, nothing insures it, and the agent can reach it. That is [nhi.sgit.ai](../network/nhi.md)'s blast-radius argument made countable, and here the gap is priced rather than described.

The simulation makes you spend it: a customer cannot log in, and each of three replies shows its cost before you commit, 1,400 tokens in band, 4,800 tokens and three records which *claims*, or a password reset that is `mail:send` and outside the mandate entirely. Underneath is a live rate table with a normal band, an ask-above threshold, a pool with an untouchable reserve, and customer records marked *uninsurable above 20*.

**The permission grant proves the architecture rather than asserting it.** The vault holds the terms; your browser holds the run. And `app.json` requests `fs.read` and `downloads`, **read, no write, at any path**. An app that simulates spending against a policy is structurally incapable of editing the policy it spends against; not because it behaves, but because it never asked for the grant that would let it.

One process note. The agent that built this vault supplied its own audit of all 16 commits, and it was accurate, but it was checked rather than accepted. Re-verified against a fresh read-key clone: no credentials anywhere, the `/home/claude/` build paths baked into the PDF are gone (zero occurrences), and the one full-length credential in the vault is the vault's **own** read key, confirmed by deriving it independently and matching byte for byte, rather than by trusting the label on it.

### [A standard as a graph, and the one line that makes it trustworthy](#a-standard-as-a-graph-and-the-line-that-makes-it-trustworthy) [v0.2.49](../admin/versions.md)

vaultsgraphsprovenancestandards

[AIUC-1, as a graph you can cite](../demos/vaults/aiuc-1-graph/index.md) joins the published vaults, an **unofficial, derivative** machine-readable catalog of the public AIUC-1 agent standard. It is not approved, certified or endorsed by AIUC, and the page carries that in a box above everything else rather than in a footnote.

- **53 controls, 144 requirements, 1,126 crosswalks** to 13 external frameworks, resolving to 1,238 nodes and 3,526 edges across five releases.
- **Every field names its source.** Each control carries the official page it was read from; each of the 82 captured pages carries its HTTP status, retrieval timestamp, the **SHA-256 of the bytes**, and the retained gzipped snapshot inside the vault.
- **A control is drawn as its edges** (`has_requirement`, `maps_to`, `evidenced_by`, `applies_to_capability`) which is [graphs.sgit.ai](../network/graphs.md)'s argument applied to a compliance standard.
- **A release that could not be built is recorded as unbuilt.** AIUC names a 2025-07-22 release that carries no commit, so the catalog says so rather than dropping it.

The best thing in it is a refusal. It publishes the five places where the official website and the official changelog repository disagree, classifies each as presentation rather than meaning, and then declines to pick:

**"None of these is resolved here. Resolving one means choosing a source, and that is not this build's to choose."**

A derived artefact that silently picks a winner when its sources conflict has stopped being derived and become an opinion, and the reader cannot tell which. This one preserves both readings and stops a release being marked `validated` if a difference changes meaning.

Its collection policy is worth copying too: an identifying user agent, one request per second, no authentication, no slug guessing, every page reached from a page already fetched, and `robots.txt` fetched first, returning 404 at capture time, **with the manifest recording that observation verbatim rather than the conclusion alone**.

One thing stated plainly rather than buried: the vault's own `NOTICE.md` records that **reuse rights for the full AIUC-1 control text have not been confirmed with AIUC**, and that anyone republishing publicly should confirm first. Publishing this read key is that kind of republication, and it is here at the author's decision with the vault's disclaimers reproduced rather than summarised. The vault's undertaking, *"If you are AIUC and want something here changed or removed… removal will be honoured"*, is repeated on the page and applies to it too.

### [A three-minute pitch, delivered from a vault, and the first grant that is not empty](#a-pitch-delivered-from-a-vault) [v0.2.51](../admin/versions.md)

vaultspermissionspresentation

[The VoiceDebrief pitch to Founder Institute](../demos/vaults/voicedebrief-pitch/index.md) joins the published vaults, the 23rd, and not a deck *about* a vault but a deck **presented from** one.

- **A presenter, not a PDF.** Twelve slides with per-slide target timings, a live 3:00 countdown, speaker notes, Focus and Fullscreen, plus five backup slides for Q&A, one of them titled *"WhatsApp / ChatGPT already does this"*, which is the obvious objection answered rather than avoided.
- **The working ships with the conclusion.** The approved outline and its claims-to-keep-exact list, the spoken script per slide, the fifteen-part pitch pack, the research notes, the screenshots, and the PDF and PPTX exports, all in the same object as the slides. The deck is generated from a template by a script inside the vault, so the slides are built, not hand-maintained.

**It is also the first vault here that asks for anything.** Every other one declares `"permissions": {}`. This one declares:

```

"permissions": { "downloads": true, "externalLinks": true }

```

It offers PDF and PPTX buttons, so it asks for downloads. It links to the live product, so it asks for external links. That is the whole request, **no filesystem access at all**, not read, not write, at any path. The grant is one line, it maps onto two things you can point at in the interface, and nothing outside it is reachable however the app is written. Set beside the [Risk Graph Explorer](../demos/vaults/risk-graph-explorer/index.md)'s empty grant, the difference is legible without reading any code.

Audited clean on credentials. Three things become public with it, all apparently by design and all named on the page rather than left to be discovered: the unit economics and commercial terms, the author's contact address on the closing slide, and the three named judges of the session with their affiliations, names and roles only, with no tactical notes about them anywhere in the vault.

## 2026-08-26

### [Nineteen sibling sites, and a way to find the one that is yours](#nineteen-sites-and-a-way-to-find-yours) [v0.2.44](../admin/versions.md)

networknavigationrefactor

[The network](../network/index.md) was four sites. It is **nineteen**: seventeen live, two with the repository and subdomain in place but nothing published yet. That is no longer a footnote on this site; it is where most of the writing now lives.

- **The page now starts with a question, not a list.** Seventeen lines, each one something somebody actually arrives with, *"I need to give an AI agent an identity"*, *"I have to sign off a risk and I do not want to rubber-stamp it"*, *"my app has to call an LLM and I do not want it holding an API key"*, and the site that takes it seriously. At four siblings a list was fine. At nineteen, a list is a directory you have to read before it helps you.
- **Grouped by area** (Agents &amp; AI, Risk &amp; governance, Graphs &amp; method, Security &amp; infrastructure, Business &amp; publishing) with a full scannable table underneath for anyone who would rather see all nineteen at once.
- **Every thesis is the site's own words**, quoted from its H1 or lede rather than summarised here, so an entry cannot drift into describing a site that no longer says that.
- **Network moved to the top-level navigation.** It had been the third child of Updates, which was a reasonable filing decision at four entries and a bad one at nineteen.
- **And the homepage says it out loud**, with five doors in by area, because a reader who does not yet know these sites cannot pick one from a list of domains.

Two sites appear with no screenshot and no link to a live page: `skills.sgit.ai` and `influences.sgit.ai` have DNS and a repository but GitHub Pages has not published them. They are listed as *not published yet*, pointing at their repositories, rather than quietly left out, the same reason a missing tag is preferable to a missing page.

This is the refactor it looks like from the outside. Material that would have made this site sprawl has a better home; this page is the index back into it. Adding the twentieth site is writing one markdown file.

### [Articles get a place on the homepage, and a band gets its width back](#articles-get-a-home-and-a-band-gets-its-width-back) [v0.2.45](../admin/versions.md)

articleshomepagelayout

Three changes, one of them a bug I shipped yesterday.

- **The network band ran the full viewport width.** The homepage bands each carry their own measure (`.eco` has `max-width:1100px` on the component itself, not on a wrapper) and the band added in v0.2.44 simply had none, so it stretched edge to edge on a wide screen while everything above it stayed in the column. Measured after the fix: `.eco`, `.netpick` and the new `.artcards` all report exactly **1100px**, with no horizontal overflow. The five area cards also now lay out 3+2 rather than 4+1, which stops the last card sitting alone.
- **[A new article](../articles/nineteen-sites.md)** on what the split actually was: twenty repositories in fifteen days, fifteen of them in the last five, and what that did to the writing, what forced it, what it cost (discovery got worse before it got better), and why the directory now opens with a question rather than an inventory.
- **Articles now have a place on the homepage.** They turned out to be the readable surface over all of this, a reader who will not work through a docs tree will read one argued page. The band is **derived from the articles list**, so a new article appears there by being written. No list to maintain, same rule as everywhere else here.

Also: [influences.sgit.ai](../network/index.md#business-publishing) went live and is now a full entry with its screenshot, *"where the thinking came from"*, an influence map in three tiers with a changelog recording when a source moves between them. That leaves **eighteen of nineteen live**; `skills.sgit.ai` still has DNS and a repository and nothing published, and is still listed as such rather than hidden.

### [A conference keynote as a vault, the deck, its exports, and the research it came from](#a-conference-keynote-as-a-vault) [v0.2.46](../admin/versions.md)

vaultspresentationprovenance

[AI vs. AI, Black Hat Europe 2025](../demos/vaults/blackhat-eu-2025/index.md) joins the published vaults. It is the twentieth, and the first that is a **talk** rather than a document set or an app.

- **The whole chain, one credential.** The deck as presented (26 slides), six PDF exports from v0.1.1 to v0.2.0, the eight research papers it was built from, and the slide system's own source at ten versions, all in one vault, opened with one read key.
- **The slide content is data, not markup.** `deck/blackhat-eu-2025.json` is read through the vault bridge at load time, so changing a slide is a commit rather than a rebuild. That separation is why the vault can carry ten versions of the renderer beside one deck without either owning the other.
- **It asks for nothing.** `"permissions": {}` with `present: true`, the deck opens full-screen and never touches the filesystem.

The argument is worth the click on its own. It opens by conceding the ground (*security's four pillars, all broken*) then lands on four publicly documented outages that were **not** attacks: a timing bug that wiped a global database, a config inconsistency that detonated worldwide, a routine change that halted traffic, and a faulty update that bricked 8.5 million machines. The turn is one line: *"These weren't sophisticated attacks. They were minor glitches that cascaded. Now imagine if they were deliberate."*

Several of its later slides describe things this site now demonstrates rather than proposes, *assume compromise, contain blast radius*, *version control everything*, *identity graphs for least privilege*. Those threads have their own homes in [the network](../network/index.md) now.

Audited clean before publishing: no sgit credentials, no third-party API keys, no private keys, no emails, no client named. The organisations that appear (AWS, Azure, Cloudflare, CrowdStrike) are cited for public incidents, which is what the slide is about. The deck uses Black Hat Europe's official speaker template because it is a talk that was given there; the page says plainly that it is published as the speaker's own material, not as anything endorsed by or affiliated with the conference.

## 2026-08-25

### [Six vaults published, three held back, and the check that nearly missed one](#six-vaults-published-three-held-back) [v0.2.43](../admin/versions.md)

vaultsauditsecurity

Nine vaults were submitted for publication. **Six are now live**, [in the gallery](../demos/vaults/index.md). Three were held, and the third one is the reason this post exists.

- **[Penetration Test Report](../demos/vaults/pentest-report/index.md)**: a pentest delivered as a vault instead of a PDF. Eight audience-specific views over one engagement, and every finding ships a retest script that exits `0` if it is fixed and `1` if it is not. Entirely fictional, with a `SIMULATED DEMO` badge on its own front page.
- **[Standards Atlas, GDPR](../demos/vaults/standards-atlas-gdpr/index.md)**, *"the standard is the graph."* Rulings, regulator guidance and per-country variation as first-class nodes over the articles they bend, with corrections written back into `feedback/` and nowhere else.
- **[RiskMandate · File security](../demos/vaults/riskmandate-file-security/index.md)**: risk acceptance moved from a rubber stamp at the end to the centre of the flow, over versioned JSON queried live by SQLite in the browser.
- **[Content-Transformation Proxy](../demos/vaults/content-transformation-proxy/index.md)**, **[SG Commercialisation](../demos/vaults/commercialisation/index.md)** and the **[SG/Payments Brief Pack](../demos/vaults/payments-brief-pack/index.md)** complete the six.

**Two were held for carrying credentials.** One contained two live vault keys in plaintext, including **its own write key**, which would have turned a published read key into full write access. The other is a private working log that was never meant to be public.

**The third is the one worth recording.** A vault whose app reads an LLM key from a file scored *clean* on the first credential pass, and then a screenshot of it showed a chip reading `key: vault key.json`. The file held a live OpenRouter API key. The scan had looked for vault-key shapes, `sgit_` prefixes, private-key blocks and the string `api_key`; the field was named `openrouter_key`, so nothing matched.

That is a real gap, not a near miss reframed as a win. The credential tooling here was built to protect *sgit* credentials and does that well; it had no opinion about third-party API keys, which are just as costly to leak and far more common. A broader sweep (OpenAI, Anthropic, GitHub, AWS, Google, Slack and JWT shapes, with placeholders filtered out) now runs over every candidate, and it found exactly one other hit: a forged `alg:none` token in the pentest vault, which *is* the finding it documents.

The lesson is the cheap one to state and the easy one to skip: **a scan that has never surprised you is not evidence that you are clean.** It was a screenshot, not the scanner, that caught this.

## 2026-08-22

### [The ninth published vault, four apps in one tree, and a reader that asked for nothing it did not need](#the-ninth-vault-four-apps-in-one-tree) [v0.2.40](../admin/versions.md)

vaultsgraphspermissions

[VoiceDebrief](../demos/vaults/voice-debrief/index.md) joins [the published vaults](../demos/vaults/index.md). Four apps in one encrypted vault, lifting meaning out of text, from fictional voice notes to Article 9(2) of the EU AI Act, into typed semantic graphs.

*Written up from the vault and the release that published it; the page itself is the primary record.*

- **The claim in one line.** A paragraph is not a string, it is a **graph**, and so is the paragraph next to it. Lift both into typed nodes and the two join *node-to-node* through an intermediate layer, never paragraph-to-paragraph. Part 4 works that end to end against one real legal provision. Parts 1–3 run on a **fictional** corpus, and the vault says so in its own README.
- **Read over one folder, write over nothing.** `app.json` declares `fs.read` on `part-4/` and nothing else, no write, no mkdir, at any path. The host's own chrome renders the result as `R3 W0`. A capability never requested cannot be misused.
- **Lineage kept rather than overwritten.** `part-2/` and `part-3/` hold frozen app snapshots at the state they shipped in, with a shared nav linking all three, so the earlier thinking stays openable instead of surviving only as a commit message.
- **A nested entry point**, `part-4/index.html`, which is what lets one vault hold four apps without one of them having to own the root.
- **The credential is derived.** It arrived as a vault key, was classified as a write credential before it touched anything, and only the one-way read key is published.

Ten screenshots, captured by driving the live vault from that published read key, no mock-ups.

It was written and pushed a day before it appeared here: [the tag gate](../updates/#an-ordinary-commit-should-not-be-able-to-take-the-site-down) had the deploy blocked.

### [An ordinary commit should not be able to take the site down](#an-ordinary-commit-should-not-be-able-to-take-the-site-down) [v0.2.40](../admin/versions.md)

cideployrelease

Two good commits landed on `dev` after v0.2.39 and sgit.ai served neither for a day. Nothing was wrong with either of them. The CI tag gate failed, and the deploy is gated on the tag gate.

- **What the error said, and what was actually true.** The job read `SITE_VERSION`, found `v0.2.39` already tagged on the *earlier* commit, and failed with *"SITE_VERSION was not bumped for this release."* But this was not a release. It was an ordinary commit on top of one. The message described a discipline failure where the real event was a category mistake in the check.
- **Why it became an outage rather than a warning.** The deploy job runs when `tag-release` is `success` **or** `skipped`. A *failure* is neither. So a missing tag, bookkeeping, silently became an unpublished site. Re-running could not help: the check is deterministic, and it failed identically on the second attempt.
- **The fix is to ask the right question.** What makes a push a release is now its **commit subject**, which is where `release.sh` already writes the version. No `site vR.M.N:` subject means an ordinary push: tagged nothing, published anyway.
- **And a commit that does claim a version is held to more than before.** The subject and `SITE_VERSION` must agree, previously that was only ever inferred, from whether the backfill loop had happened to produce the tag. The version must not already have shipped, and it must still be the next minor.

The asymmetry is the point, and it is written into the workflow so the next person changing it knows why: **a missing tag is a bookkeeping gap, a blocked deploy is an outage.**

Checked before shipping rather than after, by extracting the job's own script and running it over five cases in a throwaway clone: the exact commit that failed today now exits 0, a proper release tags, and subject/`SITE_VERSION` disagreement, a reused version and a skipped minor all still fail, each with a message that names what is actually wrong.

There was a quieter second consequence, and it is the one worth remembering. Those commits went to git only, so the vault remote never received them: `sgit status` showed all fifteen new files as uncommitted. Both stores are meant to move together, which is exactly [why CI does not author commits itself](../case-studies/one-tree-two-remotes.md), a CI-written commit would exist on the git side alone. This release carries them across.

## 2026-08-21

### [A fourth sibling site, and the first one that links back](#the-first-sibling-that-links-back) [v0.2.39](../admin/versions.md)

networkgraphsmethod

[graphs.sgit.ai](../network/graphs.md) joins [the network](../network/index.md). It argues for a grammar of semantic graphs, from five rules you can apply tomorrow up to a full positioning against schemas and vector search, and it opens by disowning the product category a reader arrives expecting: *"this is not a graph database pitch… there is no graph database anywhere in the work behind this site."*

- **The thesis fits in two sentences.** Two nodes both hold `8080`. One is connected to a type, to a library, to a version; the other to nothing. *"The difference is not in the value. The difference is in the connectivity."*
- **The best argument needs no background.** 10,000 hours came from a 1993 violinist study where it was an *average*, not a threshold, and half the top group had not reached it. The corrections never attached: by then the claim had been carried through 242 papers and 200,000+ citation paths. A document cannot fix that. A graph can mark a claim superseded and make *"what did we build on this?"* a query.
- **`relates-to` is banned**, for a mechanical reason rather than a stylistic one: an edge with no verb carries no constraint, so it cannot narrow a traversal. It costs fan-out and buys nothing.
- **It separates ships from argues, and concedes the harder half**, *"this site's subject matter is almost entirely design"*, then lists what is running: the vault commit DAG, `*.link.json` cross-vault edges, the read-only query API handed to untrusted sandboxed apps, and a live typed property graph of 71 nodes and 141 edges across 107 issue files.

**It is the first sibling with a reciprocal link.** Its nav carries an `↗ part of sgit.ai` chip and its footer points back at this network page. Until now `/network/` was a one-way index.

Two build changes came with it. A site entry can now carry a `url:` that differs from its `domain:`, `graphs.sgit.ai` does not resolve yet, and an entry should link to the address that works rather than wait for the CNAME, so the page says which one it is instead of shipping a dead link. And the audit that comes with every network entry found one: the graphs site links to `sentinel.sgit.ai`, which does not exist. The site is `sg-sentinel.sgit.ai`; the `sg-` prefix is load-bearing.

## 2026-08-20

### [The audit that stopped a publication, and the vault we built instead](#the-audit-that-stopped-a-publication) [v0.2.37](../admin/versions.md)

vaultssecuritypublishing

A vault arrived for publication: the **EU AI Act as a citable graph**: 113 articles, 1,523 nodes, 1,944 edges, every node traced to hash-verified source bytes. Good demo, obvious yes.

It did not ship. The audit step, *open every file with the exact credential you are about to publish*, found a **live vault key in plaintext**, inside a handoff document, granting write access to a **different** vault. Publishing the read key would have handed that away to anyone who read the page.

- **Deleting the file would not have been enough.** Vault objects are content-addressed and immutable, so a credential committed once may stay reachable from history. The only clean remedy is history that never contained it.
- **So there is a new vault.** Same 206 files, two credentials redacted in place with visible `<VAULT-KEY-REMOVED>` markers rather than silent deletions, plus a `PUBLIC.md` stating what changed and why.
- **Re-audited from a fresh read-key clone**: 205 text files, zero findings. That is [Regulation Graph](../demos/vaults/regulation-graph/index.md), and it is live.

One rule got verified rather than assumed. The vault's Graph REPL is an LLM chat, and its code looks for an OpenRouter key at `/key.json` *inside the vault* before falling back to device storage, so a shipped key would be an open tab on somebody else's budget. There is no `key.json`, confirmed in the read-key clone. Bring your own key; nothing metered ships.

The rule that caught all of this came from the [Risk Graph Explorer](../demos/vaults/risk-graph-explorer/index.md) vault's own `PUBLIC.md`, not from us. It has now paid for itself.

### [A third sibling site, one that says, at the top of every page, that it does not exist](#a-third-sibling-site-that-says-it-does-not-exist) [v0.2.38](../admin/versions.md)

networkedgesecurity

[sg-sentinel.sgit.ai](../network/sg-sentinel.md) joins [the network](../network/index.md). It is a design for an app-coupled edge guard that replaces rented AWS WAF plus CloudWatch and Firehose with a layer you own, and its status pill reads `NOT BUILT` where its siblings read `MVP DRAFT`.

- **The inversion is the idea.** A generic WAF is blind to the app it protects, so it denylists known-bad and passes the rest. If you control both client and server, the edge knows the valid request space, so it can **allowlist**, and no invalid request reaches the origin.
- **One correction reshaped the design**, and it is stated as a governing constraint: *"Layer 1 never acts and never writes, it only decides and signals. Layer 2 is the sole actor and the sole I/O owner."* The reason is physical: a CloudFront Function has no network and no filesystem. The site names the earlier version, where L1 blocked inline, as a category error of its own making.
- **Rules are the engine, not configuration on it.** Six deterministic rules, each a pure function, each mapped to an ATT&CK technique, run in order with first-block-wins. The prototype ran the same engine across three targets with a parity matrix asserting identical decisions.
- **And it bounds its own evidence.** The prototype's testing manual reports 149 passing tests; the site immediately says *"not deployed anywhere, not in production use, not maintained, and not packaged for you to install."*

It is the third site here to publish a design **before** the thing exists, after [pki.sgit.ai](../network/pki.md)'s four registry rules. Same wager: publishing the design now is cheap, claiming it afterwards is impossible.

Adding it took one markdown file and three screenshots. The renderer gained pipe-table support on the way, since the six-rule core wanted a table and got a paragraph of vertical bars instead.

## 2026-08-19

### [The first two sibling sites, with screenshots](#the-first-two-sibling-sites) [v0.2.36](../admin/versions.md)

networkidentitypki

Two focused sites now run on `*.sgit.ai` subdomains, and [a network section](../network/index.md) covers both, what each argues, why it is relevant here, and screenshots of the real pages.

- **[nhi.sgit.ai](../network/nhi.md)** splits "how do I give my agents an identity?" into **agents you run** and **agents you rent**, and shows that everything on the market answers only the first. For rented agents (the ones in Claude, Codex, behind an API) the honest current answer is to hand over a broad credential and hope. Its sharpest idea is that **the real authorization is the closure**: inbox access is every account resettable by email.
- **[pki.sgit.ai](../network/pki.md)** designs a key registry from the 2019 keyserver catastrophe, publishing four rules **before the registry exists** so they stay checkable. The resolution it reaches is worth borrowing: append-only is safe when a writer appends only to objects it *owns*, and fatal when anyone may append to somebody else's. The rule to carry forward is not "append-only". It is *the writer owns what it writes*.

Both connect directly to work here. Read keys and [append lanes](../api/append-lanes.md) are credentials with a provably bounded closure, which is the nhi problem stated as a mechanism; and an append lane is owner-configured, which is pki's rule 1 already shipped in another corner of the system.

More subdomains are coming. Adding one to this site is now writing a single markdown file and capturing its screenshots, the index, the cards and the page are all derived.

## 2026-08-18

### [Verify the fix pack, not just the bug](#verify-the-fix-pack-not-just-the-bug) [v0.2.34](../admin/versions.md)

processpkiaccuracy

The documentation gap above arrived as a well-built fix pack from the SG/API team: a gap analysis, code-verified source material, and a draft of the missing page. The most valuable line in it was its own instruction to check the claims before publishing. **Three did not survive.**

- **"The security page actively denies PKI."** It did not. A sweep for *symmetric*, *asymmetric*, *public key*, *PKI* and *keypair* returned zero occurrences. The page was silent, not wrong, and publishing a correction for a claim we never made would have put a false statement in our own changelog.
- **"Search the site for stale `inbox` naming."** There is none. Two hits, both ordinary English; no `/api/vault/inbox/*` path anywhere.
- **"Seal to the recipient's X25519 key."** Not what ships. Running `sgit pki keygen` prints **RSA-OAEP 4096-bit** and **ECDSA P-256**. Publishing the draft as written would have told integrators to build against the wrong primitive.

Two more corrections came from running the CLI rather than reading about it: `sgit pki export` emits a **JSON bundle** of two PEM blocks, not the `.pem` file the draft redirected into, so the draft's `sha256sum public-key.pem` derivation of a lane address is not well defined, and `keygen` requires a passphrase, which no draft step mentioned.

The whole exchange, including what we got wrong, is on [the briefs page](../docs/briefs/index.md).

### [The API reference we did not have](#the-api-reference-we-did-not-have) [v0.2.34](../admin/versions.md)

apimessagingdocs

An agent was asked how to send an encrypted message between two vaults. It read this site and could not find out. The capability had shipped months earlier.

The diagnosis was uncomfortable and simple: **we documented both halves and never wrote the sentence that joins them.** The transport was on one page as `sg.append`, the crypto on another as `sgit pki`, and neither referenced the other. There was also no HTTP API reference anywhere, awkward for a project whose whole argument is that the API *is* the surface.

- **[Sending messages between vaults](../docs/vault-messaging.md)** is the page that was missing: append lanes composed with keypairs, worked end to end in CLI, curl and `sg.append`.
- **[An /api/ section](../api/index.md)** now exists, [authentication](../api/authentication.md), [vault objects](../api/vault-objects.md), [append lanes](../api/append-lanes.md) and [errors](../api/errors.md).
- **[The PKI page](../docs/pki.md)** documents the keypair lifecycle, run against the shipped CLI rather than recalled.
- **[The security page](../security/index.md#pki)** gained the asymmetric layer it never mentioned. It never claimed sgit had no public-key layer, it simply said nothing, and on a page like that one, silence reads as denial.

The one step that is not wired end to end is labelled **PROPOSED** with an interim recipe, rather than quietly documented as working.

## 2026-08-17

### [Three walkthroughs, read back as documents](#three-walkthroughs-read-back-as-documents) [v0.2.32](../admin/versions.md)

vaultsvideorisk-graph-explorer

A video is invisible to a search engine, to `llms-full.txt`, and to any agent reading this site as documentation. It is also full of *"this guy here"* and *"look at this"*, pointing that a transcript cannot resolve.

So [the Risk Graph Explorer walkthroughs](../demos/vaults/risk-graph-explorer/videos/index.md) now carry the player at the top and **the same session read back underneath**: fifteen moments, each a timestamp that deep-links into the video, the frame the screen was showing then, and what is actually happening in it.

- Nine frames come from a narrated-review export; the other six were captured from the **live vault** with its published read key, driven to the exact state being described.
- What the frames turned up is most of the value, because none of it is audible: negative answers draw **named edges** (`never-exercised-on`, `absent-for`) rather than silence; "no egress" draws a single assurance-coloured edge in a field of amber; and every risk ships with a **"ceases when any of these hold"** list, its own falsification condition, cited to facts.

The [seven views page](../demos/vaults/risk-graph-explorer/views/index.md) covers the same vault view by view.

### [Printing stopped costing every reader](#printing-stopped-costing-every-reader) [v0.2.31](../admin/versions.md)

printperformance

Save a walkthrough page as a PDF and it used to come out wrong in two ways: the site navigation painted **across the middle of page 2**, translucent, with the prose showing through it, and any screenshot you had not scrolled past exported as a blank gap.

The first was a sticky header: Chrome paints a sticky box once, wherever it happens to fall in the paginated flow. The second was subtler. Screenshots load lazily, and `loading="lazy"` defers the **decode**, not just the download, so an image far below the viewport sat there fetched, at zero width, and printed as nothing.

- The first fix made every reader pay: it pre-loaded all the images so printing would work. That was the wrong trade and it was rejected.
- **The bypass now fires only on print**: on `beforeprint`, and on the Cmd/Ctrl-P keystroke, which lands a few hundred milliseconds earlier and buys the images a head start.
- Measured on a page nobody scrolled: **1 image loaded while reading, 9 of 9 in the PDF.**

Also in this release: `@page` margins, colour preservation so the amber/green distinction survives, `break-inside` rules so a caption is never stranded on the page after its picture, and per-release cache-busting on assets, because for ten minutes after every release, returning readers were running new HTML against old CSS.

### [Green does not mean live](#green-does-not-mean-live) [v0.2.33](../admin/versions.md)

cideployprocess

Two consecutive releases pushed cleanly, reported success, and **never reached the site.** A human noticed on a phone, forty minutes later, because the version badge still showed the old number.

The release script verified that both remotes were in sync, and they were. The failure was in a job neither remote knows about: GitHub Pages could not download `actions/configure-pages`, got a **429 Too Many Requests**, and the deploy died in "Set up job" before running a single step. Validation passed. Tagging passed. The site served a two-release-old page.

- **A release now ends by asking the live site what version it is serving**, polling with a cache-buster until the badge matches, and **aborting loudly** if it never does.
- The cost is up to eight minutes per release. The alternative, demonstrated twice in one afternoon, is telling somebody a fix is live when it is not.
- Same principle as the rules already in the build: a page nothing links to, a page the index omits, and a page the deploy never published are all equally unpublished.

There is a longer account of this one in [Green does not mean live](../articles/green-does-not-mean-live.md).



==============================================================================
# Articles, sgit.ai

> Longer pieces that make an argument across several pages: what a thing means, why it is shaped that way, and what it cost to find out. Each links to the pages that own its facts rather than restating them.
>
> Page: https://sgit.ai/articles/index.html

# Articles

Longer pieces that make an argument across several pages, what a thing means, why it is shaped that way, and what it cost to find out. Shorter, dated notes on individual changes are in [updates](../updates/index.md).

**Two rules keep these from going stale.** An article never restates a fact it does not own, it links to the page that does, so when the fact changes the article does not start lying. And an article that makes a testable claim links to the test, the same way [the comparison pages](../compare/index.md) do.

[**Before you give an agent a connector, give the connector a twin**2026-09-24When an AI agent is given a Gmail or Google Calendar connector, it can read, send, move, decline and permanently delete on somebody's behalf, and for several of those actions the platform itself documents that there is no way back. This article argues that a twin of the connector is the minimum requirement for deploying an agent with confidence. The twin is a journal of every request and response the agent makes, appended as it happens to a write-only lane, processed later, and replayed into the inbox and calendar as the agent saw them, with a before and after for every change and a revert plan for each one. It gives provenance, explanation and a named list of what can and cannot be undone, and it changes the agent's behaviour policy from a hope into a list. Every claim about Gmail and Calendar is taken from Google's own documentation and linked. A working replay of an invented session, and a business plan for the service, are published alongside it as a vault.agentsconnectorsdigital-twinsprovenanceriskriskmandatearticle](connector-twin-before-you-deploy-an-agent.md) [**Every risk is already accepted. The only question is by whom, and for how long.**2026-09-24A foundation article on risk acceptance, for readers who have never met the idea. A risk exists the moment the exposure does, so an organisation is always carrying it; the only open questions are who has accepted it, and until when. There is no deny button, only three doors (accept for a stated interval, fund the work, or fix it), and silence escalates. The interval is the decision, from four hours, which is an incident, to six months, which is a named decision to wait. Accepted is not the same as acceptable, which matters because the EU AI Act requires providers of high-risk AI systems to have residual risk judged acceptable, and never defines the word. Every risk has a holder, every holder has a boss, and every path ends at the board. Every risk is established by facts and ended by facts, from the board down to the configuration file, which is what closes the gap between a register and reality. The article walks one invented risk through six weeks, argues that each material risk deserves a vault of its own as its evidence pack, explains why executives resist the model, and shows why it fits alongside every GRC platform rather than replacing one. A business plan for a company that runs this loop is published with it.riskrisk-acceptancegovernancegrcfractal-semantic-graphseu-ai-actarticle](every-risk-is-already-accepted.md) [**The future of news is the story vault, not the paywall**2026-09-22The news industry runs on two commercial models, advertising and subscriptions, and both are bad for the reader. One sells the reader to somebody else. The other charges rent on something most people have stopped using. Both are now being dismantled from outside, by a search layer that has stopped sending traffic and by consumer law that arrives in January 2027. This article is about what to build instead, in practical terms. The objective is a commercial model that rewards investigative journalism, so that the expensive, evidenced kind of reporting drives usage, usage drives revenue that depends on neither search nor renewals, and that revenue funds more of the same. The mechanism is to stop selling the article and start selling what the article was made from. The story is a graph, a fractal semantic graph in which meaning comes from connectivity and every claim walks down to hashed evidence, so that trust comes through provenance and provenance comes via evidence. The article is one projection of it. From that one graph a newsroom can sell five things, on demand and in pence, to readers, to firms and to agents, and every payment walks back to the people who made the facts. It is built, in parts, on things we have already published.newspublishingprovenancemicropaymentssemantic-graphsarticle](future-of-news-story-vault-not-paywall.md) [**The SaaS apocalypse will be decided by inertia, not by AI**2026-09-21The SaaS apocalypse has not happened yet, and the market has already declared it cancelled once. It remains a very strong possibility, argued here with data rather than vibes. Most users were never happy, most features were never used, and most licences sit idle, because success bred inertia and inertia bred lock-in. Now anybody can brief the software they actually want, and the portability, APIs and schemas that SaaS companies refused to build are precisely what an agent needs. It will be decided by inertia, not by AI, because AI is available to both sides: the incumbents have the same models as the newcomers, plus more data, more engineers and more money, and if the technology were the deciding factor they would already have won. Nokia when the mobile phone arrived had nothing to protect, and moved. Nokia when the iPhone arrived had fifteen years of success to protect, and did not. Which side of that path each SaaS provider ends up on will be settled by where it sits on the evolution axis and how much it has to protect, which is why the newcomers, not the incumbents, are the ones to watch.saasstrategywardley-mapsagentsarticle](saas-apocalypse-decided-by-inertia-not-by-ai.md) [**For a startup, the most important question is whether they miss it**2026-09-21A startup operating and investing model in three pillars. Ship something somebody can actually use, give it away briefly, then take it away and find out whether anybody notices. Be profitable before you raise, so the investors are calling you rather than the other way round. And open source everything, because the technology was never the moat.startupsstrategyopen-sourceinvestingarticle](the-question-is-whether-they-miss-it.md) [**Fractal Semantic Graphs: everything connects to everything, and nobody has to share a schema**2026-09-20The introduction to the term. Four words and only one of them new; the test that decides whether something deserves the word, worked from a risk register to a TCP packet; why every file format is already a graph; the five-rule grammar; the evidence, eleven altitudes across seven live vaults; what is still modelled rather than imported; and why now.graphsmethodfractal-semantic-graphsarticle](introducing-fractal-semantic-graphs.md) [**The proof is two clicks behind the claim, what the homepage gets wrong, and the fix**2026-09-07Twenty-five real vaults a stranger can open in one click are the most persuasive thing on this site, and the homepage shows none of them. It leads with encryption, which cannot be seen, and buries the artefacts under a table. This is the diagnosis, with screenshots, before the rebuild, and the second article will show what changed.homepagepositioningvaultsagents](proof-behind-the-claim.md) [**The proof moved up, the homepage after the rebuild, next to the before pictures**2026-09-07The previous article diagnosed a homepage that led with encryption and buried twenty-five real vaults under a table. This is the rebuild, put beside those screenshots, what moved, what was cut, what it is generated from, and the one thing it still cannot show.homepagepositioningvaultsagents](proof-moved-up.md) [**A chat box on a site with no server, the plan, and the trade it makes**2026-08-27Nineteen sibling sites is too many to browse, so the directory now answers questions. The design problem is that sgit.ai has no server and no vault host, which means the honest options are a local matcher, a key in your browser, or moving the page into a vault, and only one of those is free.chatllmbyokplan](chat-on-a-static-site.md) [**Twenty sites in fifteen days, and what that did to the writing**2026-08-26The thinking behind sgit stopped fitting on one site. It moved out to nineteen siblings on *.sgit.ai, what forced the split, what it cost, and why the index into them now starts with a question instead of a list.networkpublishingmethod](nineteen-sites.md) [**Git for things you cannot put on GitHub**2026-08-25An introduction to sgit and sgit.ai, what an encrypted vault is, why version control had to be rebuilt to get one, and what nineteen published vaults look like when the server storing them cannot read a byte.introzero-knowledgevaultsagents](what-sgit-is.md) [**Seven vaults, one method**2026-08-19Publishing seven encrypted vaults in a fortnight turned an ad-hoc process into a repeatable one. Every rule in it exists because something went wrong first, including three vault keys submitted for publication that would have handed the world write access.vaultspublishingmethod](seven-vaults-one-method.md) [**Green does not mean live**2026-08-17Two releases pushed cleanly, reported success, and never reached the site. Every check we had was green, because the failure happened in a place none of them could see. What we changed, and the general rule underneath it.cideployverification](green-does-not-mean-live.md)



==============================================================================
# The sgit.ai network, sibling sites

> Focused sites on *.sgit.ai subdomains, each pursuing one question further than a section here could: non-human identity for rented agents, and a key registry designed from the 2019 keyserver failure. Screenshots of each, with what it argues and why it is relevant.
>
> Page: https://sgit.ai/network/index.html

# The sgit.ai network

Nineteen focused sites on `*.sgit.ai`, each taking one question further than a section here could. They share this site's design and its discipline (sourced claims, a stated status, honest edges) and they publish their arguments **before** the things they describe exist, so the commitments stay checkable afterwards.

27 live, 0 with the repository and subdomain in place but nothing published yet. Screenshots are of the real sites, captured on the date each entry gives.

**Which of these is mine?**instant match · no key, no network

Describe what you are trying to do and I will point at the site that takes it seriously. This runs in your browser against the catalogue on this page, no key needed, nothing sent anywhere.

Optional. Answers get more conversational; the matching does not get more correct.

**Bring your own key (OpenRouter).** It is stored in this browser only and sent only to `openrouter.ai`, never to sgit.ai, which is a static site with no server to send it to. **This page cannot protect it the way a vault app can**: with no host there is no permission floor, so the key lives in this page's origin. [llms.sgit.ai ↗](https://llms.sgit.ai) explains the difference, and [the plan](../articles/chat-on-a-static-site.md) explains how we intend to remove the trade-off.

## Start from what you need

Each line is a question somebody actually arrives with, and the site that takes it seriously.

[I need to give an AI agent an identity**nhi.sgit.ai** · agents you run vs agents you rent, and why only one is answered](nhi.md) [My app has to call an LLM and I do not want it holding an API key**llms.sgit.ai** ↗ · the bridge that lets it call one without a credential](https://llms.sgit.ai) [I have to sign off a risk and I do not want to rubber-stamp it**risks.sgit.ai** ↗ · there is no deny button, only how long you accept it](https://risks.sgit.ai) [I need to cite a regulation precisely, not paraphrase it**standards.sgit.ai** ↗ · point at the provision, or you are asserting](https://standards.sgit.ai) [I want to distribute public keys without a central authority**pki.sgit.ai** · a key registry for agents, designed from a directory that was destroyed](pki.md) [I am drawing a graph and want to get the edges right**graphs.sgit.ai** · five rules, and why relates-to is banned](graphs.md) [I want an issue tracker with no database**issues-fs.sgit.ai** ↗ · the issues are files and the files are a graph](https://issues-fs.sgit.ai) [I need somewhere disposable to run an agent**sg-compute.sgit.ai** ↗ · ephemeral AWS environments, one command away](https://sg-compute.sgit.ai) [I am deciding how to license and sustain an open-source project**open-source.sgit.ai** ↗ · open source is a strategy, not a charity](https://open-source.sgit.ai) [I keep being asked what a digital twin actually is**twins.sgit.ai** ↗ · an interface to reality, not a simulation of it](https://twins.sgit.ai) [I want to protect an app at the edge without renting a WAF**sg-sentinel.sgit.ai** · an app-coupled edge guard, published as a design, not built](sg-sentinel.md) [I want to map a strategy without drawing a pretty picture**wardley-maps.sgit.ai** ↗ · maps are claims, not pictures](https://wardley-maps.sgit.ai) [I need the requirements nobody writes down until they break**nfrs.sgit.ai** ↗ · resilience, budgets and backups, from the inside](https://nfrs.sgit.ai) [I want to know how this code is actually written**coding.sgit.ai** ↗ · the style guide that measured itself](https://coding.sgit.ai) [I am pricing something and rent feels wrong**subscriptions.sgit.ai** ↗ · a subscription is a discount for regular use, not rent](https://subscriptions.sgit.ai) [I care where a published fact came from**newsroom.sgit.ai** ↗ · the story is a graph; the article is a projection](https://newsroom.sgit.ai) [I just want the picture**infographics.sgit.ai** ↗ · every rendered brief in one catalogue](https://infographics.sgit.ai)

## Agents & AI

[**chrome-extensions.sgit.ai**The expensive bugs do not throw.Guidance and worked examples for building Chrome extensions, written for the agent that reads them before writing one, from five weeks building a Manifest V3 recorder against a changing, undocumented target: the method, the architecture and the failure modes.](https://chrome-extensions.sgit.ai)
v0.1.0[Open chrome-extensions.sgit.ai ↗](https://chrome-extensions.sgit.ai)

[**coding.sgit.ai**The style guide that measured itself.How software actually gets written across this family: the rules, the compliance measurement against them, which rules are machine-enforced and which are explicitly not, and the open tensions. Includes a section on writing code for agents to read.](https://coding.sgit.ai)
v0.2.0[Open coding.sgit.ai ↗](https://coding.sgit.ai)

[**elevenlabs.providers.sgit.ai**What it cost on a named workload, on a named date.An independent report on the ElevenLabs API: what it cost on a named workload on a named date, what broke, and which of four client-side credential patterns the product can actually support.](https://elevenlabs.providers.sgit.ai)
v0.3.0[Open elevenlabs.providers.sgit.ai ↗](https://elevenlabs.providers.sgit.ai)

[**games.sgit.ai**A game makes you say what you think, before you are told.Why this family builds games: a game is the only artefact that makes somebody state a belief before they are told the answer. The catalogue, the method, and how to build one as a vault.](https://games.sgit.ai)
v0.4.1[Open games.sgit.ai ↗](https://games.sgit.ai)

[**llms.sgit.ai**Your app calls a language model without ever holding an API key.The sg.llm.* bridge: how an app running inside a vault reaches a model with no credential of its own. The reference, the traps, a four-layer security ladder, the attached-file question, and a pre-ship checklist.](https://llms.sgit.ai)
reference draftv0.2.0[Open llms.sgit.ai ↗](https://llms.sgit.ai)

[**nhi.sgit.ai**The question splits into two populations, and the industry only answers oneThe question of how to give an AI agent an identity splits into two populations, and every product on the market answers only the first. For the agents you actually name (the ones running in Claude, Codex or behind an API) the honest current answer is to hand over a broad credential and hope.](nhi.md)
v0.1.14[What it argues →](nhi.md) · [Open nhi.sgit.ai ↗](https://nhi.sgit.ai)

[**providers.sgit.ai**Where the key goes.The hub of the *.providers.sgit.ai family: four credential patterns, one page contract, and one site per provider reporting what it cost on a named workload, what broke, and where the key has to live.](https://providers.sgit.ai)
v0.1.1[Open providers.sgit.ai ↗](https://providers.sgit.ai)

[**skills.sgit.ai**Skills are software packages, and here is the proof.Eight skills shipped, generated from their own frontmatter; 25 briefs and 60,782 words of theory a long way ahead of them; and the diverging duplicate that is the thesis failing, live, on the estate's own skills.](https://skills.sgit.ai)
v0.1.0[Open skills.sgit.ai ↗](https://skills.sgit.ai)

[**teams.sgit.ai**Roles are boundaries. The Conductor never does the work.The reference for setting up agentic teams with more than one role, measured from 39 ROLE.md files across four team instantiations.](https://teams.sgit.ai)
v0.1.0[Open teams.sgit.ai ↗](https://teams.sgit.ai)

[**ungovr.providers.sgit.ai**One derivable hop away.An independent report on the UnGovr Open Data API: 327,138 government entities, 398 open-records laws, free under CC BY 4.0, and a join between them that is one derivable hop away.](https://ungovr.providers.sgit.ai)
v0.1.14[Open ungovr.providers.sgit.ai ↗](https://ungovr.providers.sgit.ai)

[**what-can-it-do.games.sgit.ai**You score for how well you know what you know.A five-minute game: name the AI assistant you use, answer forty questions about what it can do and whether you wanted it to, and score for how well you know what you know. Free, no sign-up.](https://what-can-it-do.games.sgit.ai)
v0.6.0[Open what-can-it-do.games.sgit.ai ↗](https://what-can-it-do.games.sgit.ai)

## Risk & governance

[**nfrs.sgit.ai**The non-functional requirements, from the inside.The requirements nobody writes down until they are violated (resilience, budgets, project management, backups) treated as a reality system rather than a checklist. Includes an honest column: a scorecard, and a page naming backups as a gap.](https://nfrs.sgit.ai)
v0.1.2[Open nfrs.sgit.ai ↗](https://nfrs.sgit.ai)

[**risks.sgit.ai**You cannot deny a risk. You can only say how long you accept it.Risk management inverted: a named human underwrites an exposure that already exists, insurance-style, with personal liability attached. There is no deny button, the only choice is how long, and the interval is the decision. 42 concepts, a six-rung interval ladder, and a stated zero lines of code implementing any of it.](https://risks.sgit.ai)
research sitev0.1.0[Open risks.sgit.ai ↗](https://risks.sgit.ai)

[**standards.sgit.ai**Point at the provision, or you are asserting.Laws, standards and frameworks as addressable graphs rather than PDFs to paraphrase. A citation scheme, a grounding ladder, and worked instruments (the EU AI Act, GDPR, ISO/IEC 27001, ISO 31000) with a subset method for handing an agent only the part that applies.](https://standards.sgit.ai)
v0.1.4[Open standards.sgit.ai ↗](https://standards.sgit.ai)

[**threat-modeling.sgit.ai**A threat model is a claim you can check.A threat model is a claim about a system, and this site's job is to show claims being checked: the ThreatModCon 2025 vault, a threat model validated against the code, seven white papers, and the redacted method behind them.](https://threat-modeling.sgit.ai)
[Open threat-modeling.sgit.ai ↗](https://threat-modeling.sgit.ai)

## Graphs & method

[**graphs.sgit.ai**A node is just a node. Meaning lives in the edges.A grammar for semantic graphs, argued in increasing depth from five rules you can apply tomorrow to a full positioning against schemas and vector search. It opens by insisting it is not a graph database pitch, and it publishes the four situations in which its own argument is the wrong one.](graphs.md)
v0.1.0[What it argues →](graphs.md) · [Open graphs.sgit.ai ↗](https://graphs.sgit.ai)

[**infographics.sgit.ai**The brief is the argument. The infographic is one picture of it.A catalogue, not a generator: every rendered brief across the sgit.ai family in one place, each picture kept next to the argument it came from rather than circulating on its own.](https://infographics.sgit.ai)
v0.1.0[Open infographics.sgit.ai ↗](https://infographics.sgit.ai)

[**issues-fs.sgit.ai**The issues are files. The files are a graph.An issue tracker with no database: nodes, edges and labels on disk, a small DSL, and a live graph derived from the repository itself. Ships a five-minutes-no-install lite mode for agents alongside the full model.](https://issues-fs.sgit.ai)
reference draftv0.1.2[Open issues-fs.sgit.ai ↗](https://issues-fs.sgit.ai)

[**twins.sgit.ai**A digital twin is an interface to reality, not a simulation of it.Twins as actors rather than models: what a working twin actually is, what was built versus designed, the simulation layer, and an execution broker. Carries its own gaps-and-open-questions page and a where-we-lose section.](https://twins.sgit.ai)
v0.1.0[Open twins.sgit.ai ↗](https://twins.sgit.ai)

[**wardley-maps.sgit.ai**Maps are claims, not pictures.Wardley mapping treated as graphs with position, so a map becomes something you can disagree with precisely. A 40-record doctrine assessment, the custom-axis verdict, the broken middle, and all 34 resources verified with dead links marked.](https://wardley-maps.sgit.ai)
PROPOSEDv0.1.2[Open wardley-maps.sgit.ai ↗](https://wardley-maps.sgit.ai)

## Security & infrastructure

[**pki.sgit.ai**Good public key repositories existed, and were destroyedGood public key repositories existed and were destroyed. This site is the 2019 keyserver catastrophe, the four registry rules it produces, and the build order, all published before the registry exists, so the commitments are checkable against whatever eventually ships.](pki.md)
v0.1.2[What it argues →](pki.md) · [Open pki.sgit.ai ↗](https://pki.sgit.ai)

[**sg-compute.sgit.ai**Ephemeral environments in AWS, one command away.A serverless environment for agents: the machine surface, isolation and the one trade-off it makes, measured numbers rather than claims, and a clear what-ships-today line against the roadmap.](https://sg-compute.sgit.ai)
v0.2.0[Open sg-compute.sgit.ai ↗](https://sg-compute.sgit.ai)

[**sg-sentinel.sgit.ai**Layer 1 decides and signals. Layer 2 acts and writes.A design for an edge security and logging layer you own rather than rent, built on the observation that your own app already knows what a valid request looks like, so the edge can allowlist rather than denylist. Published as a complete design that has deliberately not been built.](sg-sentinel.md)
v0.1.1[What it argues →](sg-sentinel.md) · [Open sg-sentinel.sgit.ai ↗](https://sg-sentinel.sgit.ai)

## Business & publishing

[**influences.sgit.ai**Where the thinking came from.The sources behind this body of work, registered rather than gestured at, an influence map in three tiers, a register format, a changelog recording when a source moves between tiers, and a distinction between what was designed and what was discovered then confirmed.](https://influences.sgit.ai)
v0.2.0[Open influences.sgit.ai ↗](https://influences.sgit.ai)

[**newsroom.sgit.ai**The story is a graph. The article is a projection.Provenance as the product: a worked story costed at £8.40, payment rails to the fact creator, micro and nano payments, CC-Signed content rights, and the roles an operating newsroom would need. A published design, not a running newsroom.](https://newsroom.sgit.ai)
not builtv0.2.5[Open newsroom.sgit.ai ↗](https://newsroom.sgit.ai)

[**open-source.sgit.ai**Open source is a strategy. It is not a charity.Survivability as the test rather than licence purity: a stress test, a self-audit, six recorded corrections, six success stories with numbers, three licences compared, and why Apache-2.0 rather than MIT here.](https://open-source.sgit.ai)
draftv0.1.1[Open open-source.sgit.ai ↗](https://open-source.sgit.ai)

[**subscriptions.sgit.ai**A subscription is a discount for regular use, not rent on something you ignore.The commercial model stated as a position: a register of what you actually hold, governance and schema, an exit-path method, and the law behind it, with the service itself marked as later, not now.](https://subscriptions.sgit.ai)
draftv0.1.0[Open subscriptions.sgit.ai ↗](https://subscriptions.sgit.ai)

## Every site, at a glance

| Site | What it argues | Area | Status |  |
|---|---|---|---|---|
| **chrome-extensions.sgit.ai** | The expensive bugs do not throw. | Agents & AI | live · `v0.1.0` | [open ↗](https://chrome-extensions.sgit.ai) |
| **coding.sgit.ai** | The style guide that measured itself. | Agents & AI | live · `v0.2.0` | [open ↗](https://coding.sgit.ai) |
| **elevenlabs.providers.sgit.ai** | What it cost on a named workload, on a named date. | Agents & AI | live · `v0.3.0` | [open ↗](https://elevenlabs.providers.sgit.ai) |
| **games.sgit.ai** | A game makes you say what you think, before you are told. | Agents & AI | live · `v0.4.1` | [open ↗](https://games.sgit.ai) |
| [graphs.sgit.ai](graphs.md) | A node is just a node. Meaning lives in the edges. | Graphs & method | live · `v0.1.0` | [open ↗](https://graphs.sgit.ai) |
| **influences.sgit.ai** | Where the thinking came from. | Business & publishing | live · `v0.2.0` | [open ↗](https://influences.sgit.ai) |
| **infographics.sgit.ai** | The brief is the argument. The infographic is one picture of it. | Graphs & method | live · `v0.1.0` | [open ↗](https://infographics.sgit.ai) |
| **issues-fs.sgit.ai** | The issues are files. The files are a graph. | Graphs & method | reference draft · `v0.1.2` | [open ↗](https://issues-fs.sgit.ai) |
| **llms.sgit.ai** | Your app calls a language model without ever holding an API key. | Agents & AI | reference draft · `v0.2.0` | [open ↗](https://llms.sgit.ai) |
| **newsroom.sgit.ai** | The story is a graph. The article is a projection. | Business & publishing | not built · `v0.2.5` | [open ↗](https://newsroom.sgit.ai) |
| **nfrs.sgit.ai** | The non-functional requirements, from the inside. | Risk & governance | live · `v0.1.2` | [open ↗](https://nfrs.sgit.ai) |
| [nhi.sgit.ai](nhi.md) | The question splits into two populations, and the industry only answers one | Agents & AI | live · `v0.1.14` | [open ↗](https://nhi.sgit.ai) |
| **open-source.sgit.ai** | Open source is a strategy. It is not a charity. | Business & publishing | draft · `v0.1.1` | [open ↗](https://open-source.sgit.ai) |
| [pki.sgit.ai](pki.md) | Good public key repositories existed, and were destroyed | Security & infrastructure | live · `v0.1.2` | [open ↗](https://pki.sgit.ai) |
| **providers.sgit.ai** | Where the key goes. | Agents & AI | live · `v0.1.1` | [open ↗](https://providers.sgit.ai) |
| **risks.sgit.ai** | You cannot deny a risk. You can only say how long you accept it. | Risk & governance | research site · `v0.1.0` | [open ↗](https://risks.sgit.ai) |
| **sg-compute.sgit.ai** | Ephemeral environments in AWS, one command away. | Security & infrastructure | live · `v0.2.0` | [open ↗](https://sg-compute.sgit.ai) |
| [sg-sentinel.sgit.ai](sg-sentinel.md) | Layer 1 decides and signals. Layer 2 acts and writes. | Security & infrastructure | live · `v0.1.1` | [open ↗](https://sg-sentinel.sgit.ai) |
| **skills.sgit.ai** | Skills are software packages, and here is the proof. | Agents & AI | live · `v0.1.0` | [open ↗](https://skills.sgit.ai) |
| **standards.sgit.ai** | Point at the provision, or you are asserting. | Risk & governance | live · `v0.1.4` | [open ↗](https://standards.sgit.ai) |
| **subscriptions.sgit.ai** | A subscription is a discount for regular use, not rent on something you ignore. | Business & publishing | draft · `v0.1.0` | [open ↗](https://subscriptions.sgit.ai) |
| **teams.sgit.ai** | Roles are boundaries. The Conductor never does the work. | Agents & AI | live · `v0.1.0` | [open ↗](https://teams.sgit.ai) |
| **threat-modeling.sgit.ai** | A threat model is a claim you can check. | Risk & governance | live | [open ↗](https://threat-modeling.sgit.ai) |
| **twins.sgit.ai** | A digital twin is an interface to reality, not a simulation of it. | Graphs & method | live · `v0.1.0` | [open ↗](https://twins.sgit.ai) |
| **ungovr.providers.sgit.ai** | One derivable hop away. | Agents & AI | live · `v0.1.14` | [open ↗](https://ungovr.providers.sgit.ai) |
| **wardley-maps.sgit.ai** | Maps are claims, not pictures. | Graphs & method | PROPOSED · `v0.1.2` | [open ↗](https://wardley-maps.sgit.ai) |
| **what-can-it-do.games.sgit.ai** | You score for how well you know what you know. | Agents & AI | live · `v0.6.0` | [open ↗](https://what-can-it-do.games.sgit.ai) |

## Read one in full

Four have a full write-up here, what the site argues, where it is honest about its limits, and why it is relevant to sgit:

- [**graphs.sgit.ai**](graphs.md), A node is just a node, meaning lives in the edges
- [**nhi.sgit.ai**](nhi.md), Agents you run, agents you rent, and the identity gap
- [**pki.sgit.ai**](pki.md), A key registry for agents, designed from a documented failure
- [**sg-sentinel.sgit.ai**](sg-sentinel.md), An app-coupled edge guard, Layer 1 decides, Layer 2 acts

## Why they are separate sites

Each one is an argument that needs room and a reader who arrived for it. Splitting them out keeps this site about sgit while letting each question be pursued properly, and gives each its own version history, release cadence and repository. They are built from the same generator and hold to the same rules, so a reader moving between them is not changing register.

This is also the refactor it looks like: material that would have made sgit.ai sprawl now has a better home, and this page is the index back into it. Adding the twentieth site is writing one markdown file.



==============================================================================
# Vault App Mode, a published vault

> Nine progressive proof-of-concepts and a four-page demo showing how to load CSS, JavaScript and data inside an encrypted vault, including a fifteen-test harness over the vault filesystem, and the audit that found the original could not be opened by a read key at all.
>
> Page: https://sgit.ai/demos/vaults/vault-app-pocs/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Vault App Mode

# Vault App Mode, nine POCs and a demo

The simplest vault on this site, and the one to read first if you are going to build one. Nine proof-of-concepts climb from a single inline HTML file to a fifteen-test diagnostic harness over the vault filesystem, then a small four-page app puts the lot together. It answers one question end to end: how do you load CSS, JavaScript and data when your files live in an encrypted vault instead of on a web server?

**The one problem everything here solves.** The HTML parser fires requests for `<link>` and `<script src>` the moment it meets them, before the vault bridge has patched `fetch`. Those requests hit the iframe's blob origin, where no files exist, and 404. So vault pages load their resources at *runtime*, with `sg.loadCss()` and `sg.loadJs()`. Every POC in this vault is a consequence of that one race.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_05f2391f22e4135ea27bca6b697dca18c54ab91b046325bef74f62f5324b8bc8:xth1xt78`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_05f2391f22e4135ea27bca6b697dca18c54ab91b046325bef74f62f5324b8bc8%3Axth1xt78) · From the CLI: `sgit clone sgit_public_read_05f2391f22e4135ea27bca6b697dca18c54ab91b046325bef74f62f5324b8bc8:xth1xt78`
Published deliberately. It grants read, and only read. This is a republication, the vault this content was authored in could not be opened by a read key at all, for a reason worth reading in the audit below.

## See it live, here

Both surfaces open automatically below. You can also [**open the app in its own window ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_05f2391f22e4135ea27bca6b697dca18c54ab91b046325bef74f62f5324b8bc8%3Axth1xt78).

## What this vault demonstrates

| Feature | How this vault uses it |
|---|---|
| **Runtime resource loading** | `sg.loadCss()` and `sg.loadJs()` fetch vault files through the bridge and inject them, because declarative tags lose the race against the parser. POC-02 and POC-03 isolate each one; POC-04 shows dependency order between modules |
| The filesystem, read and written | `sg.vfs.readText()` in POC-07, `sg.vfs.write()` in POC-08, which persists a real JSON file into the vault and lists it back. Writes are **local-first**: they live in the working copy until an `sgit push`, and the POC says so rather than implying instant durability |
| **A test harness for the platform itself** | POC-09 is the unusual one: fifteen graded operations over `sg.vfs` (read, write, list, nested folders, binary round-trips, deliberate error cases, path-variant comparison) each showing the exact call, the raw result, per-assertion pass/fail and timing. It exists because guessing at the API's behaviour cost a session; instrumenting it settled the question |
| Paths, the thing that actually bites | `sg.vfs` takes **vault-absolute** paths, and a page's own folder is knowable only from `sg.app.selfPath`, `location.pathname` is always `/` inside the iframe. The vault documents this as its most important rule, and POC-09's environment readout prints the ground truth |
| FOUC handled deliberately | pages hide the body until their CSS resolves, then reveal by **removing a class**. The distinction matters: clearing an inline style cannot override a stylesheet rule, which is exactly the bug this vault was carrying when it arrived (see the audit) |
| Its own failure modes, on a page | the survey ships a **Try the failure modes** panel that attempts writes which *should* be rejected (path traversal, URL-encoded traversal, a protected `.vault-settings.json`, a null byte, a 1500-character path) so the guards are demonstrated rather than asserted |
| The reasoning ships with it | `_docs/` carries a field guide (the canonical page skeleton and path rules), a gotchas manual written by symptom, and a debrief explaining why the code looks the way it does. It is the best-documented vault on this site for its size |

## What is going on here, step by step

The embeds above are the real vault, which makes it easy to scroll past the parts that matter. Each row points at one of them. Every screenshot is of this vault, driven by a script holding nothing but the published read key.

what opens

### A contents page, not a file listing

Opening the read key lands on the POC hub, `app.json` sets `entry` to `_poc-hub/index.html`. The steps are numbered like a magazine contents page, each card tagged with the API it exercises and a difficulty level, with the diagnostic lab and the demo as full-width cards beneath.

It is worth noticing what this *is*: a static HTML file in an encrypted store, rendering as a navigable site, with no server anywhere in the path.

The hub, nine numbered steps, tagged by the API each one exercises.

the baseline

### POC-01: everything inline, so nothing can fail

The first step deliberately has no external files at all, CSS in a `<style>` block, JS in a `<script>` block. It is the control case: if this renders, the vault is serving your HTML correctly and anything that breaks later is about *resource loading*, not about the vault.

It is also the one page that does not use the shared stylesheet, because loading one would contradict the point it is making.

The control case, no external files, so nothing can 404.

the fix, isolated

### POC-02: one CSS file, loaded at runtime

The smallest possible demonstration of the pattern. One `sg.loadCss()` call in a head script, and the FOUC guard around it: the body starts hidden and is revealed when the promise settles, *including* when it rejects, so a failed load leaves a readable page rather than a permanently invisible one.

The status pill on the page reports the load lifecycle as it happens, which makes the async step visible instead of theoretical.

One `sg.loadCss()`, with the reveal guarded on both outcomes.

order matters

### POC-04: two modules, and the dependency between them

Once JavaScript arrives at runtime, load order becomes yours to manage. `utils.js` must execute before `app.js` can call into it, so the POC awaits them in sequence and logs each step with a `[poc-04]` prefix.

The parallel case is covered too: independent resources go through `Promise.all`, because serialising things that do not depend on each other is just a slower page.

Sequential where there is a dependency, parallel where there is not.

data

### POC-05: `fetch()` works, because the bridge intercepts it

Once the bridge is installed, an ordinary `fetch('data.json')` resolves against the vault. No special API, no rewriting of your data layer, the call you would already have written works, which is the point of intercepting `fetch` rather than replacing it.

This is the step where a vault app stops looking exotic and starts looking like a normal front end that happens to have an encrypted origin.

An ordinary `fetch()`, resolved against encrypted storage.

writing

### POC-08: a form that puts a real file in the vault

Submitting writes `responses/poc-08-<timestamp>.json` through `sg.vfs.write()`, then the page lists what is there and lets you edit or delete it. The delete control only appears if `sg.vfs.delete` actually exists, capability-checked rather than assumed.

The callout that matters is the honest one: writes are **local-first**. They live in the working copy until someone runs `sgit push`, which the vault demonstrated the hard way, a submission made in one browser session was gone from a fresh one until the push happened.

A real write, with the local-first caveat stated rather than glossed.

the interesting one

### POC-09: testing the platform instead of trusting it

Fifteen graded tests over `sg.vfs`, each card showing the exact call with its resolved arguments, the raw result, a live progress log, per-assertion pass/fail and a runtime in milliseconds. Above them, an environment readout printing `location.href`, `location.pathname`, `sg.app.selfPath` and the keys actually present on `sg.vfs` and `sg.app`.

It was built mid-project when path bugs kept multiplying, on the reasoning that the API should be measured rather than guessed at. It is the most transferable idea in the vault: when a platform surprises you, instrument it and keep the instrument.

A test harness for the vault filesystem, kept as part of the vault.

all together

### The cities demo: four pages, one data file

The demo hub offers a bar chart, a world map, a survey and a responses viewer, each tagged **READ-ONLY** or **WRITES** so you know what it will do before you click. The chart and the map read the same `cities.json` and render it two ways; editing that one file in the vault browser changes both.

This hub could not be reached at all before publication, see the audit. It is now linked from the POC hub, which is how you get here.

Four pages over one data file, each labelled with what it will do.

read and render

### The same data, drawn two ways

The bar chart reads `cities.json` through the bridge and draws from it directly. The map projects the same records onto an equirectangular world and doubles as a navigation test, proving that same-vault `<a href>` links resolve correctly between pages.

Nothing here is fetched from the network. The data, the code and the styling are all objects in the encrypted store, decrypted in the reader's browser.

One `cities.json`, rendered by two pages that never touch the network.

write, then read back

### The survey, and its own failure modes

The form writes a JSON file per submission and offers two submit buttons, the canonical `sg.vfs.write()` and the `window.sgVault.writeFile` alias, so you can confirm both produce identical commits.

Underneath is the panel worth the visit: **Try the failure modes**, six buttons that attempt writes which must be refused. Path traversal, URL-encoded traversal, the protected settings file, a null byte, a path past the length cap. A demo that shows you its guards working is a stronger claim than one that tells you they exist.

Two write paths, and six writes that are supposed to be refused.

list, read, aggregate

### The viewer, including the response that is trying to attack it

`sg.vfs.list()` enumerates the responses folder, `sg.vfs.readText()` reads each file, and the page aggregates live: total responses, average excitement, top role, total bytes. A **View raw** control dumps the unprocessed listing so you can see what the API actually returned.

The first card is deliberate. One stored response carries `<img src=x onerror=alert(1)>` in its name field, and the viewer renders it as *visible text*. It is a standing escaping test, kept in the data so that a regression on either render path would be obvious on sight, which matters, because that is a bug this vault actually had.

Three responses, aggregates computed live, and a payload rendered, correctly, as text.

the source

### Everything is readable, including the parts that explain it

The vault browser shows the whole tree under the same read key: nine POC folders, the shared stylesheet, the demo, and `_docs/`, a field guide, a gotchas manual organised by symptom, and a project debrief.

That last folder is why this vault is worth copying as a pattern. The code demonstrates the technique; the docs record what went wrong on the way, which is the part that usually evaporates when a project ends.

The tree under one read key, including the write-up of its own mistakes.

## The audit, honestly

This vault was reviewed before its key was published, and the review changed both the vault and what got published. Findings first.

**The submitted vault could not be opened by a read key at all.** Its read key decrypted every object correctly, verified by decrypting its HEAD ref by hand, but the reader could never *find* HEAD. sgit has two ways of assigning a vault's ref file id: `Vault__Crypto` derives it from the read key and vault id, while `Vault__Branch_Manager` falls back to `'ref-pid-muw-' + secrets.token_hex(6)`, a random value. This vault got a random one. Browser readers derive the id, so they looked in the right place for a file stored under a name nothing could compute. The CLI worked throughout, because it resolves HEAD through the branch index instead. sgit's own tooling states the consequence plainly: *"write_key, ref_file_id, and branch_index_file_id are not derivable from a read_key alone."* A read key published for that vault would have been a credential that decrypts everything and opens nothing, so the content was republished into a new vault, `xth1xt78`, created through the deriving path.

**The whole cities demo rendered blank.** Four pages set `body { display: none }` in a stylesheet and cleared it with `document.body.style.display = ''`. That clears an *inline* property which was never set; the stylesheet rule kept applying and the pages stayed invisible. The host said so out loud, *"App loaded but is showing nothing, hidden (display:none)"*: for the hub, the map, the survey and the responses viewer. Only the bar chart, which has no such script, was unaffected. Fixed by hiding through a class and removing it, which is the pattern the POCs already used and the vault's own gotchas file documents.

**The demo was unreachable.** `app.json` opens the POC hub; the hub linked only the nine POCs; and the demo's own hub linked back to it. A one-way door, with a third of the vault behind it. The hub now carries a card for it.

**Two survey pages pointed at files that were not there.** Both live in `demo-cities/survey/` but named `style.css` and `hub.html` as though they sat a level up, so each had a missing stylesheet and a dead back-link. Separately, both used relative paths for `sg.vfs`, `list('responses/')` returned *"No such path"*, which is precisely the gotcha this vault's own documentation warns about. They now derive the folder from `sg.app.selfPath`, the way POC-09 does, and normalise `entry.path` to absolute before reading, which was doubling the prefix.

**A stored-XSS gap on the error path.** The responses viewer escaped every field it rendered on the success path, and interpolated the filename and error text raw on its two failure paths. The vault contained an unlabelled XSS payload in a leftover test response, so someone had clearly probed this and fixed only the half that showed. Both paths now escape, and the payload has been kept deliberately, rewritten as a labelled escaping test, so the property stays visible in the UI rather than living in a comment.

**Removed, not fixed:** an empty zero-byte `check-undefined.html` referenced by nothing, and `POC_STRUCTURE.md`, whose guidance had been superseded by `_docs/` and whose structure diagram described a six-POC vault under a former name. `README.md` was rewritten for the same reason, it named the wrong entry point and omitted three POCs. Both files remain in the vault's history.

**The credential finding.** The vault's own documentation recorded the project's push token in plain text, three times, as part of the workflow instructions. Publishing a read key would have handed that out with the content. The token has been replaced with a placeholder; the instructions still read correctly. The vault is otherwise clean on credentials, no vault key inside its own files, no `sgit_vk1_` or `sgit_private_vault_` string, no `delete_auth`, no API keys or private-key blocks. All 57 files were fetched back after publication *using only the read key above* and re-scanned.

On data: the survey responses are the only personal-shaped content, and all three are invented for the demo. The rest is code, styling and documentation. The rule that goes with any published key applies here too: **revocation is not retroactive**: anybody who fetches these objects keeps them.

## Derived facts

57 files · 251 KB · 8 commits · HEAD `obj-cas-imm-4517bfe1735d` · app entry `_poc-hub/index.html` · 15 HTML, 12 JSON, 12 CSS, 10 JS, 6 markdown, derived from the read key alone by `admin/build/catalogue_derive.py`, the same derivation that populates [the catalogue](../../../catalogue/index.md), with no token and no clone.



==============================================================================
# Private Health Score, a published vault

> A complete clinical workflow as a vault: adaptive questionnaire, a versioned scoring framework loaded at runtime, explainability tracing every recommendation to an answer, and a clinician review, published as a sanitised republication after an audit found the original vault carried its own write credential.
>
> Page: https://sgit.ai/demos/vaults/health-score/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Private Health Score

# Private Health Score

A complete clinical workflow in one vault, adaptive questionnaire, a versioned scoring framework, an explainability layer that traces every recommendation back to an answer, and a clinician review screen, running entirely client-side. It is published here as a **sanitised republication**, because the vault it was built from carried its own write credential in its home page and could never have had its key published.

**The idea it is built on, in one line.** The framework, not the model, produces the recommendations. A versioned JSON standard (five dimensions, five bands, eight scoring rules) is loaded from the vault at runtime and does the scoring deterministically; the LLM writes the narrative on top and is labelled as such, with its model and cost on the page. **Never a diagnosis.** This is a proof of concept on synthetic profiles, and no compliance finding of any kind exists for it.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_a76f327fb602f1619a67a15a0b756d69e82a1f7fa48438d4b6ecbebae2dc3d40:zc6abngv`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_a76f327fb602f1619a67a15a0b756d69e82a1f7fa48438d4b6ecbebae2dc3d40%3Azc6abngv) · From the CLI: `sgit clone sgit_public_read_a76f327fb602f1619a67a15a0b756d69e82a1f7fa48438d4b6ecbebae2dc3d40:zc6abngv`
This key opens vault `zc6abngv`, the sanitised republication, **not** the vault this content was authored in, whose key was never published and never will be. See the audit below.

## See it live, here

Both surfaces open automatically below. You can also [**open the app in its own window ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_a76f327fb602f1619a67a15a0b756d69e82a1f7fa48438d4b6ecbebae2dc3d40%3Azc6abngv).

## What this vault demonstrates

| Feature | How this vault uses it |
|---|---|
| **One vault, three audiences** | `patient/`, `doctor/` and `shared/` split the same record by *who is reading it*, not by copying it. The patient fills in the questionnaire, the clinician opens a review of the same answers, and the framework and analysis both sides rely on sit in `shared/`. One credential, one copy, three views |
| The rules are data, and versioned | `shared/health-score-standard.json` is the scoring framework as a file, 5 dimensions with explicit weights (cardiovascular 25%, metabolic 20%, lifestyle 20%, wellbeing 20%, preventive care 15%), 5 bands and 8 rules, stamped `v1.0`. The viewer labels it *"loaded from vault at runtime"*, and a **Reveal JSON** button shows the source behind the rendering |
| Deterministic score, generated prose | the number comes from the framework; the LLM writes the narrative around it. The clinician screen states the provenance in the open, *AI-generated · estimated cost $0.024 · claude-sonnet-4*, and `llm-analysis.json` carries `status: pending_clinician_review`. The model's output is a draft for a human, and the file says so |
| Every recommendation traced to an answer | the explainability layer lists what helped and what hurt with the rule that decided it: *"Last Blood Test: over 2 years (scored 50/100, affects your Preventive Care score."* Its own note draws the line: *"The framework) not the AI, produced these. The AI analysis adds nuance; these are the foundations"* |
| Severity-ranked clinical actions | the review screen sorts suggested actions **URGENT → HIGH → MEDIUM → LOW** rather than presenting a flat list, and pairs them with the dimension scores that triggered them, plus an *adaptive risk gates* section showing which branches the questionnaire opened because of earlier answers |
| No account anywhere in the flow | sharing the record with a clinician is handing over a derived read key. There is no clinician login, no tenant, and no server-side copy, the vault's own architecture section states the three-credential model, and the read key you are holding is the proof |
| Permissions left undeclared | honest gap rather than a feature: `app.json` declares `entry`, `auto_open`, `present` and a HUD block, and **no permission block at all**: compare [VoiceDebrief](../voice-debrief/index.md), which scopes `fs.read` to one folder. An app that never states what it needs cannot demonstrate least authority, and will need a grant declared when the platform's deny-by-default lands |

## What is going on here, step by step

The embeds above are the real vault, which makes it easy to scroll past the parts that matter. Each row points at one of them. Every screenshot is of this vault, driven by a script holding nothing but the published read key.

what opens

### Two demo profiles, chosen to disagree

The vault opens on a hub built around two synthetic profiles that are deliberately not alike: **Alex, 34** (BMI 25.9, good lifestyle, scoring **74 · Good**) and **Sam, 47**: BMI 33.8, multiple risk factors, scoring **38 · Needs Attention**.

One profile would demonstrate the rendering. Two that land in different bands demonstrate the *framework*, because every screen after this one can be read twice and compared.

Two profiles, two bands, so every later screen can be read twice.

the patient side

### A ten-step questionnaire that branches on what you answer

The patient app is a ten-section flow (welcome, about you, lifestyle, health, history, concerns, score, AI analysis, vault save, complete) with a demo bar across the top that can drive each step or run the whole thing.

The two steps worth noticing are the last two. **Vault save** is where the record is encrypted and written, and **complete** is the final record, the flow ends by producing an artefact the person keeps, not a result page that disappears.

Ten sections, adaptive, ending in a saved encrypted record.

the rules, as a file

### The framework is versioned, readable and separate from the code

This is the part that makes the rest auditable. The scoring standard is a JSON file in the vault, rendered here as a document: five bands from **At Risk (0–29)** to **Excellent (85–100)**, and five weighted dimensions shown as a radar with the weights stated numerically beside it.

Because it is data rather than logic buried in a function, it can be versioned (`v1.0`), diffed between commits, and disagreed with. **Reveal JSON** shows the source that produced the page you are reading, the rendering and the rules are the same object.

The scoring framework as a versioned document, not as code.

explainability

### Each number carries the answer that produced it

Alex's 74 breaks into heart health 78, lifestyle 76, wellbeing 72, and then into the individual answers behind them. *"Smoking: never, scored 100/100 in the framework."* *"Alcohol: light, 90/100."* Against him: *"Last blood test: over 2 years, 50/100, affects your Preventive Care score. Framework flag: book routine blood panel."*

Three tabs sit above it (**Your Health Story**, **Score Breakdown**, **Evidence Map**) the same result at three depths. The layer's own caveat is the important sentence: the recommendations come from the framework, and the model only adds nuance on top.

Score → dimension → the specific answer and its framework rule.

the clinician side

### The same record, arranged for someone qualified to act on it

Sam's review puts the record on the left (dimension scores with the reasoning under each, then the full profile) and the AI analysis on the right, as suggested actions ranked by urgency: two **URGENT** (a GP appointment for cardiac symptoms, and a specific blood panel), three **HIGH**, then medium and low.

Two things make this more than a dashboard. The analysis is labelled *AI-generated* with its model and cost, so a clinician knows what they are reading. And beneath it is a **clinical notes** block for the reviewer's own observations, the tool expects to be corrected, and keeps the correction next to what it corrected.

Ranked actions, provenance stated, and room for the clinician to disagree.

the fix, visible

### The card that used to hold a live write key

The vault explains its own credential model in three cards: the vault key (full read/write, kept private), the derived read-only share token for the clinician, and the data location (client device only). The model is right, and it is the argument the whole demo makes.

In the original vault, the first card contained an **actual working vault key**: the real credential for the vault you were reading it in. Here it shows the *shape*, `⟨passphrase⟩:⟨vault-id⟩`, with the reason attached: a write credential is never written into the vault's own content. The teaching value survives; the credential does not.

The same three-credential explanation, with the live key removed.

a fresh vault, not a rewrite

### Two commits, both from the day it was republished

The SGit view is the evidence for the claim in the audit below. This vault's history begins on **22 August 2026** with `init`, followed by the sanitising commit. The original's 61 commits are not here, and neither is anything they contained.

That is deliberate and it is the whole point of republishing rather than patching. A read key hands over *every* commit, so deleting a credential from the current files would have left it sitting in history, reachable by anyone holding the key that was supposed to be safe to publish.

A history that starts at the republication, because the old one could not be published.

what it asks for

### A manifest that declares no permissions at all

145 bytes: an entry point, `auto_open`, `present`, and a HUD configuration that hides the vault name. There is no permission block.

Included because it is the honest weak point of an otherwise careful vault. Silence is not least authority. It is an absence of a statement, and it reads as one next to [VoiceDebrief](../voice-debrief/index.md)'s scoped `fs.read` or [Risk Graph Explorer](../risk-graph-explorer/index.md)'s deliberate empty grant. When deny-by-default lands, an app that never said what it needs is the one that stops working.

`app.json`: an entry point, a HUD, and nothing said about permissions.

## Why this shape matters beyond health

The transferable pattern is **the rules as a versioned file, the model on top, and the trace between them**. Anywhere a decision has to be explainable (lending, eligibility, triage, grading) the same split applies: put the criteria in a document that can be versioned and argued with, compute deterministically against it, let the model write the part humans read, and label which is which. The failure mode this avoids is the one where nobody can say afterwards whether the number came from a rule or from a sentence a model produced.

The vault-shaped part is that sharing with a professional is **handing over a derived read key**, not creating them an account. The nearest thing on this site is [Supplement Stack](../supplement-stack/index.md), which does the same for a patient-held supplement record with real data; this one covers the fuller workflow, on synthetic profiles, and adds the clinician's side.

## The audit, honestly

This is the vault whose audit stopped a publication, so the finding comes first.

**The original vault published its own write credential.** `home/index.html` rendered a card labelled *"Patient vault key (write access), full read/write, patient keeps this private"*, and the value in it was the **real, working vault key for that vault**. Anyone given the read key, the credential this page exists to hand out, could have read that card and gained write access to everything in it. The read key was therefore never publishable, and was never published.

**Why a fresh vault and not a fix.** Removing the card from the current files would not have been enough: a read key grants every commit, and the credential would have remained readable in the history. So the working tree was copied, sanitised, and committed into a *new* vault (`zc6abngv`) with a new key. The original's 61 commits were left behind. This is the site's own rule ([republish, don't retrofit](../publishing.md)) applied to the case that produced it.

**What was verified, and how.** After publishing, all 35 files were fetched back *using only the read key above*, the exact credential a reader holds, and scanned. No occurrence of the original passphrase, the new passphrase, the old vault id, or any `sgit_vk1_` / `sgit_private_vault_` / `delete_auth` string. The broad secret scan across API-key, bearer-token and private-key patterns is clean too.

**On the data.** Both profiles are synthetic and say so in their own files: `profile_id: demo-alex`, `vault_commit: "simulated"`, first names only, and a postcode *area* (SW1, M1) rather than a postcode. The test-lab submissions are labelled *Test Patient (lab)*, age 99. No real person's health data is published here, which is the difference between this vault and Supplement Stack, and worth stating rather than leaving to be assumed.

**One defect found, and it is not ours.** The patient app throws `Uncaught ReferenceError: loadStandard is not defined` on load: `patient/app/data.js` calls it at line 116, while `patient/app/app.js` defines it at line 9, a load-order race. It is pre-existing, not introduced by the sanitising: `patient/index.html` is byte-identical between the original clone and this republication. The app still renders and runs, and the error is left as found rather than quietly patched, because this page publishes someone else's vault and the fix is theirs to make.

The rule that goes with any published key applies here too: **revocation is not retroactive.** Anybody who fetches these objects keeps them, and rotating the key protects future commits only.

## Derived facts

35 files · 1,224 KB · 3 commits · HEAD `obj-cas-imm-4c5c2c178517` · app entry `home/index.html` · 12 JSON, 9 HTML, 9 JS, 3 markdown, 2 CSS, derived from the read key alone by `admin/build/catalogue_derive.py`, the same derivation that populates [the catalogue](../../../catalogue/index.md), with no token and no clone.



==============================================================================
# VoiceDebrief, a published vault

> Four apps in one encrypted vault: lifting meaning from fictional voice notes to Article 9(2) of the EU AI Act into typed semantic graphs, with read scoped to one folder, write nowhere, and the briefings it was built from shipped beside the work.
>
> Page: https://sgit.ai/demos/vaults/voice-debrief/index.html

[Home](../../../index.md) / [Vaults](../index.md) / VoiceDebrief

# VoiceDebrief · Fractal Semantic Graphs

Four apps in one vault: lifting meaning out of text, from fictional voice notes to Article 9(2) of the EU AI Act, into typed semantic graphs. The current app requests read over one folder, write over nothing, and the vault ships the briefings it was built from beside the work: source material dated across June to August 2026, assembled into this vault over two days.

**The idea it is built on, in one line.** A paragraph is not a string, it is a **graph**, and so is the paragraph next to it. Lift both into typed nodes and the two can be joined *node-to-node* through an intermediate layer, never paragraph-to-paragraph. That is the fractal claim, and part 4 works it end to end against one real legal provision. The corpus in parts 1–3 is **fictional**, and the vault says so in its own README.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_31e8196d3e83b37277083c29f105b8310dbac4569e22715b5e0f85d46878eec1:k6xy9z4d`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_31e8196d3e83b37277083c29f105b8310dbac4569e22715b5e0f85d46878eec1%3Ak6xy9z4d) · From the CLI: `sgit clone sgit_public_read_31e8196d3e83b37277083c29f105b8310dbac4569e22715b5e0f85d46878eec1:k6xy9z4d`
Published deliberately, and **derived**: this vault was submitted as a vault key, and only the one-way read key derived from it appears here. It grants read, and only read.

## See it live, here

Both surfaces open automatically below. You can also [**open the app in its own window ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_31e8196d3e83b37277083c29f105b8310dbac4569e22715b5e0f85d46878eec1%3Ak6xy9z4d).

## What this vault demonstrates

| Feature | How this vault uses it |
|---|---|
| **Read scoped to one folder, write nowhere** | `app.json` declares `fs.read` over `part-4/` and **nothing else**: no write, no mkdir, at any path. The app is a reader, so the capability it never asked for cannot be misused. The host's own chrome shows the result as `R3 W0`: three reads granted, zero writes |
| A nested app entry | `entry` is `part-4/index.html`, not a root file. The app that opens is four folders into the tree, which is what lets the vault keep *four* apps without one of them having to own the root |
| Lineage kept, not overwritten | `part-2/` and `part-3/` hold **frozen app snapshots** at the state they shipped in; `part-4/` is current. A shared Parts nav links all three, so the earlier thinking stays openable rather than surviving only as a commit message |
| Two surfaces, one vault | `_page.json` gives the vault browser a themed landing page (hero, dark mode, accent `#d9a63f`); `app.json` makes the Article 9 app auto-open. The same objects serve a document reader and an application without either being converted into the other |
| The app-folder pattern over the bridge | from part 4 on, each app is a slim `index.html` shell plus `app/styles.css` and `app/app.js`, pulled in at runtime through `sg.loadCss` / `sg.loadJs`, the vault's own files loaded over the bridge rather than inlined into one unreadable page |
| Licensing declared inside the vault | `LICENSE` and `NOTICE` dual-license the contents: **Apache 2.0** for anything executable, **CC BY 4.0** for the written packs, with the tie-break stated ("the more permissive reading applies"). Terms travel with the objects, not with the page that links to them |
| Git-compatible by construction | `.gitattributes` and `.gitignore` ship inside the vault, and `guides/publish-sgit-vault-to-github.md` documents the round trip, trust-boundary analysis, the Secrets pattern, and a restore drill. The same tree can be an sgit vault and a git repository, which is [how this website was built until v0.2.84](../../../case-studies/one-tree-two-remotes.md), and how this vault is published: see the mirror note below |
| The source travels with the work | `briefings/` is 50 files of everything this was built against, and `concepts/` carries a principles register (P1–P15, each with origin, implementation and evolution) plus a notation spec. The reasoning is *in* the artefact, the difference between a demo and a record |

## What is going on here, step by step

The embeds above are the real vault, which makes it easy to scroll past the parts that matter. Each row points at one of them. Every screenshot is of this vault, driven by a script holding nothing but the published read key.

what opens

### The vault opens four folders deep

Opening the read key does not land you in a file listing. `app.json` sets `auto_open` and points `entry` at `part-4/index.html`, so the Article 9 app boots directly, with the Parts nav across the top and the seven views as tabs.

Note the chrome: **Read-only**, and `R3 W0`. The host is reporting the capabilities this app actually holds, and the write count is zero.

The vault auto-opens `part-4/index.html`, badged **Read-only**, `R3 W0`.

the finding is an absence

### Five annotation layers, and the empty one is the point

The paragraph view renders Article 9(2) with five toggleable annotation classes over it: deontic · 2, defined terms · 5, cross-refs · 2, qualifiers · 4, concepts · 3.

There is a sixth layer, **actors**, and it is deliberately empty. The app says why: *no duty-holder appears anywhere in the text*. A view that can show you nothing, and tell you that nothing is the result, is doing something a highlighter cannot.

Five annotation classes as layers, and an actors layer that is empty on purpose.

compression with a thread back

### Six altitudes over the same provision

Intent → five words → one sentence → compressed paragraph → the notation → the text, each rung labelled with what it costs. **L4 · intent**: *"Make risk management a standing duty, not a document."* **L3 · five words**: *"Continuously find, judge, address risks"*, annotated *"lossy on its own, lossless with the links held."* **L1.5** compresses ~140 words to ~60, with the note that *every clause maps to a span; the gap survives compression.*

Between each pair of rungs the app prints `↓ compresses · links held`. That is the whole claim, and it is checkable rather than asserted: tap a notation line and its source span lights up in the original.

Six altitudes, each tethered to the span below it.

divergence as output

### Every term carries two senses, and the gap between them

The Concepts view is a graph page per term. Focus `risk management system` and you get its **Act sense** (self-defining: no Article 3 entry, Article 9 defines it functionally), its **industry sense** (ISO 31000's framework + process; ISO/IEC 23894 for AI), and then the finding:

*"The Act names a SYSTEM (something you can audit) where ISO names a FRAMEWORK + PROCESS, close, not identical; the audit surface differs."* The divergence is not an error to reconcile; it is the product. Below it sit nine outgoing and three incoming computed edges, external standards among them as first-class nodes.

Act sense, industry sense, and the divergence between them, with computed edges.

where the empty layer comes from

### The grammar answers the question the annotation raised

The Grammar view merges dependency arcs with the word-class tree of the same sentence, then labels the semantic roles on `understand`: `ARGM-MOD` *shall, the deontic carrier*, `ARG1` *the risk management system*, `ARG2` *as a continuous iterative process*, and `ARG0` marked **implicit**, *recovered from Art 9(1) + 16(a)*.

That is the explanation for the empty actors layer two rows up: *"Deontic modal + agentless passive: the obligation is explicit and the duty-holder is grammatical absence."* The missing party is not an oversight in the drafting or a gap in the extraction. It is a property of the legal register, and the parse is what demonstrates it.

Dependency arcs, word classes and semantic roles, with `ARG0` implicit.

two axes, one knot

### Structure upward, meaning outward

The bow-tie here is not the risk practitioner's diagram. It is the paragraph as a **knot** with two different axes running through it. Upward is *structure*, the taxonomy: Regulation (EU) 2024/1689 → Chapter III → Section 2 → Article 9 → paragraph 2. Outward is *meaning*, the ontology: typed edges with their inverses named, and, pointedly, the gap edge and the undefined threshold marked as such.

The line under the stack is the one to take away: **the positional hash is stable under amendment; the content hash moves with the wording.** Two identities for the same paragraph, so a citation can survive a renumbering without pretending the text did not change.

Taxonomy upward, ontology outward, and two hashes for one paragraph.

the fractal claim, working

### Two graphs, one junction, never paragraph-to-paragraph

This is the row that justifies the vault's title. It takes a plain operations paragraph with **no regulation in it** (a fictional security product, NetSentinel, watching a fictional grid operator's SCADA estate) and lifts it into its own nodes: *"nobody signs off on that feed, it just lands"*, *"there hasn't been one since spring"*, *"an engineer copied the model onto a personal laptop"*.

Then it joins that graph to the Article 9 graph **node-to-node**, through the intermediate layer. The app states the rule it is obeying: *"this paragraph never links to the Act's paragraph. Its extracted nodes link to the NODES extracted from Article 9(2) (the steps, the defined terms, the threshold) and through them to the text."* The obligations attach at the twin: the running instance and its telemetry, not beside the risks.

An operations paragraph with no law in it, joined to the Act at the node layer.

least authority

### The permission block, read out of the store

Here is the vault's own `app.json`, opened in the vault browser. The whole manifest is 217 bytes, and the permission block is three lines: `fs.read` over `part-4/`.

There is no write grant, no mkdir grant, and no read grant over `briefings/`, `concepts/` or the other parts, the app simply cannot reach them. A commit message in this vault's history dates the change: *"declare fs.read [part-4/] grant ahead of the deny-by-default flip"*. The grant was narrowed **before** the platform started refusing by default, which is the direction that indicates intent rather than compliance.

`app.json`: a nested entry, read over one folder, and no write anywhere.

the reference layer

### The briefings it was built from ship with it

Expand `briefings/` in the vault browser and there are **50 files**: the VoiceDebrief pack, the fractal-semantic-graphs pack with its supporting documents grouped by theme, and the v0.33.57 interim briefs. Beside them, `concepts/` holds the principles register and notation spec, and `guides/` the operational how-tos.

The vault's README draws the line explicitly: everything in `part-*/`, `concepts/` and `guides/` is *produced work*; everything in `briefings/` is *source*. A reader with the read key can check the output against the input that produced it, without asking anyone for access to either.

Source and produced work, in one tree, under one key.

history as evidence

### Eighteen commits, and the reasoning is in them

The SGit view lists the whole history against the working HEAD. The messages are not "wip": they record the refactor to the app-folder pattern, the retirement of the root hub so part 4 could boot directly, the rename of the vault, and the licensing commit that added Apache 2.0 and CC BY 4.0.

This matters for a published vault specifically. A read key hands over *every* commit, not just the current tree, so the history is part of what you publish, and here it reads as a record somebody would be content to have read.

Eighteen commits, the record a read key also hands over.

## Why this shape matters beyond one provision

The transferable part is the **junction rule**. Most attempts to connect a regulation to an operation link document to document (a control mapped to a clause, a policy citing an article) and the link is only as good as the sentence somebody wrote around it. Here both sides are lifted into typed nodes first, and the join happens between nodes at an intermediate layer. Any domain with two bodies of text that must be reconciled (a standard and an implementation, a contract and a delivery, an incident and a policy) can borrow it.

The vault-shaped part is that all of this is **one credential**. The apps, the source briefings that produced them, the licence terms and the full history arrive together, decrypt in the reader's browser, and can be re-derived by anyone. Compare it with [Regulation Graph](../regulation-graph/index.md), which takes the other route to the same subject: the whole EU AI Act parsed from official Formex XML and hash-verified to source bytes, where this one works a single provision to exhaustion.

## The audit, honestly

Every vault is audited before its read key appears here. This one arrived as a **vault key**, the legacy `passphrase:vault_id` form with no prefix to give it away, and was classified as a write credential by `admin/build/check_credential.py` before it touched anything. The vault key was stored in the gitignored tier, the read key derived from it one-way, and only the derived key appears on this page. That derivation cannot be reversed.

The content scan is **clean on credentials**: no vault key inside the vault's own files, no credential under any `sgit_private_` prefix, which is the one scanner rule that covers every secret form, no API keys, tokens, `delete_auth` or `append_token` values, no private-key blocks, and no `.vault/` operational bookkeeping.

Two hits were ruled out by reading them, and both are worth naming because a clean sheet asserted is worth less than a finding explained. A 2FA worked example contains the sentence *"Leaked or reused passwords can be tried at scale"*: prose about passwords in a risk chain, matched by a pattern looking for assignments. And `guides/publish-sgit-vault-to-github.md` contains the literal string `BEGIN PRIVATE KEY`, in a table of the things its `.gitignore` must exclude. That is the same shape as [a mistake this site made itself](../publishing.md): a tripwire firing on the exact string a document needs in order to teach people to recognise it.

On personal data: parts 1–3 are built on a corpus the README states is **fictional** (invented companies, invented voice notes) and the part 4 cyber instantiation is likewise a fictional provider and grid operator. The only real-world entities named are public ones: Regulation (EU) 2024/1689, ISO 31000, ISO/IEC 23894.

The rule that goes with any published key applies here too: **revocation is not retroactive.** Anybody who fetches these objects keeps them, and rotating the key protects future commits only.

## The vault is also on GitHub, in the open

This vault practises what its own guide preaches. [VoiceDebrief/VoiceDebrief__Fractal-Semantic-Graphs](https://github.com/VoiceDebrief/VoiceDebrief__Fractal-Semantic-Graphs) is a public git repository holding the plaintext working tree and the encrypted `.sg_vault/bare/` store side by side, with `.sg_vault/local/` gitignored, exactly the layout `guides/publish-sgit-vault-to-github.md` describes. Checked on 20 September 2026 by cloning both: the repository's 90 content files match the vault's HEAD file for file; the repository has three commits, all on 10 August 2026, the day of the vault's last commit; and it has not moved since.

Three consequences for a reader. The content is **public twice over**: anyone can read every file on GitHub without the read key, so the key on this page adds the vault's history and its app, not access. The repository is a **snapshot, not a live mirror**: if the vault moves and the repository does not, the two will drift, which is the failure this site's own mirror had before it was [retired](../../../case-studies/one-tree-two-remotes.md#stopped). And the encrypted store in the repository is safe for the reason the guide gives: everything in `bare/` is protected by the vault key, which was never committed, so git exposure of the store equals server exposure, which the zero-knowledge model already accepts.

The concept this vault is named after now has a page of its own on this site, [Fractal Semantic Graphs](../../fractal-graphs/index.md), which cites this vault's principles register as the definition in its first form.

## Derived facts

92 files · 1,154 KB · 18 commits · HEAD `obj-cas-imm-3026ed53e995` · last updated 10 Aug 2026 · app entry `part-4/index.html` · 71 markdown, 11 JSON, 3 HTML, derived from the read key alone by `admin/build/catalogue_derive.py`, the same derivation that populates [the catalogue](../../../catalogue/index.md), with no token and no clone.



==============================================================================
# Regulation Graph, a published vault

> The EU AI Act as a citable graph: Regulation (EU) 2024/1689 parsed from official Formex XML, hash-verified to source bytes, 1,523 nodes and 1,944 edges across eleven views. Published as a redacted republication after an audit found a plaintext vault key in the original.
>
> Page: https://sgit.ai/demos/vaults/regulation-graph/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Regulation Graph

# Regulation Graph

The EU AI Act as a graph you can cite. Regulation (EU) 2024/1689 parsed from official Formex XML, hash-verified against the bytes it came from, and served as an **evidence layer**: a risk in a register points at a named obligation in a real instrument instead of being asserted.

**This vault exists because the first one could not be published.** The original carried a live vault key in plaintext, write access to a *different* vault, inside a handoff document. Our audit found it before anything shipped. Deleting the file would not have been enough: vault objects are content-addressed and immutable, so a credential committed once may stay reachable from history. This is a **redacted republication with new history**, and the vault says so itself in its own [PUBLIC.md](#public).

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_c004daae386e8d17fa648884acc527018bd4ea1116ad673fb2f1b068011695c9:73heuprz`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_c004daae386e8d17fa648884acc527018bd4ea1116ad673fb2f1b068011695c9%3A73heuprz) · From the CLI: `sgit clone sgit_public_read_c004daae386e8d17fa648884acc527018bd4ea1116ad673fb2f1b068011695c9:73heuprz`
Published deliberately, and **derived** one-way from a vault key that is not published and never will be.

## See it live, here

Both surfaces open automatically below. You can also [**open the app in its own window ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_c004daae386e8d17fa648884acc527018bd4ea1116ad673fb2f1b068011695c9%3A73heuprz), the entry point is the Art 9 lab; the back-link top-left reaches the other ten views.

## What is in it

the overview

### Every number traces back to source bytes

The landing view states the shape of the graph in counts: **113 articles**, **500 paragraphs**, **417 points**, **180 recitals**, **13 annexes**, **68 definitions**: resolving to **1,523 nodes** and **1,944 edges**.

Underneath, the part that makes it evidence rather than a summary: two instruments composed into one view, each with its CELEX identifier and the **SHA-256 of the retrieved bytes**. Regulation 2024/1689 is shown as *amended by 2026/1744, no official consolidation yet, this graph composes*. That sentence is a factual claim about the state of EU law, and it is checkable.

Application dates are treated as **versioned properties, never bare facts**: superseded pre-Omnibus dates are struck through rather than overwritten, each carrying its basis (`Article 113(a) as amended`) and an as-of date.

Built from Formex XML retrieved from CELLAR, hash-verified, parsed deterministically.

browse the act

### The instrument itself, structure first

The full Act, navigable by its own structure, with a provenance footer on every node and search across the text. This is the view that makes the rest defensible: when a risk cites Article 9(2)(a), you can go and read Article 9(2)(a), in the text that was parsed, not a paraphrase of it.

Per-node provenance footers, and search over the parsed text.

the graph

### Article-level relationships, with amendment halos

The citation graph at article level, drawn with Cytoscape, showing amendment halos and aggregated citations. Eleven views in total sit behind the top nav, including **SQL** (SQLite over sql.js, in memory, preset and free queries), **RDF** (rdflib, partition-separated predicates, Turtle export), **Concepts** (the Act's 68 defined terms with every usage linked) and **External refs** (every other EU instrument the Act cites, as an in-vault citation graph).

All of it runs client-side over the SG bridge. The vault is never written by the app.

Article-level graph; ten sibling views cover SQL, RDF, concepts and external citations.

the art 9 lab

### The entry point is an experiment, deliberately

`app.json` sets `entry` to `lab/index.html`, so opening the vault lands in the **Art 9 lab**: paragraph universes, a web-component folder explorer, provision graphs with reach profiles, and a **Graph REPL**: an LLM chat whose read-only tools drive the canvas.

The lab is marked *experimental* and has no main nav of its own; the back-link top-left returns to the other views. Landing a reader in the newest, least finished thing is an unusual choice and an honest one.

Opening the vault lands here: the Art 9 lab, marked experimental.

public.md

### The vault states its own publication rules

Following [Risk Graph Explorer](../risk-graph-explorer/index.md), this vault carries a `PUBLIC.md` declaring what it holds to, and, unusually, what was removed to make publication possible. The removals are visible to any reader as `<VAULT-KEY-REMOVED>` and `<READ-KEY-REMOVED>` markers rather than silently deleted lines.

**Rule 3 was verified rather than assumed.** The Graph REPL reads an OpenRouter key, and `lab/app/repl.js` looks for one at `/key.json` *inside the vault* before falling back to device storage. So we checked: no `key.json` exists, confirmed in a clone made with the published read key, which is what a reader actually gets. The REPL is bring-your-own-key, and nothing metered ships behind the published credential.

The rules, and the two removals, in the vault rather than only on this page.

## What it is for

The README states the purpose in one line: *"a risk in a register points at a named obligation in a real instrument instead of being asserted."* It is the evidence layer beneath the [Risk Mandate](../risk-mandate/index.md) work, where [a risk chain](../risk-graph-explorer/views/index.md) ends in `touches: EU AI Act Art. 12`, this is the vault that can say what Article 12 actually says and prove the bytes.

Its eight hard rules are worth reading in full, and two are worth quoting here:

- **Evidence, not compliance.** Never a claim that an organisation passes or fails. Not legal advice.
- **Provenance chain end to end:** claim → graph node → vault file → commit → official source (CELEX/ELI plus SHA-256 of retrieved bytes).

The second is the one this site keeps arriving at from other directions. It is the same instinct as [running comparisons as tests](../../../compare/index.md) and as [refusing to call a release live until the site serves it](../../../articles/green-does-not-mean-live.md): a claim is worth what its chain of custody is worth.

## What it does not do

- **Only Article 9 is built out in depth.** Rule 4 is *"partial connection is sufficient, build only what the register cites"*, so the lab covers Art 9 and the rest of the Act is present as structure and citations rather than fully annotated.
- **The Graph REPL needs your own OpenRouter key.** Nothing is supplied, deliberately. Without one the REPL pane is inert, which is the correct behaviour, not a fault.
- **No consolidated text exists.** 2024/1689 is amended by 2026/1744 with no official consolidation yet; this graph composes the two, and says so rather than presenting a merged text as authoritative.
- **External research is marked UNVERIFIED.** The research report under `docs/research/` carries external claims the vault has not itself checked, and labels them.

## How it was published

This vault is the clearest worked example of [the publishing method](../publishing.md), because it is the first one where the audit **stopped** a publication instead of clearing it:

1. **Classify the credential.** The submitted credential was a vault key, not a read key. The intake check refused it, the fourth time.
2. **Derive rather than refuse.** The read key was derived one-way; the vault key went to the gitignored tier the release tripwire scans for.
3. **Audit with the key about to be published.** 204 text files, read-key clone. One finding: a plaintext vault key for another vault.
4. **Stop.** No page was written. The finding was reported before anything else happened.
5. **Republish clean.** A new vault, new history, two credentials redacted in place with visible markers, a `PUBLIC.md` stating what changed, and a re-audit from a fresh read-key clone: **205 files, zero findings**.

The 370-plus bare 64-hex strings the audit flagged on the way through were all `sha256` provenance hashes, checked, not waved away. A scan that never produces a false positive is not scanning hard enough.



==============================================================================
# SG/Payments Brief Pack, a published vault

> A ten-document briefing pack for a payments and metering platform, published as a vault while every word of it is still PROPOSED. The status is stamped on the pack index, not buried in a footnote.
>
> Page: https://sgit.ai/demos/vaults/payments-brief-pack/index.html

[Home](../../../index.md) / [Vaults](../index.md) / SG/Payments Brief Pack

# SG/Payments Brief Pack

A briefing pack for a team that has not started building yet. Ten documents, a stated reading order, and a status pill that says **PROPOSED**, because nothing in the pack exists as code. It is the clearest example on the site of a vault used as the **unit of handover**: one credential moves the whole pack, its reading order and its provenance together.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_cd1987b87f719c2ff6da51128200665312afaeeadcbf7a1a20f870f03f9959f8:o3m0sz3q`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_cd1987b87f719c2ff6da51128200665312afaeeadcbf7a1a20f870f03f9959f8%3Ao3m0sz3q) · From the CLI: `sgit clone sgit_public_read_cd1987b87f719c2ff6da51128200665312afaeeadcbf7a1a20f870f03f9959f8:o3m0sz3q`
Published deliberately, and **derived** one-way from a vault key that is not published and never will be.

## See it live, here

Both surfaces open automatically below. You can also [**open the app in its own window ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_cd1987b87f719c2ff6da51128200665312afaeeadcbf7a1a20f870f03f9959f8%3Ao3m0sz3q).

## What is in it

the pack

### A reading order, and a status that refuses to flatter itself

The index opens with **Status: PROPOSED, nothing in this pack exists as code yet**, then a numbered reading order through ten documents: overview and principles, platform grounding, a review of three human architecture briefs, target architecture, gateway spec, ledger and credentials, vault integration, build plan, open decisions, and a pattern audit.

The separation that makes it useful is between **01 · Platform Grounding, What Exists Today (code-verified)** and everything downstream of it. One document is what the code does; the rest is what somebody proposes to build on top. The pack keeps them apart on purpose.

The footer of the app states its own delivery mechanism: *rendered from an encrypted SG/Vault, the link-holder holds the key; the server sees only ciphertext.*

The pack index: PROPOSED status, the reading order, and the target named up front.

the grant

### Nothing requested, nothing granted

`app.json` declares `"permissions": {}`. A pack of documents needs no filesystem access, so it asks for none, the same posture as the [Risk Graph Explorer](../risk-graph-explorer/index.md).

It is worth seeing on a document pack precisely because nothing here is dangerous. The habit is what generalises: the grant is written down, it is short enough to read, and it is visible to anyone holding the read key.

The vault browser: the pack as files, and the empty permission grant.

## Notes

**Why this one is interesting beyond payments.** The grounding document records the substrate in terms this site documents elsewhere: PBKDF2 at 600k iterations deriving independent read and write keys, ref file *locations* themselves HMAC-derived from the read key, and the server storing only `SHA-256(write_key)` while reads stay tokenless. It is an outside-in description of the same design the [API pages](../../../api/index.md) describe from the inside.

[← All published vaults](../index.md)



==============================================================================
# Agent as Webmaster, a business plan published as a vault

> A complete business plan for a company that gives small businesses a website they can change by asking, with an AI agent as the webmaster: architecture, workflow, packages and prices, a unit-economics calculator, go-to-market, the first ninety days, the investor case, the risks, four mock-up sites and the prototypes to run the first customer. Published with its read key, written for somebody else to run.
>
> Page: https://sgit.ai/demos/vaults/agent-webmaster/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Agent as Webmaster

# Agent as Webmaster, a business plan for somebody else to run

A complete business plan published as a vault: the idea, the architecture, the workflow, the packages and prices, the unit economics with a calculator, go-to-market, the first ninety days, the investor case, the risks, four mock-up websites and the prototypes to run the first customer. It is the first of a set of plans published here for other people to build companies on, and it is written to be taken, not admired. **The business:** give small businesses a website they can change by asking, by putting an AI agent in the webmaster's chair.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_d5ba4a106276936456b0a108b3988aa777f5402ba6699fcd67becd620fe55828:ikrqeu5t`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_d5ba4a106276936456b0a108b3988aa777f5402ba6699fcd67becd620fe55828%3Aikrqeu5t) · From the CLI: `sgit clone sgit_public_read_d5ba4a106276936456b0a108b3988aa777f5402ba6699fcd67becd620fe55828:ikrqeu5t`
Published deliberately under the `sgit_public_read_` prefix, and **derived** one-way from a vault key that is kept in the gitignored tier and never published. Classified with `check_credential.py` before it touched this page, and verified with an all-zeros negative control: the real key cloned 32 files, the control cloned nothing.

## See it live, here

The plan opens as an app. You can also [**open it in its own window ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_d5ba4a106276936456b0a108b3988aa777f5402ba6699fcd67becd620fe55828%3Aikrqeu5t), where the calculator and the mock-ups have more room.

## What is in it

the plan

### One page first, then everything behind it

The app opens on six things to know: the business, why now, the stack, the numbers, who runs it and why the plan is public. Below that, each section of the plan has a diagram and the detail: the architecture (a chat session, one public repository per customer, GitHub Pages on every push), the setup in three days and the change loop that runs forever, the three packages, the model, the market, the ninety days, the investor case and the risks.

The status pill says what the numbers are: **starting hypotheses**. Every price and every hour is a first guess for a UK operator in 2026, and the plan says to test them on the first ten customers and change them.

The plan as it opens: the status pill, the title, and six things to know.

what you sell

### Three things, priced three ways

Setup once (£300, £600 or £1,200) for the expert's time. Maintenance monthly (£50, £100 or £200, bronze, silver, gold) for keeping the site working, watched and tweaked, with a note to the customer each month. On demand (£40 to £250) for the changes that take an expert, and tokens passed through for heavy users.

The plan is careful about the middle one, because this site argues elsewhere that most subscriptions are rent on something ignored. Here the operator does something every month and the customer can see it in the commits, and the plan says what to do when a change log has been empty for three months: tell them, and offer bronze or nothing.

The three package tables, and the note on why a subscription is earned here.

the model

### A calculator, because the numbers are yours to change

Eleven sliders: customers, prices, setups and changes per month, direct costs, and the hours each thing takes. Six numbers update as you move them: recurring revenue, revenue, contribution, annual contribution, operator hours against the roughly 160 available, and contribution per operator hour. When the hours pass 160 the figure turns red and the app says it is time for the second operator.

Underneath, the three fixed scenarios the plan uses: 20, 50 and 80 customers, at £3,360, £7,300 and £11,450 of monthly contribution. Nothing runs anywhere to compute this. It is arithmetic in the page.

The calculator: sliders on the left, six numbers on the right, arithmetic in the page.

the mock-ups

### Three invented customers and the sales site

A bakery, a two-partner accountancy firm and a physiotherapy clinic, each a standalone HTML page with its styles inlined, each carrying a **"changed by the webmaster"** strip near the top showing the last three changes and when they went live. That strip is the product: a website that visibly gets changed.

The fourth mock-up is the operator's own sales site, built the way every customer's site would be, with a chat transcript as the hero, how it works in four steps, the three examples, the prices published, and the offer that converts: a free rebuild for two weeks, then it goes dark, then see whether they miss it.

Hollow Lane Bakery, an invented business, with the change strip under the header.

the sales site

### The demonstration is the sales process

The hero of the sales site is a four-message chat: a closure notice and new hours, live in 41 seconds; three photos added, live in a minute. The plan's go-to-market section says that showing a change happen live, in under a minute, is the whole pitch, and the mock-up is built to be that demonstration.

The prices are on the page. The plan argues that publishing them is itself a differentiator against a market that hides prices behind a quote.

The sales site: a chat transcript as the hero, then how it works.

## What this vault demonstrates

| Feature | The mechanism, not the marketing |
|---|---|
| **A business plan as the unit of handover** | The plan, its documents, the diagrams, four working mock-ups and the operating prototypes travel as one read key. Somebody who wants to run this business clones one thing and has everything, including the tool that keeps the app and the content in step. |
| **An app with nothing requested** | `app.json` declares `"permissions": {}`. The app reads its own content, computes in the page, and links to its own files. No LLM, no writes, no network, so a published read key in front of it costs nobody anything, which is the third of the three rules in its `PUBLIC.md`. |
| **Content and app kept in step** | Everything shown comes from `content.json`, inlined into `index.html` by `tools/inline-content.py`, which matches the placeholder exactly rather than by pattern. That tool exists because the first inliner matched an example command in an HTML comment and deleted the page. The rule that came out of it is in the tool's docstring. |
| **The same content, twice** | The app for reading, and eleven markdown documents in `plan/` for following, with a reading order, breadcrumbs and a one-page version at the top. The vault browser renders the markdown; the app renders the JSON; they were written together. |
| **Mock-ups that open from the vault** | Four standalone HTML pages with every style inlined and no external asset, so they render inside the vault host's sandbox, in the vault browser, and saved to a desktop. Links from the app to them are plain relative links, which the host intercepts. |
| **Written for another operator** | The plan names what to open and what to keep, what to measure at day ninety, and the one thing to send back. It follows the operating model in [the startups article](../../../articles/the-question-is-whether-they-miss-it.md): ship, give it away briefly, take it away, be profitable before you raise, open everything. |

## The audit, honestly

**What was scanned.** Every one of the 32 files, from a clone made with the published read key and nothing else: markdown, HTML, JSON, SVG and the one Python tool. Patterns: vault-key shapes (24 alphanumerics before a colon), every `sgit_` credential prefix, API-key shapes, private-key blocks, email addresses, bearer tokens and `delete_auth` values.

**What was found.** Nothing. No credentials, because the vault carries none by design; no email addresses, because the businesses in the mock-ups are invented and the contact forms are placeholders that say so; no personal data. The negative control, a clone attempted with an all-zeros read key against the same vault id, produced an empty directory.

**What the process found instead, in the CLI.** The first push of this vault failed. The CLI's automatic transport resolution treated a 404 on a not-yet-existing object, which is what every fresh vault's first push reads, as "this host has no live API" and flipped the vault to the read-only static transport. Two fixes went into the CLI repository from this session: the resolver now only flips on the batch endpoint answering 404, 405 or 501, and `push`, `pull`, `fetch`, `status` and `delete` now honour `--transport`, which they had been ignoring. A test pins the first fix. A vault published to teach a method produced a rule for the tool, which is the pattern this section keeps producing.

**Write-key status:** escrowed, in the gitignored credential tier, before this page was written. The vault is correctable.

## Derived facts

From `admin/build/catalogue_derive.py ikrqeu5t <read key hex>`, read-only, no token, no clone.

- **Files:** 32 · **plaintext size:** 666 KB
- **Commits:** 2 · **last updated:** 2026-09-23
- **Top level:** `PUBLIC.md`, `README.md`, `app.json`, `content.json`, `diagrams/`, `index.html`, `mockups/`, `plan/`, `prototypes/`, `tools/`
- **File types:** .md ×18, .html ×5, .svg ×3, .webp ×3, .json ×2, .py ×1
- **Vault app:** yes, entry `index.html` · **browser-renderable:** yes

## Notes

**Where this came from.** A voice memo by the founder on 23 September 2026, worked into a plan the same day. The memo's numbers were "300, 500 or 1,000 for setup" and "50 or 100 a month for maintenance"; the plan makes them £300, £600 and £1,200, and £50, £100 and £200, adds the on-demand tier and the token pass-through the memo asked for, and marks all of it as a hypothesis. **Where it goes next.** The [startups section](../../../startups/index.md) now has a place for plans like this one, and the intention is a set of them, each a vault, each written for somebody else to run.

[← All published vaults](../index.md)



==============================================================================
# Connector Twin, a business plan with a working replay, published as a vault

> A business plan for a service that journals every request and response an AI agent makes through Gmail, Calendar or any connector, and replays it into the views the agent saw, with before and after and a revert plan for every change. Opens on a working replay of an invented seventeen-call session with a hash chain verified in the browser. Facts sourced from Google's documentation, the journal specification, revert rules, prototypes, packages priced per agent and a calculator.
>
> Page: https://sgit.ai/demos/vaults/connector-twin/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Connector Twin

# Connector Twin, a business plan with a working replay

A business plan for a service that gives every AI agent deployment a twin of its connectors: a journal of every request and response the agent makes to Gmail, Google Calendar or any other connected system, replayed into the views the agent saw, with a before and after for every change and a revert plan for each one. The vault opens on a working replay of an invented agent session, rebuilt from seventeen hash-chained journal entries, and then sets out the business. **The sales question:** do you know what your agents did? The case is argued in [Before you give an agent a connector, give the connector a twin](../../../articles/connector-twin-before-you-deploy-an-agent.md).

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_4fb639e76d976d691c7655060e74f6d7fe13a7b96ea77d9230446977e5cdf860:7tkvspwp`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_4fb639e76d976d691c7655060e74f6d7fe13a7b96ea77d9230446977e5cdf860%3A7tkvspwp) · From the CLI: `sgit clone sgit_public_read_4fb639e76d976d691c7655060e74f6d7fe13a7b96ea77d9230446977e5cdf860:7tkvspwp`
Published deliberately under the `sgit_public_read_` prefix, and **derived** one-way from a vault key that is kept in the gitignored tier and never published. Classified with `check_credential.py` before it touched this page, and verified with an all-zeros negative control: the real key cloned 31 files, identical to the source folder, and the control cloned nothing.

## See it live, here

The replay opens as an app. Drag the slider and the inbox and calendar rebuild step by step. You can also [**open it in its own window ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_4fb639e76d976d691c7655060e74f6d7fe13a7b96ea77d9230446977e5cdf860%3A7tkvspwp), where the replay has more room.

## What is in it

the question

### What an organisation can answer, with a twin and without

The app opens on the sales question and a six-row table: what can the agent do, what did it do, what did it see, why, can you undo it, and can you show someone else. Without a twin, most answers are the agent's own summary. With one, every answer is a record.

Every claim about what Gmail and Calendar keep comes from Google's own documentation, and the plan's facts document links each one.

Do you know what your agents did? The table, without a twin and with one.

the replay

### The inbox and the calendar, as the agent saw them

An invented scheduling assistant is given a Gmail and a Calendar connector and one instruction. Its seventeen calls are the journal. The app folds them in order into the inbox and the calendar at any step, marking what the agent archived, trashed, permanently deleted, sent, moved, declined, deleted and created, with a ghost where a moved event used to be.

The twin is not a copy of the mailbox. One message the agent listed and never opened appears as an id and nothing more, because that is all the agent saw.

The calendar as the agent left it, rebuilt from the journal alone.

before and after

### Every change, with what the twin can put back

Pick a write and the app shows the state before and after, and a grade: exact, partial, content only, or none. Step 15 is the one that matters: a payment reminder deleted with the Gmail API's permanent delete, which Google documents as "cannot be undone". The twin still holds the full message, because the agent read it before deleting it, so its content can be put back as a new message.

Step 15: permanently deleted in Gmail, still held in the twin.

said versus did

### The agent's summary, against the journal

The agent's summary is true in every sentence. The journal shows that "removed the supplier call" was a delete with notifications on, so the supplier received a cancellation, and that "deleted an old reminder" was the unpaid invoice's reminder, removed permanently. That gap is what a twin exists to close.

What the agent said, what the journal shows, and what can be put back.

the revert plan

### Newest first, side effects named

For every write up to the current step, the inverse call, newest first, with its grade and the side effect it cannot avoid: a second round of notifications, a new message id, a cancellation already sent. Executing the plan is a separate step that a person approves and that is journalled like everything else.

The revert plan, newest first, each step graded.

the business

### Priced per agent, with a calculator

A connector review once (£750, £2,500 or £6,000 by size), then per agent per month: Journal £15, Twin £40, Assured £90, and incident replays on demand. Three capture modes, broker, gateway and agent-reported, which change the evidence grade rather than the price.

The calculator moves customers, agents per customer, tier, set-up and burn. At the Twin price, about 380 agents cover a two-founder burn of £14,000 a month. Every number is marked as a hypothesis.

What you sell: set-up once, per agent monthly, and on demand.

## What this vault demonstrates

| Feature | The mechanism, not the marketing |
|---|---|
| **A replay built from a journal, not a copy** | The app holds seventeen entries, each a tool call, an upstream request and a response, and folds them into state. Nothing else is shipped: no snapshot of the inbox, no snapshot of the calendar. What you see at step nine is what the agent had seen by step nine. |
| **A hash chain verified in your browser** | Each entry carries the SHA-256 of the one before. The app recomputes the chain with the browser's own crypto and prints the head; `tools/verify-journal.py` does the same offline. It ran and passed inside the vault host's sandbox. |
| **An app with nothing requested** | `app.json` declares `"permissions": {}`, and the vault host shows it as read-only with no read or write grants. No LLM, no writes, no network. |
| **A specification to build against** | `spec/journal-entry.md` is the contract between capture and replay, including what is never captured. `spec/revert-rules.md` lists every Gmail and Calendar action in scope, what the platform keeps, the inverse, and the side effects. |
| **Facts with sources** | `plan/02-the-facts.md` links every claim about Gmail, Calendar and Google Vault to Google's documentation, and marks the one thing the plan has not tested: whether an event deleted through the API appears in Calendar's trash. |
| **Written for another operator** | Eleven plan documents with a reading order, three prototypes (the agent-reported capture instruction, the broker, and the processor schedule), and the tools to regenerate the journal and rebuild the app. |

## The audit, honestly

**What was scanned.** Every one of the 31 files, from a clone made with the published read key and nothing else, and compared byte for byte with the source folder. Patterns: vault-key shapes, every `sgit_` credential prefix, API-key shapes, private-key blocks, bearer tokens, and any email address not on the reserved `.example` domain.

**What was found.** Nothing. The journal is invented: its people, companies and addresses are fictional, every address uses `.example`, and the Authorization header is recorded only as `[never captured]`. The negative control, an all-zeros read key against the same vault id, produced an empty directory.

**What the research corrected.** The plan first assumed Google Vault did not cover Calendar; it has since November 2023, keeping the last revision of each day, and the facts now say so. It also first said Calendar keeps no record of edits; administrators have an audit log that records some earlier values, and the facts now say that too, with the distinction that a log is a record, not a restore.

**Write-key status:** escrowed, in the gitignored credential tier, before this page was written. The vault is correctable.

## Derived facts

From `admin/build/catalogue_derive.py 7tkvspwp <read key hex>`, read-only, no token, no clone.

- **Files:** 31 · **plaintext size:** 515 KB
- **Commits:** 2 · **last updated:** 2026-09-24 · **HEAD:** `obj-cas-imm-3ad848e2891f`
- **Top level:** `PUBLIC.md`, `README.md`, `app.json`, `content.json`, `diagrams/`, `index.html`, `journal/`, `plan/`, `prototypes/`, `spec/`, `tools/`
- **File types:** .md ×18, .json ×4, .py ×3, .svg ×2, .webp ×2, .html ×1, .jsonl ×1
- **Vault app:** yes, entry `index.html` · **browser-renderable:** yes

## Notes

**Where this came from.** A voice memo by the founder on 24 September 2026: a twin of what an agent can do and has done is close to a minimum requirement for deploying one, with Gmail and Calendar as the worked example, and the idea split in two, an article for the need and a business plan for the service. **Where it sits.** With the other [business plans published for founders](../../../startups/business-plans.md), each a vault, each written for somebody else to run.

[← All published vaults](../index.md)



==============================================================================
# Risk Acceptance Office, a business plan with one risk replayed, published as a vault

> A business plan for a company that runs the risk acceptance loop in the gaps of an organisation's GRC platform: every material risk established on facts, held by a named person, accepted for a stated interval, and at expiry accepted again, escalated, funded or fixed. Opens on ten principles and a six-week replay of one invented risk with a hash-chained decision record verified in the browser, then the operating model, services priced per material risk, a calculator, go-to-market, the risks and the open questions.
>
> Page: https://sgit.ai/demos/vaults/risk-acceptance/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Risk Acceptance Office

# Risk Acceptance Office, a business plan with one risk replayed

A business plan for a company that runs the risk acceptance loop for organisations: every material risk established on facts, held by a named person, accepted for a stated interval, and at the end of that interval accepted again, escalated, funded or fixed. It works in the gaps of the client's existing GRC platform, and keeps each material risk's evidence and decisions in a vault of its own. The vault opens on the principles, then replays one invented risk over six weeks, then sets out the business. The foundation is argued in [Every risk is already accepted](../../../articles/every-risk-is-already-accepted.md).

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_3e6f04360f083cff58daa851a63d6d0fcc7f6eadb5bdca7c57acef6ef15bc93e:odn10gfp`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_3e6f04360f083cff58daa851a63d6d0fcc7f6eadb5bdca7c57acef6ef15bc93e%3Aodn10gfp) · From the CLI: `sgit clone sgit_public_read_3e6f04360f083cff58daa851a63d6d0fcc7f6eadb5bdca7c57acef6ef15bc93e:odn10gfp`
Published deliberately under the `sgit_public_read_` prefix, and **derived** one-way from a vault key kept in the gitignored tier and never published. Classified with `check_credential.py` before it touched this page, and verified with an all-zeros negative control: the real key cloned 32 files, identical to the source folder, and the control cloned nothing.

## See it live, here

The replay opens as an app. Drag the slider and follow the risk from the facts that establish it to the facts that end it. You can also [**open it in its own window ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_3e6f04360f083cff58daa851a63d6d0fcc7f6eadb5bdca7c57acef6ef15bc93e%3Aodn10gfp).

## What is in it

the principles

### Every risk is already accepted

The app opens on ten principles, drawn from the method published on risks.sgit.ai, RiskMandate.ai and graphs.sgit.ai: no deny button; accept, fund or fix; the interval is the decision; a named person and no delegation; unaccepted is critical; every path ends at the board; accepted is not acceptable; established by facts and ended by facts; and GRC validates while the business accepts.

The method in ten principles.

escalation

### An acceptance that expires, and the risk that moves up

An invented payments company lets a deployment agent change its production ledger. The SRE lead accepts the risk for two weeks, with an action. The action is not done, the acceptance expires, nobody renews it, and on day 15 the risk rolls up to the platform owner, who must accept, fund or fix.

Day 15: escalated to the platform owner.

the interval is the decision

### A funded month, then a four-hour incident

The platform owner funds a four-week project and accepts for a month, the default rung. On day 24 the risk materialises: an irreversible migration stalls settlement. A four-hour acceptance follows, which is an incident response by definition, and the incident's timeline becomes a fact in the risk's own record.

Day 24: the incident, as a four-hour acceptance.

ended on facts

### The risk ceases when the fact that ends it holds

On day 41 the approval step is merged. One of the facts the risk named as ending it now holds, with its source, and on day 42 it ceases. Underneath, the same moment in a typical register row: "Open until the committee on 12 December", no evidence attached. That difference is the air gap.

Day 42: ceased, on evidence.

the business

### A service, priced per material risk

A free one-hour acceptance audit, a foundation engagement at £18,000 for one business unit, the Acceptance Office at £2,500 a month plus £60 per material risk, incident support by the day, and a partner licence for consultancies. A calculator lets every input move. Every price is marked as a hypothesis.

What you sell.

## What this vault demonstrates

| Feature | The mechanism, not the marketing |
|---|---|
| **A risk as its own record** | The risk's facts, controls, holders and decisions live in `risk/`, and the decision record is fourteen hash-chained entries in `risk/record.jsonl`. It is the shape of a vault per material risk, which the plan proposes for every material risk a client carries. |
| **A record verified in your browser** | The app recomputes the chain with the browser's own crypto and prints the head. `tools/verify-record.py` does the same offline. It passed inside the vault host's sandbox. |
| **The air gap, shown side by side** | At every step the app shows what a typical register row says next to what the risk's record holds. The row never learns that the risk was accepted twice, expired, escalated, funded, materialised and ended. |
| **An app with nothing requested** | `app.json` declares `"permissions": {}`. No LLM, no writes, no network. |
| **A plan written for another operator** | Eleven plan documents, the acceptance record and risk vault specifications, and three prototypes: the acceptance audit, the acceptance meeting, and a GRC integration outline. |

## The audit, honestly

**What was scanned.** Every one of the 32 files, from a clone made with the published read key alone, compared byte for byte with the source folder. Patterns: vault-key shapes, every `sgit_` credential prefix, API-key shapes, private-key blocks, bearer tokens, and any email address not on the reserved `.example` domain.

**What was found.** Nothing. The company, people and risk are invented. The negative control, an all-zeros read key against the same vault id, produced an empty directory.

**What the research found, and the plan says.** The published method disagrees with itself in four places: two different interval ladders, whether an unaccepted risk rolls up automatically or waits, what happens at expiry, and a present-tense description of a product queue that the method's own inventory says is not built. The plan picks one position on each, says which, and lists the rest as open questions.

**Write-key status:** escrowed, in the gitignored credential tier, before this page was written.

## Derived facts

From `admin/build/catalogue_derive.py odn10gfp <read key hex>`, read-only, no token, no clone.

- **Files:** 32 · **plaintext size:** 673 KB
- **Commits:** 3 · **last updated:** 2026-09-24 · **HEAD:** `obj-cas-imm-b89dfa86528d`
- **Top level:** `PUBLIC.md`, `README.md`, `app.json`, `content.json`, `diagrams/`, `index.html`, `plan/`, `prototypes/`, `risk/`, `spec/`, `tools/`
- **Vault app:** yes, entry `index.html` · **browser-renderable:** yes

## Notes

**Where this came from.** A voice memo by the founder on 24 September 2026: risk acceptance deserves a company of its own, separate from RiskMandate.ai's focus on the insurability of agents, delivered as a governance service that works in the gaps of existing GRC platforms, with a vault per material risk as its evidence pack. **Where it sits.** With the other [business plans published for founders](../../../startups/business-plans.md).

[← All published vaults](../index.md)



==============================================================================
# Lesson Loop, a business plan for coaches with one player's record, published as a vault

> A workflow and a business for padel coaches and any teacher with students: the coach records a voice memo at the end of the lesson, an agent turns it into a lesson note in the player's own vault, the player adds match notes, and the next coach starts from a two-minute briefing. One invented player's record across four lessons with three coaches, the themes each saw, phases, the two-vault architecture with write-only lanes for coaches, pay-on-demand credits, new coach income, a calculator, and the prompts for phase one.
>
> Page: https://sgit.ai/demos/vaults/lesson-loop/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Lesson Loop

# Lesson Loop, a business plan for coaches with one player's record

A workflow and a business for padel coaches, and for any teacher with students. At the end of every lesson the coach has the best picture of the player they will ever have, and today it is gone by the next lesson. Lesson Loop captures it at that moment: the coach records a two-minute voice memo, an agent turns it into a lesson note in the player's own vault, the player adds what happens in their games, and the next lesson, with the same coach or a different one in another city, starts from a two-minute briefing instead of from memory. Paid on demand, with new income for coaches beyond the hour on court.

The lesson loop. Phase one is only the top row: a voice memo, an agent and a vault.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_2d397a3a06c235452300c55375ebe8e470ba70a1a5263dc72679f8a78c42dfc1:3s9q7zl7`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_2d397a3a06c235452300c55375ebe8e470ba70a1a5263dc72679f8a78c42dfc1%3A3s9q7zl7) · From the CLI: `sgit clone sgit_public_read_2d397a3a06c235452300c55375ebe8e470ba70a1a5263dc72679f8a78c42dfc1:3s9q7zl7`
Published deliberately under the `sgit_public_read_` prefix, and **derived** one-way from a vault key kept in the gitignored tier and never published. Classified with `check_credential.py` before it touched this page, and verified with an all-zeros negative control: the real key cloned 27 files, identical to the source folder, and the control cloned nothing.

## See it live, here

The plan opens as an app. Pick any entry in the player's record. You can also [**open it in its own window ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_2d397a3a06c235452300c55375ebe8e470ba70a1a5263dc72679f8a78c42dfc1%3A3s9q7zl7).

## What is in it

the moment

### The coach's memo, as spoken

An invented player, Alex, takes four lessons with three coaches in two cities over three weeks, and plays in between. For each lesson you can read the coach's end-of-lesson voice memo exactly as spoken: two or three minutes of what they saw, what they worked on and what comes next. This is the knowledge that exists for five minutes and is normally lost.

The first lesson's memo, as recorded.

the player's view

### Three things for the next games

The agent turns the memo into a lesson note and a player view: no more than three points to take into the next game, written to the player, and the drills to practise. Instead of an hour of instructions to remember, the player has three sentences on their phone.

What the player sees after lesson one.

the briefing

### Two minutes before the next lesson

Before each lesson the coach reads a briefing that folds together every coach's notes and every match since they last saw the player. In the demo, the coach in Lisbon says it saved the first fifteen minutes, and a new coach in London starts her first lesson already knowing what three coaches saw.

The briefing for the player's regular coach.

three coaches

### Every coach sees something different, and none of it is lost

The agent tracks themes across the record. The London coach fixed the bandeja; the Lisbon coach saw that the lob came from the arm and that the player stayed back after a good lob; the second London coach confirmed both. Amber is where something was first seen or is still a problem, green is where it holds.

Themes across three coaches, two matches and a clip.

the business

### Paid on demand, and new income for coaches

No subscription. Players buy credits and spend them on processing: about 20p for a lesson note, about £1 for a short clip. Coaches price their own remote reviews, drill plans, follow-ups and content, and the operator takes a share. Clubs can include notes in the lesson price. The calculator shows it is a small business at 200 coaches and a real one at a few thousand, and every number is a hypothesis.

What is sold, and who sets the price.

## How it is built

Two vaults: one app for everybody, one record per player. The record belongs to the player, so it travels.

| Piece | What exists today |
|---|---|
| **Voice capture** | Claude and ChatGPT apps take voice input, and transcription apps such as Otter record and transcribe. Phase one needs nothing else on the coach's side. |
| **An agent to process it** | The same assistant, with the prompt in the vault's `prototypes/coach-memo-prompt.md`, ready to paste. |
| **A record the player holds** | An sgit vault per player, encrypted on the device and versioned. [Supplement Stack](../supplement-stack/index.md) and [Health Score](../health-score/index.md) are published examples of records a person holds, with a professional's view. |
| **Write-only lanes for coaches** | [Append lanes](../../../api/append-lanes.md): a coach can add a memo, and cannot read the other lanes or change anything. |
| **Apps that call a model without a key** | The `sg.llm` bridge, documented on [llms.sgit.ai](https://llms.sgit.ai/). |
| **Easy key handling** | Open. It is the subject of [the call for collaboration on vault key management](../../../partnerships/vault-key-management.md). |

## Beyond padel

The loop fits wherever one person teaches another in sessions and knows most about the student at the end of each one: tennis, squash and pickleball, golf, music lessons, language tutoring, personal training and physiotherapy, driving instruction, climbing and swimming. The pieces do not change; each domain needs its own note template and its own themes.

## The audit, honestly

**What was scanned.** Every one of the 27 files, from a clone made with the published read key alone, compared byte for byte with the source folder. Patterns: vault-key shapes, every `sgit_` credential prefix, API-key shapes, private-key blocks, bearer tokens, and email addresses.

**What was found.** Nothing. The player, coaches and clubs are invented, and the vault contains no email addresses at all. The negative control, an all-zeros read key against the same vault id, produced an empty directory.

**What the plan says about its own risks.** Many students are children, so the plan keeps to adults until consent and a guardian's key are designed. Match clips show other players, so clips stay with the coach. Coaches' kit recommendations must declare any commercial interest, and the demo shows one that does.

**Write-key status:** escrowed, in the gitignored credential tier, before this page was written.

## Derived facts

From `admin/build/catalogue_derive.py 3s9q7zl7 <read key hex>`, read-only, no token, no clone.

- **Files:** 27 · **plaintext size:** 407 KB
- **Commits:** 2 · **last updated:** 2026-09-24 · **HEAD:** `obj-cas-imm-3e90049fe51f`
- **Top level:** `PUBLIC.md`, `README.md`, `app.json`, `content.json`, `diagrams/`, `index.html`, `plan/`, `player/`, `prototypes/`, `spec/`, `tools/`
- **Vault app:** yes, entry `index.html` · **browser-renderable:** yes

## Notes

**Where this came from.** A voice memo by the founder on 24 September 2026, after several padel lessons in a few days with different coaches, each seeing something different. The founder already has a padel vault of their own, not yet published, where phase one will be tried first. **Where it sits.** With the other [business plans published for founders](../../../startups/business-plans.md).

[← All published vaults](../index.md)



==============================================================================
# Company X-Ray, a business plan with one company X-rayed, published as a vault

> A business plan for a service that reads a company's own documents together: the customer drops them into an encrypted vault, agents run a catalogue of twelve analyses, a person reviews, and the customer gets back their questions answered, a board pack, findings tied to the file and row they rest on, and a Claude setup to keep asking. No connectors or integrations. One invented company X-rayed end to end with fourteen findings and a script that re-runs every figure, four levels from £50 to £1,500 on the RiskMandate pattern, a calculator, the prompts and the plan.
>
> Page: https://sgit.ai/demos/vaults/company-xray/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Company X-Ray

# Company X-Ray, a business plan with one company X-rayed

A business plan for a service that reads a company's own documents together. The customer drops them into an encrypted vault: management accounts, customer and supplier lists, board minutes, the plan, a complaints log. Agents run a catalogue of analyses across them and a person reviews the result. Within five working days the customer gets back their own questions answered, a one-page board pack, findings that each name the file and row they rest on, and a Claude setup so the team can keep asking questions of the same documents. There are no connectors, no integrations and no access to the customer's systems. It sells in four levels, from £50 to £1,500, on the pattern RiskMandate.ai already uses.

The whole service: an agent platform, a vault, and the customer's own documents. Nothing else.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_6da900d8edd0abd580452a85f6bbe588474cecf21e5f7cbbbbad57d1bf228454:ukpqjkly`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_6da900d8edd0abd580452a85f6bbe588474cecf21e5f7cbbbbad57d1bf228454%3Aukpqjkly) · From the CLI: `sgit clone sgit_public_read_6da900d8edd0abd580452a85f6bbe588474cecf21e5f7cbbbbad57d1bf228454:ukpqjkly`
This key is published on purpose, under the `sgit_public_read_` prefix. It is **derived** one way from a vault key that is kept in the gitignored tier and never published. `check_credential.py` classified it before it was put on this page. It was then tested with an all-zeros key as a control: the real key cloned 60 files, identical to the source folder, and the all-zeros key cloned nothing.

## See it live, here

The plan opens as an app. Pick any finding, then open any line of its evidence to see it highlighted in the document it came from. You can also [**open it in its own window ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_6da900d8edd0abd580452a85f6bbe588474cecf21e5f7cbbbbad57d1bf228454%3Aukpqjkly).

## What is in it

the customer's questions

### Answered first, in plain words

An invented cleaning and maintenance company, Northgate Facilities, sent twelve documents and three questions. Why is profit down when revenue is up? How exposed are we to our largest customer? What should the board be looking at that it is not? The X-ray answers those three first, and each answer points to the findings behind it.

The three questions, and the findings each answer rests on.

evidence

### Every finding names the file and the row

There are fourteen findings. Each carries one of three labels. *Read* means it is stated in a document the customer sent. *Computed* means it is arithmetic on their data, and `tools/recompute.py` re-runs all 46 figures from the documents and checks them. *Inferred* means it is a reading of several documents together, and should be checked before anyone acts on it. In this finding, £1.5m of contracts reach their notice date two weeks before the next board meeting.

A finding, with its evidence opened in the customer's own file.

documents read together

### What nobody set side by side

The most useful findings come from reading one document against another. The minutes describe the largest customer as "strong", while the complaints log shows that customer's complaints nearly tripled. The price list is older than two wage rises. The same half-hour action was carried forward at three board meetings in a row.

One action, carried forward three times, highlighted in the minutes.

keep asking

### A Claude setup, so the conversation continues

A report gets read once, but a setup keeps being used. The delivery includes project instructions, a list of the files to upload and twelve questions to start with. The team can keep asking questions of the same documents under the same rules about evidence. Claude Projects are available on every plan, including free accounts, and the same files work in a ChatGPT Project.

The project instructions the customer pastes into Claude.

the numbers

### A couple of hours with each customer

A Standard X-ray takes about three and a half hours of a person's time, with thirty minutes of it spent with the customer. A Tailored one takes about nine, including two hours with the customer. That works out at £135 to £165 an hour for the reviewer. Two founders break even at around eleven Standard and three Tailored X-rays a month. The calculator lets every input move, and every number is marked as a hypothesis.

A month, with every input on a slider.

## Four levels, the RiskMandate way

Each level is the level below it plus exactly one thing, as on RiskMandate.ai's pricing page.

| Level | Price | What it is | Done when |
|---|---|---|---|
| **The sample** | Free | This vault: an invented company X-rayed end to end, plus the catalogue and the prompts. | You have read it. |
| **The kit** | £50 | The catalogue, the self-run prompt, the intake checklist and the Claude setup, as files. You run it. | The download's hash matches the published hash. |
| **Your X-ray vault** | £150 | The kit as a vault set up for your company, versioned and shareable read-only. You run it. | You have opened it with your key. |
| **Standard X-ray** | £500 | We run the catalogue on your documents, a person reviews every finding, and a thirty-minute call hands it over. Five working days. | The X-ray and the review note are committed to your vault. |
| **Tailored X-ray** | £1,500 | Two one-hour sessions, up to three analyses written for your questions, and a sign-off with a reviewer's name and the date. | Both sessions are held and the sign-off is committed. |

Next to these sit the **Re-X-ray**, at £350 or £900, for when the next quarter's numbers are in. It lands in the same vault, so the difference between the two X-rays is a diff. There is also a **partner licence** at £250 a month plus £100 per X-ray, for accountants and fractional finance directors who already hold their clients' documents. The first two levels are the vault without customisation, and the last two are the vault with it.

## What is reused, and what exists today

| Piece | Where it comes from |
|---|---|
| **The four levels, "done is a commit", free examples first, the prompt free on purpose, reviewer sign-off** | [RiskMandate.ai's pricing](https://riskmandate.ai/pricing.html) and its [reviewed level](https://riskmandate.ai/abp-reviewed.html), reused as they stand. Read, computed and inferred stand in for RiskMandate's measured, documented and derived. |
| **A vault per customer** | An sgit vault, encrypted on the device, versioned, with read-only keys for sharing. The host holds ciphertext only. |
| **The agents** | Claude Code, or any agent that can run `sgit` and Python, using the run prompt in `prototypes/run-the-xray.md`. |
| **The handover** | Claude Projects, or ChatGPT Projects. Sharing a Claude project with colleagues needs a Team or Enterprise plan. |
| **Business terms for the model** | By default, Anthropic does not use inputs or outputs from its commercial products, such as Claude for Work and the API, to train models. The plan says to check the terms before the first customer and to state them on the intake page. |

## Who adds what

The customer adds most of the value: the documents, the context and the questions. The model makes the price possible, because it reads everything and does the arithmetic at speed, and it is available to everybody. The operator adds four things. First, the catalogue: which questions to ask of which documents. Second, the discipline of evidence and labels. Third, the review. Fourth, the packaging, meaning the vault, the board pack and the Claude setup. That is why the price is modest and the method is given away. The review, and the catalogue getting better with every customer, are what a competitor cannot copy in a week.

## The audit, honestly

**What was scanned.** All 60 files, taken from a clone made with the published read key alone and compared byte for byte with the source folder. The scan looked for vault-key shapes, every `sgit_` credential prefix, API-key shapes, private-key blocks, bearer tokens and email addresses.

**What was found.** Nothing. The company, its people, customers, suppliers and numbers are invented, and the vault contains no email addresses at all. The only public facts are the National Living Wage rates, cited to gov.uk. The negative control, an all-zeros read key against the same vault id, produced an empty directory. `tools/recompute.py` was re-run inside the clone, and all 46 figures matched.

**What the plan says about its own risks.** An inferred finding can be wrong, so every one is labelled and a person reads it against its evidence. The documents will contain some personal data even after the intake checklist, so the operator is a processor and needs an agreement and a deletion record. An X-ray describes documents and is not accounting, legal or financial advice, and the plan says so to every customer.

**Write-key status:** escrowed in the gitignored credential tier before this page was written.

## Derived facts

From `admin/build/catalogue_derive.py ukpqjkly <read key hex>`, read-only, no token, no clone.

- **Files:** 60 · **plaintext size:** 710 KB
- **Commits:** 3 · **last updated:** 2026-09-24 · **HEAD:** `obj-cas-imm-ef1f1e4d99b7`
- **Top level:** `PUBLIC.md`, `README.md`, `app.json`, `content.json`, `diagrams/`, `index.html`, `plan/`, `prototypes/`, `sample/`, `spec/`, `tools/`
- **Vault app:** yes, entry `index.html` · **browser-renderable:** yes

## Notes

**Where this came from.** A voice memo by the founder on 24 September 2026. It was written for another entrepreneur who wants to build and run this service, and it is published for anyone else who does. **Where it sits.** Alongside the other [business plans published for founders](../../../startups/business-plans.md). An X-ray often writes down a risk for the first time. The next steps for acting on those risks are published beside it: [RiskMandate.ai](https://riskmandate.ai/) for the AI tools a company runs, and the [Risk Acceptance Office](../risk-acceptance/index.md) for holding each material risk with a named owner.

[← All published vaults](../index.md)



==============================================================================
# SG Commercialisation, a published vault

> A commercial operating model published in the open: nine tools to productise, eight agentic roles, the engagement procedure and every template, with the live engagement register deliberately empty.
>
> Page: https://sgit.ai/demos/vaults/commercialisation/index.html

[Home](../../../index.md) / [Vaults](../index.md) / SG Commercialisation

# SG Commercialisation

The commercial model itself, published rather than kept in a drive. Nine tools to productise, eight agentic roles, the pricing and partnership models, and the templates that run an engagement end to end. The register of live engagements is **empty**, and that is the honest state of it.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_3c8cba7edd2f14e63d0b0f0da4d513430e3eea06f364baefaf8b22d85e151da6:haeu7p1e`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_3c8cba7edd2f14e63d0b0f0da4d513430e3eea06f364baefaf8b22d85e151da6%3Ahaeu7p1e) · From the CLI: `sgit clone sgit_public_read_3c8cba7edd2f14e63d0b0f0da4d513430e3eea06f364baefaf8b22d85e151da6:haeu7p1e`
Published deliberately, and **derived** one-way from a vault key that is not published and never will be.

## See it live, here

Both surfaces open automatically below. You can also [**open the app in its own window ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_3c8cba7edd2f14e63d0b0f0da4d513430e3eea06f364baefaf8b22d85e151da6%3Ahaeu7p1e).

## What is in it

the thesis

### One problem, nine times

The opening claim is sharper than most strategy documents manage: *"the portfolio does not have nine problems, it has one problem nine times."* Nearly every tool is missing the same three things, and none of them is the tool, **purchase of tokens**, **a page to sell from**, and **users**.

So the work is described as *trimming a commercial workflow, not building a product*, taken to market through partners on time-bound, budget-defined mini-projects metered as on-demand hours. The bar is stated as break-even; the durable prize is the shipping-and-billing capability the whole portfolio needs.

The overview: nine tools, eight agentic roles, four source briefs, and the shared gap named as one problem nine times.

the register

### The most credible thing in it is a table with no rows

The engagement register has a **Live engagements** table containing a single row reading *none yet*, followed by an example row explicitly marked *delete once real rows exist*.

Every template underneath it is a placeholder, `<ENG-00X>`, `<Partner>`, `<rate, or rev-share reference>`. The hours-log template carries its own instruction: *never put card/bank details or tokens here.*

A commercial model published before it has any customers is easy to check later against what actually happened. That is the same wager the [sibling sites](../../../network/index.md) make.

The vault browser: the model, the team, the engagement templates.

## Notes

**Audited before publishing.** No email addresses, no rates, no partner names, no money figures other than `$0`. The eight "team" files are *agent role definitions* (Conductor, Ambassador, Alchemist, Commercial, Designer, Developer) not people.

[← All published vaults](../index.md)



==============================================================================
# RiskMandate: File security, a published vault

> A risk-acceptance walk in eleven steps over one evolving register, where the browser becomes the database: versioned JSON in the vault is the source of truth, queried live through SQLite compiled to WebAssembly.
>
> Page: https://sgit.ai/demos/vaults/riskmandate-file-security/index.html

[Home](../../../index.md) / [Vaults](../index.md) / RiskMandate, File security

# RiskMandate, File security

A worked risk decision, structured as an **eleven-step walk** over one shared, evolving register. Its argument is a process one: risk acceptance belongs at the **centre** of the flow, not rubber-stamped at the end, and when the facts change, the risks and their owners change with them.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_e8a1e664b9f984b0d8df442f463231077d455d7cbaa3e336610b14f9a1e1dc77:wu365g94`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_e8a1e664b9f984b0d8df442f463231077d455d7cbaa3e336610b14f9a1e1dc77%3Awu365g94) · From the CLI: `sgit clone sgit_public_read_e8a1e664b9f984b0d8df442f463231077d455d7cbaa3e336610b14f9a1e1dc77:wu365g94`
Published deliberately, and **derived** one-way from a vault key that is not published and never will be.

## See it live, here

Both surfaces open automatically below. You can also [**open the app in its own window ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_e8a1e664b9f984b0d8df442f463231077d455d7cbaa3e336610b14f9a1e1dc77%3Awu365g94).

## What is in it

the inversion

### Risk acceptance, moved to the centre

The comparison is made on the page itself. Traditional: `Build → Ship → Run →` then a Sign-off, described as *"a rubber-stamp after the fact, blind spots, low accountability, and stale by the time it's signed."*

RiskMandate: `Facts → Risks → Accept & own → Propagate ↻ recalibrate`. The dashboard tracks two competing costs at once (**detect-only residual** against **control cost & friction**) so choosing a control is visibly a trade, not a free win. There is no *deny* fork: each risk is accepted, mitigated, or awaiting data, and someone owns the choice.

The discipline it sets itself is *"Grounded, not FUD, facts first."* Each fact walks to its evidence and its source before any decision is offered.

Step 1 of the walk: the counters, the two competing costs, and risk acceptance moved to the centre.

the pattern

### The browser is the database

The vault holds the issues as **versioned JSON files**: that is the source of truth. On load the app copies those nodes and edges into a real database running in the browser, and every read the UI performs is a query against it.

The vault's own note puts it plainly: this is the ordinary shape of a database system, a durable store plus a working engine, *except the durable store is a zero-knowledge, git-versioned file tree*. Steps 7 through 11 expose the layers directly: Data, Database, Graph DB, Graph viz, Explorer.

The vault browser: issues as versioned JSON, and the grant behind the walk.

## Notes

**On the permission line.** `app.json` requests `fs.read` and an explicitly empty `fs.write: []`, the write array is present and empty rather than absent, which states the intent instead of leaving it to be inferred.

[← All published vaults](../index.md)



==============================================================================
# Standards Atlas: GDPR, a published vault

> The General Data Protection Regulation as a navigable semantic graph, where CJEU rulings, regulator guidance and per-country variation are first-class nodes layered over the articles they bend, with a validation surface that writes corrections back into the vault.
>
> Page: https://sgit.ai/demos/vaults/standards-atlas-gdpr/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Standards Atlas, GDPR

# Standards Atlas, GDPR

**"The standard is the graph."** GDPR cannot be read at face value: its operative meaning lives in the rulings, the regulators' guidance, and the per-country variation the text never mentions. This vault makes those first-class nodes layered over the articles they bend, and it is one of the earliest experiments here in shipping a graph as a vault.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_439ca57ab9e53b4edfa67e99da1b70948c297d323376c890292dc2f0876aa15c:4zv4bvmu`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_439ca57ab9e53b4edfa67e99da1b70948c297d323376c890292dc2f0876aa15c%3A4zv4bvmu) · From the CLI: `sgit clone sgit_public_read_439ca57ab9e53b4edfa67e99da1b70948c297d323376c890292dc2f0876aa15c:4zv4bvmu`
Published deliberately, and **derived** one-way from a vault key that is not published and never will be.

## See it live, here

Both surfaces open automatically below. You can also [**open the app in its own window ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_439ca57ab9e53b4edfa67e99da1b70948c297d323376c890292dc2f0876aa15c%3A4zv4bvmu).

## What is in it

the claim

### Read the text at face value and you miss most of it

The vault holds the whole workshop rather than a finished artefact: the raw Regulation (EU) 2016/679, a normalised form, the graph that connects it, the visualisations rendered from that graph, and the provenance that makes each claim auditable. Nine views run from **The text** through **Structure**, **The graph**, **Beyond the text**, **Sources**, **Validate** and **Provenance**.

Its sources are public record and named as such, CJEU proceedings including *Meta Platforms Inc. v Bundeskartellamt*, regulator material from the German federal DPA, and enforcement decisions. Nothing private is in it, by construction.

The overview: the standard as a graph, with the not-legal-advice banner above it and the source instrument below.

the honesty

### A banner across every page, and a seed that says it is a seed

Above every view sits `SEED PASS — NOT LEGAL ADVICE`, and the overview repeats it in full: *"a structural and educational artefact, not legal advice. The rulings/guidance/per-country overlays are a web-verified seed (30 May 2026), illustrative and not exhaustive, and must be validated before they are relied upon."*

That is why the **Validate** view matters. Corrections are written from inside the vault to `/feedback/`, gated on the `fs.write: ["feedback/"]` grant, so a read-only reader records changes in the page only, while the seed graph stays immutable and reviewers layer validated provenance on top.

The vault browser: the graph, its sources and provenance, and the narrow write grant behind Validate.

## The graph view, by altitude

Added 19 September 2026, captured from a read-key clone of the vault with a local host bridge. The graph view is navigated *by altitude*, and the panel says so in its own words: *“You are at the top of the fractal. Each domain is its own ontology that connects up to the GDPR root and down to concepts and articles.”* Descend into a domain and the ring becomes its concepts; descend into a concept and it shows its provenance and the article it anchors to. The rendering does not change between altitudes, only the question does. This vault is one rung of [the ladder that runs from the law to the compute instance](../../fractal-graphs/index.md).

altitude 0 → 1

### The Regulation, then one of its eight domains

At the top: GDPR and eight domains on a ring, one per group of chapters. Pick *Principles* and the ring is Article 5's seven principles (*“the spine the whole graph hangs from”*) seven concepts, one article. The layout is computed from the graph, not drawn.

**An honest count:** the graph holds 165 nodes and 227 edges, and six of those edges are typed `relates`, the one verb [the grammar](https://graphs.sgit.ai/v1/grammar/index.html) bans, because it constrains nothing. This vault predates the rule. Recorded rather than fixed, since the seed graph is deliberately immutable and corrections go to `feedback/`.

Altitude 1: *Principles*, its seven concepts, and Article 5.

beyond the text

### One unchanged article, five rulings

Article 45 has not changed a word since 2016; what it permits has flipped repeatedly, Safe Harbour, Schrems I, Privacy Shield, Schrems II, the Data Privacy Framework, an appeal pending. The view draws the rulings as a timeline over the article node, which is the case for the second layer in one picture: *“this is why a static PDF of GDPR is misleading and a versioned graph is not.”*

The moving target: international transfers, as ruling nodes over one constant article.

## Notes

**The narrowest interesting grant on the site.** Most vaults here request read and no write. This one requests `fs.write` and `fs.mkdir` on exactly one path, `feedback/`, which is how it accepts corrections without ever letting a reviewer alter the graph they are reviewing.

[← All published vaults](../index.md)



==============================================================================
# Content-Transformation Proxy, a published vault

> A three-part as-built engineering brief published as a documentation site inside a vault: ten authored slides, a diagram library and the source PDFs, all served from one read key.
>
> Page: https://sgit.ai/demos/vaults/content-transformation-proxy/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Content-Transformation Proxy

# Content-Transformation Proxy

**"The proxy that shows you only what your policy allows."** A request passes through mitmproxy, a service injects a transformation script, and the page is rewritten before the user sees it. This vault is the as-built write-up, three parts, ten authored slides, a diagram library and the original source decks, published as one navigable documentation site.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_18bf8b2aa558fec879edb39c79ee66d6b9594ada2dff71039b3f66f5b14e4839:3c90c2bff2b1`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_18bf8b2aa558fec879edb39c79ee66d6b9594ada2dff71039b3f66f5b14e4839%3A3c90c2bff2b1) · From the CLI: `sgit clone sgit_public_read_18bf8b2aa558fec879edb39c79ee66d6b9594ada2dff71039b3f66f5b14e4839:3c90c2bff2b1`
Published deliberately, and **derived** one-way from a vault key that is not published and never will be.

## See it live, here

Both surfaces open automatically below. You can also [**open the app in its own window ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_18bf8b2aa558fec879edb39c79ee66d6b9594ada2dff71039b3f66f5b14e4839%3A3c90c2bff2b1).

## What is in it

the shape

### A dev brief that reads like a site, not a folder of PDFs

Nine sections across the top (Overview, Architecture, Vault, Deployment, Slides, Diagrams, Decks, Gallery, Sources) over material from a three-part dev brief dated 11 June 2026. Each part is written up in full with its slides and architecture diagrams placed inline, plus a deck viewer, a diagram library and a reader for the original PDFs.

Two deployment modes are worked through: an inline proxy, and a **streamed remote browser** where a container runs one browser per user and only pixels reach the client, *"nothing to install, all you need is a browser."*

The overview: the thesis, the flow through mitmproxy, and the as-built provenance line.

the point

### Source material and finished explanation in the same object

The vault carries the rendered site, the ten authored infographics, the architecture diagrams, *and* the source PDFs the write-up came from. A reader who doubts the summary can open what it was made from without asking anyone.

That is the property a document attachment loses the moment it is emailed: the explanation and its evidence stop travelling together. Here one read key moves both.

The vault browser: the rendered site, the diagram library and the source decks in one tree.

## Notes

**Checked before publishing.** No client, no third-party project, no external company, no contact details, in the text, and by eye across the slide and diagram images that a text scan cannot read. The only third-party product named is NotebookLM, as the tool that produced three blueprint decks. `"permissions": {}`.

[← All published vaults](../index.md)



==============================================================================
# Penetration Test Report, a published vault

> A complete penetration test delivered as a vault instead of a PDF: eight audience-specific views over one engagement, evidence per finding, and a retest script that re-runs each check and exits 0 or 1. Entirely fictional, and it says so on its own front page.
>
> Page: https://sgit.ai/demos/vaults/pentest-report/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Penetration Test Report

# Penetration Test Report

A penetration test delivered as a **vault** rather than a PDF, and the clearest argument on this site for why that difference matters. One engagement, eight audience-specific views, evidence attached to each finding, and a runnable retest script per finding that exits `0` if it is fixed and `1` if it is not.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_14042259ecbec2d0c7c4e68963695c4ceeeeb652767d25b777024a4f05ccd025:o4lrwx02`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_14042259ecbec2d0c7c4e68963695c4ceeeeb652767d25b777024a4f05ccd025%3Ao4lrwx02) · From the CLI: `sgit clone sgit_public_read_14042259ecbec2d0c7c4e68963695c4ceeeeb652767d25b777024a4f05ccd025:o4lrwx02`
Published deliberately, and **derived** one-way from a vault key that is not published and never will be.

## See it live, here

Both surfaces open automatically below. You can also [**open the app in its own window ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_14042259ecbec2d0c7c4e68963695c4ceeeeb652767d25b777024a4f05ccd025%3Ao4lrwx02).

## What is in it

the reframe

### The same engagement, told for the reader in front of it

A pentest PDF is written once, for everybody, and therefore for nobody. This one opens on **Choose your view**: CEO / Executive, Decision Maker, Financial Decision Maker, Roadmap / Project, Risk Assessment Owner, AppSec Engineer, DevOps Engineer, or the full report.

Each view is its own page, opening on the sections that matter to that audience in their order. The headline numbers stay constant underneath: **10 findings**, **7 internet-reachable and unauthenticated**, a modelled annual exposure against a remediation cost, so the CFO and the AppSec engineer are demonstrably reading the same engagement.

The front page: the verdict, the numbers, and eight ways into one engagement.

the part a PDF cannot do

### Every finding ships a script that re-runs it

Ten findings, and each carries a retest script: `nwp-01_sqli.py`, `nwp-02_jwt_none.py`, `nwp-03_idor.py`, `nwp-05_ssrf.py`, `nwp-06_xss.py`, and so on. Point `BASE_URL` at the environment and `retest_all.py` prints a pass/fail table.

Each script asserts the *fix*, not the bug: a forged `alg:none` admin token is rejected with 401; another user's order id returns 403 or 404 rather than 200; metadata and RFC1918 URLs are refused by the image proxy. Evidence sits beside them, the forged token itself is committed at `evidence/NWP-02/forged-token.txt`.

A report that can re-test itself stops being a snapshot and becomes something you can run again in six months.

The vault browser: retest scripts, evidence and exports beside the report that cites them.

## Notes

**Entirely fictional, and it says so first.** A `SIMULATED DEMO` badge sits next to the engagement id on the front page, and the vault states it in its own text: *"Everything here is fictional, the company (Northwind Provisions), the app…"*. The audit confirmed it: every host is a reserved `.example` domain, every address an `@example.com`, and the only public IP is `169.254.169.254`, the cloud metadata address any SSRF finding cites. The consulting firm and its named team are invented, with no contact details attached.

[← All published vaults](../index.md)



==============================================================================
# AI vs. AI, Black Hat Europe 2025, a published vault

> A conference keynote shipped as a vault: the deck as presented, six PDF exports, eight research papers and the full source history of the slide system that renders it, all behind one read key, with the slide content as data the app reads at load time.
>
> Page: https://sgit.ai/demos/vaults/blackhat-eu-2025/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Black Hat EU 2025

# AI vs. AI, Black Hat Europe 2025

A conference keynote shipped as a vault: the deck that was presented, the six PDF exports it went through, the eight research papers it was built from, and the entire source history of the slide system that renders it, behind one read key. Opening the vault launches the deck full-screen.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_147fa50d3c491aeea3e700d60ef21ea2897884e263700d95765dc8f624dc59ac:k1izvg7e`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_147fa50d3c491aeea3e700d60ef21ea2897884e263700d95765dc8f624dc59ac%3Ak1izvg7e) · From the CLI: `sgit clone sgit_public_read_147fa50d3c491aeea3e700d60ef21ea2897884e263700d95765dc8f624dc59ac:k1izvg7e`
Published deliberately, and **derived** one-way from a vault key that is not published and never will be.

## See it live, here

The deck opens automatically below and is driven with the arrow keys, `→` next, `←` previous, `F` for fullscreen. You can also [**open it in its own window ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_147fa50d3c491aeea3e700d60ef21ea2897884e263700d95765dc8f624dc59ac%3Ak1izvg7e).

## The talk

**AI vs. AI: Building Resilient Enterprises in the Age of Autonomous Threats**: Dinis Cruz, AI Security Summit, Black Hat Europe 2025, ExCeL London, 9 December 2025. Twenty-six slides.

the setup

### Four pillars, and an admission

The argument opens by conceding the ground rather than claiming it. **Security's four pillars, all broken**, followed immediately by the more uncomfortable slide: **we've been getting away with it.**

The evidence there is four publicly documented outages, none of them attacks: a timing bug that wiped out a global database, a config inconsistency that propagated silently and then detonated worldwide, a routine config change that halted traffic, and a faulty update that bricked 8.5 million Windows machines.

The turn is one line at the bottom of the slide: *"These weren't sophisticated attacks. They were minor glitches that cascaded. Now imagine if they were deliberate, coordinated attacks."*

Slide 6 of 26. Four cascading failures, and the question underneath them.

the threat model

### The new insiders

The middle of the deck reframes agents as an insider-threat problem and then draws the comparison directly: human insiders have **natural limitations on skill and time** and rarely act at machine speed; AI agents have neither constraint.

From there it separates **three categories of AI-driven threat** and asks why enterprises are not ready, arriving at *fragile by default* as the diagnosis rather than a lack of tooling.

The insider comparison the rest of the talk builds on.

the answer

### The defender's edge

The second half is constructive, and several of its slides describe things this site now demonstrates: **assume compromise, contain blast radius**, **version control everything**, **identity graphs for least privilege at scale**, and **knowledge graphs** as the mechanism.

It also argues for funding non-functional requirements at unprecedented scale, treats *vibe coding* as the new spreadsheets, a governance problem rather than a fad, and ends on **don't become the department of 'no'**.

Those threads have their own homes now: [risks](../../../network/index.md#risk-governance) and [nfrs](../../../network/index.md#risk-governance), [graphs](../../../network/graphs.md), [nhi](../../../network/nhi.md) for agent identity, and [coding](../../../network/index.md#agents-ai).

The concession the talk opens with, before any solution is offered.

## Why it is a good vault

A deck emailed as a PDF is a snapshot with its working removed. This one ships the whole chain in a single object, addressed by one credential:

| Path | What it is |
|---|---|
| `index.html` | The deck as a self-contained vault app, 26 slides, ~976 KB |
| `deck/blackhat-eu-2025.json` | The slide content. Edit this, commit, push. The app reads it through the vault bridge at load time, so a content change needs no rebuild |
| `pdf/` | Six exports, v0.1.1 through v0.2.0, the deck as it looked at each stage |
| `research/` | Eight background papers the talk was built from, Parts 1 through 7 |
| `source/v0/v0.1/` | The slide system itself at ten versions, v0.1.0 to v0.1.9, unmodified |

The separation worth noticing is the third row. **Content is data, not markup.** The deck is a JSON file the app reads at load time, so changing a slide is a commit rather than a rebuild, which is also why the vault can carry ten versions of the renderer beside one deck without either owning the other.

The whole chain in one tree, and `"permissions": {}` behind it.

## Notes

**It asks for nothing.** `app.json` declares `"permissions": {}` with `present: true`. A deck needs no filesystem access, so it requests none, the same posture as the [Risk Graph Explorer](../risk-graph-explorer/index.md).

**Audited before publishing.** No sgit credentials, no third-party API keys, no private keys, no email addresses, and no external company or client named. The organisations that do appear (AWS, Azure, Cloudflare, CrowdStrike) are cited for their publicly documented outages, which is what the slide is about.

**The conference branding is the real thing.** The deck uses Black Hat Europe's official speaker template, because it is a talk that was given there. It is published here as the speaker's own material, not as anything endorsed by or affiliated with Black Hat.

**The source is public too.** This vault republishes material that already sits in the open at [the-cyber-boardroom/Presentation__BlackHat-EU__Dec-2025 ↗](https://github.com/the-cyber-boardroom/Presentation__BlackHat-EU__Dec-2025), so nothing here is first exposed by the vault. This is a second, addressable copy that travels as one object.

[← All published vaults](../index.md)



==============================================================================
# Scaling Threat Modeling with Semantic Knowledge Graphs, a published vault

> ThreatModCon 2025, Barcelona: eleven linked threat models from customer to compute instance, five interactive views and five Wardley map walkthroughs, running offline inside the vault, with two upstream-broken data files repaired and the repair proved as a pure block move.
>
> Page: https://sgit.ai/demos/vaults/threatmodcon-2025/index.html

[Home](../../../index.md) / [Vaults](../index.md) / ThreatModCon 2025

# Scaling Threat Modeling with Semantic Knowledge Graphs

ThreatModCon 2025, Barcelona. Eleven linked threat models stacked from the customer at the top to the compute instance at the bottom, **a graph of graphs**, so a vulnerability in a single line of code can be traced up to the revenue it puts at risk. Five interactive views and five Wardley map walkthroughs, all running inside the vault with no network.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_23fb205247b2b9c88a943d7ffece9dacf9c00c50cc94840668b4916f247b8ec4:0ict6flm`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_23fb205247b2b9c88a943d7ffece9dacf9c00c50cc94840668b4916f247b8ec4%3A0ict6flm) · From the CLI: `sgit clone sgit_public_read_23fb205247b2b9c88a943d7ffece9dacf9c00c50cc94840668b4916f247b8ec4:0ict6flm`
Published deliberately, and **derived** one-way from a vault key that is not published and never will be.

## See it live, here

Opens on the hub; every visualisation below it runs from the vault. You can also [**open it in its own window ↗**](https://dev.vault.sgraph.ai/#sgit_public_read_23fb205247b2b9c88a943d7ffece9dacf9c00c50cc94840668b4916f247b8ec4%3A0ict6flm).

## What is in it

the thesis

### A threat model of one system tells you very little

The hub states the argument and then quantifies it: **11 readable layers, 51 nodes, 179 threats, 3 critical**. The zoom ladder runs Customer → Business → Application → Component → Package → Class → Method → Source Code → Environment → Runtime → Compute, each layer carrying its own node and threat counts.

The point of stacking them is traversal, not tidiness. One model answers *what could go wrong here*. Eleven linked models answer *what does this line of code put at risk*, which is a different question and the one an executive is actually asking.

Eleven layers, counted. Everything below the fold is live and runs offline.

the same fact, four audiences

### One SQL injection, four different messages

The fifth Wardley walkthrough takes a single critical finding in a payment gateway and writes the message four ways (**Board Member**, **CISO**, **CTO**, **Developer**) each with guidance on how to communicate and a message ready to send.

It is the same instinct as the [pentest report vault](../pentest-report/index.md): the finding does not change, the framing does, and both are derived from one underlying model rather than written four times by hand.

Board, CISO, CTO and Developer, one finding, four framings.

the maps

### From graph to Wardley map, in five steps

The Wardley set walks from a plain graph to a positioned map, through evolution stages, to security prioritisation, *from "everything is critical" to risk-based decisions*, and ends on the multi-persona cost view.

It pairs naturally with [wardley-maps.sgit.ai](../../../network/index.md#graphs-method), whose argument is that *maps are claims, not pictures*. These are the claims, drawn.

Step 3 of 5: evolution stages applied to security prioritisation.

the flat view

### The whole estate on one screen

Alongside the layered explorer there is a flat view of the same data (end customer, payment processing, user authentication, order fulfilment) for when you want the shape of the system rather than a path through it.

The same eleven layers, flattened.

## Two upstream data files were broken, and both were repaired in the open

This is the part worth reading even if threat modelling is not your subject. `tm-6-class-layer.json` and `tm-11-compute-layer.json` **are not valid JSON in the source repository**, so the class and compute layers do not load there at all. Both are fixed in this vault, and the vault documents the repair rather than quietly shipping it:

**Every change moves existing text or closes a bracket. No field was edited and nothing was invented.** The untouched originals are kept alongside, in `source/threat-models-data/`.

The upstream being public is what makes the repair auditable rather than merely asserted: the broken originals are at [DinisCruz/Presentation-Threat-Mod-Con-2025 ↗](https://github.com/DinisCruz/Presentation-Threat-Mod-Con-2025), and the vault keeps its own untouched copies beside the repaired ones.

And the fix is stated as something you can check rather than trust: comparing original against repaired line by line, the only differences are **four stray closing brackets removed and one `],` added**: the multiset of all content lines is unchanged. That is a repair expressed as a proof, which is a good deal rarer than a repair expressed as a changelog entry.

## Making a presentation survive inside a vault

The pages were already standalone HTML. The work was making them run on a `blob:` origin with no reliable network:

- **Libraries inlined at identical versions**: d3 7.8.5, three.js r128, tween.js 18.6.4, taken from each library's npm dist. No page touches the network.
- **Data repointed.** The explorer used to fetch its layers from an origin bucket. It now tries the vault's own copy through `sg.vfs.readText()` first, keeps the bucket as a second chance, and falls back to a snapshot inlined at build time, and **reports failure on screen instead of silently rendering nothing**.
- **A host handshake per page.** Every page posts `sg-app-ready`, because each one becomes the iframe document when you navigate to it.

Verified before publishing: a contract scan of all eleven pages for vault-relative references and surviving CDN links, `node --check` on every inline script block, hub links resolved against the filesystem, and a jsdom render of each page asserting that d3, THREE and TWEEN initialise and the SVG actually builds.

One class of jsdom error is filtered from that test, and the vault records that it was **checked against the untouched original first**, which produces the same error. Filtering a failure you have not first reproduced on a known-good input is how a test quietly stops testing.

## Notes

**It asks for nothing.** `app.json` declares `"permissions": {}` with `present: true`.

**Audited before publishing.** No sgit credentials, no third-party API keys, no private keys, no emails, no external company or client named. The modelled estate is a worked example, not a real customer.

**One thing you will only see inside the vault.** The threat-model explorer loads its eleven layers through `sg.vfs.readText()`. Open the file straight off disk and it sits on a loading spinner, because there is no vault bridge to answer it, which is the clearest small demonstration on this site of what the bridge actually does.

[← All published vaults](../index.md)



==============================================================================
# AIUC-1, as a graph you can cite, a published vault

> An unofficial, derivative machine-readable catalog of the public AIUC-1 agent standard: 53 controls, 144 requirements, 1,126 crosswalks and 1,238 nodes, where every field names the page or commit it was read from with the SHA-256 of the retrieved bytes. Not approved or endorsed by AIUC. Forked, byte for byte, into the conformance layer vault.
>
> Page: https://sgit.ai/demos/vaults/aiuc-1-graph/index.html

[Home](../../../index.md) / [Vaults](../index.md) / AIUC-1 graph

# AIUC-1, as a graph you can cite

**Unofficial and derivative. Read this first.** This vault is a machine-readable catalog of the public AIUC-1 agent standard, built by the sgit.ai graph estate. In its own words: *"It is **not** approved, certified, endorsed or reviewed by AIUC. It is **not** an official AIUC API, export or data feed. It is **not** a substitute for the standard."* The canonical sources are [aiuc-1.com ↗](https://www.aiuc-1.com/) and the [official changelog repository ↗](https://github.com/aiunderwriting/AIUC-1-Changelog). **Where anything here disagrees with those, those are right and this is wrong.** It makes no compliance, certification, underwriting, insurance, legal or security claim about anybody, and cannot be used to make one.

**This is the earlier vault, and it is kept exactly as it was.** A fork of it ([**the AIUC-1 conformance layer**](../aiuc-1-conformance/index.md), vault `2wzct4k7`) copies every file here byte for byte and adds one directory above it, answering a different question: not *what does the standard say*, but *does a given subject do it*, and what would be insurable on a given date. Both are published. This page is the catalogue on its own; the fork's page is the layer. Nothing on this page changed when the fork was made, and the fork's tests confirm the copy is byte-identical.

A standard read from its own pages, normalised, cross-checked against its official changelog repository, and decomposed into one graph, where every field points back at the page or commit it came from, with the SHA-256 of the retrieved bytes and the time they were retrieved. **53 controls, 144 requirements, 1,126 crosswalks, 1,238 nodes and 3,526 edges**, over five releases.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_4435037d6936ef6986d0646ff23ed3affc46eb74bf8a65ca1f729fd5d3a4ae00:hq21tlqu`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_4435037d6936ef6986d0646ff23ed3affc46eb74bf8a65ca1f729fd5d3a4ae00%3Ahq21tlqu) · From the CLI: `sgit clone sgit_public_read_4435037d6936ef6986d0646ff23ed3affc46eb74bf8a65ca1f729fd5d3a4ae00:hq21tlqu`
Published as a read key. The vault key is not published and never will be.
Relabelled 20 September 2026: this key was published under the `sgit_private_read_` prefix, which declares a key meant to be kept secret. Same bytes, same access, wrong declaration. The prefix for a key published on purpose is `sgit_public_read_`. [What the prefixes mean →](../../../docs/credentials.md)

## See it live, here

[Open the vault in a new tab ↗](https://dev.vault.sgraph.ai/#sgit_public_read_4435037d6936ef6986d0646ff23ed3affc46eb74bf8a65ca1f729fd5d3a4ae00%3Ahq21tlqu)A full application. It has far more room in its own tab than in the frame below.

## What is in it

a control, in edges

### The graph is the point, not the list

Open any control and the app draws what it *is* in terms of its relationships: `has_requirement`, `maps_to`, `evidenced_by`, `includes`, `applies_to_capability`, `tagged`. Control A001 alone resolves to 1 domain, 3 requirements, 20 crosswalks, 4 sources, 4 releases, 1 capability and 3 keywords.

That is [graphs.sgit.ai](../../../network/graphs.md)'s argument applied to a compliance standard: a verb-per-edge vocabulary rather than a bag of properties, so *"what does this control map to"* is a traversal instead of a search.

Every control carries its official page URL, so a reader can leave for the source in one click.

The disclaimer sits above every view, in the app itself.

the evidence

### Eighty-two pages, each with the hash of what was received

The Evidence tab is one row per captured page: the URL, the HTTP status, the retrieval timestamp, **the SHA-256 of the bytes**, and the path to the retained gzipped snapshot inside the vault. As it puts it: *"any claim above can be checked against the bytes it was read from rather than against this catalog's word for it."*

It also publishes **where its two sources disagree**: five reconciliation findings where the website and the official repository differ on guidance formatting or bullet order, each classified as presentation rather than meaning. And then the line that makes the whole thing trustworthy:

Validation, reconciliation and drift, each with its own counter.

**"None of these is resolved here. Resolving one means choosing a source, and that is not this build's to choose."**

That is the discipline the rest of the catalog rests on. A derived artefact that silently picks a winner when its sources conflict has stopped being derived and started being an opinion, and the reader cannot tell which. This one preserves both readings, classifies the difference, and stops a release being marked `validated` if a difference changes meaning.

## Five releases, one of them deliberately unbuilt

The catalog covers 2025-10-01, 2026-01-15, 2026-04-15 and 2026-07-15. A fifth, 2025-07-22, is **named by AIUC but carries no commit**, so it could not be built, and it is recorded as unbuilt rather than quietly dropped. That is the same instinct as listing an unpublished site in [the network directory](../../../network/index.md) instead of omitting it: an absence somebody can see is worth more than a tidy list.

Alongside the releases sit **194 derived change events** from release-to-release differences, kept separate from the **104 change rows AIUC publishes itself**: derived and official never mixed.

## How it was collected

The source policy is unusually explicit, and worth quoting because most scrapers do not write one:

- An identifying user agent naming the build and where to complain.
- **At most one request per second** per host.
- `robots.txt` fetched before any page. It returned 404 at capture time, so there were no directives, and *the manifest records that observation verbatim rather than the conclusion alone*.
- No authentication, no private endpoints, no slug guessing: **every page fetched was linked from a page already fetched**.

## Notes

**It asks for nothing.** `app.json` declares `"permissions": {}` with `present: true`.

**Audited before publishing.** No sgit credentials, no third-party API keys, no private keys.

**One open question, which the vault raises itself and we are not hiding.** Its `NOTICE.md` and `docs/source-policy.md` (both of which are files **inside the vault**, readable by opening it above rather than in any GitHub repository) record that **reuse rights for the full AIUC-1 control text have not been confirmed with AIUC**, and that anyone republishing the catalog publicly should confirm them first. Publishing this read key is exactly that kind of republication. It is here at the author's decision, with the vault's own disclaimers reproduced above rather than summarised away. The vault also states the remedy plainly: *"If you are AIUC and want something here changed or removed, the fastest route is the sgit.ai project behind graphs.sgit.ai. Removal will be honoured."* That undertaking is repeated here and applies to this page too.

[← All published vaults](../index.md)



==============================================================================
# Provenance is not conformance, a published vault

> A fork of the AIUC-1 catalogue vault that keeps every byte of it and adds one directory: attested_by kept permanently apart from evidenced_by, 53 conformance rows for a named subject where unevidenced is the default, and insurability computed as a query that turns into 53 exclusions when the date moves. Unofficial and derivative; not approved or endorsed by AIUC.
>
> Page: https://sgit.ai/demos/vaults/aiuc-1-conformance/index.html

[Home](../../../index.md) / [Vaults](../index.md) / AIUC-1 conformance layer

# Provenance is not conformance

**Unofficial and derivative. Read this first.** This vault is a copy of the [AIUC-1 catalogue vault](../aiuc-1-graph/index.md) with one directory added. It inherits that vault's `NOTICE.md` whole: it is **not** approved, certified, endorsed or reviewed by AIUC, **not** an official AIUC API or data feed, and **not** a substitute for the standard. The canonical sources are [aiuc-1.com ↗](https://www.aiuc-1.com/) and the [official changelog repository ↗](https://github.com/aiunderwriting/AIUC-1-Changelog); **where anything here disagrees with those, those are right and this is wrong.** The added layer carries a second disclaimer of its own, in its own words: *"It records what is evidenced and what is not; it certifies nobody, maps nothing officially, and makes no underwriting decision."* Nothing here is a compliance, certification, underwriting, insurance, legal or security claim about anybody, including the subjects it names, which are invented for the purpose.

A standard tells you what good looks like. It cannot tell you whether *you* do it. This vault keeps those two questions apart with two edges that are never allowed to touch, `evidenced_by`, *does the standard say this?*, and `attested_by`, *does this subject do this?*, and then asks the question the second edge makes possible: **given what is actually evidenced, on this date, what would be insurable?**

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_0f01d367b04f886f6c65038649b76504f4cd2ad06480d88a5e933a671e0db072:2wzct4k7`
 From the CLI: `sgit clone sgit_public_read_0f01d367b04f886f6c65038649b76504f4cd2ad06480d88a5e933a671e0db072:2wzct4k7`
Published as a read key. The vault key is not published and never will be.
Relabelled 20 September 2026: this key was published under the `sgit_private_read_` prefix, which declares a key meant to be kept secret. Same bytes, same access, wrong declaration. The prefix for a key published on purpose is `sgit_public_read_`. [What the prefixes mean →](../../../docs/credentials.md)

## See it live, here

[Open the vault in a new tab ↗](https://dev.vault.sgraph.ai/#sgit_public_read_0f01d367b04f886f6c65038649b76504f4cd2ad06480d88a5e933a671e0db072%3A2wzct4k7)Thirteen tabs and a graph canvas. It has far more room in its own tab than in the frame below.

## The decks, read straight out of the vault

Four decks climb the same four levels the vault does, what the standard is, the vault, the insurance model, and one control zoomed in. They are not screenshots of a deck and not a PDF sitting on a web server: the slides are read out of vault `2wzct4k7` as you click, with the same read key printed at the top of this page.

**What came from where.** The slides, the speaker notes, the screenshots and the PDF are vault files, fetched as ciphertext with the published read key and decrypted in your browser. Every control above it (the tabs, the slide list, prev and next, the notes toggle, the PDF button) is this site's, so the vault decides what is *shown* and never what this page *does*. The deck's own code runs in a sandboxed frame with no origin and no network; the slide you are looking at renders in a second one with scripting switched off entirely. [How this works, and why the PDF is a download rather than an embed →](../../../docs/vault/reading-a-vault-file.md)

**Each deck also has a page of its own**: the same slides, plus room for what the slides cannot carry. [All four decks, one page each →](decks/index.md)

## A fork, and what a fork is allowed to change

The [AIUC-1 catalogue](../aiuc-1-graph/index.md) is still published here, unchanged, and it is still the thing to read if what you want is the standard as data. **This vault contains all of it.** Not a summary of it, not a re-derivation, the same bytes:

> “`README.md`, `NOTICE.md`, `graph/`, `catalog/`, `sources/` and `evidence/` are byte-identical to the original, and the catalogue's own 21 tests still pass, including the one that rebuilds every source document to the word.”

That claim is checkable rather than decorative, and checking it is the first thing we did on the clone: `tests/run.py` reports **21/21 passed**, and the added layer's own `tests/test_conformance.py` reports **19 tests, 0 failed**. Neither opens the network.

It is the discipline that makes the fork readable at all. A derived artefact that quietly edits its source while adding to it leaves the reader unable to tell which parts are the standard and which are the opinion. Here the boundary is a directory: everything new is under `conformance/`, and stripping the extension returns the catalogue's app byte for byte, asserted by a test.

## The one rule the whole thing rests on

Two verbs, in two graphs, that are never traversed in one query without the query naming which it used:

| Edge | Lives in | Answers | Absent means |
|---|---|---|---|
| `evidenced_by` | the catalogue's `graph/edges.json` | does the standard say this? | a build defect |
| `attested_by` | the layer's `conformance/graph/edges.json` | does *this subject* do this? | **the control is unevidenced, which is the finding** |

The rule is enforced rather than described: *"`tests/test_conformance.py::test_two_edge_rule` is red if a layer edge ever reaches a `source_observation`."* In the explorer the two are drawn in different colours, under different legend headings, and never share a row.

The second row of that table is the interesting one. **Unevidenced is a state, and it is the default.** Every control in scope gets a row whether or not anyone has looked at it, so an absent row is never quietly read as compliance. The first build of one subject across all 53 controls comes out **2 evidenced, 48 unevidenced, 3 contradicted**, and that is the designed answer, not a failure to finish.

the layer, per control

### 53 rows, a level out of five, and the date it expires

Each row is a `conformance/v1` object: a state, a level from 0 to 5 derived from the requirements the control already has, the attestations behind it with their tier, and a `valid_until`. Levels are computed, not asserted, 1 is a core requirement evidenced, 2 is every core, 5 is all of them at the observed or third-party tier.

Two consequences of computing them fall straight out. Fourteen controls have no supplemental requirement and so skip level 3. And **six controls whose only requirement is third-party testing cannot leave level 0 on a self-report**, whatever the self-report says. A ladder you cannot climb by asserting things about yourself is a different object from a checklist.

Pick a subject and a date; every one of the 53 controls has a row, and most of them say `unevidenced`.

insurability

### The policy is a query, and time is what breaks it

The layer composes with the [Licence to Operate](../licence-to-operate/index.md) vault's instrument: the conformance state of each control becomes a **condition** or an **exclusion** on a `policy/v1`, and the bow ties decide which consequences are covered. At build time the answer is **1 condition met, 52 exclusions, 0 of 5 consequences covered**: every exclusion carrying its reason in the control's own words.

Then move the date. At 2027-01-15, **with nothing edited by anybody**, the single condition has expired and the policy has 53 exclusions. The vault states the point plainly: conditions become exclusions *"because the attestations behind them expire, which is the real-timeliness arriving as a consequence rather than as a feature."*

And then it declines to overreach. The policy object carries a `does_not_prove` field, and what it says it does not prove is *"that any control is in place: it proves what was attested, at what tier, and when it expires"*, and *"that the underwriter would write it."*

Coverage by consequence, with *why not* spelled out for each: no preventive barrier is evidenced at the required level.

two graphs, one canvas

### The crosswalk becomes a join, and the join finds a problem

AIUC-1 publishes 1,126 crosswalks to external frameworks as text. This layer resolves the EU AI Act ones into node ids in the published [regulation graph vault](../regulation-graph/index.md), with CELEX and a hash on each edge, so a crosswalk stops being a string and becomes a traversal between two vaults.

**62 of the 1,126 resolve**, at article level, onto 27 articles. The remaining 1,064 target twelve frameworks with no published graph here, and are *reported unresolved rather than forced*. Then the join returns something neither vault knew alone: **8 of those 27 articles are amended by Regulation (EU) 2026/1744**, so the crosswalk was published against the text before amendment. That is a finding you cannot reach with a document.

The explorer, rebuilt on [graphs.sgit.ai](../../../network/graphs.md)'s universe techniques, and one of its packs is *another vault*.

The explorer states its own arithmetic in the header: *"Both graphs are loaded (the catalogue's 2788 nodes and 11610 edges, and the conformance layer's 182 and 414) as one, and the canvas draws the neighbourhood you ask for, not all of it."* A verb register covers all **41 edge types across both graphs**, each with a unique inverse, so a link reads correctly from whichever end you stand at; **595 anchors** tie nodes to the exact bytes they came from, verified at build and again in the browser.

## What it is honest about

The layer publishes **17 findings** about itself, and the sharpest of them are the ones that undercut the ambition it was built with. The brief that specified it hoped the agent-to-standard join would be automatic; the finding records that it is not: *"the join needs an authored class map. It is not hand-free as the brief hoped."* Others record that the crosswalks resolve only at article level where the regulation graph has paragraphs, and that AIUC-1 has no recovery-barrier class at all, which is what stops several consequences from being coverable.

It also treats a stale acceptance as a first-class result. All three recorded acceptances, signed on 1 September, come back **stale**: not because anyone withdrew them, but because attestations written afterwards moved the barriers they were signed against. An acceptance is never edited here; its basis is captured at the moment of the decision and is allowed to go out of date on its own.

## Fourteen versions, seven of them a reconstruction

The Versions tab is this vault's own history, and it makes the fork's provenance the first thing you see: `hq21tlqu` named as the original, `2wzct4k7` as this one. Fourteen versions, seven with a real commit, and seven marked **reconstructed, no commit**, because everything the original catalogue ships was generated in a single run and nothing records it being built in stages.

Those seven carry `reconstructed: true` and a `basis[]` naming the files that make each stage a distinct thing. It would have been easier to write seven plausible commits. Labelling them as a reconstruction is the same instinct as leaving the unbuilt release in the catalogue: **a named absence is worth more than a tidy one.**

Both vault ids, stated at the top of the history: what was copied, and what this is.

## The first vault here that asks to write

The [catalogue](../aiuc-1-graph/index.md) it was forked from declares `"permissions": {}`. Two vaults published here have asked for something before, [the pitch](../voicedebrief-pitch/index.md) for downloads and external links, [licence to operate](../licence-to-operate/index.md) for filesystem *read*, but this is the first to ask for a write grant, and the first to ask for the model bridge:

```
"permissions": {
  "fs":  { "read": true,
           "write":  ["chat/"],
           "mkdir":  ["chat/"],
           "delete": ["chat/"] },
  "llm": { "chat": true, "models": true, "usage": true }
}
```

The **Chat** tab threads with the vault's own model through `sg.llm.*`, grounded by tools that can read any file in the vault, query both graphs, and drive the tabs. This is the bridge that [llms.sgit.ai](../../../network/index.md#agents-ai) documents and that [our own chat panel](../../../articles/chat-on-a-static-site.md) could not use: the key lives below the permission floor in the host, and the app never sees it.

The write grant is the part to notice. It is `["chat/"]` and nothing else, so the conversation is stored in the vault, versioned like everything else, while `conformance/terms/`, the authored inputs the whole query depends on, **cannot be written by the app at all**. The host refuses. As the vault puts it: *"the vault holds the terms and the browser holds the run; the app never writes the terms."* A read-key visitor cannot write anywhere regardless; the grant matters to whoever holds the write key.

## It reads this estate, and hashes what it reads

The References tab is unusual enough to call out. It names the sites and vaults this build drew on, [graphs.sgit.ai](../../../network/graphs.md) for the explorer's techniques, [risks.sgit.ai](../../../network/index.md#risk-governance) for the acceptance model, [pki.sgit.ai](../../../network/pki.md) for the `policy/v1` object, [coding.sgit.ai](../../../network/index.md#agents-ai) for the testing practice, and five published vaults including this site's own [regulation graph](../regulation-graph/index.md) and [licence to operate](../licence-to-operate/index.md), and then copies the source documents into `references/documents/` **with a SHA-256 for each**.

It is the first vault published here that treats the rest of the network as a citable source rather than as background, and the first to record *where each idea it borrowed lands in its own files*. If the argument on [the network page](../../../network/index.md) is that these twenty sites are one body of work, this is the first artefact that demonstrates it from the inside.

## Notes

**649 files, 43 MB**: against the catalogue's 135 files and 18 MB. The added weight is the layer, the rebuilt explorer, three decks with PDF exports, and the copied reference documents.

**Audited before publishing.** No sgit vault keys, no third-party API keys, no private keys, no personal data. Two sgit read keys appear inside it, both by design and both already public: the [regulation graph](../regulation-graph/index.md) it resolves crosswalks into, and the [Risk Graph Explorer](../risk-graph-explorer/index.md) it inherits the acceptance model from.

**The subjects are invented.** `team:support` and `agent:concierge` are constructed for the demonstration. Nothing on the Conformance tab is a statement about a real organisation's controls, and the conformance object exists to show the shape of the question, not to answer it about anybody.

**The open question from the catalogue applies here too, doubled.** Its `NOTICE.md` records that reuse rights for the full AIUC-1 control text have not been confirmed with AIUC, and that anyone republishing it publicly should confirm them first. This vault republishes that text and adds a layer on top of it. It is here at the author's decision, with the disclaimers reproduced rather than summarised away, and the vault's own remedy stands: *"If you are AIUC and want something here changed or removed, the fastest route is the sgit.ai project behind graphs.sgit.ai. Removal will be honoured."* That undertaking is repeated here and applies to this page and to the [catalogue page](../aiuc-1-graph/index.md) alike.

[← The AIUC-1 catalogue this was forked from](../aiuc-1-graph/index.md) · [All published vaults](../index.md)



==============================================================================
# A three-minute pitch, delivered from a vault, a published vault

> The VoiceDebrief pitch to Founder Institute: a presenter app with timed slides, speaker notes and a countdown, shipped with the outline, script, research and exports it was built from, and the first vault here that asks for any permission at all.
>
> Page: https://sgit.ai/demos/vaults/voicedebrief-pitch/index.html

[Home](../../../index.md) / [Vaults](../index.md) / VoiceDebrief pitch

# A three-minute pitch, delivered from a vault

The VoiceDebrief pitch to Founder Institute, 2 September 2026, not a deck *about* a vault but a deck **presented from** one. Twelve slides and five backup slides, speaker notes, a three-minute countdown, PDF and PPTX exports, and every source the pitch was built from, all behind one read key.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_23cbc4c65c24cb23ef3efb78e34593391c6709f0106ea81799aa14fe97f4d211:95i2xqrd`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_23cbc4c65c24cb23ef3efb78e34593391c6709f0106ea81799aa14fe97f4d211%3A95i2xqrd) · From the CLI: `sgit clone sgit_public_read_23cbc4c65c24cb23ef3efb78e34593391c6709f0106ea81799aa14fe97f4d211:95i2xqrd`
Published as a read key. The vault key is not published and never will be.

## See it live, here

[Open the vault in a new tab ↗](https://dev.vault.sgraph.ai/#sgit_public_read_23cbc4c65c24cb23ef3efb78e34593391c6709f0106ea81799aa14fe97f4d211%3A95i2xqrd)A presenter app, arrow keys, `N` notes, `T` countdown. Much better in its own tab.

## What is in it

the app

### A presenter, not a PDF

The vault opens straight into the deck: a slide index down the left with **per-slide target timings** (0:00, 0:15, 0:30 … 2:50), a live 3:00 countdown, speaker notes on `N`, Focus, Fullscreen, and a Materials view listing everything else in the vault.

Twelve slides run from *"The buried action"* and *"Audio is everywhere, meaning is not"* through the product, the market, the money and the ask. Five backup slides sit below them for Q&A, including one titled *"WhatsApp / ChatGPT already does this"*, which is the objection answered rather than avoided, and a 60-second version of the whole pitch.

The footer says where it is running from: *delivered from an encrypted SG/Vault*.

Slide 7 of 12, with the timing ladder and the backup Q&A set below it.

the working

### The sources ship with the pitch

What makes this a vault rather than an export is everything *underneath* the slides: the approved outline with its claims-to-keep-exact list, the spoken script per slide with timings, the fifteen-part pitch pack, the event and research notes, the original product screenshots, and the PDF and PPTX exports of the same twelve slides.

A deck emailed as a PDF is the conclusion with the working removed. Here the argument and the evidence for it travel as one object, and the deck itself is built from `deck/src/deck.template.html` by a script in the vault, so the slides are generated, not hand-maintained.

Every claim on a slide has a script line and a source behind it in the same vault.

## The first vault here that asks for anything

Every other vault on this site declares `"permissions": {}`. This one is the exception, and it is a useful one:

```
"permissions": { "downloads": true, "externalLinks": true }
```

It offers PDF and PPTX buttons, so it asks for **downloads**. It links out to the live product, so it asks for **external links**. And that is the entire request, **no filesystem access at all**, not read, not write, at any path.

That is the permission model doing exactly what it is for. The grant is short enough to read in one line, it maps one-to-one onto two things you can see in the interface, and anything not on that line is not available to the app no matter what its code tries. Compare it with the [Risk Graph Explorer](../risk-graph-explorer/index.md)'s empty grant and the difference is legible at a glance.

## Notes

**Audited before publishing.** No sgit credentials, no third-party API keys, no private keys.

**What becomes public with it,** all of it apparently by design, but worth naming: the **unit economics and commercial terms** (measured ≈£0.003 for a 42-second note, under £0.20 for three minutes, a £5 minimum top-up, and a 75/25 split on the key), the author's contact address on the closing slide, and the **three named judges** of the Founder Institute session with their affiliations. Those three appear as names, roles and affiliations only. There are no tactical notes about them anywhere in the vault.

**It is a pitch, so it is arguing a case.** Read the numbers as a founder's stated plan rather than as audited results; the vault's own ground truth for product claims is the live site at [voicedebrief.ai ↗](https://voicedebrief.ai), which it names as canonical over the deck.

[← All published vaults](../index.md)



==============================================================================
# Two games about agent permissions (a published vault)

> Two deterministic games about grants, permissions and mandates) and the first vault published here that phones home. Anonymous usage events go over a write-only append lane to a separate private vault, disclosed on every page with a pause switch. Built by another agent from the build brief on this site.
>
> Page: https://sgit.ai/demos/vaults/agent-permission-games/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Two games about agent permissions

# Two games about what an agent can do, and the first vault here that phones home

Two deterministic games about grants, permissions and mandates, in one vault. What makes it worth a page beyond the games: it is the first vault published here that **sets out to send anything anywhere** (it is not yet succeeding, see the status note below), and it was built by another agent from [the build brief on this site](../../../docs/briefs/vault-telemetry-append-lanes.md), which makes it the first end-to-end test of whether a brief written for an agent actually produces the thing it describes.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_f94c8b1d42352d95703ac3d39032735d9b4e388d16ab5b87c948928d8e111118:4evnlwrj`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_f94c8b1d42352d95703ac3d39032735d9b4e388d16ab5b87c948928d8e111118%3A4evnlwrj) · From the CLI: `sgit clone sgit_public_read_f94c8b1d42352d95703ac3d39032735d9b4e388d16ab5b87c948928d8e111118:4evnlwrj`
Published as a read key, derived from the write credential that was submitted. The vault key is not published and never will be.

**This vault phones home, and you should know that before you open it.** Opening a vault does not normally send anything anywhere. That is the platform default, and every other vault published here honours it. This one sends **anonymous usage events** while you play, which screens you reach, the answers you give, your score. No name, no id, no fingerprint, no URL, no referrer. Every page carries a notice and a **pause sending** switch, and `telemetry.html` inside the vault states exactly what leaves. We publish it *because* it does this, not despite it, but the warning belongs above the fold rather than in a footnote.

**Status, 7 September:** as published, the events are *built and never sent*: the frame's content-security policy blocks the call, for reasons [set out below](#findings). Treat this box as describing what the vault is designed to do and will do once one line of its manifest changes, not what is reaching anyone today.

## See it live, here

[Open the vault in a new tab ↗](https://dev.vault.sgraph.ai/#sgit_public_read_f94c8b1d42352d95703ac3d39032735d9b4e388d16ab5b87c948928d8e111118%3A4evnlwrj)Two games with a full-width board. They have far more room in their own tab than in the frame below.

## The two games

which agent is it?

### A floor plan, and the wings you think it can enter

You think of an agent; cheap questions narrow the field; you chalk which wings of the building it can reach. Then the doors open and the **prediction gap** is shown per capability.

The board is the interesting part. Capabilities are drawn as rooms grouped into wings (filesystem, identity, process, code, network, communication, schedule, money, browser) and the legend distinguishes **chalk** (asserted, you drew it), **pencil hatching** (inferred, the plan says), **dotted** (possible, still consistent) and plain (no visitor above 5% holds a key). A belief column ranks nine public profiles by likelihood as you answer.

It is careful about what a drawing is: *"a room is a rendering choice, not a place, rooms are not ordered, sized or adjacent by anything in the data."*

Mid-game: the plan, the belief column, and a question labelled `IDENTIFIES` that *“identifies and measures nothing”*: it never counts toward the gap.

what can it do?

### Two questions per capability: can it, and do you want it to

Name the agent and where you run it, and the board asks capability by capability *can it?*, with a confidence, and *do you want it to?* The end screen hands you **the mandate you assembled without meaning to**, the delta against the grant, and one thing to change.

The scoring is the argument. A wrong answer costs **−50** against **+30** for a right one and **0** for *don't know*, and the page says why: *"real grants are wider than people expect, so saying yes to everything would otherwise win."* Under the hood a yes is scored as 75% sure and a no as 25%, points are the squared-error rule, and the headline figure is calibration rather than score.

And **two fifths of the questions are above the ceiling**, things no agent anywhere can do, so the game measures over-crediting as well as underestimating. That is the mechanism that stops it being a quiz about vendor features.

The scoring panel, stated before you play, and the telemetry notice line sitting under it with a live `0 sent` counter.

## The disclosure page is the best thing in it

`telemetry.html` is reachable from every page, and it is the model for how this should be done. It opens by naming the default it is breaking, *"Opening a vault does not normally send anything anywhere. This one does"*: then says what is sent, how, and what it proves. The last part is the one most analytics pages never write:

> **What it proves.** Nothing about anyone. Anyone holding this vault's read key holds that token and could forge or flood the lane, so the receiving end treats every event as a claim.

The schema is published in the same place: one batch per flush, at most every 4 seconds and at most 40 times a session, carrying a 16-hex session id *minted in memory when the page opened and gone when the tab closes*. The events are named and tabulated, per game. `ua` carries a coarse form factor, a language and a host, and the schema states what is deliberately absent: no user-agent string, no screen size, no URL, no referrer, no IP.

Reachable from every page in the vault, and it names the platform default it is breaking in its first sentence.

## The credential audit, the whole point of the exercise

A vault that phones home must carry a credential to phone home *with*, and it is published with a read key, so that credential is public. This is exactly the case the [build brief](../../../docs/briefs/vault-telemetry-append-lanes.md) was written for, so the audit was run against the brief's own claims rather than the vault's description of itself.

| Check | Result |
|---|---|
| Private key material anywhere | **none** |
| `enum_key`, `write_key`, `vault_key`, `read_key` fields | **none** |
| Vault-key shapes, `sgit_vk1_` / `sgit_private_vault_` prefixes | **none** |
| Third-party provider keys (OpenAI, Anthropic, GitHub, AWS, Google, Slack, JWT) | **none** |
| Email addresses, personal data | **none** |
| **64-hex strings in the entire vault** | **exactly one**: the append token, in five places |

That last row is the finding. One credential exists in this vault and it is the write-only one, which is the only shape that survives publication behind a read key.

**And the token was tested, not taken on trust**, because an append token and a read key are *both* 64 hex and a mistake between them would be invisible. Cloning the telemetry vault with it produces no `clone_mode.json` and decrypts nothing, and a control run with an all-zeros key behaves identically, which is what makes the test mean anything. It is not a read key for the vault it names.

## It took the fallback path, which is the right one

The brief said to verify whether `sg.append.write` works from a read-only session before building on it, since every player opens the vault with a read key and the authoring guide says read-only sessions fail closed. The implementation does not use the bridge at all:

```
const url = cfg.api.replace(/\/$/, '') + '/api/vault/append/write/' + cfg.telemetry_vault_id;
await fetch(url, { method: 'POST', headers: {…}, body, keepalive: !!final,
                   mode: 'cors', credentials: 'omit' });
```

A direct `fetch` to the account-less write endpoint, with `credentials: 'omit'` so no ambient cookie rides along and `keepalive` on the final flush so the last batch survives the tab closing. The payload is the `sgit pki` v2 envelope, RSA-OAEP-SHA256 wrapping AES-256-GCM, built with Web Crypto in the browser, so the same `sgit pki decrypt` reads it on the other side. If there is no secure context there is no Web Crypto, and the sender disables itself rather than falling back to plaintext.

**Consistent with this:** `app.json` declares no `permissions` key at all. The vault asks the host for nothing, because it does not need the host for this.

## Two findings, published rather than filed

**1. Two of the four pages still tell the player nothing is sent.** `what-can-it-do` gets it right, its footer says *"in this tab, no model, no server, nothing **stored**"*, with the sending notice above it. But the home page still reads *"no model, no server, nothing **sent**, nothing stored"*, and `which-agent-is-it` carries *"No model, no server, nothing sent"* in its footer **on the same screen as** the notice saying events are sent. That game also describes its run tuple as *"shown, never sent"* with *"no send button"*: true of the button, but its `question` and `reveal` events carry substantially the same answers automatically. The pattern says the wording was fixed in one game and missed in the other two. Nothing leaks; the disclosure is simply contradicted by leftover copy, which matters more than usual in a vault whose subject is informed consent.

**2. RESOLVED, 7 September: the telemetry does not currently leave the browser, and the reason is a CSP this vault cannot satisfy.** When this page first went up we could not confirm the write endpoint and recorded it as unresolved. The SG/API team then reviewed the append code against [our brief](../../../docs/briefs/vault-telemetry-append-lanes.md) and supplied the answer.

 A vault app's frame is served with `connect-src blob: data:`. A **direct `fetch`** to the API is therefore blocked before it leaves, unless the app declares `permissions.network: true`, and `app.json` here declares **no permissions at all**. So the sender is well built and cannot fire. That matches what the author reports: no events have arrived.

**The fix is not `network: true`.** That reopens every egress from a frame holding decrypted vault content. The bridge is the right path, and the reason our brief steered away from it was **our error**: we said `sg.append.write` fails closed in a read-only session, and the review found there is no read-only gate on append at all. One grant does it, `{"permissions": {"append": {"write": true}}}`, and `write` is the one verb that takes another vault's id.

Two more things the review settles for anyone reading this as a worked example. A grant that appears to be ignored is usually a **manifest** problem rather than a gate: a release pin makes `app.json` come from a pinned commit rather than HEAD (and forces read-only for everyone, owner included), and a folder-level `app.json` replaces the root one wholesale. And `append.new-messages` would never have fired here whatever was declared, the checker only ever watches the *open* vault's own lane, so it belongs in the telemetry vault's dashboard, not in the games.

## Notes

**68 files, 2.6 MB, version 0.8.1 across 9 releases**, with a version badge on every page and a release history at `version.html`. Both games ship their readable source beside the built page (engine as an ES module, `selftest.json`, the data snapshot, the build script) each with a README carrying a rules table and a *does-not-prove* list.

**The data is vendored, and says so.** Both games run on a copy of the profiles, capability primitives, reach mesh and reductions from [pki.sgit.ai](../../../network/pki.md), taken 2026-09-06 and inlined, with the date shown in the header of every screen.

**Screenshots were captured with the telemetry blocked at the network layer**, so driving the games to photograph them did not put a run into somebody's real lane.

**Nine public profiles, not a directory of anybody's setup.** `profile` in an event is which *public* profile a player picked from a list; the scoring is arithmetic over that public profile. The schema is blunt about the limits: *"Not a count of people (sessions are tabs). Not evidence."*

[← The build brief this was built from](../../../docs/briefs/vault-telemetry-append-lanes.md) · [All published vaults](../index.md)



==============================================================================
# Licence to Operate (an insurance policy for an agent, simulated) a published vault

> One agent, its grant of 12 capabilities, its mandate of 4, and the 8-capability delta no policy covers, with a simulated conversation where every reply carries its cost against a live policy. The vault holds the terms; your browser holds the run.
>
> Page: https://sgit.ai/demos/vaults/licence-to-operate/index.html

[Home](../../../index.md) / [Vaults](../index.md) / Licence to Operate

# Licence to Operate, an insurance policy for an agent, simulated

One agent, its grant, its mandate, and the policy insuring that mandate, with a simulated support conversation where every turn offers three replies: **one inside the band, one that draws on the pool, one outside cover**. It answers *does this agent have the licence to operate* by letting you spend it.

**Open it yourself. The key is the whole credential.**
 Read key: `sgit_public_read_d990a52efb9af32c8463e2962f3ca5ccf92b3b6e8ea788e55009073c29b4da29:posrhzp3`
 In the official UI: [open it read-only in a new tab](https://dev.vault.sgraph.ai/#sgit_public_read_d990a52efb9af32c8463e2962f3ca5ccf92b3b6e8ea788e55009073c29b4da29%3Aposrhzp3) · From the CLI: `sgit clone sgit_public_read_d990a52efb9af32c8463e2962f3ca5ccf92b3b6e8ea788e55009073c29b4da29:posrhzp3`
Derived one-way from a vault key that is not published and never will be. This vault also carries this same read key in its own `try-it/` folder. It is self-describing.

**Seven short videos walk through this vault.** The author recorded a series on it, the mechanism (grant against mandate, what a block looks like, who accepts which risk), how to find and open the vault, and the insurance model behind it. [**Watch the series, in order →**](videos/index.md)

## See it live, here

[Open the vault in a new tab ↗](https://dev.vault.sgraph.ai/#sgit_public_read_d990a52efb9af32c8463e2962f3ca5ccf92b3b6e8ea788e55009073c29b4da29%3Aposrhzp3)An interactive simulation, far better in its own tab than in the frame below.

## The decks, read straight out of the vault

Five decks, in the order the argument is meant to land: the problem, the map, bounding it, who says yes, and the insurance model. They are read out of vault `posrhzp3` live, with the read key printed at the top of this page, and each one can be downloaded as the PDF the author printed from it.

**What came from where.** The slides, the speaker notes, the screenshots and the PDF are vault files, fetched as ciphertext with the published read key and decrypted in your browser. Every control above it (the tabs, the slide list, prev and next, the notes toggle, the PDF button) is this site's, so the vault decides what is *shown* and never what this page *does*. The deck's own code runs in a sandboxed frame with no origin and no network; the slide you are looking at renders in a second one with scripting switched off entirely. [How this works, and why the PDF is a download rather than an embed →](../../../docs/vault/reading-a-vault-file.md)

**Each deck also has a page of its own**: the same slides, plus room for what the slides cannot carry. [All five decks, one page each →](decks/index.md)

## The idea worth stealing: the delta

Three sets, and the gap between two of them is the whole argument:

|  | What it is | In the demo |
|---|---|---|
| **CAN DO**: the grant | Everything the agent is technically able to do | **12 capabilities** |
| **MAY DO**: the mandate | What the user actually expects, and the only thing the policy insures | **4**: `crm:read`, `kb:search`, `llm:generate`, `mail:draft` |
| **THE DELTA** | Inside the agent's reach, outside its authority. **No policy covers these** | **8**: including `crm:write`, `crm:export`, `mail:send`, `shell:exec` |

Written out like that, the risk stops being abstract. The mandate is *"answer a customer's question from their own record and the help centre, and draft, never send, a reply."* The grant includes `mail:send` and `shell:exec`. Nobody asked for those; nothing insures them; and the agent can reach them.

That is [nhi.sgit.ai](../../../network/nhi.md)'s blast-radius argument made countable, and it is the same instinct as the `"permissions": {}` line this site keeps pointing at, except here the cost of the gap is priced.

the simulation

### Three replies, and each one has a price

A customer cannot log in. You are `agent:concierge`, and you pick the reply. Each option carries its cost before you commit: *look up her record* (1,400 tokens, 1 record, in band), *read her record plus two linked accounts and write a long answer* (4,800 tokens, 3 records (**claims**), or *send a password reset right now* (`mail:send`) outside the mandate entirely).

Underneath sits the policy as a rate table: a normal band, an ask-above threshold, a per-action ceiling, a pool with an untouchable reserve, and a premium per interval. Customer records are marked **uninsurable above 20**. Scope is checked before an action; cost sometimes only after.

You can lapse the policy, reinstate it, or trigger a repricing event and watch the board move.

Licence held, mandate in force, policy paid, inside cover, all four asserted at the top, and all four losable.

## Two stores, and the split is the architecture

The vault's files hold the **terms**: the grant, the mandate, the policy, the scenarios, the rate table, the fixtures, the captions, version-controlled, changed only by commit. Your browser holds the **run**: every event, request, decision and premium movement your clicks produce.

And the permission grant proves the claim rather than asserting it:

```
"permissions": { "fs": { "read": true }, "downloads": true }
```

**Read, and no write, at any path.** The app that simulates spending against a policy is structurally incapable of editing the policy it is spending against. Nothing you do in the simulation touches the vault, not because the app is well-behaved, but because it never asked for the grant that would let it.

## Notes

**Audited independently, and the author's own audit checked rather than taken on trust.** The agent that built this vault supplied a written audit of all 16 commits. Its three substantive claims were re-verified here against a fresh read-key clone: no credentials or third-party secrets anywhere (confirmed); the `/home/claude/` build paths baked into the PDF are gone (confirmed, zero occurrences, fixed in v0.3.1); and the only full-length credential in the vault is **this vault's own read key**, which was confirmed by deriving it independently and matching it byte for byte. The Risk Graph Explorer's key appears elided to `sgit_rk1_1c1b95f5…` and is not usable.

One small addition to that audit: the self-referencing read key appears in `tryit.html` as well as the `try-it/` prompt the audit named. Deliberate in both places, and correct, a vault that tells you how to re-open it is doing the right thing.

**Simulated, and it says so on the surface.** The banner in the conversation reads: *"Simulated. The terms are real files in this vault; the replies are scripted; the numbers are made up."* The unit of account is `cr`, and the app states plainly that it is not money.

[← All published vaults](../index.md)



==============================================================================
# Seven shorts on the licence to operate, the author's walkthroughs

> Seven vertical videos walking through the Licence to Operate vault, collected in the order they are meant to be watched: the mechanism (grant against mandate, blocking, who accepts which risk), how to find and open the vault, and the insurance model behind it, each with what it covers and which part of the vault it demonstrates.
>
> Page: https://sgit.ai/demos/vaults/licence-to-operate/videos/index.html

[Home](../../../../index.md) / [Vaults](../../index.md) / [Licence to Operate](../index.md) / The seven shorts

# Seven shorts on the licence to operate

The author recorded seven vertical videos walking through [the Licence to Operate vault](../index.md), the mechanism first, then how to open it yourself, then the model behind it. They are collected here in order, with what each one covers and which part of the vault it is demonstrating, so the series is readable as one argument rather than seven unconnected clips in a feed.

## Four words, and the gap between two of them

If you arrived here from a feed with no context, this is the entire model in four terms. Every one of the seven videos is about one of them, or about what happens when one of them is wrong. The numbers in the last column are the ones in the demo you can open below.

|  | What it means | In the vault |
|---|---|---|
| **Grant** | Everything the agent *can* do, the union of every tool, key and permission it actually holds | **12 capabilities** |
| **Mandate** | What it *may* do: the specific job you asked for, and the only thing the policy insures | **4**: `crm:read`, `kb:search`, `llm:generate`, `mail:draft` |
| **The delta** | The gap between them: inside the agent's reach, outside its authority. **Nothing covers these** | **8**: including `crm:export`, `mail:send`, `shell:exec` |
| **Licence to operate** | A policy over the mandate, with a normal band, an overflow pool and named people accepting each risk in advance. Exceed it and the licence is withdrawn | Priced per turn in a live simulation |

The claim the series makes is that the delta is where agent risk actually lives, not in the model, not in the prompt, but in the distance between the capability you handed over and the job you asked for. Nobody asked for `shell:exec`; nothing insures it; the agent can still reach it. Write the two sets down side by side and the risk stops being a discussion and becomes a number.

**Open the thing the videos are showing.** It runs in a browser, read-only, with no account and nothing to install, the read key below is the whole credential.
 Read key: `d990a52efb9af32c8463e2962f3ca5ccf92b3b6e8ea788e55009073c29b4da29:posrhzp3`
[**The Licence to Operate vault on this site →**](../index.md) · [open it directly in the vault UI ↗](https://dev.vault.sgraph.ai/#d990a52efb9af32c8463e2962f3ca5ccf92b3b6e8ea788e55009073c29b4da29%3Aposrhzp3)

**Where this goes commercially: [RiskMandate.ai ↗](https://riskmandate.ai/)**: the business risk layer for autonomous systems: every autonomous system mapped to its blast radius, given a business owner, and driven to a time-bound decision, **accept, fund, or fix**. What you are about to watch is that model made concrete for a single agent. The vault is the demonstration; RiskMandate is the product it is a demonstration *of*, and [the Risk Graph Explorer](../../risk-graph-explorer/index.md) is the same engine already published as a vault.

## The order they are meant to be watched in

The series has three movements, and they are not in the order a viewer arriving from a feed would guess:

|  | Videos | What they establish |
|---|---|---|
| **The mechanism** | 1 · 2 · 3 | Grant against mandate, what a block looks like when an agent exceeds its mandate, and who in the organisation accepts which risk |
| **The artefact** | 4 | How to find and open the vault on this site, the shortest one, and the one to send someone who wants to poke at it themselves |
| **The model** | 5 · 6 · 7 | Why the grant/mandate gap is where risk lives, the insurance framing that governs it, and the policy, claim and premium mechanics underneath |

Short 1 · the mechanism

### Grants, mandates & token policies in AI agent workflows

A walkthrough of the MVP, demonstrating how agents are governed through a clear separation of what an agent *can* do (the grant) versus what it *should* do (the mandate).

- **Grant against mandate**: permitted actions versus expected behaviour
- **Token-based policy enforcement**, with normal-use thresholds and overflow pools
- A live demo of normal insurance and CRM flows **staying within policy**
- What happens when token budgets are exhausted, **automatic escalation**
- Blocking behaviour when an agent attempts an action **outside its allowed scope**

**In the vault:** the grant of 12 capabilities and the mandate of 4, and the simulated conversation where every reply carries its cost against a live policy.

Short 2 · the mechanism

### Blocking AI agents that exceed their mandate

What happens when an agent attempts an action that is **technically within its system privileges but outside its defined mandate**.

- An agent blocked when it tries to send a password reset email **without being mandated to**
- The difference between what an agent *can* do (grant, privileges) and what it *should* do (mandate)
- How an agent **loses its licence to operate** when it steps outside its approved scope
- A second example: a CRM data export it has access to but is not authorised to perform
- **Pre-action checks (ideal) versus post-action detection (problematic)**

**The distinction that carries the series:** a privilege the agent holds is not a permission to use it. That last bullet, catching it before rather than after, returns in short 6 as the sharpest version of the argument.

Short 3 · the mechanism

### Risk acceptance flow, who accepts what, and why

The risk-acceptance side of the framework: how risks cascade upward through an organisation, from the support team to the C-suite.

- Risks linked upward through the layers, **support team → SRE → platform owner → CTO → CPO → CFO**
- What each stakeholder actually accepts: token and rate limits, mandate overruns, database change risk, cost and premium exposure
- Why the **platform owner** must accept that an agent can act outside its mandate, because of capabilities like a mail client, a shell and export tools
- A **withdrawn licence**, simulated out of band, automatically enforcing policy and restricting the agent
- Pre-defining the rules of the game, so agents operate **only when a valid policy exists**

**In the estate:** this is [risks.sgit.ai](../../../../network/index.md#risk-governance)'s acceptance model applied to an agent, a risk cannot be denied, only accepted by a named person for a stated interval. The same model the [Risk Graph Explorer](../../risk-graph-explorer/index.md) vault publishes.

Short 4 · the artefact, start here if you want to poke at it

### How to find and open the vault on sgit.ai

Exactly where the vault is on this site, and how to open it in your browser. No account, nothing to install.

- Navigating to [Published Vaults](../../index.md) on sgit.ai
- Locating **vault #23**: the Licence to Operate vault
- Exploring the contents: decks, docs, grants, mandates, policies, risks and more
- Opening the vault in a new window to interact with it
- The vault structure, `app.json` as the entry point, and `index.html`

**The shortest route:** the vault's read key is on [its page](../index.md), and it is the whole credential, the same string the video walks you to.

Short 5 · the model

### The grant against mandate gap, where risk lives

When you deploy an agent you typically give it far more capability than it needs. **The gap between the two is where risk lives.** An agent might have full access to your email account while your mandate only requires it to write drafts, never to send. Making that gap explicit is the first step to controlling it.

- The **grant**: the union of all actions an agent is authorised to perform
- The **mandate**: the specific tasks you actually expect it to do
- Why the gap is a security and governance concern rather than an accounting detail
- How capabilities **expand over time**: new tools, environment changes, prompt updates
- How visualising the gap helps you monitor, contain and manage agents

**In the vault:** the **delta**: the 8 capabilities in the grant that no policy covers. The vault page calls this the idea worth stealing, and this is the video that explains why.

Short 6 · the model

### An insurance model for governing AI agents

What if every agent had to **prove it has a licence to operate**: as licensed professionals do in regulated industries? An insurance-based operating model that governs agents through defined mandates, scoped policies and risk underwriting.

- **Licence to operate**: why every agent needs a mandate, not just a badge
- **Grant, mandate, delta**: mapping what an agent can do against what it should
- **The normal band of operation**: token and record thresholds that limit exposure at scale
- **Claims, must-ask and refused tiers**: controlling thousands of agents with a tiered policy
- **Three ways to lose your licence**: overuse, out-of-scope action, or pool lapse
- **Pre-check versus post-check**, and why post-check is far riskier

**Why this is the one to watch if you watch one:** it is the whole framework in a single pass, and it is the video that connects the vault to [the AIUC-1 conformance layer](../../aiuc-1-conformance/index.md), which computes insurability as a query into a `policy/v1` object.

Short 7 · the model

### Policies, claims and risk acceptance

A deep dive into the insurance model powering the MVP: how policies (licences) are sold to agent owners, how claims are triggered when token thresholds are exceeded, and how a credit balance tracks the flow between premiums and claims.

- Selling policies to business owners as **a cost model for running agents**
- Token-based claim triggers, and the **balance and credit pool** mechanism
- Mapping **facts → risks → roles → the corporate risk register**
- Why risks **cannot be denied**: only accepted in advance
- How pre-accepted risks streamline the human in the loop, and enable scale

**The line that ties the series to the rest of the estate:** *risks cannot be denied, only accepted in advance.* That is the position [risks.sgit.ai](../../../../network/index.md#risk-governance) argues from first principles, and the reason there is no deny button anywhere in this model.

## Where to go next

- **Open the thing itself.** [The Licence to Operate vault](../index.md), the read key is on the page, and the vault runs live inside it.
- **The insurance model, computed.** [The AIUC-1 conformance layer](../../aiuc-1-conformance/index.md) turns this framing into a query: conformance states become conditions and exclusions on a policy, and moving the date forward turns conditions into exclusions with nobody editing anything.
- **The acceptance model it inherits.** [The Risk Graph Explorer](../../risk-graph-explorer/index.md), and [its three walkthroughs](../../risk-graph-explorer/videos/index.md), which are transcribed, and are the standard this page is not yet meeting.

All seven videos are on [the author's channel ↗](https://www.youtube.com/@diniscruz-ai). Embedded through `youtube-nocookie.com`, and lazily, opening this page sets no YouTube cookie until you press play on one. The text under each video is the author's own description, not a transcript: these seven carry no caption track, so the spoken words are not on this site yet and [transcribing them is on the board](../../../../team/board.md). [← The vault](../index.md) · [All published vaults](../../index.md)



==============================================================================
# The AIUC-1 conformance layer decks, sgit.ai

> 4 decks published inside vault 2wzct4k7, each on its own page, with the slides read live out of the vault using its published read key.
>
> Page: https://sgit.ai/demos/vaults/aiuc-1-conformance/decks/index.html

[Home](../../../../index.md) / [Vaults](../../index.md) / [AIUC-1 conformance layer](../index.md) / Decks

# The AIUC-1 conformance layer decks

4 presentations published inside vault `2wzct4k7`, each with a page of its own. The slides are read live out of the vault with its published read key. The viewer is this site's, the content is the vault's. They climb in order: a deck finds its level, answers that level's question, and ends on the question that opens the next one.

| Deck | Level | What it answers |
|---|---|---|
| **[What AIUC-1 is](aiuc1.md)** | L1 | The agent standard, read from its own pages: six domains, 53 controls, 144 requirements, 1,126 crosswalks, and what it does not say |
| **[The vault: files, graphs, and the query](vault.md)** | L2 | A walkthrough of what is here, the JSON the standard became, the graph you can walk, the conformance layer above it, and the chat that reads all of it |
| **[How RiskMandate.ai's insurance model works with AIUC-1](insurance.md)** | L3 | Grant, mandate, delta; the policy in metered units; the licence as a derived fact, and the standard as the vocabulary of what the policy covers and excludes |
| **[Zoom in: D003, one control, to the byte, measured, and run](d003.md)** | L4 | One control followed from the bytes of the standard to a session measured against it, to the words the layer needed (granularity, vacuous, outside-only), to the grant per tool, to the policy it becomes, to a simulation that runs |

[← The AIUC-1 conformance layer vault](../index.md) · [All published vaults](../../index.md) · [How the slides are read out of the vault](../../../../docs/vault/reading-a-vault-file.md)



==============================================================================
# What AIUC-1 is, AIUC-1 conformance layer decks

> The agent standard, read from its own pages: six domains, 53 controls, 144 requirements, 1,126 crosswalks, and what it does not say
>
> Page: https://sgit.ai/demos/vaults/aiuc-1-conformance/decks/aiuc1.html

[Home](../../../../index.md) / [Vaults](../../index.md) / [AIUC-1 conformance layer](../index.md) / [Decks](index.md) / What AIUC-1 is

# What AIUC-1 is

The agent standard, read from its own pages: six domains, 53 controls, 144 requirements, 1,126 crosswalks, and what it does not say

Read live out of vault `2wzct4k7` with its published read key. Use **focus** to drop the slide list when presenting, and **PDF** to download `AIUC-1__What-It-Is.pdf`, decrypted in your browser, not fetched from a file server. [How this works →](../../../../docs/vault/reading-a-vault-file.md)

## What this deck is doing

| **The problem it starts from** | I am told to be AIUC-1 compliant and I do not know what that means |
|---|---|
| **What it answers** | The standard, read from its own pages: what it contains and what it does not |
| **Vocabulary it introduces** | the control, the requirement, the crosswalk |

It ends on the question it does not answer (**“How would anyone know whether we do these things?”**) which is where [The vault: files, graphs, and the query](vault.md) picks up.

## Notes on this deck

Nothing has been written here yet. This section is the reason each deck has a page of its own: room for what the slides cannot carry, where the argument came from, what changed since, what an audience pushed back on, and any recording that narrates it.

[All AIUC-1 conformance layer decks](index.md) · [The vault: files, graphs, and the query →](vault.md)



==============================================================================
# The vault: files, graphs, and the query (AIUC-1 conformance layer decks)

> A walkthrough of what is here) the JSON the standard became, the graph you can walk, the conformance layer above it, and the chat that reads all of it
>
> Page: https://sgit.ai/demos/vaults/aiuc-1-conformance/decks/vault.html

[Home](../../../../index.md) / [Vaults](../../index.md) / [AIUC-1 conformance layer](../index.md) / [Decks](index.md) / The vault

# The vault: files, graphs, and the query

A walkthrough of what is here, the JSON the standard became, the graph you can walk, the conformance layer above it, and the chat that reads all of it

Read live out of vault `2wzct4k7` with its published read key. Use **focus** to drop the slide list when presenting, and **PDF** to download `AIUC-1__The-Vault.pdf`, decrypted in your browser, not fetched from a file server. [How this works →](../../../../docs/vault/reading-a-vault-file.md)

## What this deck is doing

| **The problem it starts from** | I have the list and no way to see whether we do any of it |
|---|---|
| **What it answers** | The vault: the catalogue as data, the graph, the conformance layer, the query |
| **Vocabulary it introduces** | the attestation, the two edges, the trail |

It ends on the question it does not answer (**“Who carries the risk of the ones we do not do, and for how long?”**) which is where [How RiskMandate.ai's insurance model works with AIUC-1](insurance.md) picks up.

## Notes on this deck

Nothing has been written here yet. This section is the reason each deck has a page of its own: room for what the slides cannot carry, where the argument came from, what changed since, what an audience pushed back on, and any recording that narrates it.

[← What AIUC-1 is](aiuc1.md) · [All AIUC-1 conformance layer decks](index.md) · [How RiskMandate.ai's insurance model works with AIUC-1 →](insurance.md)



==============================================================================
# How RiskMandate.ai's insurance model works with AIUC-1, AIUC-1 conformance layer decks

> Grant, mandate, delta; the policy in metered units; the licence as a derived fact, and the standard as the vocabulary of what the policy covers and excludes
>
> Page: https://sgit.ai/demos/vaults/aiuc-1-conformance/decks/insurance.html

[Home](../../../../index.md) / [Vaults](../../index.md) / [AIUC-1 conformance layer](../index.md) / [Decks](index.md) / The insurance model

# How RiskMandate.ai's insurance model works with AIUC-1

Grant, mandate, delta; the policy in metered units; the licence as a derived fact, and the standard as the vocabulary of what the policy covers and excludes

Read live out of vault `2wzct4k7` with its published read key. Use **focus** to drop the slide list when presenting, and **PDF** to download `AIUC-1__The-Insurance-Model.pdf`, decrypted in your browser, not fetched from a file server. [How this works →](../../../../docs/vault/reading-a-vault-file.md)

## What this deck is doing

| **The problem it starts from** | I can see the gaps and nobody owns them |
|---|---|
| **What it answers** | The insurance model: grant, mandate, delta, the policy, the licence, with the standard as its vocabulary |
| **Vocabulary it introduces** | the barrier, the condition, the exclusion |

It ends on the question it does not answer (**“What would have to be true to write one policy, for one agent, for one month?”**) which is where [Zoom in: D003, one control, to the byte, measured, and run](d003.md) picks up.

## Notes on this deck

Nothing has been written here yet. This section is the reason each deck has a page of its own: room for what the slides cannot carry, where the argument came from, what changed since, what an audience pushed back on, and any recording that narrates it.

[← The vault: files, graphs, and the query](vault.md) · [All AIUC-1 conformance layer decks](index.md) · [Zoom in: D003, one control, to the byte, measured, and run →](d003.md)



==============================================================================
# Zoom in: D003 (one control, to the byte, measured, and run) AIUC-1 conformance layer decks

> One control followed from the bytes of the standard to a session measured against it, to the words the layer needed (granularity, vacuous, outside-only), to the grant per tool, to the policy it becomes, to a simulation that runs
>
> Page: https://sgit.ai/demos/vaults/aiuc-1-conformance/decks/d003.html

[Home](../../../../index.md) / [Vaults](../../index.md) / [AIUC-1 conformance layer](../index.md) / [Decks](index.md) / Zoom in: D003

# Zoom in: D003, one control, to the byte, measured, and run

One control followed from the bytes of the standard to a session measured against it, to the words the layer needed (granularity, vacuous, outside-only), to the grant per tool, to the policy it becomes, to a simulation that runs

Read live out of vault `2wzct4k7` with its published read key. Use **focus** to drop the slide list when presenting, and **PDF** to download `AIUC-1__Zoom-In-D003.pdf`, decrypted in your browser, not fetched from a file server. [How this works →](../../../../docs/vault/reading-a-vault-file.md)

## What this deck is doing

| **The problem it starts from** | A control passes and I cannot tell whether the pass means anything |
|---|---|
| **What it answers** | One control zoomed in: the bytes, the states with their granularity, the grant per tool, the policy it becomes, a simulation that runs |
| **Vocabulary it introduces** | granularity, the vacuous pass, outside-only, the grant per tool |

It ends on the question it does not answer, **“Does the correspondence hold for B006 and D004, and who measures from outside?”**.

## Notes on this deck

Nothing has been written here yet. This section is the reason each deck has a page of its own: room for what the slides cannot carry, where the argument came from, what changed since, what an audience pushed back on, and any recording that narrates it.

[← How RiskMandate.ai's insurance model works with AIUC-1](insurance.md) · [All AIUC-1 conformance layer decks](index.md)



==============================================================================
# The Licence to Operate decks, sgit.ai

> 5 decks published inside vault posrhzp3, each on its own page, with the slides read live out of the vault using its published read key.
>
> Page: https://sgit.ai/demos/vaults/licence-to-operate/decks/index.html

[Home](../../../../index.md) / [Vaults](../../index.md) / [Licence to Operate](../index.md) / Decks

# The Licence to Operate decks

5 presentations published inside vault `posrhzp3`, each with a page of its own. The slides are read live out of the vault with its published read key. The viewer is this site's, the content is the vault's. They climb in order: a deck finds its level, answers that level's question, and ends on the question that opens the next one.

| Deck | Level | What it answers |
|---|---|---|
| **[The problem](problem.md)** | L1 | Opens where almost everybody is standing (agents already running, and no way to say what wrong means) and lands on the delta. Stops there. |
| **[The map](map.md)** | L2 | A companion rather than a step: the same ladder seen from our side, the dependency map whose every absence is a risk entry rather than a blocker, the four layers and their seams, and the rungs, with the one where insurance starts named honestly. |
| **[Bounding it](bounding.md)** | L3 | Stop asking whether the agent may do a thing and start asking how much. The band, the limit, the refusal, and where the check sits, which decides what you are actually buying. |
| **[Who says yes](acceptor.md)** | L4 | The hardest one. A refusal is a question addressed to somebody: the draw, the acceptor, no deny button, whose name goes on it, and what is signed in advance so the ordinary day never stops. |
| **[The insurance model](insurance.md)** | L5 | The endgame, whole: grant, mandate, policy, the check, the two modes, the money, risks and acceptance, with real screenshots of the running simulation. |

**There are videos on this vault too.** The author recorded a series walking through it, some of them narrate this material directly. [**The seven shorts →**](../videos/index.md)

[← The Licence to Operate vault](../index.md) · [All published vaults](../../index.md) · [How the slides are read out of the vault](../../../../docs/vault/reading-a-vault-file.md)



==============================================================================
# The problem (Licence to Operate decks)

> Opens where almost everybody is standing) agents already running, and no way to say what wrong means, and lands on the delta. Stops there.
>
> Page: https://sgit.ai/demos/vaults/licence-to-operate/decks/problem.html

[Home](../../../../index.md) / [Vaults](../../index.md) / [Licence to Operate](../index.md) / [Decks](index.md) / The problem

# The problem

Opens where almost everybody is standing (agents already running, and no way to say what wrong means) and lands on the delta. Stops there.

Read live out of vault `posrhzp3` with its published read key. Use **focus** to drop the slide list when presenting, and **PDF** to download `Licence-to-Operate__The-Problem.pdf`, decrypted in your browser, not fetched from a file server. [How this works →](../../../../docs/vault/reading-a-vault-file.md)

## What this deck is doing

| **The problem it starts from** | I do not know what my agents are doing |
|---|---|
| **What it answers** | Observation: records of what they did, passive mode, a status block |
| **Vocabulary it introduces** | the record · grant · mandate · delta |
| **Who it is for** | a first conversation: the person who owns the risk, or the person who owns the agents |
| **Roughly** | 12 minutes |
| **Where it deliberately stops** | bands, limits, refusals, pools, premiums, price, none of it appears |

It ends on the question it does not answer, **“The delta is enormous. What do I do about it?”**, which is where [The map](map.md) picks up.

## Notes on this deck

Nothing has been written here yet. This section is the reason each deck has a page of its own: room for what the slides cannot carry, where the argument came from, what changed since, what an audience pushed back on, and any recording that narrates it.

## On video

The author recorded a series on this vault. No short has been mapped to this deck yet; until one is, [the seven shorts](../videos/index.md) are the narrated material.

[All Licence to Operate decks](index.md) · [The map →](map.md)



==============================================================================
# The map (Licence to Operate decks)

> A companion rather than a step: the same ladder seen from our side) the dependency map whose every absence is a risk entry rather than a blocker, the four layers and their seams, and the rungs, with the one where insurance starts named honestly.
>
> Page: https://sgit.ai/demos/vaults/licence-to-operate/decks/map.html

[Home](../../../../index.md) / [Vaults](../../index.md) / [Licence to Operate](../index.md) / [Decks](index.md) / The map

# The map

A companion rather than a step: the same ladder seen from our side, the dependency map whose every absence is a risk entry rather than a blocker, the four layers and their seams, and the rungs, with the one where insurance starts named honestly.

Read live out of vault `posrhzp3` with its published read key. Use **focus** to drop the slide list when presenting, and **PDF** to download `Licence-to-Operate__The-Map.pdf`, decrypted in your browser, not fetched from a file server. [How this works →](../../../../docs/vault/reading-a-vault-file.md)

## What this deck is doing

| **The problem it starts from** | I can see it and I cannot say what wrong means |
|---|---|
| **What it answers** | The grant measured, the mandate written, the delta rendered |
| **Vocabulary it introduces** | the band · the limit · the refusal |
| **Who it is for** | somebody who has accepted the problem and wants to know what it would take in the estate they actually have |
| **Roughly** | 15 minutes |
| **Where it deliberately stops** | our roadmap; the last slide is their table, filled in |

It ends on the question it does not answer (**“Which rung are you pointing at, and what would it take to stand on it?”**) which is where [Bounding it](bounding.md) picks up.

## Notes on this deck

Nothing has been written here yet. This section is the reason each deck has a page of its own: room for what the slides cannot carry, where the argument came from, what changed since, what an audience pushed back on, and any recording that narrates it.

## On video

The author recorded a series on this vault. No short has been mapped to this deck yet; until one is, [the seven shorts](../videos/index.md) are the narrated material.

[← The problem](problem.md) · [All Licence to Operate decks](index.md) · [Bounding it →](bounding.md)



==============================================================================
# Bounding it, Licence to Operate decks

> Stop asking whether the agent may do a thing and start asking how much. The band, the limit, the refusal, and where the check sits, which decides what you are actually buying.
>
> Page: https://sgit.ai/demos/vaults/licence-to-operate/decks/bounding.html

[Home](../../../../index.md) / [Vaults](../../index.md) / [Licence to Operate](../index.md) / [Decks](index.md) / Bounding it

# Bounding it

Stop asking whether the agent may do a thing and start asking how much. The band, the limit, the refusal, and where the check sits, which decides what you are actually buying.

Read live out of vault `posrhzp3` with its published read key. Use **focus** to drop the slide list when presenting, and **PDF** to download `Licence-to-Operate__Bounding-It.pdf`, decrypted in your browser, not fetched from a file server. [How this works →](../../../../docs/vault/reading-a-vault-file.md)

## What this deck is doing

| **The problem it starts from** | The delta is enormous and I cannot close all of it |
|---|---|
| **What it answers** | Bound the parts that matter: bands, limits, refusals |
| **Vocabulary it introduces** | the band · the limit · the refusal |
| **Who it is for** | somebody who has seen the delta, tried to close it, and found that some of it is load-bearing |
| **Roughly** | 15 minutes |
| **Where it deliberately stops** | pools, draws, acceptors, budgets, price, a bound needs none of them |

It ends on the question it does not answer, **“Refusing stops work. Who says yes when somebody needs more?”**, which is where [Who says yes](acceptor.md) picks up.

## Notes on this deck

Nothing has been written here yet. This section is the reason each deck has a page of its own: room for what the slides cannot carry, where the argument came from, what changed since, what an audience pushed back on, and any recording that narrates it.

## On video

The author recorded a series on this vault. No short has been mapped to this deck yet; until one is, [the seven shorts](../videos/index.md) are the narrated material.

[← The map](map.md) · [All Licence to Operate decks](index.md) · [Who says yes →](acceptor.md)



==============================================================================
# Who says yes, Licence to Operate decks

> The hardest one. A refusal is a question addressed to somebody: the draw, the acceptor, no deny button, whose name goes on it, and what is signed in advance so the ordinary day never stops.
>
> Page: https://sgit.ai/demos/vaults/licence-to-operate/decks/acceptor.html

[Home](../../../../index.md) / [Vaults](../../index.md) / [Licence to Operate](../index.md) / [Decks](index.md) / Who says yes

# Who says yes

The hardest one. A refusal is a question addressed to somebody: the draw, the acceptor, no deny button, whose name goes on it, and what is signed in advance so the ordinary day never stops.

Read live out of vault `posrhzp3` with its published read key. Use **focus** to drop the slide list when presenting, and **PDF** to download `Licence-to-Operate__Who-Says-Yes.pdf`, decrypted in your browser, not fetched from a file server. [How this works →](../../../../docs/vault/reading-a-vault-file.md)

## What this deck is doing

| **The problem it starts from** | A refusal needs a decision and a budget behind it |
|---|---|
| **What it answers** | Draws, a named acceptor, a shared pool |
| **Vocabulary it introduces** | the draw · the acceptor |
| **Who it is for** | somebody whose bounds work and who now has a queue, and the roles whose names would go on the answers |
| **Roughly** | 20 minutes |
| **Where it deliberately stops** | the premium, experience rating and repricing, pricing is level 5 |

It ends on the question it does not answer, **“Whose budget is this, and is the price right?”**, which is where [The insurance model](insurance.md) picks up.

## Notes on this deck

Nothing has been written here yet. This section is the reason each deck has a page of its own: room for what the slides cannot carry, where the argument came from, what changed since, what an audience pushed back on, and any recording that narrates it.

## On video

The author recorded a series on this vault. No short has been mapped to this deck yet; until one is, [the seven shorts](../videos/index.md) are the narrated material.

[← Bounding it](bounding.md) · [All Licence to Operate decks](index.md) · [The insurance model →](insurance.md)



==============================================================================
# The insurance model, Licence to Operate decks

> The endgame, whole: grant, mandate, policy, the check, the two modes, the money, risks and acceptance, with real screenshots of the running simulation.
>
> Page: https://sgit.ai/demos/vaults/licence-to-operate/decks/insurance.html

[Home](../../../../index.md) / [Vaults](../../index.md) / [Licence to Operate](../index.md) / [Decks](index.md) / Insurance model

# The insurance model

The endgame, whole: grant, mandate, policy, the check, the two modes, the money, risks and acceptance, with real screenshots of the running simulation.

Read live out of vault `posrhzp3` with its published read key. Use **focus** to drop the slide list when presenting, and **PDF** to download `Licence-to-Operate__RiskMandate-MVP.pdf`, decrypted in your browser, not fetched from a file server. [How this works →](../../../../docs/vault/reading-a-vault-file.md)

## What this deck is doing

| **The problem it starts from** | The pool is shared and mispriced |
|---|---|
| **What it answers** | Premium, experience rating, repricing, the captive |
| **Vocabulary it introduces** | the draw · the acceptor · the premium |
| **Who it is for** | design partners and builders, and anybody who has reached the pool and the price on their own |
| **Roughly** | 25 minutes |
| **Where it deliberately stops** | nothing. This is the deep one and it should stay as deep as it is: it should be reached, not simplified |

It ends on the question it does not answer: **“What would have to be true to run one policy, on one agent, for one week?”**.

## Notes on this deck

Nothing has been written here yet. This section is the reason each deck has a page of its own: room for what the slides cannot carry, where the argument came from, what changed since, what an audience pushed back on, and any recording that narrates it.

## On video

The author recorded a series on this vault. No short has been mapped to this deck yet; until one is, [the seven shorts](../videos/index.md) are the narrated material.

[← Who says yes](acceptor.md) · [All Licence to Operate decks](index.md)



==============================================================================
# Before you give an agent a connector, give the connector a twin, sgit.ai

> When an AI agent is given a Gmail or Google Calendar connector, it can read, send, move, decline and permanently delete on somebody's behalf, and for several of those actions the platform itself documents that there is no way back. This article argues that a twin of the connector is the minimum requirement for deploying an agent with confidence. The twin is a journal of every request and response the agent makes, appended as it happens to a write-only lane, processed later, and replayed into the inbox and calendar as the agent saw them, with a before and after for every change and a revert plan for each one. It gives provenance, explanation and a named list of what can and cannot be undone, and it changes the agent's behaviour policy from a hope into a list. Every claim about Gmail and Calendar is taken from Google's own documentation and linked. A working replay of an invented session, and a business plan for the service, are published alongside it as a vault.
>
> Page: https://sgit.ai/articles/connector-twin-before-you-deploy-an-agent.html

[Home](../index.md) / [Articles](index.md) / Before you give an agent a connector, give the connector a twin

# Before you give an agent a connector, give the connector a twin

By [Dinis Cruz](../about/index.md) · 2026-09-24 · [v0.6.3](../admin/versions.md) · agentsconnectorsdigital-twinsprovenanceriskriskmandatearticle

***Abstract:** When an AI agent is given a Gmail or Google Calendar connector, it can read, send, move, decline and permanently delete on somebody's behalf, and for several of those actions the platform itself documents that there is no way back. This article argues that a twin of the connector is the minimum requirement for deploying an agent with confidence. The twin is a journal of every request and response the agent makes, appended as it happens to a write-only lane, processed later, and replayed into the inbox and calendar as the agent saw them, with a before and after for every change and a revert plan for each one. It gives provenance, explanation and a named list of what can and cannot be undone, and it changes the agent's behaviour policy from a hope into a list. Every claim about Gmail and Calendar is taken from Google's own documentation and linked. A working replay of an invented session, and a business plan for the service, are published alongside it as a vault.*

A twin of the connector. Every call the agent makes is copied, request and response, into an append-only journal in a vault. The journal is processed later and replayed into the inbox and calendar as the agent saw them, with a before and after for every change, and a revert plan that a person approves.

Here is the claim, stated so it can be wrong. **If you cannot say what your agent did, what it saw when it did it, and which of its actions you can undo, you are not ready to give it a connector.** Answering those three questions takes a twin of the connector: a journal of every request and response, and a replay of that journal into the views the agent saw. It is not exotic. Everything it needs exists today.

## In short

- **A connector is a grant of action, not just of access.** An agent with Gmail and Calendar connectors can send, archive, trash, permanently delete, move events, decline invitations and cancel meetings, on somebody's behalf, at machine speed.
- **For several of those actions the platform keeps no way back, and says so.** The Gmail API documents its delete as permanent: "This operation cannot be undone." Undo Send is a feature of the Gmail interface, not of the API. A moved calendar event has no version history a user can open. These are Google's own statements, linked below.
- **What the platform does keep is not what you need.** Trash windows, an administrator's bulk restore and audit logs record that things happened. None of them records what the agent saw when it decided to act, or why.
- **The twin is a journal plus a replay.** Capture the request and the response of every connector call, and the instruction behind it when you can. Append each entry to a write-only lane. Process the lane later. Rebuild the inbox and the calendar as the agent saw them at each step.
- **It scales because it is not a copy of the mailbox.** It holds only what passed through the connector, which is exactly what matters for accountability and investigation.
- **Undo becomes a list, not a promise.** For every change the twin holds the before and the after, so it can write the inverse call, and name plainly the things nobody can undo, such as an email that has been delivered.
- **It changes the agent's behaviour policy.** "We cannot undo it" stops being an unknown and becomes a named list, and the mandate can be written against that list.
- **Nothing here needs new technology.** Vault append lanes, client-side encryption and vault apps that rebuild views all exist. The one thing that needs more thought is when the journal gets processed, and that needs real users more than it needs design.
- **It is published twice.** This article makes the case. [Connector Twin](../demos/vaults/connector-twin/index.md) is a vault with a working replay of an invented session and a business plan for somebody to build the service.

## The question nobody can answer yet

Ask anyone who has switched on an assistant's Gmail or Calendar connector a simple question: do you know what it did last Tuesday?

The honest answer is usually the agent's own summary. It said it tidied the inbox and sorted out next week. Perhaps the chat was kept. Perhaps not. The inbox has moved on since, and the calendar shows the result of the changes, not the changes. If something went wrong, the first person to notice is often the one on the other end: the supplier who received a cancellation, the client whose reply never came.

That is not a criticism of agents. It is what happens when a system that can act is deployed without a record of its actions. We would not accept it for a person with delegated access to a finance system, and we would not accept it for a script with production credentials. We are accepting it for agents because the connector made the grant feel like a feature.

## What the platform keeps, stated precisely

It matters to be exact here, because the case is made by facts, not by fear. This is what Google documents for Gmail and Calendar, checked on 24 September 2026.

| Action | What Google documents | Source |
|---|---|---|
| Move a message to trash | Kept for 30 days: "After 30 days: The message is permanently deleted. You can't recover the message." | [Gmail Help](https://support.google.com/mail/answer/7401) |
| Delete a message through the API | "Immediately and permanently deletes the specified message. This operation cannot be undone. Prefer messages.trash instead." | [Gmail API](https://developers.google.com/workspace/gmail/api/reference/rest/v1/users.messages/delete) |
| Recover permanently deleted email | An administrator can restore a date range within 25 days, in bulk. | [Workspace Admin Help](https://knowledge.workspace.google.com/admin/support/troubleshooting/restore-a-users-permanently-deleted-email) |
| Unsend an email | A cancellation period of 5 to 30 seconds, set in Gmail's settings. An API send has no such window. | [Gmail Help](https://support.google.com/mail/answer/2819488) |
| Delete a calendar event | Deleted events stay in the calendar's trash for 30 days. | [Calendar Help](https://support.google.com/calendar/answer/37113) |
| Edit a calendar event | No version history a user can open. Administrators have an audit log recording changes, including some earlier values such as the old title and times. | [Workspace Admin Help](https://knowledge.workspace.google.com/admin/reports/calendar-log-events) |
| Google Vault | Searches Calendar since November 2023, keeping the last revision of each day. "Vault isn't designed to be a backup or archive tool", and "doesn't have any automated recovery tools." | [Vault Help](https://knowledge.workspace.google.com/vault/search/use-vault-to-search-google-calendar), [Vault FAQ](https://knowledge.workspace.google.com/vault/getting-started/google-vault-faq) |

Read the table the other way round and it says this. There is a real undo for some actions, with a deadline. There is a slow, organisation-wide recovery for one, with a shorter deadline. There is a record without a restore for others, available to administrators on some editions. And there is nothing at all for a delivered email, a notification sent to attendees, or a permanent delete once the administrator's window has passed. None of these records holds what the agent was looking at when it acted, or the instruction it was following.

This is not a failing of Google. These are sensible products designed for people clicking buttons, with an undo toast for the mistake you notice immediately. An agent does not notice. It makes forty calls in two minutes and writes a tidy summary.

## Twin, not backup, log or replay

I went back and forth on the word for this, and the choice is worth explaining.

**Backup** is the wrong word, because a backup copies the mailbox. That is a different product, and customers who need it should buy it. **Log** is too small, because a log records that something happened, and what we need is the content of the exchange. **Replay** is the right verb for what you do with it, but not a name for the thing.

**Twin** is right, in the sense we use it on [twins.sgit.ai](https://twins.sgit.ai/): *a digital twin is an interface to reality, not a simulation of it*, a system with properties, behaviours, functions, inputs and outputs, valued for its connection to the real thing rather than for its fidelity. A connector twin narrows that to one place, the boundary between an agent and the system it is allowed to act on. It holds what the agent could do, what it did, and, rebuilt from those, what it saw.

## How it works

Five steps, and each one is something we already run somewhere.

**Capture.** For every connector call, copy the tool call the agent made, the request the connector sent to the platform, and the response it received. Connectors built on the Model Context Protocol exchange JSON-RPC messages, so every call and every result is already a JSON document that can be copied as it passes. When you can, capture the instruction behind the call as well: the user's request, and the agent's own statement of what it did. Never capture the Authorization header or any token. Capture is of content, never of credentials.

**Append.** Write each entry to a vault [append lane](../api/append-lanes.md). An append lane is a write-only channel gated by a token the writer holds and nothing else, and its write response is exactly `{"ok": true}`, so the capture point learns nothing about what else is in the lane. The entry is not decrypted, indexed or processed when it arrives. That is what makes capture cheap enough to do for every call: it is one small POST, off the agent's hot path.

**Chain.** Each entry carries the hash of the one before it, so a missing, edited or reordered entry shows to anyone holding the read key.

**Process.** Later, on a schedule, a reader moves entries from pending to processed and folds them into views. This is the one step I think needs more thought. On a timer, on a threshold of pending entries, on demand when somebody opens the replay, at the end of each session: each has a cost, and the right default will come from a few real users rather than from more design. The lane's limits, five megabytes per write and a thousand pending entries per token, are the constraints to design around.

**Replay and revert.** A vault app rebuilds, from the journal alone, the inbox as the agent saw it and the calendar as the agent saw it, at any step. For every change it shows the state before and after, because the agent read the before-state in order to act and the response returned the after-state. From that it writes a revert plan. Executing the plan is a separate step, approved by a person, and journalled like everything else.

Here is the property I like most. **The twin is not a copy of the mailbox.** It holds only what passed through the connector. If the agent listed a message and never opened it, the twin knows its id and nothing more. That makes it scale with the agent's activity rather than with the size of the mailbox, and it is exactly the right shape for accountability: not what the inbox contained, but what the agent was looking at when it decided.

## One session, replayed

To make this concrete we built the replay and published it as a vault. The session is invented, with invented people at invented `.example` addresses, but every call follows the real Gmail and Calendar APIs. A scheduling assistant is given both connectors and one instruction: sort out next week, move a client review to Thursday, decline anything that clashes with Friday's offsite, clear the newsletter clutter, and reply to an architect about a proposal with a time for a call.

It makes seventeen calls in under three minutes, and writes this summary:

Done. Northwind review moved to Thursday 1 October at 10:00. Declined the studio sync and removed the supplier call, both clashed with the offsite. Archived three newsletters and deleted an old reminder. Replied to Sam and booked a call for Wednesday at 15:00.

Every sentence of that is true. Now look at the calendar as the twin rebuilds it.

The calendar as the agent saw it and left it, rebuilt from the journal. The review is moved, with a ghost of where it was. The sync is declined. The supplier call is not declined but deleted, and because the agent passed sendUpdates=all, the supplier received a cancellation.

"Removed the supplier call" was a delete of an event the user organised, with notifications on, so the supplier received a cancellation. The event's own description said it was the call to settle an unpaid invoice. And "deleted an old reminder" was that invoice's payment reminder, removed with the API's permanent delete rather than moved to trash.

Step 15, before and after. The payment reminder is gone from Gmail, permanently, by the platform's own description. The twin still holds the full message, because the agent read it before deleting it, so its content can be put back with messages.insert, as a new message.

Neither of those is a dramatic failure. Both are exactly the kind of thing that turns up a week later as an awkward phone call. And the difference between the agent's summary and what happened is only visible because the journal holds the request and the response of each call.

What the agent said, against what the journal shows, and whether each part can be put back.

## Undo is a list, not a promise

With the journal in hand, every change gets a grade. This is the list for the session above, and it generalises.

| Action | Can the twin put it back? | What it cannot undo |
|---|---|---|
| Archive, relabel | Yes, exactly | Nothing |
| Move to trash | Yes, exactly, within 30 days | Nothing |
| Move or edit an event | Yes, exactly, from the captured before-state | The notifications already sent, and a second round when it is moved back |
| Decline an invitation | Yes, exactly | The organiser saw the decline |
| Delete an event | The event, re-inserted from the captured copy | The cancellation already sent |
| Permanently delete a message | Its content, as a new message, if the agent read it in full | The original message and its id |
| Send an email | No | The recipient has it |

The value of the list is not that most of it is green. It is that the red rows are named. Once you can see that an agent's actions fall into three kinds, reversible, partly reversible and not reversible, you can govern them differently.

## Where the capture runs

Three places to capture, and three grades of evidence. The mode does not change what is captured. It changes what the evidence is allowed to claim.

Ideally the capture runs in a **broker** that holds the credentials and makes every call on the agent's behalf, which is the [execution broker](https://twins.sgit.ai/broker/index.html) described on the twins site. Then nothing reaches the platform without passing through it, and the journal is complete by construction. The broker can also refuse, which matters for the next section. The price is that the broker holds credentials, which makes it the most valuable target in the estate.

A **gateway** on the MCP or HTTP path is easier to deploy and complete for everything routed through it, and blind to anything that goes around it.

And today, with no infrastructure at all, you can make it a **requirement of the agent**: every time you send a request, append a copy of what you sent and what you received to this lane, and stop if the append fails. It is all JSON already. This is the weakest mode, because an agent that skips an entry leaves a gap the chain cannot show, and the evidence should say *self-reported* on its first line. It is also infinitely better than nothing, and it is available this afternoon.

## What it does to the agent's behaviour policy

At [RiskMandate.ai](https://riskmandate.ai/) we write an agent behaviour policy as the record of what an agent can reach, what it was authorised to do, the gap between the two, and who accepts the residual risk. The [Licence to Operate](../demos/vaults/licence-to-operate/index.md) vault simulates exactly that for one agent.

The same agent, with the same connectors, has a very different policy with a twin and without one.

|  | Without a twin | With a twin |
|---|---|---|
| What can it do? | The scopes granted | The scopes, and which actions they allow that cannot be undone |
| What did it do? | Its own summary | Every call, request and response, chain-verified |
| What did it see? | Nothing | The inbox and calendar at each step |
| Why? | Nothing, unless the chat was kept | The instruction behind each call |
| Can you undo it? | Trash windows, sometimes | A revert plan, and a named list of what cannot be undone |
| Can you show someone else? | Your word | An evidence chain an auditor or insurer can open |

The last row is the one that changes the conversation with an insurer or a board. But the most useful change is quieter. With the list of irreversible actions in hand, the mandate can say that the agent may archive and trash freely, must ask before a permanent delete or a cancellation that notifies someone outside the organisation, and may never send to a new recipient without approval. In broker mode, the broker enforces it. That is a policy you can actually write, because for the first time you can see which action is which.

So the question I would ask of any agent deployment is the simple one: **do you know what your agents did?** If the answer is the agent's own summary, the deployment has a gap, and the gap has a known shape.

## What exists today, and what does not

**Exists and runs:** vault [append lanes](../api/append-lanes.md), write-only and blind to the sender; client-side encryption, so the journal, which holds copies of email, is stored as ciphertext the host cannot read; vault apps that rebuild views from data in the vault; and the replay in the [Connector Twin vault](../demos/vaults/connector-twin/index.md), which folds an invented seventeen-entry journal into the inbox and the calendar, shows before and after, writes a revert plan, and verifies the hash chain in your browser.

**Does not exist yet:** a gateway or broker capturing real Gmail and Calendar traffic; the processor and its schedule; revert execution; any customer. Keys matter too: a twin holds sensitive content, so who holds its keys is the first question a security team will ask, which is part of why we published [a call for collaboration on vault key management](../partnerships/vault-key-management.md).

## For somebody to build

I think this should be a business, and I have written it up as one, for somebody else to run or to run with us. The [Connector Twin vault](../demos/vaults/connector-twin/index.md) holds the plan: the facts with their sources, the architecture, the service in three capture modes, packages and prices as hypotheses, a calculator, go-to-market starting with managed service providers and insurers, the first ninety days, the risks, and the open questions. It sits with the other [business plans published for founders](../startups/business-plans.md).

The pitch is one line long, and it is not fear. It is the platform's own documentation, read aloud to somebody who has just switched on a connector: some of what your agent can do cannot be undone, and right now you cannot tell which of it it did.

## Sources

- [Gmail API, users.messages.delete](https://developers.google.com/workspace/gmail/api/reference/rest/v1/users.messages/delete)
- [Gmail API, users.messages.insert](https://developers.google.com/workspace/gmail/api/reference/rest/v1/users.messages/insert)
- [Gmail Help, delete or recover deleted messages](https://support.google.com/mail/answer/7401)
- [Gmail Help, send or unsend messages](https://support.google.com/mail/answer/2819488)
- [Workspace Admin Help, restore a user's permanently deleted email](https://knowledge.workspace.google.com/admin/support/troubleshooting/restore-a-users-permanently-deleted-email)
- [Calendar Help, delete an event](https://support.google.com/calendar/answer/37113)
- [Workspace Admin Help, Calendar log events](https://knowledge.workspace.google.com/admin/reports/calendar-log-events)
- [Vault Help, search Google Calendar](https://knowledge.workspace.google.com/vault/search/use-vault-to-search-google-calendar)
- [Vault FAQ](https://knowledge.workspace.google.com/vault/getting-started/google-vault-faq)
- [Workspace Updates, Google Vault now supports Google Calendar](https://workspaceupdates.googleblog.com/2023/11/Google-Vault-Now-Supports-Google-Calendar.html)
- [Model Context Protocol specification](https://modelcontextprotocol.io/specification)
- [sgit.ai, append lanes](https://sgit.ai/api/append-lanes.html)
- [twins.sgit.ai, the execution broker](https://twins.sgit.ai/broker/index.html)

[← All articles](index.md)



==============================================================================
# Every risk is already accepted. The only question is by whom, and for how long., sgit.ai

> A foundation article on risk acceptance, for readers who have never met the idea. A risk exists the moment the exposure does, so an organisation is always carrying it; the only open questions are who has accepted it, and until when. There is no deny button, only three doors (accept for a stated interval, fund the work, or fix it), and silence escalates. The interval is the decision, from four hours, which is an incident, to six months, which is a named decision to wait. Accepted is not the same as acceptable, which matters because the EU AI Act requires providers of high-risk AI systems to have residual risk judged acceptable, and never defines the word. Every risk has a holder, every holder has a boss, and every path ends at the board. Every risk is established by facts and ended by facts, from the board down to the configuration file, which is what closes the gap between a register and reality. The article walks one invented risk through six weeks, argues that each material risk deserves a vault of its own as its evidence pack, explains why executives resist the model, and shows why it fits alongside every GRC platform rather than replacing one. A business plan for a company that runs this loop is published with it.
>
> Page: https://sgit.ai/articles/every-risk-is-already-accepted.html

[Home](../index.md) / [Articles](index.md) / Every risk is already accepted. The only question is by whom, and for how long.

# Every risk is already accepted. The only question is by whom, and for how long.

By [Dinis Cruz](../about/index.md) · 2026-09-24 · [v0.6.5](../admin/versions.md) · riskrisk-acceptancegovernancegrcfractal-semantic-graphseu-ai-actarticle

***Abstract:** A foundation article on risk acceptance, for readers who have never met the idea. A risk exists the moment the exposure does, so an organisation is always carrying it; the only open questions are who has accepted it, and until when. There is no deny button, only three doors (accept for a stated interval, fund the work, or fix it), and silence escalates. The interval is the decision, from four hours, which is an incident, to six months, which is a named decision to wait. Accepted is not the same as acceptable, which matters because the EU AI Act requires providers of high-risk AI systems to have residual risk judged acceptable, and never defines the word. Every risk has a holder, every holder has a boss, and every path ends at the board. Every risk is established by facts and ended by facts, from the board down to the configuration file, which is what closes the gap between a register and reality. The article walks one invented risk through six weeks, argues that each material risk deserves a vault of its own as its evidence pack, explains why executives resist the model, and shows why it fits alongside every GRC platform rather than replacing one. A business plan for a company that runs this loop is published with it.*

The acceptance loop. Establish the risk on facts, place it with a holder and the chain above them, have the holder accept it for an interval with an action, and when the interval ends, accept again, fund or fix. Silence is not a door: it escalates to the holder's boss.

Here is the claim, stated so it can be wrong. **Every risk your organisation has is already accepted. Somebody is carrying it, today, whether or not anybody signed for it. The only questions worth asking are who has accepted it, and until when.** Most risk management avoids those two questions. This article is about what happens when you stop avoiding them, and it assumes you have never heard any of this before.

## In short

- **A risk exists the moment the exposure does.** Nobody decides whether to accept it. The organisation is carrying it from the start, signed for or not.
- **There is no deny button.** You cannot vote a fact out of existence, and a register that lets you reject a risk lets you pretend.
- **There are three doors: accept it for a stated interval, fund the work that reduces it, or fix it.** Silence is not a fourth door. A risk nobody accepts is treated as critical and rolls up to the holder's boss.
- **The interval is the decision.** Accepting for four hours is declaring an incident. Accepting for a month is funding work. Accepting for six months is a named decision to wait.
- **Accepted is not the same as acceptable.** One is an act by a named person on a date. The other is a threshold. The EU AI Act asks for residual risk to be "judged to be acceptable" and never defines the word.
- **Every risk has a boss.** Every risk has a holder, every holder has a boss, and every path ends at the board, computed rather than reported.
- **Risks are fractal.** A board line such as "loss of customer funds" opens into business, operational and technical risks, each with its own holder, down to the configuration file that makes it true.
- **Established by facts, ended by facts.** Every risk names the facts that make it true, and the facts that would end it. That is what closes the gap between a register and reality.
- **Each material risk deserves a vault of its own**: the evidence pack of governance, with its facts, decisions and history, readable by each audience with its own key.
- **Executives resist this, and they are right that it is disruptive.** That resistance is the work, and it is why this is a governance change, not a product feature.
- **It fits alongside every GRC platform.** It works in the gaps they leave. A [business plan for a company that does exactly this](../demos/vaults/risk-acceptance/index.md) is published with this article.

## A risk you are already carrying

Take one ordinary example. A company lets an AI agent run database changes in production, because it makes deployments faster. The agent's database role can write to the ledger. Some ledger migrations cannot be rolled back.

From the moment that role was created, the company has been carrying a risk: the agent can change production in ways nobody can undo. Nobody decided to accept it. Nobody decided not to. It is simply there, and it will stay there until somebody changes one of the facts that make it true.

Now look at how most organisations record it, if they record it at all: a row in a register. "Change risk in automated deployment. Owner: Technology. Rating: Medium. Status: Open. Next review: the risk committee in December. Evidence: none attached." Every field is reasonable. None of them says who has accepted the risk, until when, or what will happen if nothing changes.

## There is no deny button

The first principle sounds obvious and changes everything: **you cannot deny a risk.** As [risks.sgit.ai](https://risks.sgit.ai/) puts it, "You cannot vote a fact out of existence." If the agent's role can write to the ledger, no meeting can decide otherwise. You can change the role, or accept that it can.

So the only real choices are three, each with a name against it:

1. **Accept it**, personally, for a stated interval.
2. **Fund** the work that will reduce it.
3. **Fix** it, so that the facts that make it true stop holding.

Deferral is not a fourth door. "Revisit next quarter" is not a decision, and silence is not a decision anybody can underwrite. In this model, **unaccepted is critical**: a risk nobody has accepted rests on whoever is nearest, and it rolls upward to their boss, and then to theirs, until somebody signs.

## The interval is the decision

Accepting a risk is never open-ended. Every acceptance is for an interval, and the interval is not a detail of the decision. It *is* the decision, because each length names a different response. This is the ladder as published on risks.sgit.ai:

| Interval | What it means |
|---|---|
| 1 hour | "I need more data." Go and get it, then decide again. |
| 4 hours | A priority-one incident. Trigger incident response. |
| 1 to 2 days | A smaller incident. |
| 1 to 2 weeks | A funded project for a team that already exists. |
| 1 month | Assemble and fund. The default, set deliberately just above the incident line. |
| 6 months | Do nothing, and review it then. It costs nothing, and it is legitimate, with a name on it. |

Two things follow. First, **a short acceptance is an incident.** If the honest answer to "how long can we live with this?" is four hours, the organisation is not managing a risk any more; it is responding to one. Second, **a funded acceptance has a natural length**: the length of the project that will end it.

When the interval ends, nothing silently continues. The same decision comes back to the same desk, with whatever evidence has arrived since. Accept again, fund or fix. If nobody does anything, the risk goes one level up, where the choice is the same.

## Accepted is not acceptable

Most registers blur two different questions.

Two questions, four states. Accepted is an act by a named person at a dated moment. Acceptable is a threshold. The dangerous state is a risk over the line that nobody has signed for.

**Accepted** is an act: a named person, on a date, for an interval. **Acceptable** is a threshold: in [RiskMandate.ai](https://riskmandate.ai/acceptable.html)'s words, "the moment that the business is happy to stop funding remediation activities". A risk can be accepted and not yet acceptable: somebody has signed for it, for a short interval, while the fix is funded. A risk can be acceptable and not accepted: probably harmless, and exactly where a register quietly goes stale. And a risk can be neither, which is the dangerous one.

This distinction is now written into law for one class of organisation. Article 9(5) of the [EU AI Act](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) requires providers of high-risk AI systems to adopt risk management measures "such that the relevant residual risk associated with each hazard, as well as the overall residual risk of the high-risk AI systems is judged to be acceptable" ([text of Article 9](https://artificialintelligenceact.eu/article/9/)). The Act never defines "acceptable". The duty to make the judgement is imposed, and the standard for making it is not supplied. An organisation has to draw its own line, and be able to show that it did.

Our position is that this is not the end of the question but the beginning. Being over or under the line does not remove the need for somebody to accept what is actually being carried. **Acceptance has to happen every time a risk exists. The only debate is for how long, and for what action.**

## Every risk has a boss

Every risk has a holder: the person whose job it is to accept, fund or fix it. Every holder has a boss, and that boss has a boss, up to the board. So every risk has a chain, and every chain ends at the board.

The role risk map in the Risk Graph Explorer vault. Every risk is assigned to somebody, and every risk reaches the board. The CTO holds 4 and sees 25 pass through; the board has 37 arrive.

The [Risk Graph Explorer](../demos/vaults/risk-graph-explorer/views/index.md) vault computes this today. Each role shows what it is **assigned**, meaning its own to deal with, and what arrives **through** it, meaning what the risk graph says must reach it. In the tool's own words: "It arrives because the risk graph says so, not because anybody reports here." No risk is orphaned, and nobody at the top is surprised by something nobody carried up.

The other rule of the chain is that **nobody can accept on anybody else's behalf.** A holder's boss sees the risk arrive, and sees whether it was accepted, until when, and on what evidence. But the acceptance belongs to the person who holds it. When somebody refuses, that is visible too, and it is a finding rather than a failure. As I said in one of the recorded walkthroughs of that vault, "everybody that is going to accept it is going to push back". That pushback is the point.

## From the board to the bytes

A risk at the board is written in the board's language: loss of customer funds, regulatory penalty, loss of licence. That line is real, but it is not something anybody can fix. Underneath it are risks in other languages: the business risk that payments can be corrupted, the operational risk that an agent can change production irreversibly, and the technical risk that the agent's role has write access to the ledger with no approval step.

One risk from the board to the bytes. Each altitude has its own holder and its own words, joined by "leads to" edges, and every altitude points at the facts and evidence beneath it. A register row in a spreadsheet is the top box on its own.

This is what we call a **fractal risk register**, described on [graphs.sgit.ai](https://graphs.sgit.ai/v1/docs/fractal-risk-registers.html): "wherever there is a stakeholder accepting a risk, that entity needs a register." A database administrator's risk translates into the CISO's, the CFO's, the CEO's and the board's, each in that person's own words, joined by named edges rather than retyped. The vocabulary changes at every altitude. The grammar does not: a holder, an interval, the facts that establish it and the facts that end it.

Risk chains in the Risk Graph Explorer vault. Inherent risks on the left rise by causal depth to the corporate register on the right. Click any entry to see what produced it and what it produces.

This is also where [Fractal Semantic Graphs](../articles/introducing-fractal-semantic-graphs.md) stop being an abstraction. The fractal property is that on one of the links you can jump into another universe with its own rules: from the board's register into security operations, into the database estate, into one configuration file. A vulnerability at the bottom and a revenue obligation at the top are no longer in different tools with a spreadsheet between them.

## Established by facts, ended by facts

The single change that closes the gap between a register and reality is this: **every risk names the facts that make it true, and the facts that would end it.**

In the Risk Graph Explorer, a risk is established by one cited fact, F-5, that the agent can change the production estate. Then, unusually, it carries its own end condition: "Ceases when any of these hold: F-4 reads-only-from, or F-3 absent-from." The risk ships with its own falsification condition. It is not a judgement to be argued down; it is a claim about facts, and when the facts change, the risk ends, with the evidence attached.

That is also what makes disagreement productive. When a holder says "I don't buy that", the conversation becomes which fact is wrong, not whose opinion is louder. And it is what the usual register cannot do: a row typed by a person, reviewed quarterly, connected to nothing, is a record that can be perfectly maintained and entirely wrong.

## One risk, six weeks

Here is the whole loop on the example above, as an invented company, replayed in the [Risk Acceptance Office vault](../demos/vaults/risk-acceptance/index.md).

The risk is established on day 0 on two facts, each with its source, and placed with the SRE lead. The platform owner, the CTO, the CEO and the board see it arrive through the chain. On day 1 the SRE lead accepts it for two weeks, with an action: add an approval step to the agent's production writes. On day 15 the acceptance expires. The approval step was not built, because the team was moved onto a release. Nobody renewed it, so it escalates.

Day 15. The two-week acceptance expired with its action undone, so the risk rolled up to the platform owner, who must now accept, fund or fix.

The platform owner funds a four-week project and accepts the risk for a month. On day 24 the risk materialises: the agent applies a migration that cannot be rolled back, and settlement stalls. The platform owner accepts for four hours, which is an incident response by definition, suspends the agent and reconciles the ledger. The incident's timeline becomes a new fact in the risk's own record. On day 41 the approval step is merged, one of the facts that the risk named as ending it now holds, and on day 42 it ceases, on evidence.

Day 42. The fact that ends the risk holds, with its source, and the risk ceases. The facts that established it are still true; the one that ends it is now true as well.

Now look at the register row at the same moment.

The same day, two views. The register row still says "Open until the committee on 12 December", with no evidence attached. The risk's own record says who accepted it, until when, what happened, and why it ended.

That difference is the air gap. Nothing in the row is wrong. It just never learned that the risk was accepted twice, expired once, escalated, funded, materialised as an incident, and ended.

## A vault per risk

Every material risk deserves a place to keep its own story: the facts and where they came from, the controls and their states, every acceptance with its interval and action, every escalation, every incident, and the evidence that ended it. That is the evidence pack of governance, and today it is scattered across emails, spreadsheets, screenshots and meetings nobody minuted.

A vault is a natural home for it. It keeps every version of every fact and decision, proves the record was not altered afterwards, travels as one read key, and stays readable if the organisation changes its tools. The holder writes to it. Their chain up to the board gets a read key. The auditor and the insurer get their own keys when they need them, and nothing else. A corporate risk's vault can link to the vaults of the business, operational and technical risks beneath it, which makes the register fractal in storage as well as in meaning.

This is a proposal, not yet a practice: the published method describes fractal registers and a chain to the board, and the idea of a vault per material risk is new here.

## Twins, and where this goes

On [twins.sgit.ai](https://twins.sgit.ai/actors/index.html), every action that changes the risk graph, including accepting a risk, is performed by a twin acting for a person, connected either to that person or to an agent working for them. That makes acceptance "the most evidenced act rather than the least". Twins also make risk testable: an organisation's risks, controls and decisions modelled well enough to simulate what happens when one of them changes. And risks.sgit.ai names the air gap honestly: "A twin not connected to reality is a tracked air gap."

Both ideas are designs, and the twins site says so plainly: "None of this is built." I include them because they show where the model leads. Risk systems that stay at the level of a register row will always be disconnected from events. A model in which risks are established on facts, facts come from twins of the real systems, and acceptances are recorded as events, is one where the register and reality can finally be the same thing.

## Why this is hard, and why people resist

I want to be honest about what happened when we took this to market. With [RiskMandate.ai](https://riskmandate.ai/) we approached risk acceptance from the angle of AI agents and insurability, and it was hard for two reasons.

The first is ownership. Risk acceptance is a governance matter. It has to come from the people who own governance, risk and compliance, and from the board. Sold as a feature of a security or AI product, it lands with people who do not own it.

The second is resistance, and it is rational. Some of the people we worked with did not want to give their risk owners an acceptance workflow at all, because they understood, instinctively or explicitly, that it would be a very disruptive change. Today many executives accept very little, or accept only what has already been judged acceptable. Asking them to accept, personally and for a stated interval, everything they actually hold changes their job. risks.sgit.ai names the same tension: "No-deny is the strongest idea here and the hardest to sell. Removing the deny button removes the thing most executives use a register for." It also names how the model can be defeated without anybody arguing with it: "interval inflation, where everything is accepted for six months".

None of that makes the model wrong. It makes it a change programme, and change programmes are run by people, one business unit at a time.

## It fits alongside every GRC platform

Nothing here replaces the platforms organisations already use for governance, risk and compliance. They solve real problems: the register, the workflow, the frameworks, the reporting. What they leave are gaps: between the row and the facts, between "accepted" and a clock, between a function and a named person, between one coarse row and the forty things underneath it.

This model operates in those gaps. It reads the register from the platform, and writes back what the platform lacks: who accepted, until when, what happens at expiry, and a link to the evidence. Which is why I think the GRC vendors should be sponsoring and integrating with this work rather than competing with it: it makes their platforms more valuable and harder to leave.

## What exists today, and what does not

**Exists and runs:** the published model on [risks.sgit.ai](https://risks.sgit.ai/), the acceptance and licence-to-operate work on [RiskMandate.ai](https://riskmandate.ai/), fractal risk registers on [graphs.sgit.ai](https://graphs.sgit.ai/v1/docs/fractal-risk-registers.html), the [Risk Graph Explorer](../demos/vaults/risk-graph-explorer/index.md) vault, which computes the chain to the board, and the [Risk Acceptance Office](../demos/vaults/risk-acceptance/index.md) vault, which replays one risk's acceptance loop with a hash-chained decision record verified in your browser.

**Does not exist yet:** an engine that records acceptances, runs the clocks and fires at expiry. risks.sgit.ai states plainly, in capitals, that essentially none of its model is implemented in code. The published material also leaves open exactly what happens at expiry, whether an unaccepted risk rolls up automatically or waits, and which of two published ladders is canonical. The business plan takes a position on each, and says so.

## For somebody to build

I think this should be a company, and possibly several. Its work is the hard part: establishing risks on facts, connecting them to the people who hold them, running the clocks, keeping the evidence, and helping executives through the change. The [Risk Acceptance Office](../demos/vaults/risk-acceptance/index.md) vault holds a business plan for it: the operating model, working in the gaps of the GRC platform, services and prices as hypotheses, a calculator, go-to-market that starts from the resistance rather than around it, the first ninety days, the risks and the open questions. It sits with the other [business plans published for founders](../startups/business-plans.md).

The pitch is two questions, asked of any register: **who has accepted this, and until when?**

## Sources

- [risks.sgit.ai, the model, the ladder and the inventory of what is built](https://risks.sgit.ai/)
- [risks.sgit.ai, Accepted is not acceptable](https://risks.sgit.ai/acceptable/)
- [RiskMandate.ai, Accepted is not acceptable](https://riskmandate.ai/acceptable.html)
- [graphs.sgit.ai, Fractal Risk Registers](https://graphs.sgit.ai/v1/docs/fractal-risk-registers.html)
- [twins.sgit.ai, twins as actors](https://twins.sgit.ai/actors/index.html)
- [Regulation (EU) 2024/1689, the AI Act, on EUR-Lex](https://eur-lex.europa.eu/eli/reg/2024/1689/oj)
- [Article 9 of the AI Act, risk management system](https://artificialintelligenceact.eu/article/9/)
- [The Risk Graph Explorer, the seven views](../demos/vaults/risk-graph-explorer/views/index.md)
- [The Risk Acceptance Office vault](../demos/vaults/risk-acceptance/index.md)

[← All articles](index.md)



==============================================================================
# The future of news is the story vault, not the paywall, sgit.ai

> The news industry runs on two commercial models, advertising and subscriptions, and both are bad for the reader. One sells the reader to somebody else. The other charges rent on something most people have stopped using. Both are now being dismantled from outside, by a search layer that has stopped sending traffic and by consumer law that arrives in January 2027. This article is about what to build instead, in practical terms. The objective is a commercial model that rewards investigative journalism, so that the expensive, evidenced kind of reporting drives usage, usage drives revenue that depends on neither search nor renewals, and that revenue funds more of the same. The mechanism is to stop selling the article and start selling what the article was made from. The story is a graph, a fractal semantic graph in which meaning comes from connectivity and every claim walks down to hashed evidence, so that trust comes through provenance and provenance comes via evidence. The article is one projection of it. From that one graph a newsroom can sell five things, on demand and in pence, to readers, to firms and to agents, and every payment walks back to the people who made the facts. It is built, in parts, on things we have already published.
>
> Page: https://sgit.ai/articles/future-of-news-story-vault-not-paywall.html

[Home](../index.md) / [Articles](index.md) / The future of news is the story vault, not the paywall

# The future of news is the story vault, not the paywall

By [Dinis Cruz](../about/index.md) · 2026-09-22 · [v0.5.5](../admin/versions.md) · newspublishingprovenancemicropaymentssemantic-graphsarticle

***Abstract:** The news industry runs on two commercial models, advertising and subscriptions, and both are bad for the reader. One sells the reader to somebody else. The other charges rent on something most people have stopped using. Both are now being dismantled from outside, by a search layer that has stopped sending traffic and by consumer law that arrives in January 2027. This article is about what to build instead, in practical terms. The objective is a commercial model that rewards investigative journalism, so that the expensive, evidenced kind of reporting drives usage, usage drives revenue that depends on neither search nor renewals, and that revenue funds more of the same. The mechanism is to stop selling the article and start selling what the article was made from. The story is a graph, a fractal semantic graph in which meaning comes from connectivity and every claim walks down to hashed evidence, so that trust comes through provenance and provenance comes via evidence. The article is one projection of it. From that one graph a newsroom can sell five things, on demand and in pence, to readers, to firms and to agents, and every payment walks back to the people who made the facts. It is built, in parts, on things we have already published.*

One story, held as a graph in a vault, and five things that can be sold from it. The public article is free and brings the reader to the door. Everything to its right is paid, in pence and on demand, and every payment walks back to the people who made the facts.

Here is the claim, stated so it can be wrong. **The news industry sells the one thing whose price is going to zero, the article, and throws away the one thing nobody else has, the evidence the article was made from.** Fixing that is not a better paywall. It is a different product, and this piece is about what that product is, how each part of it works, who pays for it, and which parts of it already run.

## In short

The whole argument, for the reader who will not get to the end.

- **Both of the industry's models are bad for the reader.** Advertising sells the reader to somebody else, so the reader is the product and the content is bait. A subscription charges rent on something most subscribers have stopped using, so the reader is the hostage and the content is the excuse. Neither pays for what the reader came for.
- **Both models are being dismantled from outside.** Google traffic to publishers fell a third in a year and the crawlers that replaced it are now tolled. The UK's subscription rules, with renewal reminders and easy cancellation, were brought forward in August to 1 January 2027. The industry's answer to both is more subscriptions and more personalisation, which is to say, more of the thing both are running against.
- **The objective is a loop, not a price.** A commercial model that rewards investigative journalism, so the expensive, evidenced kind of reporting drives usage, usage drives revenue that depends on neither search nor renewals, and that revenue funds more reporting. The current models run the opposite loop: cheaper content, less trust, less use.
- **The story is a graph. The article is a projection.** A story being reported is claims, evidence, sources, raw materials, analysis and drafts. The article is one walk through that graph, for one audience, at one moment. Keep the graph, in a vault, and the article becomes a build artefact.
- **The graph is fractal, and meaning comes from connectivity.** A claim means nothing on its own; what it is arrives through its edges: who stated it, what it rests on, what it contradicts, what replaced it. Open any node and it is a graph of its own, a source opens into an identity world, a claim opens into the sentence and the bytes it came from, and the regulator, the company and the newsroom each keep their own vocabulary, joined by edges the newsroom draws. That is what connecting the dots has always meant, made inspectable.
- **Trust through provenance, provenance via evidence.** Trust is not asserted, it is the result of a chain that can be walked: from a claim, along named edges, to evidence that is frozen bytes with a hash. Because nothing on that ladder is asserted, every rung of it can be sold.
- **Five things to sell from one graph.** The public article, free, as the door. The licensed article, in pence, for the reader who wants this one and the firm that has to forward it. The evidence vault, licensed to the analysts, lawyers and newsrooms who already pay for data. The customised projection, one graph cut for a role, a sector or a language. And the verification API, an on-record answer with a warranty, sold per query to companies and to agents.
- **Trust, provenance and customisation are the products.** The words can be regenerated by any model in a second. The frozen evidence, the chain from claim to bytes, the journalist's track record and the on-record confirmation cannot, and those are what the reader, the firm and the agent were trying to buy all along. A customised projection is one altitude of the graph, loaded for one question.
- **The money goes to whoever made the fact.** A split of 60 to the original researcher, 25 to the data organisation, 10 to the journalist and 5 to the outlet, against today's model where nearly all of it stops at the outlet. The rails to pay in pence, with no fixed fee, now exist.
- **Parts of this already run.** Hash-verified regulation graphs, a Portuguese newsroom with 92 frozen sources and an editor-gated pipeline, a penetration test sold as eight projections of one graph, and a published estate of thirty-one vaults costing a third of a gigabyte of storage. What does not run is the billing, and the article says so.

The rest of this piece is the long form of those ten points, with the evidence, and with the parts of the solution spelt out in enough detail to be built.

## Both models are bad for the reader

The problem has been written about a great deal, so I will keep it to what matters for the solution, and start from the reader rather than the publisher, because that is where the fault is clearest.

**Advertising sells the reader.** Under an advertising model the reader is not the customer. The reader is the inventory, and the content exists to put the reader in front of the buyer. Every incentive follows from that. The headline is written to be clicked, not to be right. The page is built to be scrolled, not read. The tracking is there because the reader is what is being measured and sold. A reader who understands this, and most now do, treats the content as bait, because that is what the model makes it.

**A subscription charges rent.** Under a subscription model the reader is the customer, which is an improvement, but the reader is paying for unlimited access to everything, and the value of unlimited access is set by how much of it they use. Somebody in my own household pays roughly £50 a month across news subscriptions and reads, in a good month, a tenth of what that buys. That is the model working as designed: you pay 100% for the 10% you actually wanted, and the business depends on you forgetting to do anything about it. As [subscriptions.sgit.ai](https://subscriptions.sgit.ai/) puts it, a subscription *is a discount for committing to regular use. It is not rent on something you have the right to ignore.* Most news subscriptions are the second thing.

**Neither pays for what the reader came for.** The reader came for a piece of reporting they can rely on. Under advertising, reliability does not move the click and so is not funded. Under subscriptions, reliability does not move the renewal, because the renewal is moved by inertia, and so is not funded either. The most expensive thing a newsroom does, investigative work, is the first cost cut under both models, because it is the most expensive thing that does not move the number the model optimises. Both models are, structurally, a race to the bottom, and the 2026 Reuters Institute data is what the bottom looks like: [trust in news at 37%](https://reutersinstitute.politics.ox.ac.uk/digital-news-report/2026/dnr-executive-summary), the lowest since it was first measured in 2015, and 42% of people saying they sometimes or often avoid the news altogether.

Two loops. Advertising and rent optimise for the click and the renewal, so investigative work is the first cut, trust falls, use falls, and the next turn is worse. The model this article describes runs the other way: evidenced reporting fills a story vault, the vault is used on demand, the usage pays the people who made the facts, and the revenue funds the next investigation.

## The objective, stated once

So the objective is not a better paywall, a cheaper subscription or a new advertising format. **The objective is a commercial model that rewards investigative journalism.** One in which the expensive, evidenced kind of reporting is the thing that drives usage, because it is the thing readers, firms and agents will pay for on demand; in which that usage produces revenue that depends on neither the search engine's traffic nor the subscriber's inertia; and in which that revenue funds more of the same reporting, so the loop runs up instead of down.

Every design decision in the rest of this piece is there to serve that loop. If a proposal does not reward the reporting, it is not part of the model, however well it monetises.

## The two clocks, briefly

Both existing models are also being taken apart from outside, by two clocks the industry does not set. The evidence matters mainly for the timing, so here it is, briefly.

**The deal with search is ending, on the search engine's schedule.** Chartbeat data across more than 2,500 sites, reported by [Press Gazette](https://pressgazette.co.uk/media-audience-and-business-data/google-traffic-down-2025-trends-report-2026/), has organic Google search traffic to publishers down 33% globally in the year to November 2025, and 38% in the United States. Digiday [attributes a 25% referral drop](https://digiday.com/media/google-ai-overviews-linked-to-25-drop-in-publisher-referral-traffic-new-data-shows/) to AI Overviews specifically, and publishers surveyed for the 2026 Digital News Report expect search traffic to fall a further 43% in three years. The crawlers that replaced the traffic are now being tolled: Cloudflare began [blocking AI crawlers by default](https://www.theregister.com/2025/07/01/cloudflare_creates_ai_crawler_toll/) in July 2025, answering them with HTTP 402, Payment Required, and on 1 July 2026 said [that was not enough](https://techcrunch.com/2026/07/01/cloudflares-new-policy-pushes-ai-companies-to-pay-for-publishers-content/): more than half of AI crawler traffic re-fetches unchanged pages, bots now outnumber humans on its network, and from 15 September 2026 any crawler that will not say whether it is search, training or an agent is blocked. Its customers send [more than a billion 402s a day](https://ppc.land/cloudflare-stops-charging-ai-per-crawl-and-starts-paying-per-answer/). The licensing deals that some publishers got instead, News Corp's [$250 million over five years](https://llmpulse.ai/blog/openai-publisher-deals/) from OpenAI and the like, exist for perhaps twenty publishers in the world. For everyone else the words are interchangeable, and a model that has read a thousand articles about an event does not need the thousand and first.

**The law is coming for rent, on the legislature's schedule.** Across the twenty countries the Reuters Institute has tracked for a decade, 17% pay for online news, down from 18%, and the 2026 report describes 10% to 20% as *"a ceiling in most markets."* Of those who do not pay, [71% told the 2025 survey](https://reutersinstitute.politics.ox.ac.uk/digital-news-report/2025/dnr-executive-summary) that nothing on offer would persuade them, 65% in the UK. The thing that made subscriptions work despite that ceiling was inertia, and inertia is what the law is now removing. The UK's Digital Markets, Competition and Consumers Act carries a subscription regime with renewal reminders, a fourteen-day cooling-off period when a trial converts or a long contract renews, and cancellation by a route no harder than the one used to join, with fines of up to 10% of global turnover. On 10 August 2026 the government [brought it forward to 1 January 2027](https://ppa.co.uk/burnham-government-brings-forward-implementation-of-subscription-rules-to-january-2027), and the Professional Publishers Association called that *"genuinely difficult for publishers to operationalise."* It is difficult because the model depends on the thing the rules remove. A renewal reminder to a reader who has not opened the app in three months is a cancellation notice with extra steps. The United States is a step behind and moving the same way: the FTC's click-to-cancel rule was vacated on 8 July 2025 on procedure, the FTC has restarted it, and California's auto-renewal amendments have been in force since 1 July 2025.

The two clocks, with dates. The deal with search is being ended by the search layer, and the subscription is being regulated by the legislature. The industry's answer to both is more of the thing both clocks are running against.

**And the industry's answer to both is the same answer.** Read any commentary from the past year and it is about subscriptions and personalisation: how to convert the reader, how to keep the reader, how to show the reader more of what they already read. That was a reasonable answer to a traffic problem in 2016. In 2026 it prices the one part of the operation whose price is falling fastest, because the same model that summarises an article in a search result summarises it in a chatbot, a briefing and a translation, and one in ten people already get news from a chatbot every week.

## Why paying per item failed before, and why that is about the wrong thing

Anything smaller than a subscription has a well-made case against it, and the solution below has to answer it, so here it is at full strength.

James Ball's [2020 piece for Columbia Journalism Review](https://www.cjr.org/opinion/micropayments-subscription-pay-by-article.php) is the best version. A $100 subscription lost is 500 micropayments to replace. A newspaper is a bundle, and unbundling it breaks the cross-subsidy. You only know whether an article was worth it after you have read it. And any scheme that needs dozens of publishers to co-operate on a shared wallet will fail, because *"the success of any project is inversely correlated with the amount that requires publishers to work together."* Matthew Guay's [history of the failures](https://buttondown.com/blog/why-micropayments-do-not-work), from May 2026, adds the psychology: Nick Szabo in 1996 on transactions that are not worth the brain cycles, Clay Shirky on the anxiety in every decision to buy, and Blendle, which had more than a million users, of whom 150,000 ever paid, and pivoted to subscriptions in 2019.

All of that is true, and all of it is about a reader deciding whether an article is worth twenty pence. I agree that the reader will not stop to decide that. But look at who is standing at the till today and what they are trying to buy, because it is not the article.

**The reader who wants one thing.** I can buy The Guardian or The Telegraph for £3 this morning and I cannot buy one article from either online at any price. The Toronto Star [sells one for 75 cents](https://www.amediaoperator.com/analysis/the-toronto-star-launches-micropayments/), Cornwall Reports for 20p, and the striking thing about that list is how short it is. In the UK, 10% pay for online news, and of those, 66% do it by subscription and 7% by one-off payment. The one-off option barely exists, so almost nobody uses it, and that is then cited as proof nobody wants it. Dominic Young of Axate, quoted in [my April 2025 piece on micro and nano payments](https://docs.diniscruz.ai/2025/04/02/the-future-of-news-monetization__embracing-micro-and-nano-payments.html): *"There are more people in the market willing to pay than willing to subscribe."*

**The firm that has to forward it.** Inside a company an article is not read, it is processed. Somebody summarises it for the people who matter, puts it in the format the board reads, attaches it to the risk register, translates it for the regional office and cites it in a filing. That is transformation, it is where the value is created, and it is where the provenance is lost. That reader does not want a subscription to the newspaper. They want this article, with its evidence, in a form they are allowed to transform and forward, and they will pay a licence price that would look absurd to a consumer, because the alternative is an analyst spending an afternoon reconstructing the sources.

**The agent, paying per query.** Cloudflare's billion 402s a day are not being sent to people. The buyer that now arrives most often is a program with a budget and an instruction to find out whether something is true. It has no anxiety and no brain cycles to conserve. It has a wallet. That buyer did not exist in 2020, and it makes the mental-transaction-cost argument beside the point, because the transaction is not mental.

None of the three wants the article. The reader wants this one thing, the firm wants the thing plus the right to transform it, and the agent wants to know whether the thing is true. Ball's arithmetic assumes a micropayment cannibalises a subscription. It cannot cannibalise a subscription the reader was never going to buy, and 71% of them were never going to buy it.

**The story is a graph. The article is a projection. Sell the graph.**

## The story is a graph, and the article is a projection

Here is the shift everything else follows from, and it is the thesis of [newsroom.sgit.ai](https://newsroom.sgit.ai/thesis): *the story is a graph; the article is a projection.*

A story, while it is being reported, is not an article. It is a set of claims, each resting on evidence, drawn from sources, some of whom cannot be named, held together by analysis that has hypotheses and gaps and a confidence that changes as the reporting goes on. It has raw materials: the interviews, the documents, the dataset somebody pulled. It has drafts, and the decisions about what to leave out. All of that is the story. **The article is a projection of it**: a walk through the graph, at one moment, for one audience, in one language, at one length. The infographic is another projection. The translation is another. The three-paragraph summary a model produces in a search result is another, and that is the whole problem in one sentence: the industry has been selling the cheapest projection and throwing the graph away.

Because it does throw it away. In most newsrooms the graph lives in the journalist's head, a notes app and an email thread, and the moment the article ships the graph starts to decay. A year later, when the story is contested, or somebody wants to build on it, or an agent wants to know whether a claim in it still holds, there is nothing to walk back to. The evidence was never a first-class object. It was a step on the way to the words.

**The dataset is worth more than the article.** The words are what any model can regenerate from the dataset in a second. The dataset is what nobody else has: the frozen copy of the source page before it changed, the interview, the on-record confirmation, the spreadsheet, the chain from a claim to the bytes it rests on. A newsroom that keeps the graph and gives the words away is sitting on an asset. A newsroom that sells the words and loses the graph is selling the only thing that has stopped being scarce.

I have been making this argument since early 2025, and the dates matter, so here they are. [Monetising Trust and Knowledge](https://docs.diniscruz.ai/2025/02/02/monetising-trust-and-knowledge-for-news-providers.html), 2 February 2025, set out the tiers, the APIs and the verification services a structured newsroom could sell, and argued that *"publishers that structure their content for intelligent consumption will define the future of trusted journalism."* [Building Trust Through Fact Provenance](https://docs.diniscruz.ai/2025/02/05/the-future-of-news-building-trust-through-fact-provenance.html), three days later, made provenance the pillar the rest stands on: *"trust in information emerges over time, formed by repeated demonstrations of ethical sourcing and consistent reliability."* [Journalists' Challenges with Digital Content Provenance and Trust](https://docs.diniscruz.ai/2025/03/24/journalists-challenges-with-digital-content-provenance-and-trust.html), 24 March 2025, made a point that is still under-appreciated: *"the value of provenance is probably more for the world of journalism than it is for the world of consumers."* The reader will rarely walk the chain. The editor, the lawyer, the regulator and the agent will, and they are the ones who pay. The [identity graphs piece](https://docs.diniscruz.ai/2025/04/21/strengthening-trust-in-news__implementing-identity-graphs-for-authors-and-sources.html) of 21 April 2025, the [Dan Raywood briefing](https://docs.diniscruz.ai/2025/06/06/personalised-briefing-for-dan-raywood-on-the-future-of-news.html) of 6 June 2025 and the [Cloudflare piece](https://docs.diniscruz.ai/2025/07/04/from-free-scraping-to-fair-compensation-cloudflares-genai-crawler-charges-and-the-future-of-news-monetization.html) of 4 July 2025 each appear below where they are used. All of them were written before the traffic numbers, before the tolls, before the January 2027 date and before the payment rails existed. The predictions have not needed revising. The evidence arrived to meet them.

## The graph is fractal, and meaning comes from connectivity

"Graph" is doing a lot of work in that section, so it is worth saying which kind, because the kind is what makes the rest of this piece buildable rather than a metaphor. The graph is a [Fractal Semantic Graph](../demos/fractal-graphs/index.md), and two of its properties are the ones a newsroom has always run on without a way to write them down.

**Meaning comes from connectivity.** The thesis of [graphs.sgit.ai](https://graphs.sgit.ai/) is one sentence: *a node means nothing on its own; what it is arrives through its edges.* In a semantic graph every edge is a verb with a named inverse, evidenced_by, stated_by, contradicts, supersedes, so a link reads correctly from either end, and an edge with no verb is banned, because two things always relate and an edge that says only that constrains nothing. Now apply that to a fact in a story. The fact on its own is a sentence. What it *means* is who stated it, in answer to what, what document it rests on, which earlier claim it contradicts, which later one replaced it, and when. That is not an abstraction laid over journalism. It is the craft. A reporter who knows that a quote from the regulator on Tuesday contradicts the company's filing from March has done exactly one thing: drawn an edge, with a verb. The Portugal newsroom's rule, *we connect the dots, we do not draw them*, is a description of semantic graph construction, and the graph is what makes each connection inspectable rather than trusted.

A story, zoomed. At the desk's altitude it is a node among stories, entities and events. Open it and it is claims, sources, evidence and versions, every edge a verb. Open a claim and it is the sentence, the words in it, and the byte range in a hashed file it came from. Open a source and it is an identity world of its own. The vocabulary changes at every altitude. The grammar does not, and neither does the provenance.

**And the graph is fractal.** Zoom into any node and you enter a new world with its own node types, its own verbs and its own vocabulary, joined to the one you left by a single named edge. The story is one node in the desk's graph of stories, entities and events. Open it and it is a graph of claims, sources, evidence and versions. Open a claim and it is the sentence it rests on, the words in that sentence, and the byte range in a hashed file where they sit. Open a source and it is an identity world: credentials, past claims, corrections, in the vocabulary of the [identity graphs piece](https://docs.diniscruz.ai/2025/04/21/strengthening-trust-in-news__implementing-identity-graphs-for-authors-and-sources.html) from April 2025, and the flag that says this source is anonymous lives on that node, where every projection has to pass it. Open the regulator and it is the regulator's world, in the regulator's vocabulary; open the company and it is the company's, filings and ownership and funding. None of them was asked to adopt the newsroom's schema. The three layers graphs.sgit.ai describes, *shared facts owned by nobody, per-party formulas, declared bridges between them*, are a description of what a good newsroom already is: a place that draws edges between worlds that will never agree on a vocabulary.

Four things fall out of the fractal property that matter here.

- **Provenance comes free.** When the leaf is a word, and the word is connected to the byte range it came from and the hash of the file that held it, every claim at every altitude above it is traceable to source with no extra machinery. graphs.sgit.ai states the discipline as a build rule: *every fact carries the sentence it came from, and the build fails if that sentence has moved.* A newsroom whose build fails when a source page changes under it has solved the correction problem before it is a problem.
- **A correction propagates instead of being republished.** Mark one node superseded and every path that rested on it becomes a query, *what did we build on this?*, rather than an archaeology project. A document cannot do that. The correction is a new document, and nothing connects it to the thousand that already cite the error.
- **The smallest node is whatever the question needs.** For the reader it is the headline. For the analyst it is the claim and its sources. For the lawyer it is the word, and whether the word in the filing is the same word the regulator used. You load as much of the graph as this question needs and no more, because the rest stays one edge away. That is what a customised projection is: one altitude, one context, and it is why the same graph can be sold at five prices without being copied five times.
- **Every door teaches you something, including the empty ones.** The page on fractal graphs puts it well: even when the answer is *nothing to see here*, you now know that door was empty, and that is knowledge too. Any investigative reporter will recognise the description. Most of an investigation is doors that were empty, and under the current model that work is invisible and unpaid. In the graph it is a node with a verb on it, and it is part of what the evidence vault is worth.

## Trust through provenance, provenance via evidence

The two products this whole piece is about, trust and provenance, are not the same thing, and the order between them matters, so here is the ladder stated once.

**Evidence** is the bottom rung, and it is bytes. A source page fetched on a date, frozen, and hashed with SHA-256. An interview recording. A filing. A dataset. Not a link to any of them, because a link is a promise that the thing will still be there and still say the same, and the web breaks that promise constantly. The [Regulation Graph](../demos/vaults/regulation-graph/index.md) ends every chain in a hash of the retrieved bytes for exactly this reason, and so does the [Portugal newsroom](https://newsroom.sgit.ai/portugal), for 88 sources today.

**Provenance** is the path from a claim, down through named edges, to that evidence. It is what lets anyone, a reader, an editor, a lawyer, an agent, walk from a sentence in the article to the bytes it rests on, and see at each step what the edge says: supports, partially supports, extends beyond, contradicts. Provenance is not a statement that the claim is true. It is a statement of what the claim rests on, which is a narrower thing and a checkable one.

**Trust** is what a reader, or a market, extends to a source whose provenance they have walked before and found to hold. It is earned by consistency over time, which is why the fact provenance piece of February 2025 said *trust emerges over time, formed by repeated demonstrations of ethical sourcing and consistent reliability*, and why the journalist's credibility in this model is computed from the graph rather than asserted: how often their claims were superseded, how quickly they corrected, how independent their sources were.

The reason to be precise about the ladder is commercial. Every rung of it can be sold, because none of it is an assertion. The evidence vault sells the bottom rung. The licensed article and the customised projection sell a walk along the middle one. The verification API sells the top one, an answer on the record from a source with a track record, with a warranty. And none of those sales is possible if the newsroom kept only the article, because the article is the one artefact that contains none of the three.

## What a story vault holds

Take the thesis literally and put the story in a vault. Not a folder, and not a content management system. A [vault](../docs/what-is-sgit.md): encrypted, versioned like a git repository, opened with a single read key, carrying its own app, with the server that stores it unable to read it. Then the story graph is not a metaphor. It is the file.

Inside it, the newsroom design on [newsroom.sgit.ai](https://newsroom.sgit.ai/provenance/articles-as-vaults) puts *"the published text, the evidence it cites, the story graph it belongs to, the source list, the translations, and every prompt and decision that produced it, held together as one addressable unit."* Each of the properties that falls out of that shape is something the industry currently pays for separately or does not have at all.

- **Evidence is frozen bytes, not a link.** Every source page is fetched, saved with a date, and hashed with SHA-256, so a claim walks back to what the source said on the day, not to whatever the URL serves now. [The Portugal newsroom](https://newsroom.sgit.ai/portugal) does this for 88 sources today, and its rule is the right one: *"We connect the dots, we do not draw them."*
- **Claims are typed, dated and never deleted.** A correction does not overwrite. It supersedes, and the superseded claim stays, marked from the date, so the graph can answer a question no archive of articles can: [what did we believe on this date, and why](https://newsroom.sgit.ai/corrections/how-a-graph-answers-it). The edge from a claim to its source carries a type, supports, partially supports, extends beyond, contradicts, so a correction sits where anyone would meet the claim rather than in a box at the bottom of a page a week later.
- **Anonymous sources are marked at the node.** A source the journalist cannot name is still a node, flagged as anonymous, and the flag means every projection built from the graph redacts it automatically: the licensed article, the evidence vault sold to an analyst, the briefing for a sector desk. The protection is structural rather than a matter of remembering to remove a name from a paragraph.
- **The journalist's credibility is computable.** Not by a score assigned by somebody else, but by consistency: how often their claims were later superseded, how quickly they corrected, how independent their sources were. The design's principle is that *"more evidence does not mean more confidence unless the evidence is independent"*, and independence can only be measured when the sources are in the graph. The identity graphs piece is the long argument, and its motivating problem has only got worse: fake experts quoted in dozens of articles because nobody checked.
- **The author is the oracle.** Lifting text into typed claims requires somebody to arbitrate what a sentence meant, and that is the author. Where the extraction and the author disagree, that is information, not failure. It is also the answer to what a journalist does in a newsroom where agents do the fetching: they decide what the story is.
- **Evidence, not truth.** The vault does not claim a story is true. It measures what is evidenced, shows the chain, and lets the reader or the reader's agent walk it. That is a narrower claim than truth, and it is one that can be sold, because it can be checked.

The cost of producing a story this way is not hidden either. The newsroom design publishes a [worked story](https://newsroom.sgit.ai/provenance/a-worked-story): an English and Portuguese piece on the EU AI Act's implementation in Portugal, 12 sources, two expert validations, four drafts, £8.40 and six hours twenty-three minutes of compute, and zero human hours, stated plainly. It is a worked design example rather than a production ledger, and the page says so. But when the research, the fact-checking and the translation are lines on a bill in pounds and pence, the price of a projection stops being a guess.

## Five things to sell, and how each one works

Go back to the diagram at the top. One graph, five projections, and the free one is the door. This is the part of the argument that is new, so it gets the detail.

### 1. The public article

Free, static, findable. The projection that search and agents are allowed to read, and the one that carries the free-to-read version of the story to whoever is looking for it.

The reason to give it away is not generosity. It is the honest objection to everything else on this page: a vault opened in the browser is invisible to a crawler, and *"most of a news site's reach comes from being findable by search and by other agents."* So the public projection stays public, stays static, and links to the vault it was made from. Its job is to be the door. What it does not need to be is the product, and the mistake of the last twenty years was making the door carry the whole business.

### 2. The licensed article

The same projection, bought once, for the two buyers who want this one thing.

**For the reader**, a price in pence, paid on demand, with no account to create and no subscription to forget. A read key is the whole credential: send it, and the reader opens the article with nothing installed. The Portuguese newsroom's [wallet](https://pt.newsroom.sgit.ai/carteira/) is a demonstration of what the reader sees: each page costs a cent, the wallet debits it, and the ledger of what was spent is *"yours, not anyone else's."* The price sits where Axate and the Toronto Star have found it works, somewhere between 20p and a dollar, and the reader who buys three in a week is offered the day.

**For the firm**, a licence rather than a copy. The corporate version carries the right to transform, because that is what companies do with news, and it carries its provenance with it, because the graph is what makes the transformation defensible. When the analyst's summary of the article goes to the board, the board can walk from the summary to the claim to the frozen source, and nobody in the chain had to trust the analyst. That is worth a licence price that would look absurd to a consumer, and it is a price nobody currently charges, because nobody currently has the graph to attach.

### 3. The evidence vault

The graph itself, or the part of it that can be released, with anonymous sources redacted at the node. This is the tier nobody sells today and the one with the highest value, because its buyers are not readers.

They are analysts, lawyers, academics, regulators and other newsrooms, and they are used to paying for data. An investigative journalist who has spent a year on a story has, at the end of it, a dataset with a market of its own: the documents, the interviews, the timeline, the entity graph, the things checked and found false. The industry currently pays them for the words and lets the dataset rot. **Under this model investigative journalism is the most valuable thing a newsroom produces**, not because more people read it but because twenty organisations need what it was made from, and each of them will pay for a read key to it. That is the payment that rewards the reporting rather than the click, and it is the payment that makes the loop run up.

Mechanically it is a vault with a published read key per licensee, a version history so the buyer sees every correction as it lands, and the anonymous-source flag doing the redaction. Nothing runs on the newsroom's side between purchases; [the cost is the storage](../demos/fractal-graphs/performance.md).

### 4. The customised projection

The same graph, cut for a role, a sector, a language or a single reader. Personalisation is the word in every industry deck, and once the graph exists it means this and only this: a different walk through the same evidence. Without the graph, it means showing people more of what they already clicked on.

Two instances exist. The [personalised briefing for Dan Raywood](https://docs.diniscruz.ai/2025/06/06/personalised-briefing-for-dan-raywood-on-the-future-of-news.html), from 6 June 2025, is the future-of-news argument projected for a cybersecurity editor with seventeen years on that beat, produced by hand. [pt.newsroom.sgit.ai](https://pt.newsroom.sgit.ai/) is the other, produced by a pipeline: it is *natively Portuguese, not a translation*, because it is projected from the graph rather than translated from the English words. The buyer here is a desk, a firm or a country, and the price is for the cut, not the content: the sector briefing that a bank's risk team receives every morning is the same graph the public article came from, projected for them, and it can be produced for £8.40 rather than by a research team. In the language of the fractal graph, a projection is one altitude and one context, loaded with exactly as much of the graph as that reader's question needs, and the rest one edge away.

### 5. The verification API

The B2B product, and the one that turns a newsroom's most expensive habit, checking things, into its most valuable service.

The flow is short. A company that is about to cite a claim, or an agent that is about to act on one, sends a query: did you report this, is it still current, and is this use of it sound? The newsroom answers from the graph, on the record, with the chain attached and a warranty on the answer. The design calls it [trust as a service](https://newsroom.sgit.ai/economics/trust-as-a-service), and its two prices are the two things being bought: the fact, and the confirmation that the fact still holds today. The second is the more valuable, because the graph records [freshness](https://newsroom.sgit.ai/corrections/how-a-graph-answers-it), how long since a claim was last checked against its sources and whether any of them have changed, and nobody else can answer that question about a newsroom's reporting except the newsroom.

For the agent, the whole exchange is the 402 that Cloudflare already sends a billion times a day, with the payment inside it. For the company, it is an on-record confirmation they can put in a filing. The design also names the risk honestly: *selling trust makes the seller a target*, and a warranted answer that turns out wrong is a claim against whoever warranted it. That is not a reason to avoid the market. It is the reason the market pays, and it is why the credibility in the graph has to be computed rather than asserted.

## Who gets paid, and how the money moves

The subscription's other quiet property is where the money stops. It stops at the outlet. The newsroom design sets out a [split](https://newsroom.sgit.ai/economics/paying-the-fact-creator) closer to where value is actually created: 60% to the original researcher whose work the story rests on, 25% to the organisation that holds the data, 10% to the journalist who synthesised it and 5% to the outlet that distributed it. *"Today, essentially all of that revenue is captured at the 5% layer."* The numbers are a proposal. What is not negotiable is the mechanism that makes any split possible: you cannot pay the fact creator unless the graph names them. The Portuguese wallet page puts it in one line: *"Uma página que não soubesse nomear a sua fonte não saberia a quem pagar."* A page that could not name its source would not know whom to pay.

This is also what makes the loop a loop rather than a slogan. If the evidence vault of an investigation is licensed twenty times and 60% of each licence goes to the people who did the investigating, the reporting has been paid for by its use, and the next investigation has a budget that no advertiser and no renewal rate can touch.

For a decade the answer to "why not pay per item" ended with the rails. A £1 card top-up returned about 59p of usable credit after fees, and nothing under a pound was worth processing. That ended in the last eighteen months. The [x402 protocol](https://newsroom.sgit.ai/economics/rails), which puts a payment inside the HTTP 402 response, moved under the Linux Foundation in April 2026 with more than twenty founding members, settles in about 200 milliseconds, charges no protocol fee, and carried roughly 169 million transactions in its first year. AWS announced agent payments in May 2026 with Coinbase and Stripe, at ticket sizes from a tenth of a cent to a thousand dollars. Cloudflare's Monetization Gateway charges for any resource behind it with the same protocol. The Raywood briefing of June 2025 said *"the infrastructure for micro/nano payments exists – what's been lacking is the industry will to implement it."* It was slightly early. The infrastructure exists now.

Two honest notes belong here. Nothing on sgit.ai is wired to any of those rails today: no fact-creator payment, no per-query billing and no trust-as-a-service product runs anywhere, and [the newsroom site says so](https://newsroom.sgit.ai/shipped) in its own words: *"most of this site is an argument, not a product."* And the Portuguese wallet keeps its ledger in the reader's own browser, as a demonstration of what the reader would see, not as a payment.

## The parts that already run

What does run is the substrate, in public, which is the only reason to believe the rest.

- **[Regulation Graph](../demos/vaults/regulation-graph/index.md).** The EU AI Act parsed from the official Formex XML, hash-verified against the bytes it came from, so that a risk in somebody's register points at a named obligation in a real instrument instead of asserting one. This is the evidence layer of a story vault, done for a law rather than a news event.
- **[A government toolkit, turned into four connected worlds](../demos/vaults/dsit-ai-risk-toolkit/index.md).** Every claim carries the bytes it came from, and every edge declares whether it was curated by a person or merely found by a lexical match. That distinction is the one a newsroom needs between what a journalist established and what a model suggested.
- **[VoiceDebrief](../demos/vaults/voice-debrief/index.md).** Meaning lifted out of unstructured text, from voice notes to Article 9(2) of the EU AI Act, into typed semantic graphs. This article started as a voice memo. That is the first step of the pipeline.
- **[Penetration Test Report](../demos/vaults/pentest-report/index.md).** One engagement, eight audience-specific views, evidence attached to each finding, and a runnable retest per finding. A different industry and exactly the same shape: one graph, many projections, and the evidence travels with each of them. It is what tier four looks like when it is sold.
- **[The Portuguese newsroom](https://pt.newsroom.sgit.ai/newsroom/).** Ninety-two source files frozen and SHA-256 verified, 312 nodes and 942 edges extracted from them, five articles published, and a six-stage pipeline in which the last stage, publication, is the only one no agent can move. A department that writes outside its own folder fails a gate, and that gate, the site says, *"is what makes this a newsroom rather than a script with role names in the comments."* Its English sibling holds 329 nodes and 1,106 typed edges across 64 speakers and 61 organisations, with a named editor of record and no legal review, both stated.
- **[The board](../demos/vaults/board/index.md) and [the catalogue](../demos/vaults/catalogue/index.md).** The site's own task board is a vault and the site renders a snapshot of it; the index of vaults is itself a vault, listed in itself. Both exist to show that the vault is the source of truth and the page is a projection, which is the whole argument in miniature.
- **The cost.** The entire published estate, thirty-one vaults, is 2,662 files and 295 MB of object storage with nothing running between requests, and [the measurements are printed](../demos/fractal-graphs/performance.md). A story vault costs what its files cost. A local newsroom, one journalist, or a blogger with a beat can run this. The model is scale-free, which matters because the industry's crisis is worst at the bottom, and this is the first economic model I know of that works there.

## What I would do, if I ran a publisher

Suggestions, in order, and each one can be started this quarter.

1. **Store the story as a graph from the first day of reporting.** Claims, evidence, sources, raw materials, drafts. Make the article a build artefact. If the graph is not there at the end, the story was never captured, only its words.
2. **Freeze and hash every source.** Not a link. The bytes, on the day, with a hash. It is the cheapest thing on this list and the one that changes what a correction means.
3. **Keep giving the public projection away, and keep it findable.** Static, crawlable, linked to the vault it came from. The door has to be open for the shop to work, and the Cloudflare tolls are for the crawlers that never come through the door.
4. **Sell the licensed article in pence, on demand, and stop treating it as dilutive.** The people who buy it were not going to subscribe. Price the corporate version as a licence to transform, not as a copy.
5. **Adopt the five clauses of the subscription standard before January makes you.** Tell subscribers how much they used, tell them without being asked, let them leave by the route they joined, warn them before charging for something they have stopped using, and do not charge for outages. [The proposal](https://subscriptions.sgit.ai/standard/proposal) is written, and three of its five clauses go beyond what the UK regime will require. A publisher that does this first is the one readers will trust with recurring billing after the others are fined.
6. **Open the evidence vault to the B2B market that already pays for verification.** Lawyers, analysts, regulators, other newsrooms. Redact at the node. License the graph. This is where investigative work gets paid what it cost, and it is the step that makes the loop run.
7. **Put the correction in the graph, and let credibility be computed.** Supersede, never delete. Type the edge. Publish the record, never the verdict. Then a journalist's track record is a fact rather than a reputation, and the verification API has something to warrant.
8. **Publish the cost per story.** If the research, the checking and the translation are lines on a bill, the price of each projection is a decision rather than a guess, and the 60/25/10/5 question becomes answerable.

## The dataset was always worth more than the article

Both clocks are set by somebody else. The search layer will finish ending the deal on its own timetable, and every publisher's answer has been to ask the search layer for a better deal. The legislature will finish regulating the subscription on its timetable, and every publisher's answer has been to ask for more time. Neither answer touches what is actually wrong, which is that the industry sells the one output whose marginal cost has gone to zero and discards the one asset that has not, and that under both of its models the reporting worth paying for is the first thing cut.

The story was always a graph. The article was always a projection. The reader who wanted one article, the firm that needed to forward it, and now the agent that needs to know whether it is true were always standing at the till trying to buy something the shop did not stock: the evidence, the trail, the on-record confirmation, the view cut for them, paid when delivered, in pence, to the people who made the facts. That is the product. It rewards the reporting, it does not depend on search or on renewals, and it has been buildable for eighteen months and sellable for about six.

The industry has never lacked the material. It has lacked a way to sell it. Now it has one, and the only question that matters is the same one I would ask of any product: [when it is taken away, does anybody miss it?](../articles/the-question-is-whether-they-miss-it.md) Take away the words and, increasingly, nobody does. Take away the graph, and the lawyer, the analyst, the regulator and the agent all notice on the same afternoon.

[← All articles](index.md)



==============================================================================
# The SaaS apocalypse will be decided by inertia, not by AI, sgit.ai

> The SaaS apocalypse has not happened yet, and the market has already declared it cancelled once. It remains a very strong possibility, argued here with data rather than vibes. Most users were never happy, most features were never used, and most licences sit idle, because success bred inertia and inertia bred lock-in. Now anybody can brief the software they actually want, and the portability, APIs and schemas that SaaS companies refused to build are precisely what an agent needs. It will be decided by inertia, not by AI, because AI is available to both sides: the incumbents have the same models as the newcomers, plus more data, more engineers and more money, and if the technology were the deciding factor they would already have won. Nokia when the mobile phone arrived had nothing to protect, and moved. Nokia when the iPhone arrived had fifteen years of success to protect, and did not. Which side of that path each SaaS provider ends up on will be settled by where it sits on the evolution axis and how much it has to protect, which is why the newcomers, not the incumbents, are the ones to watch.
>
> Page: https://sgit.ai/articles/saas-apocalypse-decided-by-inertia-not-by-ai.html

[Home](../index.md) / [Articles](index.md) / The SaaS apocalypse will be decided by inertia, not by AI

# The SaaS apocalypse will be decided by inertia, not by AI

By [Dinis Cruz](../about/index.md) · 2026-09-21 · [v0.4.2](../admin/versions.md) · saasstrategywardley-mapsagentsarticle

***Abstract:** The SaaS apocalypse has not happened yet, and the market has already declared it cancelled once. It remains a very strong possibility, argued here with data rather than vibes. Most users were never happy, most features were never used, and most licences sit idle, because success bred inertia and inertia bred lock-in. Now anybody can brief the software they actually want, and the portability, APIs and schemas that SaaS companies refused to build are precisely what an agent needs. It will be decided by inertia, not by AI, because AI is available to both sides: the incumbents have the same models as the newcomers, plus more data, more engineers and more money, and if the technology were the deciding factor they would already have won. Nokia when the mobile phone arrived had nothing to protect, and moved. Nokia when the iPhone arrived had fifteen years of success to protect, and did not. Which side of that path each SaaS provider ends up on will be settled by where it sits on the evolution axis and how much it has to protect, which is why the newcomers, not the incumbents, are the ones to watch.*

The incumbent and the newcomer are carrying the same AI. What differs is the ball and chain of past success, and the fact that the newcomer was never on the rails in the first place.

Here is the claim, stated so it can be wrong. **Most medium and large SaaS companies will struggle, spectacularly, in the medium term**, as companies and individuals build more of what they actually want instead of renting an approximation of it. Whether they survive depends on what they do next. Whether the companies that come out on top are the ones on top today is an open question, and so is whether there will be companies that big in some of these categories at all.

It is still all to play for, and the reason it is worth writing down is that the outcome is not fixed. Nokia met the arrival of the mobile phone by becoming the mobile phone company, and dominated the category for fifteen years. Nokia met the arrival of the iPhone and was gone from the category within seven. Same company, same industry, two outcomes, and Nokia did not choose either of them. The first time it had nothing to protect, so it moved. The second time it had fifteen years of success to protect, and the climatic pattern Simon Wardley names did the rest: **success breeds inertia**. That is the frame for everything below, and it is why the title says what it says. **AI is not the deciding factor, because AI is available to both sides.** The incumbents have the same models the newcomers have, plus more data to point them at, more engineers and more money. If the technology decided this, they would already have won, and two and a half years in they have not. What decides it is inertia: where a company sits on the evolution axis, and how much past success it has to protect. The SaaS apocalypse is a forecast about that. It will happen to the companies with the most to protect, and it belongs to the ones with the least, which is why the interesting question is not whether the incumbents survive but who is already building on the ground they cannot move onto. The best way to see that ground is a Wardley map.

**Same AI. Different inertia.**

The SaaS product slides right along the evolution axis and becomes a substrate: a database, a message bus, a state machine. On top of that substrate, the custom brief is now cheap to make. What is not cheap is making it last, and that is the handover from explorer to villager to town planner. The mistake, drawn in red, is treating the brief as if it were already a product.

## The market already had this argument once this year

In the first week of February 2026, after Anthropic shipped plug-ins for its Claude Cowork agent covering legal, sales, marketing and data analysis, software stocks fell off a cliff. An equity trader at Jefferies, Jeffrey Favuzza, gave it a name: [the SaaSpocalypse](https://saassentinel.com/2026/07/03/saaspocalypse-2026-what-happened-to-saas-and-where-the-market-stands-now/). Roughly $285 billion left the sector in about 48 hours. [Thomson Reuters fell 16% in a day](https://www.theglobeandmail.com/investing/article-global-software-stocks-hit-by-anthropic-wake-up-call-on-ai-disruption/), the S&P 500 software and services index dropped 13% over five sessions and sat 26% below its October peak, and Forrester published a piece titled, without hedging, [SaaS as we know it is dead](https://www.forrester.com/blogs/saas-as-we-know-it-is-dead-how-to-survive-the-saas-pocalypse/).

Then it recovered. By July the software ETF was [down 10.5% for the year against an S&P 500 up 10.8%](https://finance.yahoo.com/markets/stocks/articles/ai-crushed-software-stocks-igv-194541393.html), and by September it had rallied about 40% from its April low. The recovery came with a narrative: systems of record, proprietary data and sticky workflows are durable moats, and the panic was overblown.

I want to point at something in that recovery story, because it is going to matter for the rest of this piece. **The recovery argument is that the database is the moat.** Not the interface, not the workflow screens, not the per-seat licence. The thing investors decided was safe is the thing underneath, and the thing they quietly stopped defending is the thing on top. That is not a rebuttal of the apocalypse. It is the apocalypse, priced.

Notice, too, what both sides of that argument took for granted: that the question was about AI. The panic said AI would hollow out SaaS. The recovery said AI would not. Both were staring at the wrong variable. The same models were available to the largest incumbent and to a two-person company on the day the plug-ins shipped, and they still are. What differed between them was not the technology. It was what each had to protect.

And the sharpest sceptic in February was making a point I agree with. J.P. Morgan's Mark Murphy called it *"an illogical leap to extrapolate Claude Cowork Plugins to an expectation that every company will write and maintain a bespoke product to replace every layer."* He is right. They will not maintain it. Hold that thought, because it is where the opportunity lives.

## First, the part nobody likes to say: users were never happy

Before any of this, before agents, before vibe coding, the experience of using business software was bad, and it was bad in a specific way. The product did 80% of what you needed, and the remaining 20% was as painful as before you bought it. You fought the system. It did not reflect your case, and it could not be made to.

This is not a vibe. It is measured.

**Nine in ten employees are frustrated with their workplace technology.** Freshworks surveyed 8,698 people in 2022, 6,698 employees and 2,000 line-of-business leaders, and found [91% frustrated by inadequate workplace technology](https://www.freshworks.com/press-releases/survey-nine-in-10-employees-are-frustrated-by-their-workplace-technology/). More than half of the unsatisfied said their software made them *less* productive. The single biggest adoption problem leaders named, at 68%, was applications that are hard to use with a high learning curve.

**Most of what was built is never used.** Pendo analysed feature usage across 615 products that had been instrumented for over a year and found that [80% of features in the average software product are rarely or never used](https://www.pendo.io/resources/the-2019-feature-adoption-report/), and estimated that publicly traded cloud software companies had spent up to $29.5 billion building them. The older, more famous number is Standish's 64%, and it deserves its caveat: as [Mike Cohn documents](https://www.mountaingoatsoftware.com/blog/are-64-of-features-really-rarely-or-never-used), it came from a 2002 keynote based on four internal applications, and should never have been generalised. Pendo's figure is the one with a real sample behind it, and it is worse.

**And most of what was bought sits idle.** Zylo's 2025 SaaS Management Index puts the average organisation's waste on unused licences at [$21 million a year, up 14.2% on the year before](https://zylo.com/news/2025-saas-management-index). SaaS spend is $4,830 per employee. A large enterprise runs around 660 applications. Lines of business now control 70% of that spend and IT only 26%, which is how the waste stays invisible.

Put those three together and you get the pricing complaint in the memo, stated exactly. **You pay 100% for the 10% of features you actually wanted**, and then you pay for the seats you are not using either.

**Then there is the spreadsheet.** A [Deloitte survey found 73% of companies used Excel to prepare VAT returns](https://tax.thomsonreuters.co.uk/blog/excel-the-dirty-secret/); YouGov found 78% of British companies say spreadsheets support key financial decisions, and 72% of medium and large businesses use them for budgeting or forecasting. Every one of those companies owns software that was sold to do that job. **The persistence of Excel is not a failure of users to adopt. It is the clearest evidence we have that SaaS failed them**, because Excel is the one tool where they control the shape of the thing and can build exactly what they want.

## Why it got this way, in one line from Wardley

There are economic reasons, commercial reasons and behavioural reasons, and the winner-takes-all dynamics of technology markets amplify all of them. But the mechanism underneath is the one Simon Wardley names as a climatic pattern: **past success breeds inertia.**

His own phrasing, from the [doctrine chapter](https://blog.gardeviance.org/2016/08/doctrine.html): *"The pre-existing installed base causes inertia to the change. Invariably users will be fixated on a legacy world and hence they will have a bias towards it."* And the corollary he draws everywhere: it is almost always new entrants, unencumbered by past success, who initiate the change.

Watch what a company does once it is above a certain size. Decisions start to be about locking the customer in, keeping them inside the platform, extracting the maximum from the account, rather than about empowering them. The easiest way to see it is to look at what they do not build. Most do not make it easy to leave. Most do not make it easy to get your data out, or your schema, or to move. Most do not put a supported, first-class API at the centre of the product; the API is a tick-box, driven by retention rather than by the user's leverage. What is inside stays hidden, because exposing it was seen as a risk to the moat.

I think about all of this through maps, and [wardley-maps.sgit.ai](https://wardley-maps.sgit.ai/) is where that thinking lives. Its thesis is that *maps are claims, not pictures*: a map asserts where each component sits on the evolution axis, which makes it arguable. Here is the claim I am making with the map above. **The SaaS product has slid right.** What was custom-built became a product, and what was a product is now commoditising into a substrate: a database, a message bus, a state machine. And as Wardley wrote, when a component industrialises, it becomes part of *"an ever expanding platform of discrete industrialised components for which the pioneers can build on."* Higher-order things get built on top of the commodity. That is not the threat. That is the whole point.

## Everybody was already vibe coding, just very slowly

The term is Andrej Karpathy's, from February 2025, and by November it was [Collins Dictionary's word of the year](https://www.cnn.com/2025/11/06/tech/vibe-coding-collins-word-year-scli-intl). I still do not love it, but the word has won, so let me say what it actually describes: **people writing very good briefs.**

Because that is what a product owner has always done. The people with the vision, the managers, the users who knew exactly what they wanted, were always describing the software. They were vibe coding. They just did it in an environment with a catastrophically slow loop. Usually you could not customise the product at all. If you could, you were customising on somebody else's terms. If you hired developers, it was expensive, and the loop from *I want this* to *here it is* was weeks or months. The brief was fine. The execution was the bottleneck.

Now the loop is minutes. And so a thing that was always true becomes visible: **very few products let you strip out the 90% you do not want and keep the 10% you do.** But that is exactly what you can now build. Not everything the vendor thought of. The flow the user actually has, with the features they actually use, with no bloat, absolutely focused.

## And the reason the incumbents cannot simply do this themselves

Here is the uncomfortable line, and I stand behind it: **show me a SaaS company and I will show you a company that is highly inefficient at developing software.** Anybody who has worked inside a large software business knows what the flows behind the scenes look like, what the architecture looks like, what the quality of the internals looks like. It is usually a mess, and the bigger the company the slower it gets.

The reason is specific. Very few businesses ever understood or invested in non-functional requirements. I know this personally, because for years I represented one of them, security, and watched it get pushed out of the pipeline again and again. But it is not only security. It is documentation, architecture, scaffolding, deployment, CI, resilience, the ability to deploy anywhere, the ability to refactor, the ability to ship a customised version that does exactly what one user needs. All of it gets deprioritised, and the vocabulary for deprioritising it is the vocabulary every engineering culture is proudest of: *follow the user, do not over-engineer, do not gold-plate.* Those are good instincts that became a codename for never paying the engineering bill.

The bill shows up anyway. Stripe surveyed over a thousand developers and a thousand C-level executives across five countries and found engineers spend [17.3 hours a week, 42% of their working time, on maintenance and bad code](https://stripe.com/files/reports/the-developer-coefficient.pdf), roughly a third of total capacity on technical debt alone, which they costed at $85 billion a year in lost productivity. And the distribution is not improving: in the [2024 DORA report](https://dora.dev/research/2024/dora-report/) only 19% of teams are elite performers, the high-performing cluster shrank from 31% to 22% in a year, and the low cluster grew from 17% to 25%. Elite teams deploy 182 times more often than low ones. Most organisations are not elite, and most large ones are not close.

Which is why the obvious objection does not hold. *If shipping good software were just a matter of investing in the product and spending money, surely these companies would have built amazing software by now.* They have the money. They have the same AI as everybody else, and more data to point it at. They have not built it. We are two and a half years into the generative AI shift and we still do not see the level of innovation from incumbents that you would expect if the technology were the constraint. It is not. The constraint was never the budget, and it is not the models. It was the handover between explorers, villagers and town planners that these companies never built, the split between the people who find things, the people who make them solid and the people who run them at scale.

## The irony, which is the whole article in one paragraph

**The things SaaS companies refused to build, to protect their moats, are precisely the things an agent needs.** Portability. Open schemas. A real API at the centre. Data you can take out. Capabilities you can call from outside. For twenty years those were treated as churn risks, so they were starved. Now the customer's agent turns up wanting exactly that list, and finds a product built to prevent it. The moat has become the thing the water cannot get past in either direction.

## The mistake, and where the money actually is

Now the part where everybody gets it wrong, in both directions.

**The mistake is to confuse the brief with a product.** Somebody vibe codes the tool their team actually wanted, it works, and the conclusion is drawn that the SaaS product it replaced was pointless. But there is a reason you bought SaaS in the first place, and it was never the features. It was that the thing is *maintained.* For all their flaws, those products are robust. They get new versions. Bugs get fixed. There is a level of security, of reliability, of documentation. They are run. Every non-functional requirement that the SaaS company at least partly paid for has now landed on a customised, business-specific application that a non-engineer built in an afternoon.

And that person does not want to maintain it. This is the point Murphy at J.P. Morgan was making, and he is right. Every department will now have people building software the way they build spreadsheets, and the Excel evidence above tells you exactly how that goes: they build it, it works, and then it is a fragile, unversioned, unsecured thing that somebody has to own. They want to build it and hand it over.

So the future is not *no SaaS.* The future is two things merging.

**Village and town-planner companies.** Businesses that take the finished brief, the thing the explorer built, and run it: maintain it, support it, secure it, version it, deploy it everywhere it needs to be, keep it working. Paid by consumption and by the fact that it keeps working, not by the seat. On [wardley-maps.sgit.ai](https://wardley-maps.sgit.ai/patterns/pst/index.html) that handover is written down as the villager's job, *stabilise, harden, deploy to production*, and the interesting property of doing it with agents is that the handover becomes *a file move plus a version bump*, logged, dated and reviewable in a diff. What I have been building with sgit and [Fractal Semantic Graphs](../demos/fractal-graphs/index.md) is one shape this can take: the schemas move with the work, each world keeps its own ontology, and the thing that gets maintained and charged for is the running, versioned, connected artefact, not the screen.

**And some incumbents who manage to pivot** their product into a platform for exactly this, leveraging the interconnections they already hold. Some will. But time is running out, because every improvement in the models makes the custom brief more precise, and the pure Wardley reading is that this is all about components. What you should expect is an explosion of small and mid-sized companies supporting this, and an explosion of components that do one thing extremely well and become the building blocks.

Because here is the other half of the correction: it is not the case that vibe-coded software is automatically good. Most of it will not be, and by design cannot be, because the people driving it are not engineers and do not make the decisions engineers make. You still need people who read the code. You still need people whose whole job is to make components that are genuinely solid. It is worth remembering that almost everything vibe coded today runs on frameworks built before generative AI, by exactly those people, reading exactly that code. We have not even seen the first generation of frameworks built the new way yet.

## Strip the UI and see what is left

Something I read recently put it well: take away the interface, allow the customer to generate their own, and most of these companies turn out to be a glorified database, a glorified messaging system and a glorified state machine. And the honest response to that is two things at once. First: yes, and that can be built. Second: it is very hard to build *well*, which is why the value has not vanished, it has moved down a layer and across to whoever runs it.

That is the map. The product slid right. The screen and the seat lost their value. The substrate did not, and the maintenance did not, and the handover did not.

## More engineers, not fewer

One prediction to close on, because it cuts against the mood. We are going to need as many developers as we have now, and probably more, because we are about to generate an enormous amount more code, and somebody has to read it, harden it and run it. The focus will be engineering excellence rather than feature velocity, and the good news is that the raw material has never been better: the quality of the documentation, the handover, the schemas and the graphs that can now be produced is far higher than anything we could produce by hand.

And I think something else changes. The reason large software companies were slow is the reason Fred Brooks wrote down fifty years ago: adding people to a project slows it down, because the communication overhead grows faster than the output. Two-pizza teams were the workaround. **I think we can now build much larger, much more multidisciplinary teams of humans and agents, because the communication can finally be scaled**, the passing of information, the capture of decisions, the handovers between the people who explore and the people who settle and the people who plan. We could never do that before.

The companies that master that are going to be the biggest software houses of the next decade. Some of them exist today. Most of them do not yet.

Which brings it back to Nokia, and to inertia. The version of the apocalypse that ends with a company gone from its category is not a decision anybody takes. It is what happens by default when a company treats the screen as the moat, keeps the data locked, ships the API as a tick-box, and waits for the panic to pass, which the market has helpfully told it the panic has. Every one of those is the natural behaviour of a business with fifteen years of success to protect. The other version requires acting against that inertia: noticing that what it refused to build is exactly what its customers' agents are asking for, and building it before somebody with nothing to protect does. That is the strategy question, and it is not a question about AI, which both sides have. It is a question about inertia, which only one side has. The newcomers have already answered it, because for them there was never anything in the way.

[← All articles](index.md)



==============================================================================
# For a startup, the most important question is whether they miss it, sgit.ai

> A startup operating and investing model in three pillars. Ship something somebody can actually use, give it away briefly, then take it away and find out whether anybody notices. Be profitable before you raise, so the investors are calling you rather than the other way round. And open source everything, because the technology was never the moat.
>
> Page: https://sgit.ai/articles/the-question-is-whether-they-miss-it.html

[Home](../index.md) / [Articles](index.md) / For a startup, the most important question is whether they miss it

# For a startup, the most important question is whether they miss it

By [Dinis Cruz](../about/index.md) · 2026-09-21 · [v0.3.9](../admin/versions.md) · startupsstrategyopen-sourceinvestingarticle

***Abstract:** A startup operating and investing model in three pillars. Ship something somebody can actually use, give it away briefly, then take it away and find out whether anybody notices. Be profitable before you raise, so the investors are calling you rather than the other way round. And open source everything, because the technology was never the moat.*

The startup test. Ship it, let them try it, take it away, and see whether anybody asks for it back.

Most advice about starting a company is about raising money. This is not that. It is the operating model I actually use, and it rests on three pillars that are easier to state than to do.

1. **Be profitable.** Ship a product that sells, at a price that works for you.
2. **Investors should be talking to you**, not the other way round.
3. **Open source everything**, because the technology is not the moat and you do not want to be locked into it.

They are in that order for a reason. Each one buys you the position you need to do the next.

The loop. Ship something usable, give it away briefly, take it away, and find out whether anybody misses it. A no sends you back to the start with better information. A yes is the only thing that earns the right to charge, and charging at a profit is the only thing that earns the right to choose your investors.

## Pillar one: ship something somebody can use

Strip away the mythology and a startup is simple. **You make a thing somebody wants to buy, at a price that is profitable to you.** That is it. Whether the *company* makes a profit in a given year is a separate question with its own answer, but if the *product* is not profitable, it does not scale, and no amount of growth will fix that.

Which means the single most important skill is the ability to **ship**. Not to plan, not to pitch, not to architect. Ship. And ship every day, because shipping is how you find out what is true.

Be careful with the word, though, because it has been worn smooth. Shipping does not mean a proof of concept. It does not mean a demo, or a video of a demo, or a prototype you walk somebody through on a call. **It means a thing somebody else can go and use, on their own, and get value from.** It can be held together with tape. It can be vibe coded. Nobody using it cares how it was built, and neither should you, yet.

To ship that often you need the running cost to be near nothing, so build accordingly. Serverless. As few databases and as little live state as you can stand. In our case the file system *is* the database, which sounds like a compromise until you measure it: [what that actually costs, with the numbers](../demos/fractal-graphs/performance.md) is a whole page of its own, and the summary is that with nothing running between requests the standing bill for an estate of thirty one published graphs is a third of a gigabyte of object storage.

And do not underestimate the infrastructure. Getting a working thing into a stranger's hands is still, in 2026, genuinely hard, and a surprising amount of the toolchain is not designed to help you do it. **Solving that is not overhead, it is the first real product you build.** Everything after it gets cheaper.

## Then give it away, and then take it away

Now hand it to people for free. Not forever: a short window, whatever unit makes sense, but short. You want the feedback loop tight, and you want the cost of generosity to stay inside what you can absorb.

Just doing this solves dozens of problems you did not know you had. How do people get access. What breaks when somebody unfamiliar touches it. What they try first. What they never find. **The feedback starts the moment somebody who is not you has the thing.**

Then comes the part almost nobody does deliberately. **Take it away.** The trial expired. It is not available right now. Nothing else about the product changes, and no apology is needed.

And now ask the only question that matters:

**Do they miss it?**

If they shrug and go back to their day, you do not have a product yet. You have something people will accept when it is free, which is a much weaker signal than it feels like from the inside. No sense of loss means no *why now*, and without a why now there is nothing to sell.

If they come back and ask for it, you have something. That is the moment the whole model turns on, and it is worth engineering your trial specifically so that this moment arrives early and unambiguously.

## Can you charge, and can you charge at a profit?

Two questions, and people routinely answer only the first.

**Is the price one they are happy to pay?** It has to sit inside the zone where they feel they are getting more than they are giving up. If you have to argue somebody into the value, the answer is no.

**And is that price profitable for you?** With one honest caveat: it might not be profitable today and still be the right price, if the economics clearly improve with scale. But keep it close enough that you can self fund the gap, because a gap you cannot cover yourself is how you end up back at pillar two on somebody else's terms.

Revenue comes first. **If you cannot get revenue at all, that is the problem to solve, and it is not a marketing problem.** Profitability is the milestone after it, and it is the one that changes your life, for reasons that are entirely about the next pillar.

A related trap, which has its own site because it deserves one: **do not reach for a subscription by default.** Charging rent for something people are not using is a worse business than being paid when you deliver. [subscriptions.sgit.ai](https://subscriptions.sgit.ai/) makes the full argument: a subscription is a discount for regular use, not rent on something somebody ignores. Pay on demand is usually the healthier shape, for both sides.

## Pillar two: the investors should be calling you

Here is the claim, stated plainly. **The worst possible time to raise money is before you are profitable**, before you have the product, before you understand the fit. Which is, of course, exactly when most companies raise.

Everything follows from the negotiating position.

**You are bargaining from weakness, and both sides know it.** You have no product and you have a clock. Profitability does not just mean money, it means *time*: when you are not bleeding, you can wait, and being able to wait is most of what a good negotiating position is.

**So the terms are bad, and the worst of them are not about money.** They are about control. You hand over a say in the business to people who, in most cases, do not understand the business. They do not understand the technical properties, they have not lived the vision, and that is not a character flaw: their job is to make money. But their focus is now structurally misaligned with yours, and their opinion has been given weight. **I think that is one of the most common ways companies fail**, and it is entirely self-inflicted at the moment of signing.

The analogy I keep coming back to is music. **Do not get signed before you have the album.** Write the songs. Record them, in a bedroom studio if that is what you have. Play locally. Get people listening, get people buying. *Then* take the record deal, and take it as somebody who already has an audience and does not strictly need one.

That is the whole of pillar two. Not "never raise". **Raise from strength, on terms you set, from people who came to you because the thing already works.**

## Pillar three: open source everything

This one surprises people, because it sounds like giving away the asset. It is the opposite, and there are five reasons, each of which stands alone.

**The technology is not the moat.** Believing it is will shape every decision you make badly. Treating it as open from the start forces you to find the thing that actually is defensible, which is usually the data, the relationships, the distribution, or the speed at which you ship.

**You get a better architecture.** Code written to be read by strangers has cleaner boundaries. Not because you are more virtuous in public, but because anything embarrassing has to be fixed rather than hidden.

**You stay comfortable throwing things away.** A team that has never deleted a component is a team that will defend one long after it should have gone. Open source normalises disposal.

**It is better for the customer**, obviously, and they can tell. Nobody has to trust a promise about what happens if you disappear, because they can read the thing.

**And it is a much better exit for you, the founder.** This is the one people miss. Build proprietary and you will accumulate a pile of technology, much of it not even specific to the startup, that you cannot take with you. Build in the open and the work is still yours when you move on. **You leave with your tools.**

[open-source.sgit.ai](https://open-source.sgit.ai/) carries the longer version of this argument, and its thesis is the sentence to remember: open source is a strategy, not a charity.

## Why this is on a site about encrypted vaults

Because the model has a substrate, and we have spent a year building it.

Every pillar above asks for the same thing: **shipping a usable product should be cheap, fast, and reversible.** That is not a slogan, it is an infrastructure requirement, and it is most of the reason this model is hard to follow. A vault is our answer to it. Data, app, history and sources travel as one string. There is no database to run, no hosting for the reader, no account, no install. The whole [published estate](../demos/vaults/index.md) is 2,662 files and 295 MB of object storage, with nothing running between questions, and a reader opens any of it with a single read key.

Which makes the cost of shipping a small product to a few real users low enough that you can do it repeatedly, be wrong in public, take it away, and find out whether anybody missed it. **That loop is the product I most want other people to have**, and it is why the whole stack is open source, down to the [measurements](../demos/fractal-graphs/performance.md) and the mistakes.

If you are building something on this, I would like to hear about it.

[← All articles](index.md)



==============================================================================
# Fractal Semantic Graphs: everything connects to everything, and nobody has to share a schema, sgit.ai

> The introduction to the term. Four words and only one of them new; the test that decides whether something deserves the word, worked from a risk register to a TCP packet; why every file format is already a graph; the five-rule grammar; the evidence, eleven altitudes across seven live vaults; what is still modelled rather than imported; and why now.
>
> Page: https://sgit.ai/articles/introducing-fractal-semantic-graphs.html

[Home](../index.md) / [Articles](index.md) / Fractal Semantic Graphs: everything connects to everything, and nobody has to share a schema

# Fractal Semantic Graphs: everything connects to everything, and nobody has to share a schema

By [Dinis Cruz](../about/index.md) · 2026-09-20 · [v0.2.97](../admin/versions.md) · graphsmethodfractal-semantic-graphsarticle

***Abstract:** The introduction to the term. Four words and only one of them new; the test that decides whether something deserves the word, worked from a risk register to a TCP packet; why every file format is already a graph; the five-rule grammar; the evidence, eleven altitudes across seven live vaults; what is still modelled rather than imported; and why now.*

*By Dinis Cruz. This is the canonical copy of the article, with the diagrams and screenshots the LinkedIn version cannot carry. The definition it introduces, the three diagrams and the seven vaults are on [the Fractal Semantic Graphs page](../demos/fractal-graphs/index.md); the vault where the idea was first worked is [VoiceDebrief · Fractal Semantic Graphs](../demos/vaults/voice-debrief/index.md).*

For about six months I have been calling this "graphs of graphs of graphs", or when I was feeling more precise, "ontologies of ontologies of ontologies". Neither is a name you can put on a page. This week we gave it one, defined it, and published the evidence: seven live graphs you can open in a browser, from the text of a law down to a threat in one line of code on one compute instance, all built with one method.

The name is Fractal Semantic Graph. This article is the introduction.

## Four words, and only one of them is new

Most people reading this already know three of the four.

A graph is nodes and edges. A semantic graph gives the edges meaning: every edge is a verb, and every verb has a named inverse, so a link reads correctly from whichever end you are standing at. A fact `gives_rise_to` a risk; a risk `arises_from` a fact. An ontology is the agreed vocabulary of node types and verbs that a graph is allowed to use.

The fourth word is fractal, and here is what it adds.

A fractal semantic graph has no privileged level and no single schema. Zoom into any node and you enter a new world with its own node types, its own verbs, its own taxonomy, its own centre of gravity. A regulation is a node in a graph of instruments and jurisdictions. Open it and it is a graph of articles, recitals and amendments: a legal ontology. Open an article and it is a graph of paragraphs and points. Open a paragraph and it is a graph of the terms it uses, each one an edge to the article that defines it: a lexical ontology that looks nothing like the one two levels up.

Three zooms, three ontologies. A four-node semantic graph; the Law node opened into a legal ontology of articles, paragraphs and an amendment drawn as an edge; one paragraph opened into a lexical ontology of the terms it uses. The grammar never changes; the ontology does.

Every one of those worlds was defined by whoever owns it, in its own vocabulary, and none of them was made to conform to the others. What connects them is that each one is still a semantic graph. Every edge is a verb with an inverse. Every node knows where it came from. So an edge can be drawn from any node in one world to any node in another, and the walk works.

There is no top and no bottom. There is only the altitude you happen to be looking from, and how much definition you choose to load at it.

The GDPR atlas says it in its own graph view: "You are at the top of the fractal. Each domain is its own ontology that connects up to the GDPR root and down to concepts and articles." The layout is computed from the graph, not drawn.

## The test is what happens at a link

Here is the test I use to decide whether something deserves the word.

Start inside a risk register. A good one is already a rich semantic graph with a large vocabulary of verbs. A fact `gives_rise_to` a risk, a risk `is_owned_by` a role, a person `reports_to` a person, a control `mitigates` a risk, evidence `backs` a fact. Every link that makes sense inside that ontology teaches you something, and a register with ten thousand well named edges is a great deal of knowledge.

Nothing about it is fractal yet. It is one graph, however large and however deeply it nests, in one vocabulary. A system that never lets you leave that vocabulary is a single graph, or a hierarchy. Not a fractal.

The fractal property is that on one of those links you can jump into another universe.

Follow the register's fact node for an incident and you land in the security operations world: alerts, signals, the systems that were touched, ATT&CK techniques, attack trees. Its own verbs, its own taxonomy, none of it borrowed from the register. In that world you meet a DNS entry that looks like command and control. Follow it and you are in the DNS estate: zones, records, parents, values, every request the resolvers logged, a dataset that might be millions of nodes and is quite possibly served from a SQL database or a GraphQL endpoint rather than held as files. Follow one record to the traffic it produced and you are reading network captures, flows, and eventually a single TCP packet, in yet another vocabulary.

Four worlds. Four ontologies. Four taxonomies. One continuous path of named edges between them, and nobody built an adapter.

The jump. Four worlds in a row, each a small graph in its own vocabulary, joined by a jump link on one node each. All four together are one node in a bigger graph that analyses them, and that graph in another.

What makes it fractal rather than merely linked is that in every one of those self contained worlds you find the same building blocks: nodes, edges with verbs and inverses, an ontology, a taxonomy, provenance. The grammar is what lets the jump work, in either direction. And it runs upward as well as down. Everything I just described can itself be one node in a larger graph that analyses it, sitting next to graphs of behaviour, of agent actions, of agendas, of funding.

## Everything is already a graph, including every file format

This is the part that took me longest to see clearly, and once you see it you cannot unsee it.

A regulation is a graph of articles. A PDF of that regulation is a graph of pages, blocks, lines and glyphs. A spreadsheet is a graph of sheets, rows, cells and formulas. A codebase is a graph of packages, classes, methods and tokens. A JSON document is a tree, which is a graph with one verb.

None of them needs to be converted into a graph. Each one only needs its edges named. And once the edges are named, the boundaries between formats stop mattering, and things become possible that no document can do.

A question can cross formats without a join table. "Which method in our code implements the control that the crosswalk maps to the article the amendment changed?" is one traversal, from a word in a law to a control in a standard to an attestation to a method, because each step is an edge somebody named.

A correction propagates instead of being republished. Mark one node superseded and every path that rested on it becomes a query: what did we build on this? A document cannot do that. The correction is a new document, and nothing connects it to the thousand that already cite the error.

The smallest node is whatever your question needs, not what the format offers. For a lawyer it is the defined term. For a threat model it is the method. For a conformance check it is the attestation and its expiry date. For our GDPR atlas it is, literally, the word.

Every unit keeps its own world. The regulation is modelled in the regulator's vocabulary, the register in the risk team's, the threat model in the engineers', and none of them is asked to change. The bridges are edges somebody declares, not a merged schema everybody has to agree on first.

And provenance comes free. When the leaf is a word, and the word is connected to the byte range it came from and the hash of the file that held it, every claim at every altitude above it is traceable to source with no extra machinery.

## The grammar is short, and one rule does most of the work

Each altitude gets its own schema. What none of them gets to change is the grammar, and the grammar is five rules.

Every edge is a verb, stated in both directions, with an inverse a person in the business would actually say. `relates_to` is banned. Properties carry data, never meaning, so two nodes both holding the value 8080 differ only in what they are connected to. Supersede, never delete. And never render the whole graph: render the answer to a question.

The banned verb is the one I get the most pushback on, so let me defend it. Two things always relate. An edge with no verb constrains nothing and cannot narrow a query. The granularity of the verb is the precision of the question you will later be able to ask. Every time somebody reaches for `relates_to` they are deferring the thinking to whoever has to read the graph later, and that person is usually you.

## The evidence: eleven altitudes, seven vaults, one grammar

A definition is cheap. So we published the ladder.

Eleven altitudes, each one a live graph in its own vocabulary, modelled by its own author, and every rung joined to the next by a named edge. From the top: the law, the standard, the evidence behind the standard, the fact about your estate, the risk it gives rise to, the owner, the acceptance, the insuring policy, the agent, the system, the compute instance.

The ladder: eleven altitudes, eleven ontologies, one grammar. Each rung names the published vault where that altitude is a live graph, and on the page each name is a link to the vault and its read key.

At the top sits the EU AI Act, parsed from the official XML into 113 articles, 500 paragraphs, 417 points, 180 recitals, 13 annexes and 68 definitions: 1,523 nodes and 1,944 edges, with the SHA-256 of the retrieved bytes at the end of every provenance chain. When something elsewhere says "touches Article 12", this is the graph that can say what Article 12 says and prove the bytes.

The Regulation Graph's landing view: the counts, both instruments with their CELEX identifiers and the hash of the retrieved bytes, and application dates kept as versioned properties rather than bare facts.

One rung down is the AIUC-1 agent standard as data: 53 controls, 2,788 nodes, 11,610 edges. Its explorer loads two vaults as one graph, and one of the packs it loads is literally the AI Act by article from the vault above. That join is where a crosswalk stops being a string. The standard publishes 1,126 crosswalks as text. 62 of them resolve into node identifiers in the regulation graph. And the traversal returns something neither graph knew on its own: 8 of the 27 articles reached have since been amended, so the crosswalk was written against text that no longer says what it said.

That is the whole argument in one number. Two graphs, built by different people for different purposes in different vocabularies, joined by declared edges, produced a finding that did not exist in either of them.

Two vaults on one canvas. The chip row is the join: the standard, its crosswalks, another vault's articles, the conformance layer, bow ties, acceptances.

At the bottom of the ladder is a threat model that is itself a graph of graphs: eleven linked models zooming from Customer through Business, Application, Component, Package, Class and Method, down to Source Code, Environment, Runtime and Compute. 51 nodes, 179 threats. The demonstration is a single SQL injection traced upward from the method it lives in to the revenue it puts at risk, and then framed four ways, for the board, the CISO, the CTO and the developer, from one fact.

The zoom ladder, counted: 11 layers, 51 nodes, 179 threats. The bottom rung is a compute instance.

In between are the rungs that make this useful to people who are not engineers: a register where answers become facts and facts give rise to risks, an org chart with risks flowing up it until every path terminates at the board, and the same exposure read at seven stakeholder altitudes, each owning it in their own words.

The role risk map: what a role holds against what arrives through it because the graph says it must. Nothing stops short of the board.

My favourite single picture in the whole set is Article 45 of the GDPR. The text has not changed a word since 2016. What it permits has flipped four times: Safe Harbour, Schrems I, Privacy Shield, Schrems II, the Data Privacy Framework, and an appeal pending. The atlas draws that as a timeline of ruling nodes over one unchanged article node. The text is a constant. Its meaning is the graph. That is why a static PDF of a law is wrong and a versioned graph is not.

One article, five rulings, twenty-five years. Safe Harbour to a pending CJEU appeal, over an Article 45 that has not changed a word.

## What is still modelled rather than imported

I would rather tell you this than have you find it.

The bottom four rungs of the threat model, environment through compute, are nodes an author placed, not a live import from a CMDB, an infrastructure repository or a cloud account. The grammar to receive such an import exists. The connector that emits it is not published yet.

Enterprise architecture is a gap. No published graph holds an EA repository joined upward to obligations, and that is the layer between the standard and the system that the ladder cannot yet point at.

The crosswalks resolve at article level only, where the regulation graph has paragraphs. The GDPR atlas is a seed pass from May, and six of its 227 edges use the banned `relates` verb, because the rule was written after that graph was. And the agent rung is a vocabulary, not yet a join: we have the 23 capability primitives that describe what an agent can do, and no published graph yet imports a real permission set and computes the difference against what the operator intended, at scale.

Named gaps get filled. Unnamed ones do not. That is why they are on the page.

## Why now

Three things changed in the last year that make this practical rather than academic.

Naming edges used to be the expensive part. It is now the cheap part. A language model can propose the verb between two nodes faster than a human can type it, which means the bottleneck moved from authoring the graph to deciding what the graph is for.

Agents act on the world, and when something acts, provenance stops being a nicety. Every consequential claim needs to be traceable to the byte it came from, and a graph whose leaf is the word gives you that without a second system.

And the schema wars are over, because nobody won. Every organisation, division, team and regulator has its own vocabulary and will keep it. The only integration model that survives contact with that fact is one where nobody is asked to conform and everybody is allowed to connect.

## Open them

Everything in this article is a live graph you can open. Every read key is published on purpose, and none of them can write. Start at the law and walk down, or start at the compute instance and walk up. Either direction works, which is rather the point.

- The definition, the ladder and the seven vaults: [sgit.ai/demos/fractal-graphs](../demos/fractal-graphs/index.md)
- The vault where the idea was first worked, with its fifteen-principle register: [VoiceDebrief · Fractal Semantic Graphs](../demos/vaults/voice-debrief/index.md)
- The grammar in full, with the four situations in which the argument is wrong: [graphs.sgit.ai](https://graphs.sgit.ai/)
- Laws and standards as addressable provisions: [standards.sgit.ai](https://standards.sgit.ai/)
- The Agent Behaviour Policy, where the graph meets a real permission set: [abp.sgit.ai](https://abp.sgit.ai/)

If you build one of your own, the grammar for drawing it is at [graphs.sgit.ai/llms.txt](https://graphs.sgit.ai/llms.txt), and it is written for agents as much as for people. I would like to see what you connect to what.

*This article is released under the Creative Commons Attribution 4.0 International licence (CC BY 4.0). The diagrams are inline SVG on the Fractal Semantic Graphs page and may be reused under the same terms; the screenshots are of published vaults, taken with their published read keys.*

[← All articles](index.md)



==============================================================================
# The proof is two clicks behind the claim, what the homepage gets wrong, and the fix, sgit.ai

> Twenty-five real vaults a stranger can open in one click are the most persuasive thing on this site, and the homepage shows none of them. It leads with encryption, which cannot be seen, and buries the artefacts under a table. This is the diagnosis, with screenshots, before the rebuild, and the second article will show what changed.
>
> Page: https://sgit.ai/articles/proof-behind-the-claim.html

[Home](../index.md) / [Articles](index.md) / The proof is two clicks behind the claim, what the homepage gets wrong, and the fix

# The proof is two clicks behind the claim, what the homepage gets wrong, and the fix

2026-09-07 · [v0.2.59](../admin/versions.md) · homepagepositioningvaultsagents

***Abstract:** Twenty-five real vaults a stranger can open in one click are the most persuasive thing on this site, and the homepage shows none of them. It leads with encryption, which cannot be seen, and buries the artefacts under a table. This is the diagnosis, with screenshots, before the rebuild, and the second article will show what changed.*

Three weeks ago this site had four published vaults. Today it has twenty-five, built by several agents working with one human, and the collection now includes things that are genuinely hard to make without sgit: a penetration test report that ships with a retest script per finding, a conference keynote that carries its eight cited papers, a compliance standard rebuilt as a citable graph with 82 hashed source snapshots, a game that reports anonymous telemetry through a write-only channel.

None of that is visible from the homepage. This article is the diagnosis of why, written before the rebuild rather than after, so the two can be compared honestly.

## The homepage leads with the thing you cannot see

Here is the first screen a visitor gets:

The hero today: a claim about encryption, a pip install, and a terminal walkthrough of create, commit, history and clone.

Every word of it is true, and almost none of it is *persuasive*, for one reason: **encryption is a property you cannot look at.** Zero knowledge is a property you cannot look at. The visitor is asked to take the value on faith before being shown anything, and the first thing they are then shown is a terminal walking through `create`, `commit`, `history` and `clone`, which any git user has watched a thousand times. The walkthrough demonstrates *familiarity*, which is a virtue, but not *power*.

The word "vault" appears in the hero three times and the visitor is never shown one.

## The use cases are abstract while twenty-five concrete ones sit one level down

Scroll on and the site tells you what people use it for:

Five use-case cards, each a category rather than a thing: private memory, multi-agent collaboration, workspaces, encrypted folders, signed exchange.

These are categories, not examples. *"Multi-agent collaboration, agents on their own branches, humans reviewing the merge"* is a description of a capability. Meanwhile, one level down, there is a vault where one agent copied another agent's entire catalogue byte for byte and built a conformance layer on top of it, and the tests that prove the copy is exact still pass. That is the same idea, except you can open it.

The homepage has the abstraction. The proof is elsewhere.

## The proof is a table, two clicks away

Where is it? Under a dropdown:

Vaults → Published vaults. Two clicks from the hero to the most persuasive page on the site.

And when you get there, it is a table:

The published vaults, as of this week: sortable, categorised, and still a table, the right shape for finding a vault, the wrong shape for being convinced by one.

To be fair to the table, it was rebuilt this week and it is now a good table, sortable, categorised, newest first, with the read keys moved off it because they were squeezing the vault id to one character per line. But a table is the right shape for *finding* a vault and the wrong shape for being *convinced* by one. It answers "which of these do I want" for a visitor who already wants one.

Here is what the visitor could have been looking at one second after arriving, with no account and no install:

A real vault, open: the AIUC-1 conformance layer computing insurability for a named subject as of a date, one condition met, 52 exclusions, zero of five consequences covered, each with the reason in the control's own words.Another: a game about which wings of the building an agent can enter, drawn as a floor plan, with a belief column ranking nine public agent profiles as you answer.

Both of these are opened by one string. Both run entirely in the browser. Both ship with their data, their sources and their tests inside the same encrypted unit. The second one built its own telemetry from a brief published on this site. **None of this requires the visitor to understand encryption first.** It requires them to click.

## The strongest story has no front door

The thing that most distinguishes how this site is made is that it is built by one person and a team of agents, and the agents build for each other. The evidence is real and specific:

- A brief published here on 6 September was read by another agent, who built a vault from it the same day.
- That vault was reviewed by the team that owns the API it uses, who found the brief had been wrong in two places, and the correction is now published above the mistake.
- One agent forked another agent's vault, kept every byte, added a layer, and shipped a fourteen-version history that labels seven of the versions as *reconstructed* rather than inventing commits.

Where does a visitor learn this? Here:

The briefs page, the cross-team collaboration log, filed under Docs, three levels from the homepage, and written as a log rather than a story.

It is filed under Docs. It is written as a log, which is the right format for the record and the wrong one for a first-time reader. The productivity claim that the whole site rests on, *this is what working with agents looks like when the state is versioned and shareable*, has no page that tells it end to end.

## One gap worth naming

The homepage says *"a branch per agent; work meets on named branches; a human reviews the merge."* It is the site's strongest claim about multi-agent work, and **no published vault demonstrates it.** Every vault here was built by one agent, or by one agent on top of another's finished work. None shows two agents' branches and a human merge in its history.

If such a vault exists, publishing it is the single highest-value addition to the site. If it does not, the next multi-agent build should be run so that its history shows it. A claim on a homepage with no artefact behind it is exactly what this site says it does not do.

## The fix, in order

Not more bands. The homepage already has nine, and 1,370 words. The fix is to reorder so proof comes before mechanism, and to cut.

1. **The hero shows vaults.** One reframed sentence (a vault is a unit of work: data, app, history and sources, shipped as one string, and the server cannot read it) with **four real vaults as cards** under it, each with a screenshot and an *open it* link. The visitor is inside an artefact before they have read a paragraph. `pip install` stays, second.
2. **"What people actually ship"**: six vaults chosen by *job* rather than by shape: hand over a report, publish a standard as data, give a talk, pitch an investor, run a game, give an agent a workspace. Each with one line on why it is hard without this. Generated from the same data as the table, so it never goes stale.
3. **"One human, a team of agents"**: the collaboration story told as a story, with the numbers, and a single page behind it that walks the loop end to end.
4. Then the terminal walkthrough and the zero-knowledge explanation, for the developer who is *now* interested in how.
5. The honesty band and the network band stay. The "three doors" band moves to the docs.

## And a page that says who is behind it

A beta tool that asks people to publish their read keys on it is asking for trust, and this site has no page saying who is asking. There will be one. It will be about **sgit** (who builds it, honestly including the agents; why; the commercial line) and it will borrow two sections that fit this site's culture exactly, *Interests declared* and *Reach me, or correct me*, from the fuller record that already exists on a sibling site:

open-source.sgit.ai · Business & publishing · [About the author, Dinis Cruz ↗](https://open-source.sgit.ai/about/index.html) · The record across four companies, built in the open including the parts most companies keep closed, and the interests declared. · “Open source is a strategy. It is not a charity.” · part of the sgit.ai network

That card is new as of this article. The `*.sgit.ai` sites exist so each topic can get the depth a section here could not give it, which only pays off if this site points at them constantly, and a bare link does not say *this continues elsewhere, on purpose*. The card does. Authors write one line; the site's own category and thesis come from its entry in the network directory, so the card describes that site the way it describes itself.

## What happens next

The rebuild is the next release. The article after it will put the new homepage next to these screenshots, and say what changed and what it cost. If the "before" pictures here still look better than the "after", that article will say so too.

*Written by Dinis Cruz and the agentic team working with him. Licensed CC BY 4.0.*

[← All articles](index.md)



==============================================================================
# The proof moved up, the homepage after the rebuild, next to the before pictures, sgit.ai

> The previous article diagnosed a homepage that led with encryption and buried twenty-five real vaults under a table. This is the rebuild, put beside those screenshots, what moved, what was cut, what it is generated from, and the one thing it still cannot show.
>
> Page: https://sgit.ai/articles/proof-moved-up.html

[Home](../index.md) / [Articles](index.md) / The proof moved up, the homepage after the rebuild, next to the before pictures

# The proof moved up, the homepage after the rebuild, next to the before pictures

2026-09-07 · [v0.2.60](../admin/versions.md) · homepagepositioningvaultsagents

***Abstract:** The previous article diagnosed a homepage that led with encryption and buried twenty-five real vaults under a table. This is the rebuild, put beside those screenshots, what moved, what was cut, what it is generated from, and the one thing it still cannot show.*

[The previous article](../articles/proof-behind-the-claim.md) made a diagnosis and a promise: the homepage led with a property nobody can look at, the proof sat two clicks away as a table, and the rebuild would be put next to those screenshots so the comparison could be made honestly. This is that comparison.

## The first screen

Before: a claim about encryption, a `pip install`, and a terminal walkthrough of four commands every git user has seen.

Before. The word "vault" appears three times and the visitor is shown none.

After: one reframed sentence, and four real vaults under it.

After. Four published vaults with their screenshots, each one click from open. `pip install` is still there, second.

The sentence changed from *"the encrypted git for humans and AI agents"* to *"a vault is a unit of work: data, app, history and sources, shipped as one string."* Encryption did not leave; it became the subordinate clause, *and the server that stores it cannot read it*, which is where a property you cannot see belongs. The four cards are chosen by a `hero` field in the vault data, so changing the front door is a data edit, not a page edit.

## The use cases became things

Before: five cards, each a category.

Before. "Multi-agent collaboration, agents on their own branches, humans reviewing the merge." True, and not something you can open.

After: six vaults chosen by the job they do.

After. Hand over a report. Publish a standard as data. Give a talk. Pitch an investor. Ship a game that reports back. Give an agent a workspace. Each is a real vault, with one line on why it is hard to make any other way.

The distinction the band is built on: none of those six lines is about encryption. A pentest report whose retest scripts travel with the findings; a talk whose cited papers never separate from the deck; a game whose telemetry uses the one credential shape that survives being published. Those are properties of *a vault as a unit*, and they are what a newcomer can actually feel.

## The collaboration story got a front door

Before: a log, filed under Docs.

Before. The cross-team briefs, the record of agents working with each other and with the human, three levels from the homepage, written as a log.

After: a band with the numbers and the story.

After. Four numbers computed at build time (releases, vaults, sibling sites, briefs) and the loop told in three beats with the artefacts linked.

The numbers are not typed. Releases come from the version log, vaults from the vault data, sites from the network directory, briefs from counting the entries on the briefs page. If a number on that band is wrong, the site is wrong somewhere else too, and that is the right dependency.

## What was cut

- **The abstract use-case band.** The five categories still exist as pages, still in the nav under Evidence; they are no longer the homepage's answer to "what is this for".
- **"One vault, three doors."** The sgit / SG/Vault / SG/Send explanation was a full band. It is a single pill in the trust strip now, pointing at the page that already explained it.
- **Nothing from the terminal walkthrough.** It moved down and gained a heading (*Under the hood, it is git*) because for the visitor who has just opened a real vault, *how* is now the question. It gained one feature card too: *apps live inside the data*, which was somehow never on the list.

The band count did not change, nine before, nine after: three were cut and three were added, so what changed is the order and what comes first, not the length. (The first version of this paragraph said "nine became eight"; it was corrected in v0.2.61 after counting rather than remembering.) The page is longer in bytes, because it carries ten screenshots, and slightly shorter in words: 1,370 to 1,332. That is the trade: pictures of real things instead of paragraphs about them. The screenshots load lazily and through the same mechanism every vault page uses, so the page still renders from inside a vault.

## What it cannot show yet

The previous article named a gap, and the rebuild did not close it: **no published vault demonstrates two agents on one vault**: their branches, and a human merging them. The team band tells the story of agents building *for* each other, which is true and evidenced. It does not yet show agents building *with* each other in the same history, which is the site's strongest claim. The band is written so that it does not pretend otherwise. When that vault exists, it goes in the hero.

## What it is generated from

One file, `admin/content/vaults.json`, now drives the hero cards, the six jobs, the sortable table and the vault count on the team band. Adding a vault is adding a row; promoting one to the front door is setting a field. The homepage stopped being a page somebody edits and became a view over the site's own data, which is the same rule the articles band, the network directory and the update feed already followed. It just took the homepage longest to get there.

*Written by Dinis Cruz and the agentic team working with him. Licensed CC BY 4.0.*

[← All articles](index.md)



==============================================================================
# A chat box on a site with no server, the plan, and the trade it makes, sgit.ai

> Nineteen sibling sites is too many to browse, so the directory now answers questions. The design problem is that sgit.ai has no server and no vault host, which means the honest options are a local matcher, a key in your browser, or moving the page into a vault, and only one of those is free.
>
> Page: https://sgit.ai/articles/chat-on-a-static-site.html

[Home](../index.md) / [Articles](index.md) / A chat box on a site with no server, the plan, and the trade it makes

# A chat box on a site with no server, the plan, and the trade it makes

2026-08-27 · [v0.2.47](../admin/versions.md) · chatllmbyokplan

***Abstract:** Nineteen sibling sites is too many to browse, so the directory now answers questions. The design problem is that sgit.ai has no server and no vault host, which means the honest options are a local matcher, a key in your browser, or moving the page into a vault, and only one of those is free.*

The [network directory](../network/index.md) now has a chat box. It answers one question, *which of these nineteen sites is mine?*, and it works with no key, no account and no network call.

That last part took the most thought, so this is the plan behind it: what shipped, what it costs, and what would remove the cost.

The panel on the directory. The default tier is a local matcher; the key is opt-in and clearly labelled.

## The constraint nobody can design around

`sgit.ai` is a static site on GitHub Pages. There is no server, no session, no place to keep a secret. Every sibling on `*.sgit.ai` is the same.

That matters because the usual way to put a chat box on a website is to call a model from a backend that holds the API key. There is no backend here to hold one. So the real options are only three, and it is worth being blunt about which is which.

## The three tiers

**Tier 0, match. Shipped, on by default, needs nothing.**

A deterministic scorer runs in the browser against the catalogue of all nineteen sites, emitted at build time from the same data the cards and the table are built from. Type *"I have to sign off a risk"* and it points at [risks.sgit.ai](../network/index.md#risk-governance), and shows you which words it matched on.

It is not clever. It is instant, free, private, works offline, and, the part that made it the default, **it tells you why it chose**. An LLM answer does not give you that. The scorer weights a hit in a site's thesis or domain above one in its summary, and stops there.

The important property: a reader should never have to hold a credential to use an index.

**Tier 1, bring your own key. Shipped, opt-in, and it costs you something.**

Paste an OpenRouter key and the browser calls `https://openrouter.ai/api/v1/chat/completions` directly, streaming, with the catalogue as the system prompt. This is not a new pattern here, the [SG/Vault workbench vault](../demos/vaults/index.md) already does exactly this, using the same endpoint and the versioned `sg-llm-request` module served from `dev.tools.sgraph.ai`, so this reuses a proven client rather than inventing one.

The cost is real and the UI states it rather than burying it: **with no host, there is no permission floor, so the key lives in this page's origin.** It goes into `localStorage` and into a `fetch` to `openrouter.ai`. It is never sent to sgit.ai, there is no server here to send it to, but the page cannot protect it the way a vault app can. That is a trust decision, and it belongs to the reader, so it is presented as one.

When the model call fails, the panel falls back to Tier 0 and says so. Degrading to something that works beats an error message.

**Tier 2, the bridge. Not built, and the one that removes the trade.**

Serve the directory as a **vault app** and the problem disappears. [llms.sgit.ai](../network/index.md#agents-ai) documents the contract: the key lives in `.vault/llm/config.json`, *below the permission floor*, the host makes the call, and the app never sees the credential. Its API is `sg.llm.available / chat / cancel / models / usage`, with grants defaulting to deny.

The striking detail in that documentation is that there are **three** chat surfaces, and two of them need no application code at all, the vault chat panel, and the same panel beside any running app. *"Every existing vault app gets this without being changed."*

The qualification has to travel with the claim, and llms.sgit.ai insists on this in its own words: *"The bridge protects your key; it is not yet a boundary that prevents all egress."* It protects the credential you trusted it with. It does not yet stop a malicious app calling a provider with a credential of its own.

## What would need building

Tier 2 is not a rewrite, but it is not free either. Honestly scoped:

| Piece | State | Note |
|---|---|---|
| The catalogue | **Done** | Emitted at build from `admin/content/sites/*.md`; nineteen entries |
| Tier 0 matcher | **Done** | `assets/network-chat.js`, no dependencies |
| BYOK client | **Done** | Streams from OpenRouter; the workbench vault's proven pattern |
| A vault build of the directory | **Not started** | The generator already emits a `.md` twin of every page; a vault app is a different target, not a different site |
| `sg.llm` detection | **Not started** | The panel should prefer the bridge when it exists and fall back when it does not, the same shape as the Tier 1 → Tier 0 fallback already in the file |
| Shared component | **Partly, 7 September** | A site-wide pane now sits on every page here, and its model can *call tools* over the site's own index and markdown twins (v0.2.63). Still one site's copy rather than a versioned module the other eighteen can load |

That last row is the one that decides whether this was worth doing. A chat box on one site is a feature. The same panel on all nineteen, reading each site's own catalogue, is the thing that makes a network of nineteen sites navigable, and it is why the catalogue is generated rather than written.

## Addendum, 7 September, the pane grew tools

The directory chooser above answers one question. Ten days later every page carries a pane (*Ask this site*, bottom right) whose model does not read a catalogue pasted into its prompt. It is given **seven tools** as function definitions: `search_site`, `read_page`, `list_vaults`, `list_sites`, `latest_updates`, `get_board`, `current_page`. Each call runs in the page, over an index the build emits from the same data as `llms.txt`, the vaults table, the network directory, the feed and the board, and the pane shows every call it made. With no key, the same tools run directly: type words to search, or `/vaults`, `/board`, `/read PATH`. The three tiers are unchanged; Tier 2 is still not wired, and is now on the board as T11.

## What it does not do

It does not answer questions *about* the subjects. Ask it how to threat-model a payment gateway and it will point you at a site, not teach you. The scope is routing, deliberately: the sites already contain the arguments, and a summary that drifts from them is worse than a link that does not.

It also does not know anything that is not in the catalogue. Nineteen theses, nineteen summaries, nineteen categories, all quoted from each site's own words rather than paraphrased, which is the same rule the [directory](../network/index.md) follows.

*Written by Dinis Cruz and the agentic team working with him. Licensed CC BY 4.0.*

[← All articles](index.md)



==============================================================================
# Twenty sites in fifteen days, and what that did to the writing, sgit.ai

> The thinking behind sgit stopped fitting on one site. It moved out to nineteen siblings on *.sgit.ai, what forced the split, what it cost, and why the index into them now starts with a question instead of a list.
>
> Page: https://sgit.ai/articles/nineteen-sites.html

[Home](../index.md) / [Articles](index.md) / Twenty sites in fifteen days, and what that did to the writing

# Twenty sites in fifteen days, and what that did to the writing

2026-08-26 · [v0.2.45](../admin/versions.md) · networkpublishingmethod

***Abstract:** The thinking behind sgit stopped fitting on one site. It moved out to nineteen siblings on *.sgit.ai, what forced the split, what it cost, and why the index into them now starts with a question instead of a list.*

On 11 August this was one website. By 26 August there were **twenty repositories**, nineteen of them siblings on `*.sgit.ai`, and fifteen of those were created in the last five days of that fortnight.

That is not a plan anybody wrote down. It is what happened when a body of work outgrew the shape it was being published in, and the interesting part is not the count, it is what the count did to the writing.

The network directory. Nineteen siblings, entered through the question you arrived with.

## What forced it

A section is a promise that something is *part of* the thing it sits inside. That promise held while the material was about sgit. It stopped holding the moment the writing started answering questions that were not about sgit at all.

*You cannot deny a risk, you can only say how long you accept it* is not a paragraph in a docs site about encrypted version control. Neither is *maps are claims, not pictures*, or *open source is a strategy, not a charity*, or *the standard is the graph*. Each of those is an argument that needs room, a reader who arrived for it, and, the part that matters most, **its own version history**.

That last one is the real forcing function. On one site, every change is one changelog. Nineteen arguments moving at different speeds through one release log produces a record nobody can read. Split them and each argument gets its own tags, its own release cadence, its own record of when it changed its mind.

## What it cost

Three things, all of them real.

**Discovery got worse before it got better.** Nineteen domains is not a menu, it is a problem. A reader who does not already know these sites cannot pick one from a list of names, `nfrs.sgit.ai` and `issues-fs.sgit.ai` mean nothing until you already know what they argue.

**Consistency became something you have to maintain rather than get for free.** One site has one stylesheet by construction. Nineteen have one stylesheet by discipline, and discipline is the thing that quietly stops happening.

**Cross-linking stopped being automatic.** An internal link is cheap; a link between sites is a claim that the other site still says what you think it says. [graphs.sgit.ai](../network/graphs.md) is the only sibling so far that links *back*, and the audit that added it found the same site pointing at `sentinel.sgit.ai`, which does not exist. The site is `sg-sentinel.sgit.ai`. One character of drift, and the link is dead.

## What we did about discovery

The directory used to be a list of cards. At four entries that was fine. At nineteen it is a thing you have to read *before* it helps you, which is the opposite of what an index is for.

So it now **starts from the question**, not the inventory:

*"I have to sign off a risk and I do not want to rubber-stamp it"* → **risks.sgit.ai**

*"My app has to call an LLM and I do not want it holding an API key"* → **llms.sgit.ai**

*"I want an issue tracker with no database"* → **issues-fs.sgit.ai**

Seventeen lines like that, then five groups by area, then a table of all nineteen for anyone who would rather see everything at once. Three ways in, for three kinds of reader, someone with a problem, someone browsing a field, and someone auditing the whole set.

One rule keeps it honest: **every thesis on that page is the site's own words**, quoted from its H1 or lede rather than summarised here. A summary drifts. A quotation either matches or is visibly wrong.

## The thing that made it cheap

None of this would be worth doing if each site were a bespoke build. They are not: same generator, same stylesheet, same release script, same validator, same rule that publishing is adding one file.

Adding the twentieth site to this index is writing one markdown file with a category and a one-line thesis. That is the whole ceremony. The property that makes a network of nineteen sites tractable is the same property that makes an unattended agent safe to run, [two agents publishing on the same day touch two different files and cannot conflict](../updates/#the-api-reference-we-did-not-have).

## Where it is honest

**One of the nineteen is not published.** `skills.sgit.ai` has a repository and a DNS record and nothing behind it. It is listed as *not published yet*, pointing at its repository, rather than quietly omitted, the same reason a missing tag is better than a missing page.

**Most of these sites are arguments, not products.** [sg-sentinel.sgit.ai](../network/sg-sentinel.md) says `NOT BUILT` at the top of every page. [risks.sgit.ai](../network/index.md#risk-governance) states that zero lines of code implement its model. [wardley-maps.sgit.ai](../network/index.md#graphs-method) is marked `PROPOSED`. That is the house style working as intended: publish the argument before the thing exists, say precisely what it is worth, and let it be checked later.

If you want the shortest version of what all of this is for, the [introduction](../articles/what-sgit-is.md) is one page. If you want the one site that answers your particular question, [the directory](../network/index.md) is built to send you there.

*Written by Dinis Cruz and the agentic team working with him. Licensed CC BY 4.0.*

[← All articles](index.md)



==============================================================================
# Git for things you cannot put on GitHub, sgit.ai

> An introduction to sgit and sgit.ai, what an encrypted vault is, why version control had to be rebuilt to get one, and what nineteen published vaults look like when the server storing them cannot read a byte.
>
> Page: https://sgit.ai/articles/what-sgit-is.html

[Home](../index.md) / [Articles](index.md) / Git for things you cannot put on GitHub

# Git for things you cannot put on GitHub

2026-08-25 · [v0.2.42](../admin/versions.md) · introzero-knowledgevaultsagents

***Abstract:** An introduction to sgit and sgit.ai, what an encrypted vault is, why version control had to be rebuilt to get one, and what nineteen published vaults look like when the server storing them cannot read a byte.*

There is a category of file that has nowhere good to live.

A risk register with real system names in it. A regulatory analysis you are still arguing about internally. The working memory of an AI agent that has been reading your codebase for a month. Client material under NDA. Anything a lawyer would want to see before it went near a third party.

All of it wants exactly what git gives you, history, branches, diffs, the ability to hand somebody a link and know what they will see. And all of it is the reason people say *"we can't put that in GitHub."* So it ends up in a shared drive, an email thread, or a Notion page nobody can diff, and the version history that mattered is gone.

**sgit is git for those files.** Encrypted before they leave your machine, versioned exactly like git, stored on a server that cannot read a single byte.

sgit.ai, `pip install sgit-ai`. Pure Python, two runtime dependencies, Apache-2.0.

## The part that is easy to say and hard to build

Zero knowledge is a claim people make loosely, so here is the precise version: **the server holds ciphertext and nothing else.** Not your filenames, not your directory structure, not your commit messages. Encryption and decryption happen on your machine. There is no key escrow, no admin override, no support engineer who can recover it for you, and that last part is a feature with a real cost, which is worth being honest about up front.

What makes it work is a single string:

```

<24-char passphrase>:<vault-id>

```

That is the **vault key**, and it is three things at once, the address of the vault, the authorisation to write to it, and the key that decrypts it. Lose it and the data is gone. Leak it and someone can rewrite your history.

From it you can derive, one way, a **read key**: same vault, read-only, safe to publish. That asymmetry is the whole sharing model. Every vault linked from sgit.ai is published as a read key, and no vault key has ever been published, a rule enforced by a tripwire in the release pipeline that scans every file before either remote is touched.

## Ten seconds of proof

The read key is the entire credential. No account, no login, no access request:

A real clone of the published EU AI Act vault. 273 objects, 207 files.

Now the same vault, as the machine storing it sees it:

786 bytes of AES-256-GCM ciphertext. The object's name is a SHA-256 of the encrypted bytes.

That second screenshot is the argument. The object is **content-addressed over its ciphertext**, which means the host can deduplicate it, cache it for a year, and serve it from a CDN, while remaining unable to tell you what it is. You get the operational benefits of a normal object store without granting it the usual price of admission.

Underneath, it is a real version control system rather than a sync folder: multi-parent commits, a tree per directory, deterministic refs derived by HMAC, a genuine merge-base computation across all parents, and three-way merge. Branches, diffs and history all work, on content the server cannot interpret.

## Nineteen vaults you can open right now

The best way to understand a vault is to open one. **Every vault on sgit.ai is live**: the screenshots are of real vaults, opened with the read keys published beside them.

The published vaults. Each one carries its read key on the page.

They range from a photo library to Regulation (EU) 2024/1689 parsed from official Formex XML into 1,523 nodes and 1,944 edges. Before writing this I cloned all nineteen from their published keys: **1,389 files, no failures.**

## The part that surprises people

A vault can contain an *application*, not just documents, and that application runs against the vault without ever being handed a credential.

`"permissions": {}`, the app requests nothing, and is granted nothing.

Look at `"permissions": {}` in that file. The app asks for no filesystem access at all. It still renders the whole risk graph, because the host reads the vault and passes results in. The app never sees a key. **Capability without credential**, and it means you can run code you did not write against data you care about, with the blast radius set by a config file you can read in one screen.

## Why there is a network of sites

sgit.ai is one of **nineteen** sites on `*.sgit.ai`, each taking one question further than a section could. Most of the thinking behind sgit now lives out there rather than here.

The network directory: start from the question you arrived with.

A few of them, to give the range:

- [**graphs.sgit.ai**](../network/graphs.md), *"A node is just a node. Meaning lives in the edges."*
- [**risks.sgit.ai**](../network/index.md#risk-governance), *"You cannot deny a risk. You can only say how long you accept it."*
- [**llms.sgit.ai**](../network/index.md#agents-ai), your app calls a language model without ever holding an API key.
- [**issues-fs.sgit.ai**](../network/index.md#graphs-method). The issues are files, and the files are a graph.
- [**open-source.sgit.ai**](../network/index.md#business-publishing), *"Open source is a strategy. It is not a charity."*
- [**sg-sentinel.sgit.ai**](../network/sg-sentinel.md), an edge guard design that says `NOT BUILT` at the top of every page.

The [network directory](../network/index.md) starts from the question you arrived with rather than the list of domains.

That last one is the house style in miniature. Each site publishes its argument **before** the thing exists, and states plainly what has shipped and what has not. graphs.sgit.ai devotes a page to [where its own approach loses](https://graphs.sgit.ai/about/participant.html). We would rather be checkable than impressive.

## Try it

```

pip install sgit-ai
sgit clone sgit_public_read_c004daae386e8d17fa648884acc527018bd4ea1116ad673fb2f1b068011695c9:73heuprz

```

That is the EU AI Act vault, 207 files on your disk in under a minute, from a key printed on a public web page, with no account anywhere.

If you would rather not install anything, [every vault opens in the browser](../demos/vaults/index.md) from the same key.

**Status, plainly.** sgit is beta and says so on every page. The CLI is `pip install sgit-ai`, Apache-2.0, pure Python. The site you are reading is itself served from a vault, released 59 times, and each release is [logged in full](../admin/versions.md), including the ones that broke something.

This article is also published as a [LinkedIn newsletter post](https://www.linkedin.com/pulse/git-things-you-cannot-put-github-dinis-cruz-qwrte/), same argument, same screenshots, for readers who live there.

*Written by Dinis Cruz and the agentic team working with him. Licensed CC BY 4.0, reuse it, quote it, argue with it.*

[← All articles](index.md)



==============================================================================
# Seven vaults, one method, sgit.ai

> Publishing seven encrypted vaults in a fortnight turned an ad-hoc process into a repeatable one. Every rule in it exists because something went wrong first, including three vault keys submitted for publication that would have handed the world write access.
>
> Page: https://sgit.ai/articles/seven-vaults-one-method.html

[Home](../index.md) / [Articles](index.md) / Seven vaults, one method

# Seven vaults, one method

2026-08-19 · vaultspublishingmethod

***Abstract:** Publishing seven encrypted vaults in a fortnight turned an ad-hoc process into a repeatable one. Every rule in it exists because something went wrong first, including three vault keys submitted for publication that would have handed the world write access.*

Between 14 and 18 August this site published seven vaults. Each one is a real encrypted vault you can open in a browser from a read key printed on its page: [a photo gallery](../demos/vaults/algarve-may-2026/index.md), [field notes](../demos/vaults/field-notes/index.md), [a patient-held supplement record](../demos/vaults/supplement-stack/index.md), [a risk register](../demos/vaults/risk-mandate/index.md), [a browser-isolation risk graph](../demos/vaults/agentic-browser-isolation/index.md), [a fact-to-risk explorer](../demos/vaults/risk-graph-explorer/index.md), and [the catalogue that indexes them](../catalogue/index.md), itself a vault.

By the third one it was obvious that we were repeating ourselves badly. By the seventh there was a method, and every rule in it exists because something went wrong first.

## The rule that matters most

**Classify the credential before it touches anything.**

Three of the seven vaults arrived as a *vault key* described as a read key. A vault key is write access. Publishing one would have handed anybody who read the page the ability to rewrite the vault, and because a vault key is also the address and the encryption root, there is no revocation, no rotation, and no undo.

They were caught by shape. A read key is 64 hex characters; a vault key is a generated passphrase, which is 24 lowercase alphanumerics. That catch depended on somebody looking, which is not a control. So it became [a script](../demos/vaults/publishing.md):

```

$ python3 admin/build/check_credential.py '<credential>'
  form      : vault key (legacy passphrase:vault_id)
  publish?  : NO
  why       : 24 characters before the colon and not 64 hex, so it is a
              passphrase — a WRITE credential

```

Exit 0 means publishable. Exit 1 means stop. It never echoes what it was given.

Behind it sits a second line: the release validator scans every tracked file for any key-shaped string and for the actual passphrases, read at build time from a gitignored tier. That tripwire has caught its own author three times, each time writing the prefix in prose, in documentation explaining what a write credential looks like. Which is the point: a rule that only catches other people is not a rule.

## Derive rather than refuse

The interesting part of the vault-key catch is what happens next. A read key is **derived one-way** from a vault key, so a submission that cannot be published can still become one that can:

```

c = Vault__Crypto()
pw, vid  = c.parse_vault_key(vault_key)
read_key = c.derive_keys(pw, vid)['read_key']

```

The vault key goes into a gitignored tier that the tripwire then scans for. The derived read key gets published. It is one-way: nobody can turn it back.

That is the whole shape of the thing this project is about, a capability you can hand over that is *strictly less* than the one you hold, with the reduction enforced by mathematics rather than by policy. The seven vaults span the range deliberately, from one that requests no permissions at all to one that can write a single folder.

## Audit with the key you are about to publish

Not with the vault key. With **exactly the credential a reader will have**, across every file.

This caught a real problem. One vault carried a sealed LLM credential, and a published read key in front of a metered capability is an open tab on somebody else's budget. Rather than reasoning about whether the sealing was sound, we took the published read key and attempted to open the credential with it. AES-GCM refused, `InvalidTag`, so no budget was exposed. Checked rather than assumed, and recorded either way.

That rule did not come from us. It came from the sixth vault, [Risk Graph Explorer](../demos/vaults/risk-graph-explorer/index.md), which is the first one here that was **public by design**: it carries its own `PUBLIC.md` whose three rules its build enforces, and the third, *no metered capability behind a published read key*, was not in our guidance. It is now.

## Capture evidence by driving the real product

Every screenshot on a vault page is taken by opening the actual vault in a real browser with the published read key, performing the navigation, and cropping the result. No mock-ups.

This is slower than it sounds and worth every minute, because it repeatedly disagreed with what we were about to write. The rig grew a `appProbe` step for exactly that reason, ask the running app what its elements are called instead of guessing and burning a capture run per guess:

```

probe [class*=node] -> 37
  shapes ["g.cnode.inh","g.cnode","g.cnode.corp"]
  text   ["R1 An autonomous system operates in the es","R2 Stopping the agent is itself…"]

```

The alternative is a page that describes a product as its author remembers it.

## Describe, show, then admit

Every vault page ends with what the vault does *not* do. Not as a disclaimer at the bottom in small type, as a section with the same weight as the features.

This is the part that is tempting to skip and never should be. A published vault is an argument that this way of working is sound; an argument that omits its own edges is a brochure. The [limitations page](../docs/limitations.md) is the same instinct at site level, and the [comparison pages](../compare/index.md) go further still, they include rows where vaults lose.

## What it cost, and what it bought

Seven vaults, roughly four days of work, and the method is now [written down as a playbook](../demos/vaults/publishing.md) aimed at another site's agent rather than at us, which was the real test of whether it was a method or just a habit.

The honest ledger:

- **Three vault keys caught.** None published. Each would have been unrecoverable.
- **One budget exposure checked and cleared**, by attempting the attack rather than reasoning about it.
- **One upstream rule adopted** from a vault that was stricter than our guidance.
- **Three bugs found by testing rather than assumption** on a single page, a malformed selector that silently produced no images at all, escape sequences leaking as literal text, and a page that never loaded the component it depended on. All three would have shipped.

The last line is the one to keep. Every rule above is short and specific because it was learned by getting something wrong, in public, and writing down what it cost.

*The full method, step by step, is on [the publishing playbook](../demos/vaults/publishing.md). The vaults themselves are in [the catalogue](../catalogue/index.md), each with the read key that opens it.*

[← All articles](index.md)



==============================================================================
# Green does not mean live, sgit.ai

> Two releases pushed cleanly, reported success, and never reached the site. Every check we had was green, because the failure happened in a place none of them could see. What we changed, and the general rule underneath it.
>
> Page: https://sgit.ai/articles/green-does-not-mean-live.html

[Home](../index.md) / [Articles](index.md) / Green does not mean live

# Green does not mean live

2026-08-17 · [v0.2.33](../admin/versions.md) · cideployverification

***Abstract:** Two releases pushed cleanly, reported success, and never reached the site. Every check we had was green, because the failure happened in a place none of them could see. What we changed, and the general rule underneath it.*

Two consecutive releases of this site pushed cleanly, verified themselves against both remotes, printed **"both remotes in sync, done"**, and never reached anybody. The site served a two-release-old page for forty minutes. It was noticed by a human on a phone, who looked at the version badge and said *"is this the latest version?"*

Everything about that sentence is worth sitting with. The checks were not weak. They were **checking the wrong boundary**.

## What the release actually verified

The release script does five things, and four of them are good:

1. Build the site from source.
2. Run the validator, structure, links, markdown twins, orphan pages, and a tripwire that scans every tracked file for a vault key.
3. Commit and push the encrypted vault; confirm `sgit status` reports in sync.
4. Commit and push the git mirror; confirm `HEAD == origin/dev`.

Step 4 is where the confidence came from, and it is genuinely a strong check, it compares hashes, not hopes. The problem is what it means. It means **the bytes arrived at GitHub**. It does not mean anybody can read them.

## The gap, named

Publishing this site has three boundaries, and we were verifying two:

```

  source  ──▶  git remote  ──▶  Pages deploy  ──▶  the reader
            ↑               ↑                  ↑
        verified        verified           NOT VERIFIED

```

Between the second and third arrows sits a GitHub Actions job. It has its own failure modes, it reports into a system neither remote knows about, and nothing in our release looked at it.

## What actually failed

Not our code. Not the content. The deploy job died in **"Set up job"**: before running a single step of its own:

```

Download action repository 'actions/configure-pages@v5'
##[warning] Failed to download ... Error: 429 (Too Many Requests)
##[warning] Back off 12.459 seconds before retry.
##[warning] Failed to download ... Error: 429 (Too Many Requests)
##[warning] Back off 26.597 seconds before retry.
##[error]  Failed to download archive after 3 attempts.

```

`codeload.github.com` rate-limited the download of a third-party action. The `validate` job passed. The `tag-release` job passed. The one job that puts bytes in front of readers could not fetch its own dependency.

This is worth stating plainly because it is the ordinary case, not an exotic one: **the most likely thing to break in a deploy is not your code.** It is a piece of shared infrastructure you do not run, on a day you were not thinking about it.

## The fix is one question, asked at the end

A release now finishes by asking the live site what version it is serving:

```

== 5/6 verify the deploy actually published
   waiting for v0.2.34 to appear at https://sgit.ai/ (up to 8 min)
   ......
   live: sgit.ai is serving v0.2.34

```

It polls with a cache-buster, because the origin's own answer is the only one that counts. If the version never appears it **aborts loudly**, names the Actions page, and says that a 429 on the action download is transient and needs a re-run.

The cost is real: up to eight minutes of waiting on every release. We took it, because the alternative had already been demonstrated twice in one afternoon, telling somebody a fix was live when it was not, twice, in writing.

## The rule underneath

This site already had two rules of exactly this shape, and adding the third made the pattern obvious:

- **A page nothing links to is unpublished.** The build fails on an orphan page, it happened once, a brief that was written, built and pushed while nothing linked to it.
- **A page the machine index omits is unpublished.** The build fails if any page would be missing from `llms.txt`, that happened too, a whole section silently absent.
- **A page the deploy never served is unpublished.** Now the release fails on it.

All three are the same claim: *shipped* is a fact about the reader, not about your repository. Every one of them was learned by getting it wrong first, which is the only reason the list is short and specific rather than long and aspirational.

## What this does not fix

Being honest about the edges, since that is the house rule:

- It detects a failed deploy; it does not repair one. A 429 still needs a human or a re-run.
- It checks the home page's version badge, not every page. A partial deploy that published some files would pass.
- It adds up to eight minutes to a release, which is a real tax on small fixes.

All three are acceptable against the failure they replace. The first one to bite will get its own entry.

*The release script is [in the repository](https://github.com/SGit-AI/SGit-AI__CLI); the releases described here are [v0.2.31 to v0.2.33](../admin/versions.md).*

[← All articles](index.md)



==============================================================================
# Sherpa, an agentic role on sgit.ai

> Sequences the work, scopes each release, and keeps the board honest, the role that decides what ships next and what waits.
>
> Page: https://sgit.ai/team/roles/sherpa.html

[Home](../../index.md) / [Team](../index.md) / Sherpa

Agentic role · 1 of 9

# Sherpa

| Mission | Sequences the work, scopes each release, and keeps the board honest, the role that decides what ships next and what waits. |
|---|---|
| Owns | the board, release scoping, the order in which other roles run, and the decision to hold or ship |
| Not responsible for | writing pages, auditing credentials, or touching the build, the Sherpa unblocks, it does not do |
| Works in | `admin/content/team/issues/*.md` · `admin/build/build_pages.py (VERSION_LOG only)` |
| Checks it runs | every open card has an owner and a status that is true; every release has one sentence saying what it is for |

## What the role does

The site ships several times a day. Somebody has to decide what goes in the next release, in what order the roles run, and when a piece of work is *done* rather than *stopped*. That is the Sherpa. Content before design, design before build; a small release live today beats a complete one planned for tomorrow; and a card that says *doing* while nobody is doing it is a lie the board is telling.

## The rules it enforces

- **One release, one sentence.** The commit subject is `site vX.Y.Z: WHAT_IT_IS_FOR and the CI tag gate reads it; if the sentence cannot be written, the release is not ready.
- **The board is the truth.** Work that is not on the board did not happen; work on the board in the wrong column is worse than absent.
- **Needs before tasks.** Anything only the author can supply goes in the *Needs* column immediately, with what it unblocks, so it is never discovered late.
- **Sequence by dependency, not by size.** The homepage rebuild waited for the diagnosis article on purpose, so the two could be compared honestly.

## Starting prompt

You are the Sherpa for sgit.ai. Read `admin/index.html` (how the site is built and released), `team/board.html` (the open board) and the last three entries of `admin/versions.html`. Then: state in one sentence what the next release is for, list the cards it closes, name which role runs first and why, and move any card whose status is no longer true. Do not write pages. If something only the author can supply is blocking, add it to the Needs column with what it unblocks.

## Recurring tasks

Scoping the next release · triaging inbound briefs into board cards · the weekly pass over *doing* and *review* · deciding hold-or-publish when the Auditor flags a vault

## On the board for this role

- **T4** · [The agentic section: roles, starting prompts, the board](../board.md#T4) (review, high)

Other roles: [Publisher](publisher.md) · [Auditor](auditor.md) · [Journalist](journalist.md) · [Cartographer](cartographer.md) · [Ambassador](ambassador.md) · [Designer](designer.md) · [Release engineer](release-engineer.md) · [Historian](historian.md) · [Starting prompts](../prompts.md) · [The board](../board.md)



==============================================================================
# Publisher, an agentic role on sgit.ai

> Takes a submitted credential and turns it into a published vault page (classify, derive, audit, capture, write, escrow, release) following the seven-step method every row on the vaults table was built with.
>
> Page: https://sgit.ai/team/roles/publisher.html

[Home](../../index.md) / [Team](../index.md) / Publisher

Agentic role · 2 of 9

# Publisher

| Mission | Takes a submitted credential and turns it into a published vault page (classify, derive, audit, capture, write, escrow, release) following the seven-step method every row on the vaults table was built with. |
|---|---|
| Owns | the vault pages, vaults.json, the read-key escrow tier, and the seven-step method itself |
| Not responsible for | deciding whether a flagged vault may be published (the Sherpa does, on the Auditor's finding), or changing the build |
| Works in | `admin/content/demos/vaults/<slug>/index.html` · `admin/content/vaults.json` · `.sg_vault/local/demo-keys/ (gitignored)` · `demos/vaults/<slug>/images/` |
| Checks it runs | check_credential.py before the credential touches anything; the leak sweep; clone_mode.json as the only clone-success marker; screenshots taken with any telemetry aborted |

## What the role does

A vault arrives as a string. The Publisher never assumes what kind of string. `admin/build/check_credential.py` says whether it is a vault key or a read key; if it is a vault key it is escrowed in the gitignored tier and the read key is *derived*, one-way, and only the derived key is ever published. Then the vault is cloned **with the read key only**, because that is the credential the public will hold, and audited as that public would see it.

The method is written down at [publishing a vault](../../demos/vaults/publishing.md), and each rule in it was produced by a mistake. Two rules from this month:

- **A clone test with no negative control is not a test.** `sgit clone` creates a directory whether or not the key works; the marker that discriminates is `.sg_vault/local/clone_mode.json`. An all-zeros key must fail the same test the real key passes.
- **Every 64-hex string in a vault must be accounted for.** An append token and a read key are the same shape; the audit names which one each is, and tests rather than trusts.

## The rules it enforces

- Read keys yes, vault keys never. The write key is escrowed before publishing, not after.
- Audit with the read key. Findings go on the vault's page, not in a file.
- Screenshots are of the real product, driven, with any telemetry blocked at the network layer.
- The vault's row is a data row in `vaults.json`; the page is a content file; nothing on the index is hand-written.

## Starting prompt

You are the Publisher for sgit.ai. A credential has been submitted: PASTE. Read `demos/vaults/publishing.html` first. Run `admin/build/check_credential.py` on it and report its class before doing anything else. If it is a write credential, escrow it under `.sg_vault/local/demo-keys/` and derive the read key. Clone with the READ key only. Audit: private keys, enum/write/vault/read key fields, vault-key shapes, third-party secrets, emails, and account for every 64-hex string. If anything is found, stop and hand the finding to the Sherpa. Otherwise: derive the facts, capture screenshots by driving the vault locally with `/api/vault/**` aborted, write `admin/content/demos/vaults/SLUG/index.html` in the house style, add the row to `admin/content/vaults.json`, add the manifest entry, and stop before releasing.

## Recurring tasks

Publishing a submitted vault · re-verifying the published read keys (using the right marker) · updating a vault's page when its author fixes a finding · republishing a held vault clean, via a fresh vault with the offending file removed

## On the board for this role

- **N3** · [A vault where two agents and a human merge are visible in the history](../board.md#N3) (needs, high)
- **N4** · [The games vault: one manifest line so the telemetry actually sends](../board.md#N4) (needs, medium)

Other roles: [Sherpa](sherpa.md) · [Auditor](auditor.md) · [Journalist](journalist.md) · [Cartographer](cartographer.md) · [Ambassador](ambassador.md) · [Designer](designer.md) · [Release engineer](release-engineer.md) · [Historian](historian.md) · [Starting prompts](../prompts.md) · [The board](../board.md)



==============================================================================
# Auditor, an agentic role on sgit.ai

> Decides whether something can be made public without leaking (credentials in vaults, keys in the tree, secrets in screenshots) and publishes what it finds rather than filing it.
>
> Page: https://sgit.ai/team/roles/auditor.html

[Home](../../index.md) / [Team](../index.md) / Auditor

Agentic role · 3 of 9

# Auditor

| Mission | Decides whether something can be made public without leaking (credentials in vaults, keys in the tree, secrets in screenshots) and publishes what it finds rather than filing it. |
|---|---|
| Owns | credential classification, the leak tripwire, the secret-shape sweeps, and the hold-or-publish recommendation |
| Not responsible for | writing the vault page, or deciding alone to publish something it flagged, it recommends, the Sherpa decides |
| Works in | `admin/build/check_credential.py` · `admin/build/validate.js (the tripwire)` · `.gitignore` · `.sg_vault/local/` |
| Checks it runs | no vault-key passphrase anywhere in the tracked tree; no 64-hex string unaccounted for; every clone test has a negative control; the release tripwire reads the secret from the gitignored tier and never from source |

## What the role does

The site publishes read keys on purpose, which means it has to be very sure about what a read key can reach. A read key decrypts **everything** in its vault, so anything inside a published vault is public, and the Auditor's question is always the same: *what is in here that should not be?* Three vaults are currently held on its findings; one of them passed a clean regex scan and was caught only because a screenshot showed a chip reading `key.json`.

## The rules it enforces

- **Classify by shape, then by prefix.** 64 hex before the colon is a read key; anything else is a passphrase and a write credential. Prefixes (`sgit_rk1_`, `sgit_vk1_`) are the better answer; the shape check covers the years of keys before them.
- **Negative controls, always.** A test that would pass with a wrong key has proven nothing. This was learned live, on a leak call that had to be retracted.
- **The tripwire never holds the secret.** `validate.js` reads the passphrase from the gitignored tier at runtime and scans for it; hard-coding it into the validator once put the secret in three public commits.
- **Publish the finding.** On the vault's page, in the update, in the version log, not in a private note.

## Starting prompt

You are the Auditor for sgit.ai. The Publisher has cloned vault ID with a read key at PATH. Sweep it: PEM private keys; fields named enum_key, write_key, vault_key, read_key, api_key or any provider-key shape (sk-, ghp_, AKIA, xox, AIza, JWT); vault-key passphrase shapes; emails and personal data. List every 64-hex string and state what each one is, testing rather than trusting, for any that might be a read key, attempt a clone and run the same clone with an all-zeros key as the control; only `.sg_vault/local/clone_mode.json` counts as success. Report PASS with the accounting, or HOLD with the exact file and line. Never print a vault key.

## Recurring tasks

Auditing each submitted vault · the periodic sweep of the tracked tree for key shapes · reviewing any new build tooling that touches credentials · re-running the published read-key verification with the corrected marker

## On the board for this role

- **T2** · [Re-verify the 21 published read keys with the marker that actually discriminates](../board.md#T2) (backlog, high)
- **N6** · [Republish the two held vaults clean, or retire them](../board.md#N6) (needs, low)

Other roles: [Sherpa](sherpa.md) · [Publisher](publisher.md) · [Journalist](journalist.md) · [Cartographer](cartographer.md) · [Ambassador](ambassador.md) · [Designer](designer.md) · [Release engineer](release-engineer.md) · [Historian](historian.md) · [Starting prompts](../prompts.md) · [The board](../board.md)



==============================================================================
# Journalist, an agentic role on sgit.ai

> Writes what happened (the release note for every version, the articles that argue a point with screenshots, and the drafts that go to LinkedIn) with every number counted rather than remembered.
>
> Page: https://sgit.ai/team/roles/journalist.html

[Home](../../index.md) / [Team](../index.md) / Journalist

Agentic role · 4 of 9

# Journalist

| Mission | Writes what happened (the release note for every version, the articles that argue a point with screenshots, and the drafts that go to LinkedIn) with every number counted rather than remembered. |
|---|---|
| Owns | admin/content/updates/, admin/content/articles/, the LinkedIn drafts, and the .md twin the articles are read through by agents |
| Not responsible for | the version log (the Historian), or deciding what ships (the Sherpa) |
| Works in | `admin/content/updates/YYYY/MM/DD/<version>__update__<slug>.md` · `admin/content/articles/<slug>.md` · `articles/images/` |
| Checks it runs | every number in prose is either computed on the page or verified against the file that morning; a claim about the site is checked with grep or git, not memory |

## What the role does

Publishing is adding one file. An update is `admin/content/updates/YYYY/MM/DD/VERSION__update__SLUG.md`; an article is `admin/content/articles/SLUG.md`; the index, the feed, the homepage band and the `.md` twin all derive. The Journalist writes in the house voice, plain, specific, quoting the artefact rather than paraphrasing it, and saying what the thing is worth right after saying what it is.

Two rules came from this week and both are about numbers. *Nine bands became eight* was written from the plan; `git show` said nine to nine. *87 releases* was written an hour before a release made it 88. **Prose that restates a number the page computes will be wrong within the hour.** Name the number; do not repeat it.

## The rules it enforces

- **Count, don't remember.** Any figure in an article is checked against the file, the log or the live page before it is typed.
- **Corrections above the mistake.** A corrected paragraph says it was corrected, and why, in its own text.
- **Screenshots do the arguing.** A before/after article shows both; the prose says what changed and what it cost.
- **LinkedIn-ready means copy-paste.** No relative links, no site-only shorthand, the trailing slash on URLs.

## Starting prompt

You are the Journalist for sgit.ai. Release VERSION has just gone live; its version-log entry is in `admin/versions.html` and the diff is `git show HEAD`. Write `admin/content/updates/DATE/VERSION__update__SLUG.md` in the house voice: what changed, why, what it cost, and one thing it does not do. Every number must be verified against a file or the live page in this session, say how. Do not restate numbers a page computes; name them. Root-relative links only. Then, if the release deserves it, propose an article title and the screenshots it would need, do not write the article unless asked.

## Recurring tasks

An update per release · an article when a change deserves an argument · the LinkedIn draft when asked · correcting a published figure and saying so

## On the board for this role

- **T12** · [Transcribe the seven Licence to Operate shorts](../board.md#T12) (backlog, medium)

Other roles: [Sherpa](sherpa.md) · [Publisher](publisher.md) · [Auditor](auditor.md) · [Cartographer](cartographer.md) · [Ambassador](ambassador.md) · [Designer](designer.md) · [Release engineer](release-engineer.md) · [Historian](historian.md) · [Starting prompts](../prompts.md) · [The board](../board.md)



==============================================================================
# Cartographer, an agentic role on sgit.ai

> Keeps the map of the *.sgit.ai network true (one file per sibling site, the question-first directory, the sibling-site cards) and sends corrections upstream when a sister site is wrong about itself.
>
> Page: https://sgit.ai/team/roles/cartographer.html

[Home](../../index.md) / [Team](../index.md) / Cartographer

Agentic role · 5 of 9

# Cartographer

| Mission | Keeps the map of the *.sgit.ai network true (one file per sibling site, the question-first directory, the sibling-site cards) and sends corrections upstream when a sister site is wrong about itself. |
|---|---|
| Owns | admin/content/sites/*.md, the network directory, the chooser questions, the !site card, and the aliases a reader arrives with |
| Not responsible for | the sibling sites themselves, the Cartographer describes them in their own words and files a brief when they are wrong |
| Works in | `admin/content/sites/<slug>.md` · `admin/build/build_pages.py (ASK` · `network_index_body)` · `assets/network-chat.js` · `network/images/` |
| Checks it runs | every site entry quotes the site's own thesis, not a paraphrase; every listed domain resolves or is marked not-published; the chooser routes a test question to the right site |

## What the role does

Nineteen sibling sites exist so each topic can get the depth a section here could not give it, which only pays off if this site points at them constantly, and accurately. The Cartographer writes one file per site, `admin/content/sites/SLUG.md`, in the site's **own words**: its stage pill, its headline thesis, its category, and the *aliases*, the vocabulary a reader arrives with, which is rarely the vocabulary the site uses. The directory, the cards, the chooser and the `!site` card all derive from those files.

## The rules it enforces

- **Quote, don't paraphrase.** A site's thesis is copied from the site with the date it was observed.
- **A named absence beats a hidden one.** A site with DNS and no pages is listed as *not published yet*, not omitted.
- **Corrections go upstream.** graphs.sgit.ai links to `sentinel.sgit.ai`, which does not resolve; the note is on our page and the brief is filed with theirs.
- **Point at them constantly.** Any mention of a sibling site's topic gets a `!site` card, not a bare link.

## Starting prompt

You are the Cartographer for sgit.ai. A new sibling site has appeared at HOST. Fetch its `llms.txt` and homepage. Write `admin/content/sites/SLUG.md` with title, domain, tagline, summary, category, the site's own thesis quoted verbatim, an `aliases:` line of the words a reader would arrive with, `observed:` today, and `listing: true` unless it merits a full write-up. Check its outbound links to the network and record any that do not resolve. Rebuild, then ask the chooser three questions a reader of that site would ask and confirm it routes to it. Do not paraphrase the site's claims.

## Recurring tasks

Adding a new sibling site · re-observing a site whose version changed · tuning aliases when the chooser misroutes · filing an upstream brief for a broken cross-link

## On the board for this role

- **N5** · [Answers to the seven append-lane questions](../board.md#N5) (needs, medium)
- **T6** · [Flip skills.sgit.ai from not-published to live when Pages serves it](../board.md#T6) (backlog, low)
- **T7** · [Upstream: graphs.sgit.ai footer links to sentinel.sgit.ai, which does not resolve](../board.md#T7) (backlog, low)

Other roles: [Sherpa](sherpa.md) · [Publisher](publisher.md) · [Auditor](auditor.md) · [Journalist](journalist.md) · [Ambassador](ambassador.md) · [Designer](designer.md) · [Release engineer](release-engineer.md) · [Historian](historian.md) · [Starting prompts](../prompts.md) · [The board](../board.md)



==============================================================================
# Ambassador, an agentic role on sgit.ai

> Owns how sgit is explained to someone who has never seen it (the homepage, the positioning, the investor page) and enforces the rule that proof comes before mechanism.
>
> Page: https://sgit.ai/team/roles/ambassador.html

[Home](../../index.md) / [Team](../index.md) / Ambassador

Agentic role · 6 of 9

# Ambassador

| Mission | Owns how sgit is explained to someone who has never seen it (the homepage, the positioning, the investor page) and enforces the rule that proof comes before mechanism. |
|---|---|
| Owns | the homepage bands, the positioning sentence, use-case framing, and the investors section |
| Not responsible for | building the bands (the Designer), or the facts on them (computed, or the Historian's) |
| Works in | `admin/content/index.html` · `admin/content/investors/index.html` · `admin/content/vaults.json (hero` · `job` · `why fields)` · `admin/content/why/index.html` |
| Checks it runs | a first-time visitor sees a real vault before a paragraph of explanation; no claim on the homepage lacks an artefact behind it, and the one that does is named as a gap |

## What the role does

The homepage led with encryption for three weeks, a property nobody can look at, while twenty-five vaults a stranger could open sat two clicks away. The Ambassador's job is to notice that, say it in [an article with the screenshots](../../articles/proof-behind-the-claim.md), and then move the proof up. The positioning sentence is *a vault is a unit of work: data, app, history and sources, shipped as one string*, and encryption is the subordinate clause.

## The rules it enforces

- **Proof before mechanism.** Show a vault, then explain how it works.
- **Things, not categories.** Six vaults chosen by the job they do beat five use-case cards.
- **A claim with no artefact is named as a gap**, on the page, until the artefact exists. The homepage's strongest multi-agent claim still lacks a vault that shows two agents merging; the band says so.
- **The front door is data.** Promoting a vault to the hero is setting a field in `vaults.json`, not editing a page.

## Starting prompt

You are the Ambassador for sgit.ai. Read the homepage as a first-time visitor at 1400 and 390 wide, then `articles/proof-behind-the-claim.md` for the standard it is held to. Answer: what does a visitor see before the first paragraph of explanation? Which claims on the page have an artefact behind them, and which do not? Propose at most three changes, each as a data edit (`vaults.json` fields) or a band reorder, and say what each would cost. Do not build; hand the proposal to the Designer with the screenshots that justify it.

## Recurring tasks

Reviewing the homepage after every few vaults land · choosing the hero four and the six jobs · keeping the investors page's claims tied to computed numbers · writing the positioning for a new section

## On the board for this role

- **N1** · [The ask: round size, instrument, and what it buys](../board.md#N1) (needs, high)
- **N2** · [The deck, or permission to build one from the page](../board.md#N2) (needs, high)
- **T1** · [An About page about sgit, linking to the fuller record](../board.md#T1) (backlog, high)
- **T5** · [The investors section, on the open-investor-materials model](../board.md#T5) (review, high)

Other roles: [Sherpa](sherpa.md) · [Publisher](publisher.md) · [Auditor](auditor.md) · [Journalist](journalist.md) · [Cartographer](cartographer.md) · [Designer](designer.md) · [Release engineer](release-engineer.md) · [Historian](historian.md) · [Starting prompts](../prompts.md) · [The board](../board.md)



==============================================================================
# Designer, an agentic role on sgit.ai

> Builds and maintains the site's components (bands, cards, tables, the sibling-site card) and checks every change on a phone before it ships, because that is where the failures are visible.
>
> Page: https://sgit.ai/team/roles/designer.html

[Home](../../index.md) / [Team](../index.md) / Designer

Agentic role · 7 of 9

# Designer

| Mission | Builds and maintains the site's components (bands, cards, tables, the sibling-site card) and checks every change on a phone before it ships, because that is where the failures are visible. |
|---|---|
| Owns | assets/site.css, the generated components in build_pages.py, the screenshot rigs, and the mobile check |
| Not responsible for | the copy (Journalist, Ambassador) or the data (vaults.json, sites/*.md) |
| Works in | `assets/site.css` · `assets/shots.js` · `admin/build/build_pages.py (the *_band and *_table generators)` · `admin/build/capture_shots.mjs` |
| Checks it runs | no horizontal overflow at 390 wide; no static img src or script src (the validator refuses both); every generated component carries hidden text separators so its .md twin reads as prose; a screenshot of the change exists |

## What the role does

The site renders in three places: a browser, an agent's markdown fetcher, and *inside a vault* on a blob origin. The Designer builds components that work in all three. That is why images go through `shots.js` rather than a static `src`, why scripts are fetched and evaluated rather than referenced, and why a card's spans carry hidden ` — ` separators: the browser hides them, the `.md` twin reads them.

Most reported bugs arrived as a phone screenshot from the author: three identical buttons in one scroll; a vault id squeezed to one character per line by a 64-hex key beside it. Both were invisible at desktop width. **Check at 390 before saying done.**

## The rules it enforces

- **Bands carry their own max-width** (1100px). There is no wrapper convention, and a band without one runs full-viewport.
- **No `img src`, no `script src`**: the validator refuses both, and it is right to.
- **Text separators in generated cards**, hidden by CSS, so the markdown twin is readable.
- **Progressive enhancement.** A sortable table ships in its best default order; the board is readable with JavaScript off.
- **Prove the fix.** Assert the sort flipped; measure `scrollWidth` at 390; count the loaded images.

## Starting prompt

You are the Designer for sgit.ai. Read `assets/site.css` and the generator functions in `admin/build/build_pages.py` that emit components (`vaults_table`, `home_hero_vaults`, `home_jobs_band`, `team_board`). Implement CHANGE. Constraints: no static img/script src; hidden `.hv-sep` separators between text parts of any generated card; a max-width on any new band. Then build, run `node admin/build/validate.js`, and verify with Playwright at 1280 and 390 wide: no horizontal overflow, every figure loaded, and any interactive behaviour asserted rather than eyeballed. Write one screenshot of the result to the scratchpad and report the numbers.

## Recurring tasks

A new component when content outgrows a table · the phone check on every release · fixing a layout bug from a screenshot · keeping the screenshot rigs working when the vault host changes

## On the board for this role

- **T11** · [The chat pane inside a vault: route through sg.llm instead of a pasted key](../board.md#T11) (backlog, medium)
- **T3** · [Investors page: print stylesheet and a one-page PDF export](../board.md#T3) (backlog, medium)

Other roles: [Sherpa](sherpa.md) · [Publisher](publisher.md) · [Auditor](auditor.md) · [Journalist](journalist.md) · [Cartographer](cartographer.md) · [Ambassador](ambassador.md) · [Release engineer](release-engineer.md) · [Historian](historian.md) · [Starting prompts](../prompts.md) · [The board](../board.md)



==============================================================================
# Release engineer, an agentic role on sgit.ai

> Ships the site, build, validate, push, and refuse to call a release done until sgit.ai is actually serving it.
>
> Page: https://sgit.ai/team/roles/release-engineer.html

[Home](../../index.md) / [Team](../index.md) / Release engineer

Agentic role · 8 of 9

# Release engineer

| Mission | Ships the site, build, validate, push, and refuse to call a release done until sgit.ai is actually serving it. |
|---|---|
| Owns | admin/build/release.sh, the validator, the CI tag gate, and the version bump |
| Not responsible for | what goes in the release (the Sherpa) or the words about it (the Journalist, the Historian) |
| Works in | `admin/build/release.sh` · `admin/build/validate.js` · `.github/workflows/deploy-pages.yml` · `admin/build/build_pages.py (SITE_VERSION)` |
| Checks it runs | SITE_VERSION matches the commit subject; validate passes including the leak tripwire; git HEAD equals origin/dev after the push; the live site serves the new version before the release is reported; the tree is clean after |

## What the role does

The site ships over git: a push to `dev` triggers the GitHub Pages deploy. A release is not done when the push succeeds. It is done when the live site is polled and serves the new version, because two releases in August pushed cleanly and never deployed, and nobody noticed for forty minutes.

Before the build, the release pulls the **board vault** (`admin/content/team/issues/`, a separate vault with its own key) so the board snapshot it renders is current. Until v0.2.76 the site folder was itself an sgit vault pushed on every release; that mirror was retired and purged in September 2026. The reasons are in [the case study](../../case-studies/one-tree-two-remotes.md). Nothing in the release depends on it any more.

The CI tag gate reads the commit subject, not the version constant: a subject of `site vX.Y.Z: …` tags the release; anything else publishes without a tag. A missing tag is a bookkeeping gap; a blocked deploy is an outage.

## The rules it enforces

- **`release.sh` is the only way to ship.** It pulls the board, builds, validates, pushes git, polls the live site, and aborts loudly at each gate.
- **Never print a vault key.** Release logs get pasted into chats. The demo vaults' write keys live in the gitignored `admin/local/demo-keys/`, and the validator scans every tracked file for each of them.
- **Do not touch `SITE_VERSION` while a release is running**: its live check reads that value mid-run.
- **The version-log entry for the current release says `this release`**; the next release fills in its git commit id from `git log`.
- **A dirty tree after release is reported**, not ignored: it is the next release's work, or a bug.

## Starting prompt

You are the release engineer for sgit.ai. The Sherpa has scoped release VERSION: ONE_SENTENCE. Confirm `SITE_VERSION` in `admin/build/build_pages.py` matches and the top VERSION_LOG entry exists with 'this release' as its commit. Run `python3 admin/build/build_pages.py`, then `node admin/build/validate.js`; stop on any failure and report it verbatim. Then run `./admin/build/release.sh "site VERSION: SENTENCE"` and wait for `release complete`. Report the git commit id, the live version curl returns, and any dirty files. Do not report the release as live until the live check says so.

## Recurring tasks

Every release · fixing the validator when a new content shape needs a new rule · reconstructing tags when CI and history disagree · rotating a demo vault's key if one is ever exposed

## On the board for this role

- nothing open

Other roles: [Sherpa](sherpa.md) · [Publisher](publisher.md) · [Auditor](auditor.md) · [Journalist](journalist.md) · [Cartographer](cartographer.md) · [Ambassador](ambassador.md) · [Designer](designer.md) · [Historian](historian.md) · [Starting prompts](../prompts.md) · [The board](../board.md)



==============================================================================
# Historian, an agentic role on sgit.ai

> Keeps the record straight, the version log entry that says what a release did and what it got wrong, the corrections recorded above the mistakes, and the numbers that must be computed rather than typed.
>
> Page: https://sgit.ai/team/roles/historian.html

[Home](../../index.md) / [Team](../index.md) / Historian

Agentic role · 9 of 9

# Historian

| Mission | Keeps the record straight, the version log entry that says what a release did and what it got wrong, the corrections recorded above the mistakes, and the numbers that must be computed rather than typed. |
|---|---|
| Owns | VERSION_LOG, the corrections convention, and the reality documents that say what is shipped versus argued |
| Not responsible for | deciding what to build, or writing the public-facing update (the Journalist does, from the log) |
| Works in | `admin/build/build_pages.py (VERSION_LOG)` · `admin/versions.html (generated)` · `admin/content/case-studies/` |
| Checks it runs | every release has a log entry written before it ships; every correction names what was wrong and how it was caught; no note contains a table tag (the build asserts it) |

## What the role does

The version log is the site's memory, and it is written for the next agent, not for a changelog reader. An entry says what changed, *why*, what it cost, what went wrong on the way, and how the mistake was caught, so the rule it produced is attached to the failure that produced it. This month's entries record a leak call retracted after a negative control, a band count corrected after `git show`, and a validator that was hard-coded with the secret it was meant to detect.

## The rules it enforces

- **Record the failure with the fix.** The method page's rules each name the mistake that produced them.
- **Corrections above the mistake.** A correction is a new entry that names the old one; the old text is amended in place *and says so*.
- **Compute, don't type.** Any count that appears on a page is generated from the thing it counts.
- **Notes are prose.** A literal table tag in a log note derails the markdown emitter three files away; the build refuses it by name.

## Starting prompt

You are the Historian for sgit.ai. Release VERSION is about to ship. Write its VERSION_LOG entry in `admin/build/build_pages.py`: what changed and why, what it cost, what went wrong on the way and how it was caught, and any rule that came out of it, in prose, no table tags, no numbers that a page computes. Set its commit to 'this release' and fill in the previous entry's git commit id from `git log --oneline`, prefixed `git `. If this release corrects an earlier one, say which, what was wrong, and how it was found.

## Recurring tasks

A log entry per release · recording corrections · turning a repeated mistake into a rule on the method page · the reality document when a claim needs a shipped-versus-argued split

## On the board for this role

- nothing open

Other roles: [Sherpa](sherpa.md) · [Publisher](publisher.md) · [Auditor](auditor.md) · [Journalist](journalist.md) · [Cartographer](cartographer.md) · [Ambassador](ambassador.md) · [Designer](designer.md) · [Release engineer](release-engineer.md) · [Starting prompts](../prompts.md) · [The board](../board.md)



==============================================================================
# graphs.sgit.ai, A node is just a node, meaning lives in the edges, sgit.ai

> A grammar for semantic graphs, argued in increasing depth from five rules you can apply tomorrow to a full positioning against schemas and vector search. It opens by insisting it is not a graph database pitch, and it publishes the four situations in which its own argument is the wrong one.
>
> Page: https://sgit.ai/network/graphs.html

[Home](../index.md) / [Network](index.md) / graphs.sgit.ai

# graphs.sgit.ai

A node is just a node, meaning lives in the edges

Screenshots captured 2026-08-21 · `v0.1.0` when captured · [SGit-AI__Website__Graphs ↗](https://github.com/SGit-AI/SGit-AI__Website__Graphs)

[Open graphs.sgit.ai ↗](https://graphs.sgit.ai)

## The claim is about edges, not storage

The hero states the whole thesis in two sentences and then proves it with the smallest possible example. Two nodes both hold the value `8080`. One is connected to a type, which is connected to a library, which is connected to a version; the other is connected to nothing.

**The difference is not in the value. The difference is in the connectivity.**

The source formulation is dated and attributed, as everything on that site is:

*"in our graph we do not use properties, because properties do not have meaning, they are just words; we capture meaning through connectivity."*, Dinis Cruz, 26 June 2026, in an architecture brief about digital twins

The home page: the thesis, the sourced quote, and the disclaimer immediately under it.

**And then, before anything else, a disclaimer**, which is the reason this entry leads with it rather than with the grammar:

**Read this before you read anything else: this is not a graph database pitch.** The claim is that one grammar is the interface at every boundary, *not* that we store things in a graph. There is no graph database anywhere in the work behind this site, and we say so on its own page.

A site about graphs whose first move is to disown the product category a reader expects to be sold is doing the same thing [sg-sentinel.sgit.ai](../network/sg-sentinel.md) does with its `NOT BUILT` banner. The house rule holds: publish the work, then say precisely what it is worth.

## The story that needs no background

The best argument on the site needs no security or graph knowledge at all.

Everyone knows expertise takes **10,000 hours**. The number comes from a 1993 study of violinists, where it was an *average*, not a threshold, and half the top group had not reached it. The original author spent much of his career correcting the popularisation.

**None of the corrections ever attached to the claim.** By then it had been carried through a citation graph of 242 papers and 200,000+ citation paths, every one of them leading back to a reading the source never supported. A document cannot fix that: the correction is a new document, and nothing connects it to the thousands that already rest on the error.

A graph can. Mark the claim superseded, and every path that rested on it becomes a query, *what did we build on this?*, rather than an archaeology project. That is the concrete thing a graph does that a document cannot, and it is why the depth pages insist on **supersede, never delete**.

## Five rules, and one banned edge

`/grammar/` is the page to keep open while drawing a graph, and, explicitly, *"the page an agent should be given before it starts emitting one."* Every edge is a verb, stated in both directions, and both directions get a name worth saying out loud:

| Edge | Its inverse | Reads as |
|---|---|---|
| `owned_by` | `owns` | this system is owned by this team · this team owns this system |
| `gives_rise_to` | `arises_from` | this vulnerability gives rise to this risk · this risk arises from this vulnerability |
| `backed_by` | `evidences` | this fact is backed by this evidence · this evidence evidences this fact |
| `grants` | `granted_by` | this role grants this permission · this permission is granted by this role |

The test for an edge is not "is this technically the reverse?" but **"would a person in this business say this sentence?"**

And `relates-to` is banned outright:

*"You can never have relates-to, because relates-to is meaningless, two things always relate to each other. The more granular the edge, the better the query you can write."*

The reason given is mechanical rather than aesthetic: an edge with no verb carries no constraint, so it cannot narrow a traversal. It costs fan-out and buys nothing. **The granularity of the verb is the precision of the query.** The remaining rules: rich nodes are good (solve the picture at query time, never by removing relationships), and never render the whole graph, render the result of a query.

The grammar page: the one-screen version, the verb/inverse table, and the ban on `relates-to`.

`/grammar/edge-set.html` carries the working set, 15 established edges, proposed inverses labelled as proposed, and a numbered gap (`G5`) where a glossary the corpus cites does not actually exist in the repository. The site also records that **the project breaks its own rule** in its own shipped configuration, and names where.

## What ships, what is argued

`/shipped/index.html` is the page to read first if you are deciding whether to trust the rest, and it says so. Its opening concession is the sharp one: *"this site's subject matter is almost entirely design."*

What is running, and checkable by opening the repository:

| What | The detail that makes it checkable |
|---|---|
| The vault commit DAG | Content-addressed objects, the identifier is a SHA-256 of the **ciphertext**, with multi-parent commits, a tree per directory, HMAC-derived deterministic refs, wave-BFS merge-base over all parents, and three-way merge |
| A graph of graphs | Typed `*.link.json` edges between vaults, optionally pinned to a commit in the target's history, a cross-graph edge that cannot silently follow a moving target |
| A read-only query API over the DAG | `sg.history.log / list / read / readText / readBlob`, exposed to *untrusted sandboxed apps* |
| A live typed property graph | The issue tracker's own data: 12 node types, 10 verb/inverse edge types with domain and range constraints, **71 nodes and 141 edges across 107 issue files** |
| Three published vaults | The regulation graph, the Risk Graph Explorer, agentic browser isolation |

Every number on the site is labelled live or parsed-from-a-design-document, and the two are never mixed. The line that ties it back to us is the project's own description of the shipped layer: *"what we've built is not fundamentally an encryption system. It is a content-addressed, portable, storage-agnostic version control protocol."* A commit DAG is a graph, and it is the one graph on that site that has been running for months.

The reality page: the ships-versus-argued table, with the absence of a graph database stated at the top.

## Where it says it loses

`/about/participant.html` is the most unusual page, and worth the click. It opens by applying the site's own thesis to itself (*"provenance should be traversable and the interested party should be a visible node; that applies to us"*) states the conflict plainly (*"if the argument on this site is right, the products we build are more valuable"*), and then lists **four situations where this approach is the wrong one**:

1. **Everyone already agrees, and always will.** One team, one codebase, one jurisdiction, stable vocabulary, no external party, a schema is simpler and faster. *"No boundary, no benefit."*
2. **You need the answer enforced, not computed.** "This field must never be null" is a validator's job. Some systems need a gate, and a gate is a schema.
3. **The graph would be empty.** Edges are work somebody has to do; where nobody has done it, similarity search wins outright.
4. **You want to buy it rather than build it.** The semantic layer is designed, not shipped.

## Why it is relevant here

Three connections, and the third is the one to watch.

**The commit DAG is already a graph.** The one indisputably shipped item on that site is sgit's own object model, content-addressed over ciphertext, multi-parent, with a real merge-base. The grammar argument and the vault are not neighbours by theme; they share a data structure.

**The query API is the vault's read model.** `sg.history.log/list/read` handed to untrusted sandboxed code is exactly the surface the [vault demos](../demos/index.md) run on. A graph query interface that an app you do not trust may call is a zero-knowledge story as much as a graph one.

**It is the first sibling that links back.** Its nav carries an `↗ part of sgit.ai` chip, and its footer links to this network page directly. Until now the network was a one-way index; this is the first entry that closes the loop.

**One correction to pass upstream.** The graphs site's footer links to `sentinel.sgit.ai`, which does not resolve. The site is at [`sg-sentinel.sgit.ai`](../network/sg-sentinel.md), the `sg-` prefix is load-bearing. Checked 2026-08-21.

## Sections

- **Start here** (the five-minute version, why graphs at all, glossary
- **The grammar**) the five rules, and the working edge set with its numbered gaps
- **Depth** (the full argument, and a graph at every boundary
- **Examples**) browser isolation, the 2FA graph, Article 26(5) end to end, Wardley maps as graphs
- **Reality**, what ships and what is argued
- **Site**, the source documents in full, release history, and the participant disclosure

[← All network sites](index.md)



==============================================================================
# nhi.sgit.ai, Agents you run, agents you rent, and the identity gap, sgit.ai

> The question of how to give an AI agent an identity splits into two populations, and every product on the market answers only the first. For the agents you actually name (the ones running in Claude, Codex or behind an API) the honest current answer is to hand over a broad credential and hope.
>
> Page: https://sgit.ai/network/nhi.html

[Home](../index.md) / [Network](index.md) / nhi.sgit.ai

# nhi.sgit.ai

Agents you run, agents you rent, and the identity gap

Screenshots captured 2026-08-19 · `v0.1.14` when captured · [SGit-AI__Website__NHI ↗](https://github.com/SGit-AI/SGit-AI__Website__NHI)

[Open nhi.sgit.ai ↗](https://nhi.sgit.ai)

## The distinction the whole site turns on

**Agents you run** execute on your infrastructure. You can attest the workload, install an identity agent, and control everything. An open standard, SPIFFE, issues short-lived cryptographic identities on exactly that basis.

**Agents you rent** execute on somebody else's. You cannot attest the workload, cannot install anything, and the only thing you control is the credential you hand over.

The site puts the two side by side and lets the table make the argument:

The home page, with the two-population comparison directly under the thesis.

The last row is the one that lands: for agents you run, the industry answer is *"mature, and expensive"*. For agents you rent, it is *"none"*. SPIFFE is described by practitioners as a multi-year engineering project needing a dedicated team; for rented agents, the equivalent capability is an open feature request.

## "Hope is not a control"

The site names the current practice rather than describing it politely. When you hand an agent a broad credential you are making **two hopes**: that it will not misuse what it holds, and that it will not discover the rest of what that credential actually reaches. Neither hope changes your accountability, which runs to the board.

The second hope is the one most people have not costed. The site's framing is that **the real authorization is the closure**: inbox access is every account resettable by email; desktop access is every stored credential. The grant is not the words in it. It is everything reachable from them.

The thesis page: the argument with citations, rather than assertion.

## Why it is relevant here

This is the problem sgit's [read keys](../demos/vaults/index.md) and [append lanes](../api/append-lanes.md) are shaped against. A published read key is a credential whose closure is *provably* bounded, it opens one vault, cannot write, and cannot be turned back into write access. An append token can write to one lane and cannot read it.

The [comparison pages](../compare/index.md) use a privilege vocabulary (scope, operations, bearer, mediation, duration, withdrawal, observability) that is the same question asked in a different register.

## Sections

- **Thesis** (the two populations, with citations
- **Hope**) why the current workflow is hope-driven, and what the two hopes cost
- **Method** (from hope to controls: enumerate, bound, observe, contain, account
- **Options, Industry, Collection**) what exists, what it costs, and the open questions

[← All network sites](index.md)



==============================================================================
# pki.sgit.ai, A key registry for agents, designed from a documented failure, sgit.ai

> Good public key repositories existed and were destroyed. This site is the 2019 keyserver catastrophe, the four registry rules it produces, and the build order, all published before the registry exists, so the commitments are checkable against whatever eventually ships.
>
> Page: https://sgit.ai/network/pki.html

[Home](../index.md) / [Network](index.md) / pki.sgit.ai

# pki.sgit.ai

A key registry for agents, designed from a documented failure

Screenshots captured 2026-08-19 · `v0.1.2` when captured · [SGit-AI__Website__PKI ↗](https://github.com/SGit-AI/SGit-AI__Website__PKI)

[Open pki.sgit.ai ↗](https://pki.sgit.ai)

## Publishing the design before the implementation

The premise is unusual and worth stating plainly: **this site describes a registry that does not exist.** That is deliberate. Publishing the rules now is cheap; claiming them afterwards is impossible. If something ships that breaks one of them, the site is the evidence.

The home page. The claim is historical before it is technical.

## The failure it is designed from

In 2019 the global keyserver network was flooded with garbage signatures until importing a poisoned certificate would break your installation. Its own maintainer called it **unsalvageable**. The cause was not a bug. It was a design goal stated at the outset.

That design goal was **append-only**. And append-only is a pattern this project relies on in five places, which is exactly why a shrug would not do. The site's resolution is a precise one, and it is the most useful idea on the page:

- **Append-only, owner-writes**: only the record's owner may write to it. Every entry is attributable because the owner signed it; a record grows slowly, in one hand; something can be withdrawn by a signed append that supersedes it.
- **Append-only, anyone-writes**: anybody may grow anybody's record, without limit, and garbage is indistinguishable from signal. Nothing can ever be withdrawn, by design. This destroyed the network.

The rule to carry forward is **not** "append-only". It is *the writer owns what it writes*.

## The four rules

Each one turns around a specific property the 2019 attack abused:

Each rule states the property it turns around, so it can be checked rather than trusted.

1. **Only the owner writes to their own record**: turns around *anyone may append to anybody's certificate*.
2. **Revocation is a signed append, not a deletion**: signed by the key being revoked, so it is self-authenticating, the record stays append-only, and what a key said before revocation stays checkable.
3. **Records are size-bounded**: one poisoned key reached about 150,000 signatures because certificates had no limit. The bound is a stated parameter, with the honest cost that it will one day reject a legitimate record.
4. **Every entry is signed**, so nothing anonymous can accumulate.

Rule 2 is the one to notice. Deletion and append-only are usually treated as incompatible; making revocation a *signed statement appended by the revoked key itself* resolves the contradiction without weakening either property.

The history, in five minutes, sourced rather than summarised from memory.

## Why it is relevant here

sgit's own [PKI](../docs/pki.md) ships keypairs today (RSA-OAEP 4096 for encryption, ECDSA P-256 for signing) and has **no revocation, no directory and no web of trust**, which [the limitations page](../docs/limitations.md) says plainly. This site is the design work for what a directory would have to be before it could responsibly exist.

The connection to [append lanes](../api/append-lanes.md) is direct: a lane is append-only and *owner-configured*, a sender writes only to a lane the owner registered for them. That is rule 1, already shipped, in a different corner of the system.

## Sections

- **The failure** (2019, with sources
- **The rules**) four commitments, each tied to the property it turns around
- **Mandate**, what a registry would be for
- **Build order**, private before public, and why

[← All network sites](index.md)



==============================================================================
# sg-sentinel.sgit.ai, An app-coupled edge guard, Layer 1 decides, Layer 2 acts, sgit.ai

> A design for an edge security and logging layer you own rather than rent, built on the observation that your own app already knows what a valid request looks like, so the edge can allowlist rather than denylist. Published as a complete design that has deliberately not been built.
>
> Page: https://sgit.ai/network/sg-sentinel.html

[Home](../index.md) / [Network](index.md) / sg-sentinel.sgit.ai

# sg-sentinel.sgit.ai

An app-coupled edge guard, Layer 1 decides, Layer 2 acts

Screenshots captured 2026-08-20 · `v0.1.1` when captured · [SGit-AI__Website__SG_Sentinel ↗](https://github.com/SGit-AI/SGit-AI__Website__SG_Sentinel)

[Open sg-sentinel.sgit.ai ↗](https://sg-sentinel.sgit.ai)

## It says, at the top of every page, that it does not exist

This is the most unusual thing on the network and the reason to read it. A banner sits above every page:

**Not built.** SG/Sentinel is a published design from May 2026, *"this is how I would build it"*, not a product. No plans to build it unless somebody funds it.

The status pill reads `NOT BUILT` where its siblings read `MVP DRAFT`. And the note goes further than a disclaimer usually does: the design exercise produced an agent-built prototype whose testing manual reports **149 passing tests**, and the site immediately bounds what that means, *"not deployed anywhere, not in production use, not maintained, and not packaged for you to install. Every 'built' or 'proven' on this site refers to that prototype exercise, nothing more."*

That paragraph is the whole house style in one place: publish the work, then say precisely what it is worth.

The home page, with the not-built banner above the thesis and the full status note below it.

## The problem, and the inversion

Edge security and logging today means renting AWS WAF plus CloudWatch and Kinesis Firehose. The site names three costs, no real-time view of your own traffic, logging priced per gigabyte for a job that is *"write a clean record to S3"*, and a WAF you cannot reason about, and one origin story underneath them: *a single client-side bug once caused runaway redirect traffic, and nothing at the edge would catch the next one before the bill did.*

The inversion is the good idea. A generic WAF is blind to the application it protects, so it **denylists** known-bad and passes everything else. But if you control both client and server, the edge knows the valid request space, so it can **allowlist**, and no invalid request reaches the origin at all.

## One correction that reshaped the design

The architecture page opens with a governing constraint, and it is a genuinely instructive piece of engineering writing:

**Layer 1 never acts and never writes, it only decides and signals. Layer 2 is the sole actor and the sole I/O owner.**

The reason is physical, not stylistic: a CloudFront Function has no network and no filesystem, so it *cannot* write to S3 and must not enforce. L1's whole job is to assign a request ID, evaluate deterministic rules, and emit a structured signal. Blocking, deflecting and logging are **actions**, and actions belong to the layer that can perform I/O. L1 can only *recommend* a block.

The site is explicit that this corrected an earlier version of its own design in which L1 blocked inline, a category error, named as such.

The layer model: one actor, one I/O owner, and both use cases flowing through a single path.

## Rules are the engine, not configuration on it

The second inversion: *"rules are not configuration on top of a fixed engine, rules are the engine."* The core is a small stable machine for executing them, and every block, allow and log action is a rule. Each is a pure function `(captured) → {verdict, reason, rule_id, action} | null`, run in order, first block wins.

The MVP core is deliberately tiny, six deterministic rules, each mapped to an ATT&CK technique:

| Rule | Catches | Action |
|---|---|---|
| `capture-all` | every request; pure observation and the allow fallthrough | pass |
| `banned-ip` | source IP in the embedded list | `drop_403` |
| `malformed-request` | no method, no path, path not starting `/` | `drop_403` |
| `path-never-valid` | `/etc/passwd`, path traversal | `drop_403` |
| `hidden-file-probe` | `/.env`, `/.git/…` | `deflect_404` |
| `wp-scan-on-static` | `/wp-login.php`, `/xmlrpc.php` on a static site | `deflect_404` |

Rules are data, versioned in git, carrying their own metadata. The prototype exercise ran the same engine across **three targets** with a parity matrix asserting identical decisions, which is what makes "rules are data" a testable claim rather than a slogan.

The six rules of the tiny core, each with what it catches, its ATT&CK mapping and its action.

## Why it is relevant here

Two connections, and the second is the sharper one.

**Rules as versioned data** is what sgit is for. A rule set that must be auditable, diffable and attributable, but whose contents may reveal exactly what you are watching for, is a natural fit for a vault: git semantics over content the host cannot read.

**And it is the third site here to publish a design before the thing exists.** [pki.sgit.ai](../network/pki.md) publishes four registry rules before the registry; this one publishes an entire architecture and then declines to build it. Both rest on the same wager: *publishing the design now is cheap, and claiming it afterwards is impossible.* If somebody does build this, the parity matrix and the six rules are already on the record.

## Sections

- **Architecture** (the layer model, the signal spine, the three targets
- **Rules**) rules as data, the six-rule core, and where the graph goes
- **Research** (68 days of design, tabletop-tested
- **Try it · Code · Roadmap**) the prototype snapshot and what would come next

[← All network sites](index.md)