Field Notes
Field notes on Execution Assurance: canonicalization, replay verification, policy-bound authority, and what it takes to make autonomous systems provable rather than merely observable.
Editorial reference, read-only. Posts explain the mechanism; they do not create, sign, or verify proof truth.
Read the trust modelField Notes
Editorial reference on the execution-assurance mechanism. Each post separates what is true today from what is planned; none of them create, sign, or verify proof truth.
A log is a record the executor wrote about itself; proof is something an independent party can recompute. The difference decides every dispute.
When an AI agent does something consequential — moves money, files a claim, changes a record — the first instinct is to reach for the log. The log says the agent checked the policy, saw the right inputs, and acted. This feels like evidence. It is not.
A log is a record the executor wrote about itself. It is produced by the same system whose behavior is in question, retained under that system's control, and editable by anyone who can reach the store it lives in. Every property that would make it trustworthy in a dispute is the property it structurally lacks. The log answers 'what did the system say happened.' The question that matters is 'what can an outside party establish happened, without taking the system's word for it.'
Consider the three ways a log fails under pressure. It can be altered after the fact, because it is mutable storage and the party holding it is the interested party. It can be selectively retained, because nothing forces the record of the inconvenient decision to exist alongside the record of the convenient one. And it can be internally consistent yet wrong, because a log that faithfully reports a flawed decision process is still a faithful log — it re-reads its own narrative rather than re-deriving the outcome.
None of these are exotic failure modes. They are the default condition of any self-attested record. An auditor, a counterparty, or a claims adjuster who understands this will discount the log accordingly, which means the log does not actually reduce the disagreement it was supposed to settle.
Proof has one property a log does not: it can be checked by someone who does not trust the party that produced it. Concretely, that means the decision must be reduced to a canonical form — inputs, the exact policy version, the identity and delegation under which the agent acted, the constraints in force — and that canonical form must be hashed into a stable value. The same execution reduced the same way yields the same hash, on any machine, run by anyone.
At that point the record stops being a story and becomes a computation. A third party takes the claimed inputs and policy, recomputes the canonical form, recomputes the hash, and compares. If it matches, the claim about what was decided holds. If it does not, the claim fails — and it fails for the checker directly, not on the executor's say-so.
This is the distinction between reading a log and replaying a decision. Reading a log trusts the writer. Replay re-derives the decision from the same policy and the same inputs and observes whether it lands in the same place. Because the policy is deterministic and versioned, the same execution produces the same proof every time; there is no run-to-run drift to explain away.
Replay also catches the failure a consistent log hides. If the authority under which the agent acted has drifted — the delegation was narrower than claimed, the policy version was different, a constraint was violated — replay resolves to DENY where the log said ALLOW. A log will happily narrate the ALLOW. Replay will not reproduce it.
Intentrax is the engine that performs this reduction. The engine — not the agent — generates the Autonomous Execution Proof, so the executor cannot edit the evidence about itself. Canonicalization plus hashing produces a proof hash; the proof is then signed. A standalone offline verifier recomputes the hashes and fails closed on authority drift, with no runtime, no network, and no private key required to run it.
We are precise about stage. The engine recently began signing real proofs; live production traffic with mutation is currently blocked, and the trust-network layer is planned, not shipped. What exists today is the mechanism that makes the difference in this post concrete: a proof you can hand to someone who does not trust you, and have them check it themselves. A log was never that.
Financial systems learned to settle transactions independently of the parties making them. Autonomous agents create a new settlement problem, and it looks the same.
Payment systems did not become trustworthy because the parties involved became honest. They became trustworthy because the record of what happened was made independent of the parties who benefited from it. A transaction is settled when a record exists that neither counterparty can quietly rewrite and that a third party can reconcile against. That independence is the entire point; without it a payment is just two conflicting stories.
Autonomous agents reintroduce this problem in a new domain. When an agent acts on its own — retrieves data, applies a rule, executes an action — that action has consequences that outlast the moment. The question 'did this action actually happen under the authority it claimed' is a settlement question. Today, in most agent stacks, it is answered by the agent's own logs, which is the pre-settlement world: two stories and no referee.
It is tempting to treat the model output, the conversation, or the workflow as the thing to record. But the thing with consequences is the execution: the concrete action taken, under a specific identity, bound to a specific policy, against specific inputs. That is what a counterparty disputes, what an auditor examines, and what a claim is filed over.
This is why the billing and record unit is the Verified Execution Event, not the token or the API call. The execution is where authority meets consequence. Recording the prompt tells you what was asked. Recording the execution tells you what was done and whether it was permitted — the only part that has to settle.
Borrow the discipline of transaction settlement and the requirements fall out directly. The record must be produced by something other than the executor, or it settles nothing. It must be tamper-evident, so alteration is detectable rather than deniable. It must be reconcilable by a third party without privileged access to the executor's systems. And it must bind the action to the exact authority under which it was taken — the policy version, the identity, the delegation, the constraints — because 'it happened' and 'it was allowed to happen' are different claims.
Intentrax produces this record as an Autonomous Execution Proof: the engine canonicalizes the execution, hashes it to a proof hash, and signs it. Authority is not a footnote in the proof; the fail-closed model resolves to ALLOW only when both the execution and the authority permit it, and to DENY otherwise. A settlement record that ignored authority would settle the wrong question.
The test of a settlement layer is whether an outside party can reconcile against it alone. Intentrax ships a standalone offline verifier that recomputes the proof's hashes and fails closed on authority drift, requiring no runtime, no network connection, and no access to any private key. Anyone holding the proof can check it — which is the property that makes it evidence in a dispute rather than a claim within one.
The evidence is portable by design: the same proof exports as JSON, aep-json, or PDF for an audit, a dispute, or an insurance claim. Reconciliation should not depend on the executor still being online, still cooperating, or still in business.
We do not claim a regulatory mandate is forcing this. The pressure is market pressure — insurers pricing autonomous-agent risk, counterparties demanding verifiable action, standards bodies converging on assurance expectations. When a party has to price or contest what an agent did, self-attested logs are worth what self-attested anything is worth in a dispute.
Intentrax is the reference implementation of the AEVN verification protocol, which is open; we implement it, we do not own it. And we are candid about where the work stands: the engine recently began signing real proofs, live production traffic with mutation is currently blocked, and the trust-network layer is planned. The claim here is narrower and firmer — the unit that has to settle in the autonomous economy is the execution, and settlement means a record the parties cannot control and a third party can check.
If the system that acted also produces and controls the evidence about what it did, verification is theater. Independence is not a feature of the evidence — it is the precondition for it.
An agent that generates its own evidence, stores it, and attests to its own correctness has verified nothing. It has produced a more elaborate assertion. The structure is circular: the party whose behavior is in question is also the sole author and custodian of the record used to judge that behavior. No amount of formatting, signing-with-your-own-key, or confident logging escapes the circle.
Independence is therefore not a nice-to-have layered on top of good evidence. It is the property without which the artifact is not evidence at all. Everything else — hashes, signatures, exports — is machinery in service of one requirement: someone who does not trust the executor must be able to reach a conclusion about the executor's actions.
There are two distinct separations, and both must hold. The first is independence of generation: the evidence must be produced by something other than the agent. If the executor can shape, suppress, or edit the record of its own decision, generation-side independence is broken and the rest is moot.
The second is independence of checking: verifying the evidence must not require trusting or even involving the executor. If confirming a proof means calling the executor's API, running the executor's server, or holding a key only the executor controls, checking-side independence is broken. A record you can only verify by asking the party you distrust is not verifiable in any sense that matters.
Intentrax separates generation by making the engine — not the agent — the author of the Autonomous Execution Proof. The agent executes; the Assurance Engine observes the execution and generates the proof. The executor cannot edit that proof, because the executor did not write it. This is the first of the five value props and the load-bearing one: independence.
The engine canonicalizes the execution into an ordered, deterministic form and hashes it into a proof hash, then signs the result. Because the policy is deterministic and versioned, the same execution yields the same proof hash — so the engine's output is not a discretionary summary the executor might have leaned on, but a mechanical function of what actually occurred and under what authority.
Intentrax separates checking with a standalone offline verifier. It recomputes the proof's hashes from the canonical form and re-derives the authority decision, and it fails closed on authority drift — if the delegation, policy version, or constraints do not support the claimed outcome, it resolves to DENY. Critically, it requires no runtime, no network, and no private key. It does not phone home to Intentrax and it does not phone the executor.
That last property is what makes the evidence portable to a hostile reader. An auditor, a counterparty, or an insurer can verify a proof on their own machine, offline, without any cooperation from the party being examined. Verification that depends on the examined party's goodwill is not verification; it is a courtesy.
Independence has to extend to us as well. The verification protocol, AEVN, is open; Intentrax is its reference implementation, not its owner, and the verifier runs without contacting us. If verifying a proof required trusting Intentrax specifically, we would have relocated the circular-trust problem, not solved it.
We state the stage plainly. The engine recently began signing real proofs; the offline verifier exists and fails closed today; live production traffic with mutation is currently blocked, and the layered Assurance Levels and trust-network are planned rather than shipped. What is real now is the part this post is about: evidence generated by the engine rather than the executor, and checkable by anyone without the executor's help.
Not a dashboard, not a transcript, not a confidence score. An auditor needs to reconstruct a specific decision and confirm it was permitted — without trusting the system under review.
An auditor examining an AI agent's action is not asking whether the system was generally healthy, whether latency was low, or whether the model seemed confident. The auditor is asking a specific, adversarial question about a specific action: what exactly was done, under whose authority, against which inputs, bound to which version of which rule — and can that be established without taking the system's word for it.
Most of what agent platforms offer answers a different question. Dashboards report aggregate health. Transcripts report what was said. Confidence scores report how the model felt. None of these reconstruct a single decision to the standard an examiner needs, because none of them were built to be checked by someone who distrusts the source.
Observability tools are built to help the operator understand their own system. That is a real job, but it is the operator's job, and the artifacts inherit the operator's trust assumptions. The data is aggregated, sampled, mutable, and retained at the operator's discretion. An auditor cannot pin a claim to a sampled metric or an editable trace; there is nothing to recompute and nothing that resists after-the-fact adjustment.
This is a category difference, not a quality gap. Intentrax is not monitoring, observability, or analytics. Observability tells you how the system is doing. An execution proof lets an outsider establish what the system did on one occasion and whether it was allowed to. An auditor needs the second thing and cannot substitute the first.
Concretely, an examiner needs four properties in the artifact. Reconstruction: the specific decision must be re-derivable from the recorded inputs and policy, not merely narrated. Authority binding: the action must carry the exact policy version, the identity, the delegation, and the constraints under which it was taken, so 'it happened' and 'it was permitted' can be evaluated separately. Tamper-evidence: any alteration to the record must be detectable rather than deniable. And independent checkability: confirming all of the above must not require the cooperation of the party under review.
An Autonomous Execution Proof carries these by construction. The execution is canonicalized and hashed to a proof hash and signed; the policy binding names the exact version and the authority in force; the fail-closed model resolves ALLOW only when both execution and authority permit. The auditor recomputes rather than reads.
Auditors also receive external artifacts — a payment confirmation, a vendor receipt, a system-of-record entry. These matter, but they occupy a specific place. In Intentrax's model, ingested external evidence is an execution passport: it is bound to the Autonomous Execution Proof but never replaces it. The proof remains the authoritative reconstruction of the decision; the passport is corroborating external context attached to it.
The same discipline separates the certificate from the receipt. The certificate is the signed proof presented as an attestation — authoritative. An Action Receipt is a non-authoritative local summary — convenient, but not something an auditor should settle on. Naming these apart matters, because an examiner who mistakes a receipt for a proof is trusting exactly the source they were supposed to check.
The workflow is deliberately unglamorous. The auditor takes the proof and runs the standalone offline verifier: it recomputes the hashes, re-derives the authority decision, and fails closed on authority drift — no runtime, no network, no private key, no call to Intentrax or to the executor. Evidence exports as JSON, aep-json, or PDF, so it travels into an audit file, a dispute, or a claim without depending on the executor staying online or cooperating.
We are honest about maturity. The engine recently began signing real proofs and the offline verifier fails closed today; live production traffic with mutation is currently blocked, and layered Assurance Levels are planned rather than shipped. But the auditor's core need is met by what exists now: a specific decision, reconstructable and authority-bound, that they can verify themselves without trusting the agent.
Posts unpack the difference between observing an agent and holding independent, signed, replayable proof of what it did.
We cover Execution Assurance infrastructure, not monitoring, orchestration, workflow automation, or compliance documentation.
Every post separates what is true today from what is planned, and cites the mechanism behind each claim.
Continue to the review path when your team is ready to map an assurance pilot.
See how it worksKeep exploring the public site — no account required.
Documentation Developer Resources Trust FrameworksResearch, standards, and the AEVN Initiative remain available as public resources.
Explore Intentrax LabsIntentrax will review your context and prepare a recommended assurance path.