Platform
Trace every AI operation from request to result
One action, end to end: what asked, whose authority it held, which policies applied, how they evaluated, what was decided, and what was recorded.
One action, six stages
Stages
6
End to end
11ms
Written as one record at decision time, not assembled afterwards from three systems with three clocks.
What this adds
A log says what happened. A trace says why.
Most teams already have logs and reasonably ask what this adds. The answer is the inputs: a trace carries what each stage was given alongside what it concluded, which is the difference between reconstructing an incident and merely dating it.
- The inputs, not just the outcome
- Each stage records what it was given as well as what it concluded. A log says the refund was authorized; a trace says it was authorized at eighteen thousand four hundred against a twenty-five thousand ceiling.
- The authority in force
- Whose authority the action held at the moment it ran, and how far it had narrowed from the person at the root. Reconstructing that from logs means joining three systems and trusting the clocks.
- The rule version
- Which version of which policy decided this. A log entry from before a rule changed is unexplainable afterwards; a trace names the version and stays readable.
- One record, not a correlation exercise
- Written as a unit at decision time rather than assembled later from several systems. There is no window in which the trace and the action disagree.
Sealed before the response returns.
The trace is not written after the fact by a collector that might be behind. It is part of the decision, which is why there is no window in which the action has happened and the record does not yet say so.
One action, opened up
Six stages, and every claim on this site visible in one place.
A refund proposing to move money. Read down: the identity resolved, the authority narrowed, the clauses were evaluated one at a time, the verdict was reached, and the record was sealed and chained.
ACT-7512 · issue.refund
11ms end to endThe agent asked
0 msrefund-resolver asked to run issue.refund against Razorpay for ₹18,400 on ORD-40122. Nothing has run yet.
- Passedidentityworkload-id · mTLS attested
- Passedactionissue.refund
- PassedidempotencyACT-7512
Authority traced to a person
1 msEvery hop holds a subset of the hop before it. A sub-agent cannot be talked into authority it was never issued.
- Priya NairSupport Ops
- refund-resolver⊆ parent · L3
Bounds matched
2 msTwo bounds apply. Both were written by the team that owns the risk — not by the agent, and not by a prompt.
- refund.ceiling
- delegation.depth
Bounds evaluated
6 msEvery bound held. The action is cleared to run exactly as asked — no wider.
- Passedagent.identityworkload-id · attested
- Passeddelegation.depth1 ≤ 3
- Passedamount ≤ ceiling₹18,400 / ₹25,000
- Passedscope == own-orderORD-40122 · placed by subject
- Passedorder.statusdelivered
- Passedrate ≤ 5/hour3 / 5 this hour
Decision
11 msAuthorized. The call went out with the bound attached, so it cannot widen in flight.
Decision: Authorized0 inference callsRecord sealed
13 msThe decision, its inputs and the bound version were written to the ledger before the response returned. Nothing here can be edited afterwards.
- PassedrecordEV-7512
- Passedbound versionv7 · 30 Jun 2026
- Passeddigestd7ffd0b3bab589c9f5e902…
What to look for.
- Every clause, evaluated separately
- Not one composite pass or fail. Each clause carries what the request actually presented against it, which is what makes a refusal answerable rather than merely final.
- The version, named
- v7, in force since 30 Jun 2026. When the rule changes this record stays explainable, because it says which rule decided it.
- The chain digest
- Each record carries the digest of the one before it. Removing or editing an entry breaks the chain at that point rather than quietly succeeding.
- No inference
- Zero model calls in the whole sequence. That is why it finished in 11ms and why running it again gives the same answer.
What the trace concluded
High risk, and authorized.
Risk and outcome are two different judgements. High risk does not mean stopped — it means the action was consequential enough that the rule governing it had to be checked clause by clause against a specific amount, a specific order and a named accountable owner. It cleared.
Action proposed
ACT-7512 · decided in 11 ms- Agent
- refund-resolver
- Asked to
- issue.refund
- Target
- Razorpay
- Subject
- ORD-40122
- Amount
- ₹18,400
- Policy
- refund.ceiling v7
- Approval
- Within bound
- Passedagent.identityworkload-id · attested
- Passeddelegation.depth1 ≤ 3
- Passedamount ≤ ceiling₹18,400 / ₹25,000
- Passedscope == own-orderORD-40122 · placed by subject
- Passedorder.statusdelivered
- Passedrate ≤ 5/hour3 / 5 this hour
The same action at a higher figure reads differently.
Above the ceiling this becomes a hold for a named co-signer, and the record says so — including who was asked and whether they answered before the window closed. Nothing about the trace changes shape; only the verdict and the reason differ.
That is the property that makes the record worth keeping. A trail that only contains successes is a marketing artefact; one that contains the refusals and the expiries is something an auditor can work with.
Authorized
215
inside their bound
Held
20
awaiting a co-signer
Denied
5
a clause was not met
Median
17ms
policy, not inference
Illustrative240 decisions from the OpsAI sample estate over 24 hours, not a customer deployment or a published benchmark.
Every action, traceable
The last few decisions, each with a record behind it.
Every row here opens into the same six stages. The Record column is the entry in the evidence ledger — a trace and its record are the same object read at two resolutions, not two systems that have to agree.
Recent decisions
240 decisions over 24 hours| Action | What was attempted | Subject | Amount | Authority | Decision | Latency | Record |
|---|---|---|---|---|---|---|---|
| ACT-7740 | adjust.stock | SKU-36771 | — | Anita Rao | Decision: Authorized | 17ms | EV-7740 |
| ACT-7739 | read.contract | MSA-53043 | — | Kabir Sen | Decision: Authorized | 13ms | EV-7739 |
| ACT-7738 | adjust.stock | SKU-57815 | — | Anita Rao | Decision: Authorized | 17ms | EV-7738 |
| ACT-7737 | update.record | ACC-84125 | — | Sneha Iyer | Decision: Authorized | 26ms | EV-7737 |
| ACT-7736 | close.ticket | TKT-82747 | — | Priya Nair | Decision: Authorized | 10ms | EV-7736 |
| ACT-7735 | close.ticket | TKT-7639 | — | Priya Nair | Decision: Authorized | 8ms | EV-7735 |
| ACT-7734 | read.contract | MSA-43863 | — | Kabir Sen | Decision: Authorized | 20ms | EV-7734 |
| ACT-7733 | adjust.stock | SKU-42088 | — | Anita Rao | Decision: Authorized | 13ms | EV-7733 |
A trace and its record are the same object.
This matters more than it sounds. Where the operational view and the audit trail are separate systems, they eventually disagree — and the reconciliation becomes somebody's quarterly job. Here the trace is the readable form of the sealed record, so there is nothing to reconcile.
Search it
Audit
The same records, queryable by person, system, policy or outcome, with the chain intact.
Aggregate it
Observability
What the estate attempted, what it called, what it read and what it cost — across every connected system.
When it goes wrong
Incidents
An investigation starts at the trace, because the trace already contains the inputs.
Where to start
Bring us the action you would least like to explain.
Not the one you are proud of. The one where somebody would ask who authorized it, under which rule, on whose authority — and the honest current answer is that it would take a while to find out.