The release record
Every release writes one record. It says what went out, which rules were in force, what each of them actually established, and who signed for it. It cannot afterwards be edited.
It covers one brand and names no other
A record is generated per brand. There is no report that spans the account, because the document you hand a client or a regulator must not be one you had to redact first — the file naming your other customers is never produced at all.
The register behind it is filtered the same way. Somebody with access to one brand sees that brand’s history and no trace that the others exist.
What is in it
- What was released, and when
- A fingerprint of the content as it stood at release, the moment it went out, and the format it went out in.
- Which rules were in force
- Every rule that applied, at every level, with the wording it had at that moment rather than the wording it has today.
- What each rule established
- Per rule: whether code checked it and it passed, whether code swept for the phrases it knows and found none, whether a model reviewed it, whether nothing read it, or whether it was in force but out of scope for what was checked. The five are never collapsed into a percentage.
- What was flagged and what happened to it
- Every finding, including the ones set aside — with the reason given and the hand that gave it. A record describing a tidied version of the content would be worthless.
- Who signed, and what they were asserting
- The signature carries its meaning: authored, reviewed, approved for release, or responsible. Four different claims that used to be one word.
- Whether a model reviewed it at all
- Stated explicitly, either way. When no model review ran, the record says so in a sentence rather than leaving the reader to infer it from silence.
Why it cannot be edited
The record and the register are append-only in the database: they carry a policy for reading and a policy for inserting, and none for updating or deleting. A delete affects no rows for anyone, including the account owner who released, and including us.
One update is permitted, and it is the only one. When a person exercises their right to erasure, the columns naming them are replaced with an erasure token — and a trigger checks that the new value is exactly that token, that the person really has been erased, and that every other column in the row is byte-for-byte unchanged, hash included. Anything else is refused. The entry still stands and still says what happened; it stops saying who.
Two things worth knowing, because a guarantee stated without its edges is not a guarantee. This is enforced at the database, so there is no path through the application that can rewrite an entry — but a migration running as the database owner can disable a trigger, and one has, once, for a single documented backfill statement inside a transaction. And model_calls and import_outcomes are append-only because nothing grants them an update policy, which binds every customer and does not bind our own service role. The record and the register above are the ones with the trigger.
That has a cost, and it is deliberate. A wrong entry is corrected by a later entry that says so, never by editing the first — because a history that can be tidied before an audit answers nothing, and the only version of this worth selling is the one you cannot quietly fix.
What it does not claim
A record is evidence that a control ran, not a warranty that the content is compliant. Where a rule needed human judgement and got it, the record names the human. Where it needed human judgement and did not get it, the record says that too — which is the sentence most tools in this category will not print.
