Append-only by construction
Entries cannot be edited or deleted by any actor including our own engineers, and each is hash-chained to its predecessor so a gap or alteration is detectable rather than invisible.
Platform · trust
Every system has an audit log. Very few answer the question auditors actually ask, which is not what changed but why it changed, on whose authority, and what the state was immediately before. A log of field diffs cannot answer that, and with agents in the picture it becomes the difference between a defensible record and a misleading one.
What it does
Entries cannot be edited or deleted by any actor including our own engineers, and each is hash-chained to its predecessor so a gap or alteration is detectable rather than invisible.
A person, an agent, an API key, and a portal user produce entries in the same format. Auditors read one trail rather than correlating four.
For an automated action: the inputs it read, the policy that permitted it, the confidence, and the alternatives it rejected. That is what makes an automated decision reviewable.
Every entry carries the specific grant that permitted it, so the question of whether somebody was allowed to do this is answered by the record rather than by a separate permission report.
Any record can be reconstructed as it stood at any past moment, which is how a question about what the balance looked like before an adjustment gets a direct answer.
By actor, object, entity, period, or authority, exported in a format an auditor can work with directly rather than screenshots of a search screen.
The standard log records that a user changed a field from one value to another at a timestamp. That is sufficient when the question is whether somebody tampered with a number. It is insufficient for every other question an auditor asks.
Was this person authorised to make that change at that value in that entity? What was the approval that permitted it? What did the record look like before the chain of changes started? A diff log answers none of those, so the answers are assembled by hand from permission exports, email threads, and memory.
When a person codes an invoice, the reasoning lives in their head and the audit standard has always been to accept that. When an agent codes an invoice, there is no head, and a log entry saying an agent set the account to 6400 is not a record of a decision — it is a record of an outcome.
So every automated action stores what it read, which policy authorised it, what confidence it assigned, and what it considered and rejected. A reviewer can evaluate the decision rather than only the result, which is the only basis on which automation becomes auditable at all.
Append-only is a claim that has to survive the question of who can bypass it. Ours is enforced at the database level with no update or delete path exposed to application code, and each entry hash-chains to the previous one so removal or alteration breaks the chain.
Our own engineers cannot edit it either. Break-glass production access is itself logged into the same trail, time-bound, dual-approved, and reported to you. A control that exempts the vendor is not a control.
Seven years by default, longer on request, with export at any time. The log survives the deletion of the records it describes, because the question of who deleted something is precisely the one you need answered after it is gone.
Limits
A full-fidelity trail of every actor, including reasoning on automated actions, is a substantial amount of data. That is a cost we accept rather than sample away.
Changes made directly in a connected system are recorded as observed at sync, not as authored. Their own log remains authoritative for their own actions.
A small number of our engineers can reach production under time-bound, dual-approved, reported access. Claiming nobody can would be untrue.
Questions
We will show you exactly what the trail returns for each item on it.