Workflows & vaults
This is also a worked example of the kind of company that can be built on sgit and encrypted vaults + Vault Apps — the commission's own note. No new infrastructure was invented for this business.
The pipeline already exists
A debrief from 29 March 2026 records the exact workflow, already run: credit card statements shared into a vault by short token, an agent cloning it, working inside the vault, committing and pushing back, the human pulling and seeing exactly what changed — a genuine shared workspace, persistent and versioned across sessions.
| The March workflow | This service |
|---|---|
| Statements as raw input | The same |
| Parse into a ledger | Parse into a subscription inventory |
| Agent works inside the vault, versioned | Unchanged |
| Shared by a short token | Unchanged |
| Output: an accountant-ready pack | Output: a claim file per subscription |
Only the destination changes — the novel work is the legal mapping and the claim file, not the plumbing.
The vault architecture — three stores, three rules
| Store | Holds | Rule |
|---|---|---|
| The person's own vault | Statements, the claim file, full responses, anything identifying them | A completed claim file is a concentrated dossier of one person's financial life — it belongs to them; the operator holds only what a live claim requires |
| The public register vault | Company rows, dates, verbatim replies (details removed), exit measurements, templates, parsers | The unit of the register is a company's behaviour, never a person's case — CC BY, re-pointable to a neutral domain at the split |
| Per-provider parser workspaces | The template for that provider, the known reply shape, the extraction workflow | One person works out how to parse one provider's export, and everybody after them gets it for nothing — the crowdsourced asset is the parsers, not the data |
The honest vault claim
Publishing the last row of this table is the network's standing discipline: a page that names where its own approach loses is what makes the rest of it credible.
| Property | True? |
|---|---|
| The client holds their own evidence pack and can take it elsewhere | Yes |
| Sharing with a specific party is a key rather than an account | Yes |
| The store cannot read it | Yes |
| Every change versioned — what was submitted when is answerable in a dispute | Yes |
| The agent reading the statements cannot see the contents | No — it reads plaintext |
Vaults buy portability and controlled sharing, not zero knowledge. An agent that reads bank statements to find subscriptions is reading plaintext, so the privacy claim for the processing step is operational (we do not retain it) rather than architectural (we cannot see it).
Bring-your-own-model, by default
Being the meter puts an operator in the request path, and the content passing through here is bank statements — more sensitive than most of what this network has metered before. So the ordering is inverted from the usual:
| Mode | Position |
|---|---|
| Bring your own model | The default. The claim stays architectural, and nothing passes through the operator. |
| Hosted, metered per token | The convenience option, priced per extraction, with retention stated structurally rather than promised. |
The access-request workflow, with its constitution
A subject access request is the discovery engine behind an entry — representative requests must be honoured, with a high threshold for refusal and one month to respond. The ask-list is ordered by claim value: usage and access logs first (converts a feeling into a record), then the sign-up record, consent records, billing history, correspondence, and the terms in force at the time — not today's website.
Every access request is a genuine request for the person's own data, sent because they want it. It is never sent as leverage, never bundled with a demand, and never sent in a volume calculated to burden.
Merit is tested before the request, never after, and the decline rate is published once the service exists to publish one. Authority to act is captured as evidence, not assumed — an authority-capture workflow is one of the items blocking the register's first entry.
The showcase, in one paragraph
A consumer service where the client's file lives in the client's own vault, the operator is thin and serverless, the shared asset is workflows in vaults — parsers, templates — the register is published data in a re-pointable vault, metering is a generic ledger, and the model is bring-your-own-model first because the meter costs the privacy claim. Assembled from primitives that already existed: the March pipeline, the vault architecture, the comparison-page discipline, the store-the-choices-not-the-answers rule. The sgit business-model argument, in one worked example →