Platform
A complete record of AI activity
Search the record by person, system, policy or outcome. Every entry is sealed at the moment the decision is made and cannot be edited afterwards.
The record
Entries
240
Editable
0
after sealing
25 of them are refusals or holds. A trail of only successes cannot answer what an agent tried to do.
Why this is not a log
Sealed when the decision is made, and chained to what came before.
Permissions are a claim about who can edit a record. A chain is a property that makes an edit detectable even by someone who could make it — and that difference is the one an auditor actually cares about.
- Sealed at decision time
- Written as part of the decision, before the response returns. Not shipped to a collector that might be behind, so there is no window where the action has happened and the record does not say so.
- Chained, not just protected
- Each entry carries the digest of the one before it. Permissions are a claim about who can edit; a chain makes an edit detectable even by someone who could make it.
- Names the version in force
- Which version of which policy decided this. An entry from before a rule changed stays explainable afterwards, which is the whole point of writing it down.
- Contains the refusals
- Denials, holds and expiries are records too. A trail of only successes cannot answer the first question anyone asks after an incident, which is what the agent tried to do.
The record includes what was refused.
25 of the 240 entries in the sample estate are holds or denials. Teams are often surprised to want this, right up until the first time somebody asks what an agent attempted — at which point a trail of successes turns out to be the wrong artefact entirely.
A refusal is also the more informative entry. An authorized action tells you the system worked; a pattern of refusals tells you something is reaching for what it was never granted.
The evidence ledger
Every decision, with the record before it named.
Read the Chains-to column against the Digest column of the row beneath. Each entry names its predecessor, which is what turns a set of records into a sequence that cannot be quietly shortened.
Evidence ledger
240 entries · none editable| Record | What it was for | Subject | Decided | Policy version | Chains to | Digest |
|---|---|---|---|---|---|---|
| EV-7740 | adjust.stock | SKU-36771 | Decision: Authorized | write.window v2 | f113ccde602b | 8aa688e42829 |
| EV-7739 | read.contract | MSA-53043 | Decision: Authorized | pii.export_block v11 | e3b7375dd66c | c3307766ab4b |
| EV-7738 | adjust.stock | SKU-57815 | Decision: Authorized | write.window v2 | 9957a40165f7 | b34da714573e |
| EV-7737 | update.record | ACC-84125 | Decision: Authorized | write.window v2 | 497d8d4dfda5 | 20db948841aa |
| EV-7736 | close.ticket | TKT-82747 | Decision: Authorized | write.window v2 | 0e2386e829ed | 773e9be89f8f |
| EV-7735 | close.ticket | TKT-7639 | Decision: Authorized | write.window v2 | 1c310ca20336 | 0b46589958bd |
What a broken chain looks like.
Removing an entry does not leave a gap — it leaves a record whose stated predecessor does not exist, and every entry after it fails to verify. Editing one changes its digest, so the entry after it now points at something that no longer matches. Either way the break is located precisely, at the entry where it happened.
That precision is the useful part. A tamper-evident trail that only tells you something is wrong somewhere is barely better than none; one that names the entry gives an investigation a starting point.
Entries
240
24 hours, sample estate
Refusals recorded
25
holds and denials
Policies referenced
8
each by version
Editable after sealing
0
by anyone
IllustrativeThe OpsAI sample estate. Open any record as a trace.
Evidence
4 records| Seq | Record | Action | Decision | Policy | Previous | This record |
|---|---|---|---|---|---|---|
| 7737 | EV-7737 | update.record | Decision: Authorized | write.window v2 | 497d8d4d | 20db948841aad218… |
| 7738 | EV-7738 | adjust.stock | Decision: Authorized | write.window v2 | 9957a401 | b34da714573e047c… |
| 7739 | EV-7739 | read.contract | Decision: Authorized | pii.export_block v11 | e3b7375d | c3307766ab4bf592… |
| 7740 | EV-7740 | adjust.stock | Decision: Authorized | write.window v2 | f113ccde | 8aa688e428297eec… |
How the record is used
Four questions, and each one has a different shape.
An audit trail is only as good as the questions it can answer quickly. These are the four people actually ask, and the fourth is the one that finds a pattern rather than an instance.
- By person
- Everything a named accountable owner answers for, including actions taken by agents they own while they were asleep. The question a performance review or an investigation starts with.
- By system
- Everything that reached Razorpay, or the ledger, or the warehouse. The question a system owner asks when something looks wrong at their end rather than ours.
- By policy
- Every decision made against a given bound and version. The question that follows a rule change: what did this actually affect.
- By outcome
- Every refusal, or every expiry, or every co-signed approval. The question that finds a pattern rather than an instance.
Searchable by person means the whole chain.
Asking what Priya Nair answers for returns the actions their agents took, not only the ones they personally triggered. That is the honest reading of accountability, and it is only possible because the authority chain is part of each record rather than something reconstructed later.
Where to start
Ask what your current trail would say about last Tuesday.
Specifically: which rule was in force, who authorized it, and whether anything was refused. If assembling that takes more than a few minutes across more than one system, that is the gap this closes.