▸ BLOG

What we actually mean by "evidence in the same transaction"

The single line on the Orkena homepage that draws the most technical questions is: “authorizes every agent action against your policies before it executes, and writes the audit record in the same database transaction that executes it.”

The questions come in two flavors. From engineers: “same transaction how, specifically?” From compliance officers: “why does the transaction boundary matter?”

The two questions are the same question. This post answers both, at the implementation level, with the actual data structures. It’s a longer read than usual because the details matter — the difference between “we log the action after it happens” and “the action and the log commit together atomically, into a hash-chained tamper-evident ledger” is precisely the difference between an audit trail that satisfies a regulator and one that does not.

The transaction#

When an agent proposes a tool call — say, tool.payments.issue_refund with an amount and a destination — several things need to happen, in order, atomically:

1. Evaluate the proposed action against the active policy pack for this graph
2. If permitted, execute the tool call
3. If the tool call succeeded, commit the resulting effect (in our example, the refund)
4. Write the ledger event capturing all of the above — the proposal, the policy evaluation, the execution, the outcome

These four steps have to succeed or fail together. If step 4 fails after step 3 succeeded, you have a refund that isn’t in the audit trail. If step 3 fails after step 4 succeeded, you have an audit trail with a phantom refund. Neither is acceptable for a regulated workflow.

The transaction boundary is what guarantees this. In Orkena, the ledger event and the effect commit are in the same Postgres transaction. Either the whole thing lands or none of it does. There is no window in which the action and the evidence can disagree.

This sounds obvious. It is not the default in agent frameworks today. Most agent frameworks execute the action, then produce an audit event asynchronously — sometimes minutes or hours later, sometimes to a different data store, sometimes to a message queue that eventually consistent-ly makes it to the audit database. Every one of those gaps is where the audit trail and the reality can diverge.

The hash chain#

Committing the ledger event with the action solves the “consistency” problem but does not solve the “tampering” problem. A ledger table with INSERTs in it can be modified after the fact — a DBA with sufficient privileges can update or delete rows. From an auditor’s perspective, that’s not evidence; it’s a report about evidence.

The tamper detection is the hash chain. Each ledger event carries the hash of the previous event:

SEQ 0416 · prev_hash = 8c31...a09d
SEQ 0417 · prev_hash = 4f9a...c7e1
SEQ 0418 · prev_hash = 3e12...b8ff

Where each prev_hash is SHA-256 over the canonical serialization of the previous event. This means that modifying any event invalidates all events that came after it — the hashes no longer match. Deleting an event has the same effect. Reordering events has the same effect.

The chain is per-tenant, so a modification in one tenant’s chain cannot affect another tenant’s chain. Each org’s chain starts at SEQ 1 and grows monotonically.

This is not novel technology. Hash chains are how Git works, how blockchain platforms work, how audit systems that need tamper-evidence have worked for decades. What’s specific to Orkena is that the chain is per-tenant, is committed in-transaction with the action, and can be exported for offline verification — see below.

The anchor#

Hash chains detect tampering, but they don’t prove when a state was current. Someone with enough privilege could, in principle, re-hash the entire chain from scratch — modify SEQ 0212, then recompute every subsequent hash, then update the whole table. Detectable by comparison against a snapshot, but not by inspection of the chain alone.

The anchor closes this. Periodically — every N events, or every M minutes, whichever comes first — Orkena signs the current chain head with an Ed25519 signature. The signature travels with the chain:

ANCHOR #0042
signed_at: 2026-08-15T09:14:22Z
seq_signed: 417
head_hash: 4f9a...c7e1
signature: 3e12b8...ffee1a
public_key: MCowBQYDK2VwAyEA...

Once an anchor is signed, the chain up to that anchor cannot be modified without also modifying the anchor. The anchor is signed with a private key that Orkena controls, but the public key travels with the export, so an auditor can verify the signature without depending on Orkena.

Anchors are how “this state was current at this moment” becomes cryptographically provable, not just cryptographically consistent.

The bundle#

Regulator asks for evidence of a specific run, or a specific date range. The evidence bundle is what you hand them.

The bundle is a signed archive containing:

