Where the evidence lives
What is written down, which surfaces are only projections of it, and what you can read without our tooling.
There is one thing to understand before you open any of these surfaces, and it changes how you cite them.
The readable files are projections. They are not the source. Registries of actors, delegations, machines, seats and capabilities are one signed, append-only log. Nothing in it is edited in place — a status change is a new entry, and a read resolves to the latest entry for that subject. The human-readable registries people browse day to day are regenerated views over that log.
Two consequences for an audit. Deleting or losing a readable file destroys no evidence, because it can be regenerated. And a readable file is never the artefact to cite for non-repudiation; the signed log is. If you are handed a rendered registry as proof of an admission, ask for the signed entry behind it.
The surfaces, and what each one is good for
| Surface | What it holds, and how to treat it |
|---|---|
| The signed governance log | Admissions, delegations, seats, capability grants — every act of governance, in order, each one signed. This is the artefact for who was allowed to do what, on whose authority. Verifiable against your root public key alone. |
| Gate rows | One row per decision — the actor, the decision from a closed set of words, the time, and the evidence the decision rested on. saphan gates renders them for reading. This is the artefact for who approved this, and on what basis. |
| Run records | One row per run — what ran, under which configuration and which standing instructions, what confined it and which directories stayed writable, the cost, the timing, and on a refusal the rule and the reason. This is the artefact for what actually happened, as distinct from what was asked for. |
| The refusal ledger | Refusals with their named class and reason, recorded as ordinary data. This is the artefact for the controls firing, not merely existing. |
| The cost ledger | The quote set before a run, the actual, and the drift, recorded beside the evidence for the same work rather than on a separate invoice. This is the artefact for what this change cost, answered the same way and in the same place as who approved it. |
| Your version control | The commits, branches and change requests themselves. The product observes them and does not write to them. |
Where the record physically sits
The record store runs on infrastructure you control, and it is readable with ordinary database tooling — the product's own surfaces are views over it, not gatekeepers of it. Alongside it, the documents that make up a stream's channel are plain files in your own repository.
Two practical facts follow. Nothing of yours needs to transit our infrastructure for the record to exist. And an export is a convenience rather than a truth — losing one invalidates nothing, because it can be produced again from the record.
Retention is yours. The record lives in your store under your own retention and backup policy. Nothing in this section sets a retention period for you, and you should not read the existence of the trail as a retention control. If your management system requires a stated retention period for change evidence, that period is a decision you record, applied to a store you operate.
The record can be rebuilt from its inputs
Ingestion of a stream's channel documents is a replayable function of what is on disk, de-duplicated by content digest. The same inputs produce the same record. For an audit this is worth more than it sounds — it means the record is not a one-way transformation whose correctness has to be taken on trust, and a disagreement about what the record says can be settled by replaying it.
Reading actor names correctly
The actor field on a gate row holds a canonical registry name — the spelling the signed actor registry holds, byte for byte. The key that signed the row lives in the signature, not in that field, because a key identifier does not survive rotation and a column of hexadecimal would destroy the readability the render exists to provide. Name for policy, key for cryptography, bound to each other.
Two things you will meet when you tally decisions by person.
A name in the log may not be in the registry. A workspace's gate log can carry decisions under names that are not enrolled — someone who used to decide under a different spelling, a service identity retired long ago, a name that predates the registry. Those recorded decisions are untouched and stay valid. What changes is that such a name cannot write a new decision. saphan actor list reports this as the roster gap and marks every name that would be refused at its next decision, with the reason. Run it before you rely on a name, and read its status word first — a gap that could not be measured is reported as unmeasured, and no conclusion about who would be refused may be drawn from it.
Old spellings are explained, never rewritten. Recorded rows bind their actor string inside the signed row, so nothing rewrites history to tidy a name. Instead a signed alias states that a historical spelling names the same person as a canonical actor, and the render shows the stored string verbatim with a marker beside it. An alias resolves names for aggregation and never a signature — enrolling or withdrawing one cannot change whether a row verifies, and it cannot make a name able to write a new decision.
For an auditor this is the right trade to have made, and it is worth saying why: a system that silently normalised names would be right almost every time, and the one time it was wrong it would have merged two identities inside signed content, irreversibly.
What you will not find in any record
No record, log or export holds a secret value. Credentials are configured as the name of an environment variable or the path to a file, never as a value; durable evidence is redacted before it is written; cost and audit records carry names, references and numbers only.
This is a property to test rather than to accept. It is also the reason an export can be handed to a reviewer without a redaction pass of your own.
What an auditor asks next
- Can I get a period export in a format my working papers accept? The record is queryable in your own store and the product renders its rows for reading. A defined export artefact for an audit period is not documented in this section — treat producing one as work you scope, against a store you already have access to.
- Which fields exactly? The field-level detail of machine admission, capability grades and confinement claims belongs to the security and operations sections, and the vocabulary the record uses is in concepts.