VENDOR SPECIFICATION · V1

Prove the terminal transition—and label the evidence honestly.

MandateShield Execution Receipt v1 signs the final authorization state, exact execution bindings and evidence class without turning a caller assertion into independent settlement proof.

TOKEN PROFILE

ES256 with a distinct MSE+JWT protected type

The terminal receipt is a compact ES256 JWT. Its protected header must contain typ=MSE+JWT, alg=ES256 and a retained MandateShield JWKS kid. Its exact string aud binds the PROCESSOR audience that caused the transition. It is evidence of a past state transition and can never authorize another provider submission.

Execution Receipt JWT Claims JSON Schema

TERMINAL STATE

Action, origin, destination and outcome remain inseparable

The signed claims bind the authorization, original decision receipt, optional permit, transition, input, attempt, protocol, provider, payee, amount and resource. They record exactly one action and its legal terminal state:

  • COMMIT → COMMITTED for a recorded successful result, including a late canonical success after a prior SETTLEMENT_UNKNOWN.
  • RELEASE → RELEASED for a confirmed failure or non-submission before the release boundary.
  • EXPIRE → EXPIRED for an unused reserved authorization derived from the MandateShield ledger.
  • SETTLE_UNKNOWN → SETTLEMENT_UNKNOWN with outcome SETTLEMENT_UNKNOWN when submission ambiguity remains conservatively charged.

A nullable provider, resource, payment reference or occurrence time is an explicit absence, never an invitation for a verifier to infer missing facts.

EVIDENCE CLASSES

Provenance and independent verification are separate fields

ClassMeaning
CALLER_ASSERTEDThe authenticated PROCESSOR adapter supplied the result; it is not provider-signed evidence.
FACILITATOR_SIGNEDA facilitator-signed artifact is bound, but is independently verified only when the receipt explicitly says so.
PROVIDER_API_VERIFIEDAn exact provider API result is bound. Treat it as independently verified only when independent_verification is true; the hosted Stripe path sets both after its own exact API lookup.
CHAIN_FINALIZEDA canonical chain-finality result is bound. Treat it as independently verified only when independent_verification is true; the hosted x402 path sets both after its own RPC checks.
UNRESOLVEDSubmission may have occurred but no conclusive terminal provider or chain result is available.
LEDGER_DERIVEDThe terminal fact follows only from MandateShield's own authorization ledger, such as unused reservation expiry.

A direct manual COMMIT or RELEASE still emits CALLER_ASSERTED for its authenticated processor_result and sets independent_verification=false. Signed Stripe webhooks are also caller hints, not independent evidence. Unused expiry remains LEDGER_DERIVED, while an inconclusive provider or chain observation remains UNRESOLVED.

Hosted provider reconciliation may emit PROVIDER_API_VERIFIED with independent_verification=true after an exact Stripe API lookup, or CHAIN_FINALIZED with that boolean after canonical x402 chain verification. Only supported, non-conflicting evidence can autonomously COMMIT or RELEASE and produce that receipt. Pending, unknown and conflicting observations remain fail-closed. A stronger evidence_class never overrides the boolean by itself.

VERIFICATION BOUNDARY

Cryptographic authenticity is precise but deliberately bounded

Offline verification can prove that MandateShield signed these exact terminal claims with the identified retained key. It does not independently prove the underlying provider assertion, settlement, chain finality, facilitator policy or customer deployment. Consumers must evaluate evidence_class, evidence_digest and independent_verification together.

This is vendor-published integration infrastructure, not an independent audit, provider certification or statement that a provider currently mandates MandateShield.

Read the one-use Execution Permit specification