What is an Outcome Receipt?

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

The receipt does not authorize payment or establish that settlement happened. Spoolis verifies the outcome and signs the record. It does not hold or move money.

What the receipt records

The receipt uses the versioned schema spoolis/outcome-receipt@1. Its agreement fields identify the accepted Spool and agreement version. Its condition_results show how each condition resolved. The result, optional units, and amounts.earned fields record the aggregate 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 does not 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 does not decide how much the provider earned.

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

The receipt is independent of the rail

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

This separation is why receipt verification is independent of payment execution. Spoolis supplies the signed outcome. The consumer decides whether its policy permits an action, and its chosen rail handles money movement.

Authenticity works offline, status is optional

A consumer can pin trusted receipt keys and verify the Ed25519 signature without a Spoolis account or API call. That offline check answers 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 does not make the signature valid and does not reverse a payment automatically. The consumer decides how correction, revocation, or advisory state affects its own workflow.

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 cannot authorize production payment. They can demonstrate receipt creation and signature verification, but they do not grant spending authority and do not 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.