Reference
Concepts
The Vault is built on one idea: an append-only, hash-chained record of what your agents knew and did. A handful of concepts explain the whole product.
Events
An event is a single thing an agent recorded. Every event has a type:
| Type | Means | Example |
|---|---|---|
know | Something the agent recalled or was told | “recalled: deploy target is Hetzner” |
did | An action it took, with a side effect | “ran db.migrate on production” |
decision | A choice it made, with rationale | “chose Postgres over SQLite” |
Pairing know with did is the point: when an action goes wrong, the record shows the knowledge the agent was acting on. Fields: agent, action (a short verb like db.migrate), summary, status(ok / blocked / flagged), and a free-form payload.
The hash chain
Each event is linked to the one before it. Its hash is the SHA-256 of its own contents plus the previous event’s hash, forming an unbroken chain from a fixed genesis value. Because every link depends on all the links before it, you cannot edit, delete, or reorder an event after the fact without every later hash changing — which verification detects immediately.
Integrity verification
Verification recomputes the entire chain from genesis and compares each recomputed hash to the stored one. If they all match, the record is intact. If any diverge, verification stops at the first bad event and reports it — a broken link, a sequence gap, or altered content. Run it any time from the Integrity page or the API.
Agents
The agent field groups events by whoever produced them — deploy-bot, research-agent, one per model, one per role, however you divide your fleet. The Vault rolls up per-agent activity and blocked-action counts automatically.
Ownership & isolation
Every event belongs to your account and is visible only to you. Ingest keys are scoped to your account; the full key is shown once at creation and only its hash is stored. Revoke a key and anything using it stops recording immediately — the events it already wrote stay in the chain.