Core concept

What is an Outcome Receipt?

An Outcome Receipt is a signed record of what verification found and what was earned. It stays separate from the payment system that may act on it.

Updated September 14, 2026

An Outcome Receipt is Spoolis's signed record of a verification result. It keeps the accepted agreement, verification plan, condition results, evidence digest, overall result, and earned amount in one portable artifact. Another system can check that record, read what was earned, and decide what to do under its own policy.

The receipt doesn't authorize payment or establish that settlement happened. Settlement is the step where the payment is completed. Spoolis checks the outcome and signs the record before that step.

What the receipt records

The receipt uses the versioned schema spoolis/outcome-receipt@1. Its agreement fields identify the accepted Spool and agreement version. When declared, acceptance_authority records who authored the acceptance policy, whether it was mutually agreed, and which parties accepted or acknowledged it. Its condition_results show how each condition turned out. The result, optional units, and amounts.earned fields record the overall outcome and the value produced by the agreed economic rule.

Spoolis canonicalizes the unsigned receipt and signs it with Ed25519. A valid signature from a trusted key proves that the signed record is authentic and unaltered. It doesn't prove that the underlying evidence was true, authorize payment, or prove that money moved.

A $100 worked example

A buyer authorizes a maximum of $100.00 for 100 units at $1.00 each. That authorization sets a spending ceiling. It doesn't decide how much the provider earned.

Spoolis checks the delivered units against the agreed conditions. Ninety-eight of 100 units pass. The receipt records 98 accepted, 2 rejected, and amounts.earned of 98.00 USD. After checking the receipt and applying its own authorization policy, the payment system settles $98.00.

Keep the claims separate. The buyer authorizes up to $100.00. The receipt records $98.00 earned. The rail settles $98.00. The receipt doesn't perform or prove the settlement.

The receipt is independent of the rail

Rail independence. The Outcome Receipt is a signed record of what was earned, consumable by any payment system that understands its schema and trusts its signing key. Changing the payment rail doesn't change the verification result.

A card stack can use earned value as a capture amount. A wallet, marketplace, or external settlement system can carry the same value into its own payment lifecycle. Each consumer remains responsible for payment authorization, replay protection, amount checks, timing, and settlement state.

That's why checking the receipt stays independent of executing the payment. Spoolis supplies the signed outcome. You decide whether your policy permits an action, and your chosen rail handles the money movement.

Authenticity works offline, status is optional

Offline verification and online status. Offline signature verification proves authenticity without Spoolis uptime. The optional status endpoint only adds correction, revocation, or advisory state.

You can pin trusted receipt keys and verify the Ed25519 signature without a Spoolis account or API call. That offline check tells you whether the receipt came from a trusted key and remained unaltered.

The optional GET /api/v1/receipts/{receipt_id}/status endpoint can report current, superseded, or unknown. It doesn't make the signature valid, and it doesn't reverse a payment automatically. You decide how correction, revocation, or advisory state affects your own workflow. A party named in the Spool's dispute policy can supersede a receipt through POST /api/v1/receipts/{receipt_id}/supersede, which issues a signed successor and marks the original superseded.

Demo receipts stop at the production boundary

Every receipt declares its environment as production or demo, and a verifier must require the environment it expects. Account-free sandbox receipts use the demo environment and its separate trust material.

Sandbox and demo attestations can't authorize production payment. They can demonstrate receipt creation and signature verification, but they don't grant spending authority and don't move real money. A production payment system must verify a production receipt against its accepted production trust set and apply its own authorization policy.

What to check before acting

  1. Require the expected receipt environment and trusted signing key.
  2. Verify the signature and the receipt's structural and economic checks.
  3. Apply buyer policy for identity, amount, scope, replay, and timing.
  4. Optionally check online status when current correction or revocation state matters.
  5. Observe the payment system's own result before claiming settlement.

The Outcome Receipt specification defines the artifact. The verification guide shows how to check it with pinned trust material.

What is an Outcome Receipt? · Spoolis