StableMindMachine AuthorityProof Explorer · Synthetic and browser-local
A consequential AI action can leave behind logs, receipts, screenshots, callbacks, hashes, approvals, and a very confident green checkmark. None of those artifacts gets to promote itself into truth. StableMind Proof Explorer separates authorization lineage, executor testimony, independent observation, and the final Proof of Consequence so reviewers can see both what is known and where certainty ends.
Synthetic proof package: every identifier, digest, observation, execution result, verifier record, and proof state below is fictional. The explorer performs no network calls and creates zero external production proof.
The executor contributes evidence. It does not get to certify its own consequence.
Product definition
A Proof of Consequence package is an attributable, tamper-evident evidence envelope that compares precommitted expected postconditions and prohibited collateral effects with independently observed post-action state. It preserves the request and authority lineage that preceded execution, the exact Action Permit and executor receipt, the verifier identity and observation window, content digests and provenance, and the deterministic proof result. It is designed to resist a common failure mode in agentic systems: treating “the tool call returned 200” as equivalent to “the intended institutional consequence occurred correctly.”
One package · Four evidence states
The synthetic action and authorization lineage below stay constant. What changes is the quality of independent evidence available after execution. That lets the explorer demonstrate why a successful executor receipt can coexist with VERIFIED, PARTIAL, MISMATCHED, or UNVERIFIABLE proof.
The normalized request binds the action, target, purpose, requester, authority lineage, and expected consequence before downstream execution begins.
Three evidentiary layers
RECEIPT ≠ OBSERVATION ≠ PROOF
The certified executor can report that it invoked the permitted action, which endpoint responded, when the call occurred, which permit it consumed, and whether the transport or target returned success. That testimony is valuable and attributable. It remains testimony from the component that performed the action.
A distinct verifier observes the resulting state under its own workload identity and credential class. It does not inherit the executor's credential, and it cannot modify the target while supposedly verifying it. The observation records both expected postconditions and prohibited collateral effects.
The proof engine compares the precommitted consequence contract with independent observations. It can conclude VERIFIED, PARTIAL, MISMATCHED, or UNVERIFIABLE, preserving uncertainty rather than converting missing or contradictory evidence into a favorable outcome.
Even a synthetic VERIFIED state on this page does not become external production proof. A public product interface cannot manufacture a named customer, customer acceptance, settlement, recognized revenue, realized savings, or independently attributable production outcome.
Inside the envelope
SEVEN ATTRIBUTABLE ARTIFACTS
The exact action, target, purpose, consequence dimensions, requester, and request digest. This prevents later evidence from drifting to a different operation than the one originally considered.
The attributable grantor, active delegation path, scope, inherited conditions, revocation state, and current validity evidence used when ActionGate evaluated the request. Valid lineage remains context, not a permit.
The normalized policy inputs, decision result, narrowing conditions, required approvals, consequence-capacity conditions, policy version, and decision digest. The proof package preserves what was allowed before anyone knows the outcome.
The narrow, short-lived artifact binding actor, action, target, constraints, expiry, consequence limits, executor class, and request/decision lineage. A permit is authority to attempt an exact action, not evidence that the consequence succeeded.
The executor identity, connector certificate, invocation timestamps, permit consumption, target response, retry lineage, and attributable result. “Success reported” belongs here rather than in the final proof verdict.
The verifier identity, observation time, read-only credential class, observed postconditions, observed prohibited effects, missing evidence, and raw observation digest. The executor cannot sign both sides of the story.
The deterministic comparison between expected and observed state, final proof classification, evidence references, verification deadline, signatures, and package digest. The result preserves ambiguity when the evidence does.
Four proof outcomes
UNCERTAINTY IS A VALID RESULT
All required postconditions are independently observed inside the allowed verification window, and no prohibited collateral effect is found. The proof supports the bounded consequence claim encoded before execution.
Independent evidence supports part of the expected outcome, while another required postcondition is pending, incomplete, outside its confidence threshold, or missing. Partial does not get rounded upward.
The executor may still have reported success, but independent evidence shows a required postcondition failed or a prohibited collateral effect appeared. The contradiction remains visible and can drive Guardian, recovery, or compensation workflows.
A verifier may be unavailable, the target may expose insufficient read evidence, the window may expire, provenance may fail, or evidence may be incomplete. Missing evidence is not treated as success and is not silently converted to failure either.
Tamper evidence and provenance
HASHES PROVE INTEGRITY, NOT MEANING
Request, decision, permit, receipt, observation, and proof digests make later mutation detectable. Stable canonicalization matters because a hash is only as meaningful as the object definition whose bytes were committed.
Signing can establish which governed component attested to an artifact and whether the signature remains valid. A valid signature from an executor still says “the executor attested to this,” not “the external consequence is independently proven.”
A proof package should distinguish policy-derived facts, customer-provided context, executor-reported facts, verifier-observed facts, synthetic data, and externally attributable evidence. Provenance is part of the meaning.
Append-only linkage can make deletion or mutation detectable across an evidence sequence. It does not grant permission to act, validate a policy decision, or guarantee that the factual claim encoded in an intact artifact is correct.
Review paths
ONE PACKAGE · DIFFERENT QUESTIONS
Inspect the current authority chain, policy inputs, approvals, permit constraints, credential timing, executor class, revocation state, and any Guardian intervention. Evidence should let security reconstruct why capability existed at that moment.
Compare request intent, executor receipt, observed state, retries, partial effects, and recovery references. A MISMATCHED proof should expose the delta needed for correction rather than simply append a red status.
Reviewers need immutable references, verifier independence, timestamps, signatures, digests, provenance, policy version, exception evidence, and explicit uncertainty. The goal is reconstructability rather than screenshot theater.
StableMind keeps Proof of Consequence separate from customer acceptance, cleared settlement, revenue recognition, insurance coverage, and realized value. A commercial process may consume proof as evidence, but it owns its own authoritative gate.
Public Truth boundary
The Proof Explorer is intentionally detailed enough to feel like a production evidence workspace, because evidence architecture becomes clearer when the package is inspectable. But every artifact is embedded synthetic teaching data. Selecting an outcome or artifact changes only local presentation state.
Proof Explorer FAQ
VERIFY THE CLAIM, NOT THE COLOR