Execution Evidence integration

The v2.4.0-rc.1 enterprise-local first layer accepts lifecycle evidence through MCP or loopback HTTP and returns Execution Receipts for attempts, outcomes, reversals, and reconciliations. Ordered checkpoints and optional transparency, witness, and neutral-anchor layers are verified separately from this ingress.

The caller defines the action and retains business authorization, private values, routing, finalization, and reversal. The evidence methods remain evidence-only. If an enterprise enables the separate Semantic Dispatch Guardrail, a preconfigured local adapter—not a caller-supplied callback—becomes the guarded execution boundary. ChoiceProof does not require an action-specific business schema.

At local ingress, caller-defined private values are canonicalized and hashed. The journal stores opaque commitments, lifecycle records, declared source metadata, and signatures.

The signing key may remain in an enterprise KMS, HSM, or signing service. The external-signer helper receives the fixed EIP-712 hash profile rather than the complete Execution Receipt.

Ingress operations

begin creates an attempt record. append adds a source-reported outcome or reversal, or derives a strict reconciliation from committed readback. Neither operation invokes a provider or an external tool.

MCP methods

  • choiceproof.receipt.begin
  • choiceproof.receipt.append

Loopback HTTP service

Bearer-authenticated local routes for begin, append, read, bundle export, and health.

External signer

Use an absolute reviewed helper for any KMS, HSM, or signing service. ChoiceProof re-verifies every returned signature.

Optional semantic dispatch guardrail

This separately deployed enterprise-local control mediates a preconfigured adapter before a guarded callback. Hosted ChoiceProof, the public protocol, transparency, witnesses, anchors, and verification never invoke the action or custody adapter credentials.

  1. The guardrail derives K internally from enterprise scope and a stable operation lineage, then derives F from the normalization profile, action, normalized intent, and relevant configuration. The caller cannot inject trusted K, F, callbacks, credentials, permits, fences, or approval booleans.
  2. The durable store enforces lifetime uniqueness of (enterpriseScopeHash, K, F). A historical fingerprint always resolves to the stored operation, so F1 → F2 → F1 creates no new reservation, head advance, permit, or guarded callback.
  3. A never-before-seen F may advance only from the exact resolved current head at revision n + 1 with verified supersession approval.
  4. Pre-dispatch evidence commits before the store atomically consumes the single-use fenced permit. At or after consumption, callback failure, timeout, cancellation, missing report, and crash recovery are authoritative-readback-only.
  5. Under the certified deployment assumptions, one semantic binding revision can cause at most one guarded adapter callback. The claim requires complete credential-path mediation, stable normalization of every material field, durable atomic storage, and fencing. Preventing duplicate downstream external effects additionally requires one-dispatch or downstream-idempotency adapter behavior.

Implementation boundary

Public materials define the record format, semantic binding schema, deterministic derivations, fixed vectors, evidence classifications, and independent verification rules. They do not include the enterprise capture or guardrail service, adapter, credentials, durable dispatch state, or production configuration.

Capture-boundary policy, semantic normalization, durable reservation and fencing, supersession approval, authoritative readback connectors, adapter configuration, anomaly controls, key operations, deployment, and service operations are maintained as proprietary systems.

Caller-defined private values

The examples use caller-defined JSON. Private values are hashed at local ingress and are not included in an Execution Receipt or Receipt Bundle.

Create an attempt record

{
  "source": {
    "runtimeId": "runtime:any",
    "agentId": "agent:any",
    "invocationId": "invocation-001",
    "protocol": "mcp",
    "implementation": "external-agent-runtime"
  },
  "occurredAt": "2026-07-28T00:00:00.000Z",
  "traceId": "trace-001",
  "action": {
    "name": "external_tool_call",
    "effectKind": "org.example/declared-effect",
    "effectMode": "one_time"
  },
  "privateInput": {
    "callerDefined": "opaque value"
  }
}

Append a lifecycle observation

{
  "attemptId": "attempt_<begin-result>",
  "lifecycle": "outcome",
  "sourceEventId": "source-observation-001",
  "occurredAt": "2026-07-28T00:00:01.000Z",
  "status": "unknown",
  "privateResult": {
    "callerDefined": "opaque value"
  }
}

Generated Execution Receipts

An Execution Receipt is the artifact.receipt object. Its sibling artifact.commitment is the Receipt Commitment, which contains the Execution Receipt hash and signature. A Receipt Bundle packages lifecycle-linked receipts. The verification report is a separate result, not another Execution Receipt.

The selected synthetic attempt below shows the enterprise-local receipt boundary. No real external action occurred.

Where the Execution Receipt lives

Receipt Bundle
└── entries[0]
    ├── record
    ├── reference
    └── artifact
        ├── receipt      ← the Execution Receipt
        └── commitment   ← Receipt Commitment (hash + signature)

The complete Receipt Bundle is long because it also carries records, references, commitments, and signatures. The object named receipt is the Execution Receipt itself.

Actual generated Execution Receipt

JSON pathentries[0].artifact.receipt
Lifecycleattempt · requested
Signaturestored beside it as the Receipt Commitment
Inspect selected Execution Receipt fields
{
  "schemaVersion": "choiceproof.evidenceEvent.v0.1",
  "eventId": "evt_a76fbd04cf2d26c47efe19fc549d6b3bc81ea35675790dd8a05b478bd0333976",
  "eventType": "agent.update_record",
  "occurredAt": "2026-08-12T00:00:00.000Z",
  "capturedAt": "2026-08-12T00:00:10.000Z",
  "action": {
    "name": "update_record",
    "phase": "intent",
    "status": "requested"
  },
  "commitments": {
    "request": "sha256:3f1c14c87f102f8c60277279dd13126767b0348705a69dc500aca94d94ea8fbe"
  },
  "sourceAttestation": {
    "level": "self_asserted",
    "status": "unverified"
  }
}
Open complete Execution Receipt (JSON)

Offline verification

Receipt Evidence offline verification checks record integrity, lifecycle links, commitment bindings, and declared-signer signatures. A separate semantic reference verifier derives and validates bindings when its required inputs are supplied, then classifies the supplied set; the current Receipt Bundle verifier does not produce that semantic result automatically. Classification does not authorize or prevent external execution. Active replay mediation is only the separately deployed enterprise-local guardrail, subject to its certified assumptions; source identity, completeness, ordering, and factual truth remain outside the verifier result.