The Executor Cannot Verify Itself

Agent systems often stop their reasoning at the moment an API returns success. That is operationally convenient and evidentially dangerous. A successful HTTP response, tool result, transaction submission, workflow completion event, or executor receipt can tell you what the executor reported. It cannot, by itself, establish that the intended consequence actually occurred or that prohibited collateral effects did not.

Success is a statement from the actor

Every execution boundary produces some form of self-report. A cloud API reports that a change request was accepted. A payment rail returns an identifier. A SaaS connector reports that a record was updated. An automation worker says a job completed. These reports are useful and often necessary, but they originate at or near the system that performed the action. They describe execution from the executor’s perspective.

That perspective can be incomplete without being malicious. An API may acknowledge a request before an asynchronous downstream process fails. A payment may be submitted but rejected later. A record mutation may succeed while an associated entitlement remains stale. A remediation script may return zero while the target state drifts seconds later. The gap between “command accepted” and “consequence established” is where evidentiary overclaim begins.

StableMind therefore treats the execution receipt as one artifact in a larger proof package. It can establish attribution, timing, request identifiers, executor identity, and other useful facts. It does not receive the constitutional privilege to certify its own outcome.

Proof starts before execution

Independent verification is stronger when the expected postconditions are committed before the action occurs. If a verifier invents success criteria after seeing the result, the proof can become a retrospective story. A consequence contract instead records what state should exist afterward, which collateral effects are prohibited, which observation sources are admissible, and what evidence is required to support each conclusion.

This precommitment matters in both simple and complex actions. For a payment, the intended beneficiary, amount, currency, settlement expectations, and prohibited destination mutations can be explicit before execution. For an infrastructure change, the intended configuration state, affected resource set, safety invariants, and rollback expectations can be explicit. For a SaaS entitlement change, the target user, role, scope, and forbidden privilege expansion can be declared in advance.

The verifier then asks a narrower and more defensible question: what can the available independent observations support relative to the consequence contract that already existed? That is very different from asking the executor whether everything went well.

Four outcomes are more honest than green or red

Real evidence is rarely binary. StableMind’s Evidence model keeps four canonical outcomes because they describe materially different states. VERIFIED means the required independent evidence supports the committed postconditions. PARTIAL means some required evidence supports the intended state while other required facts remain incomplete. MISMATCHED means observed state conflicts with the committed expectation. UNVERIFIABLE means the required evidence is missing, unavailable, inadmissible, or insufficient to reach a stronger conclusion.

The last outcome is especially important. In many operational systems, missing telemetry drifts toward success because no error was observed. Proof of Consequence takes the opposite stance. Missing required evidence cannot become VERIFIED. Absence of contradictory evidence is not evidence of the intended consequence.

This is why the same executor receipt can coexist with all four proof outcomes. “SUCCESS REPORTED” can remain fixed while independent observations change. That is not an inconsistency. It is the point. One artifact describes the executor’s report; another describes what a separate evidentiary process can support about the resulting state.

Integrity is not meaning

Hashes, signatures, append-only logs, secure timestamps, and provenance chains are powerful evidence controls, but they solve a different problem. They can help establish that an artifact has not changed, who signed it, when it entered a chain, or how it relates to other artifacts. They do not automatically make the proposition inside the artifact true.

A perfectly signed receipt can faithfully preserve an incorrect or incomplete statement. A tamper-evident log can immutably record that a system believed an action succeeded. Cryptographic integrity protects the record from mutation; it does not confer omniscience on the source. Proof systems become stronger when integrity, attribution, admissibility, independence, and semantic verification are all treated as separate dimensions.

That separation also prevents a seductive category error in AI governance: the existence of an audit trail is not the same as the existence of proof. Auditability makes investigation possible. Proof of Consequence asks whether the available attributable observations support a defined post-action claim.

The distinction becomes even more important when several executors participate in one workflow. A payment gateway, workflow engine, reconciliation service, and ledger may each produce internally consistent receipts while still disagreeing about the final state that matters to the institution. Rather than selecting whichever success event arrived last, a consequence-verification layer can bind those artifacts to the precommitted postconditions and ask which observations are independent, which are merely derivative, and which facts remain unresolved. This turns multi-system telemetry from a pile of logs into an evidentiary graph.

Proof must not become future authority

There is one final boundary that matters as much as independent verification: favorable evidence from a past action cannot become permission for the next action. A VERIFIED outcome may support settlement, release of consequence reserve, operational closure, audit conclusions, or future policy analysis. It cannot silently grant, expand, restore, or extend delegated authority.

This prevents reputation from mutating into power. A machine that has performed one hundred verified actions still needs current authority for action one hundred and one. A connector with an excellent reliability record still cannot decide its own mandate. A vendor that passes a conformance test still cannot substitute that status for tenant-local delegation. Evidence can inform governance without becoming governance.

For enterprises evaluating agentic systems, the practical test is simple: can the executor’s success report be separated from independent observations, and can the final proof state remain honest when evidence is incomplete? If the architecture cannot represent “the executor says success, but we cannot verify the consequence,” then the evidence model is still too close to the actor it is supposed to evaluate.

An execution receipt can report success. It cannot independently prove its own consequence.