• The relevant slice of the ledger (all events in the requested scope)
• All anchors that cover that slice
• The Orkena public key
• A readable HTML report summarizing what happened
• The dependency-free verify.py script

The auditor extracts the archive on their own machine, opens a terminal, runs:

$ python verify.py bundle.zip
chain: 417 events verified · anchors: 3 signatures valid
RESULT: OK

The script has no dependencies beyond the Python standard library. It does not call out to any Orkena endpoint. It does not require Orkena to be online, to be available, or to still be in business.

If the bundle has been tampered with — even a single byte in one event — the script returns:

$ python verify.py tampered.zip
RESULT: FAILED — hash mismatch at SEQ 0212

And identifies which event failed.

This is the differentiator. It’s the artifact a competitor cannot trivially copy, because copying it is not shipping a verify.py script — it’s shipping the entire underlying architecture that makes the script’s answer meaningful. Building this after the fact into a system that started as a dashboard requires rebuilding the data model, the transaction boundaries, the async paths, and the storage layer.

What this looks like in practice#

To make the abstraction concrete: here’s what happens for a single agent action, end-to-end, at the implementation level.

An agent proposes tool.payments.issue_refund(amount=12400, currency="USD", order_id="SO-88213"). The engine:

1. Loads the active policy pack for this graph — policy.baseline-security v3 plus any workspace-specific packs
2. Evaluates the action against the policy in-process — Cedar’s Rust evaluator via cedarpy, schema-validated packs (BE-17, landed 2026-08-16)
3. The evaluation returns {effect: "deny", reasons: ["baseline-security: irreversible tool invoke with taint requires HITL"]} — the action is denied because it derives from a customer email flagged as untrusted, and the payment tool is marked side_effects: irreversible
4. Because the effect is deny, no tool call happens
5. The engine writes a ledger event:

SEQ 0417
at: 2026-08-15T09:14:22.117Z
type: policy.decision
actor: {kind: agent, id: refund_bot}
subject: tool.payments.issue_refund
effect: deny
reasons: [baseline-security: irreversible tool invoke with taint requires HITL]
context_hash: <sha256 of the context dict at evaluation time>
engine: baseline-python
prev_hash: <hash of SEQ 0416>

6. The ledger event and the run-state update (marking this step “denied”) commit in the same transaction
7. The next anchor scheduled for this org, when it fires, will sign the current head — including SEQ 0417

At no point between step 3 and step 6 is the state inconsistent. There is no queue, no async retry, no eventual consistency. The denial and the record of the denial are the same commit.

Why this matters for the compliance officer#

The Chief Compliance Officer at a regulated institution has one question at the end of the day: can I produce, on demand, cryptographically verifiable evidence of every consequential decision made by every AI system in production, in a form my regulator can verify without depending on the vendor?

Every alternative to a hash-chained tamper-evident ledger with signed anchors and offline verification requires one or more of the following: trust the vendor to preserve the log; trust the vendor to be available; trust the vendor to be honest under adversarial audit. Regulated institutions do not, and should not, extend that trust.

The transaction boundary is what makes the log the evidence, and not a report about the evidence. The hash chain is what makes the log tamper-evident. The anchor is what makes the tamper-evidence time-stamped. And the verifier is what makes it all independent of Orkena’s continued cooperation.

This is not the ambitious version of the design. It’s the minimum viable audit trail for a workflow you have to defend to a regulator. Everything Orkena does downstream — the evidence bundle export, the offline verify.py, the deterministic replay, the eval-gated promotion — is downstream of the transaction boundary being right.

Reading further#

• Technical brief — full architecture, including the run executor, policy engine, and memory subsystem
• Compliance mappings — how the audit chain maps to DORA Article 5, EU AI Act Article 12, ISO 42001, and NIST AI RMF
• Benchmark — the 3.9% engine overhead measurement with method

The next post in this series takes on the eval-gated promotion path: how a new agent version passes its regression suite before it reaches production, and why “the fourth coupling” (change only through tested updates) matters as much as the other three.

---

If you are the platform engineer responsible for the substrate of an agent programme at a regulated institution, and you want to see the transaction boundary, the ledger export, and the verifier live: request a demo →.