How verification works

Start with the transaction boundary

Spoolis is for transactions where payment depends on whether the agreed outcome actually happened.

For an integration, each check follows the same path:

criterion -> evidence -> verifier -> result -> economic rule

1. Criterion: define the condition before verification.
2. Evidence: supply the artifact or confirmation the criterion requires.
3. Verifier: route the evidence to an available execution method.
4. Result: record what the verifier returned, then apply the agreed rule to determine earned value.

Who runs the check?

Outcome Receipt condition results support four execution methods. Two are live today. Schema acceptance of a method value does not mean an executor is live.

If Spoolis cannot support a criterion with an available verification method, it does not invent a verdict.

Method and provenance are separate facts

The method says who or what resolved a condition. Evidence provenance records where an evidence item came from, how it was captured, its artifact reference, when it was observed, and which verifier used it. Provenance is origin and capture metadata, not a trust score. When provenance is missing, the origin is unknown.

Required fields are present
result: pass
method: deterministic
evidence provenance: uploaded JSON

Spoolis does not assign universal assurance labels. A deterministic check over manually entered input and a human confirmation after physical inspection make different claims. The receipt exposes the raw facts so your integration can apply its own policy.

Deterministic verifier registry

The live deterministic registry includes checks for structured data, URLs, text, files, hashes, and timestamps. Fixed code and inputs produce a fixed evaluation. Durable evidence can support later reproduction, while a network response is a time-bound observation even when the checking code is fixed. Examples include:

• json.path.equals compares a dot or bracket path in a structured evidence payload.
• http.status checks one public HTTP or HTTPS URL with SSRF protection and a bounded timeout.
• text.contains checks whether delivered text contains an agreed non-empty string.
• hash.matches computes SHA-256 over delivered file bytes and compares the agreed digest.
• deadline.met compares the evidence record timestamp with the agreed ISO deadline, never the evaluation clock.

Missing or unreadable input does not pass. Each verifier returns an explicit reason when a check fails.

Verify the receipt, then apply your policy

In the canonical example, Spoolis verifies 100 enrichment records at $1.00 per accepted record, accepts 98, rejects 2 with reasons, and signs a receipt for $98.00 earned. Install the public npm verifier and verify that Outcome Receipt with a pinned trust set.

import { verifyOutcomeReceipt } from '@spoolis/receipt-verifier'

const verification = await verifyOutcomeReceipt(receipt, { trustSet })
if (!verification.valid) throw new Error(verification.reasons.join(', '))

console.log(receipt.amounts.earned)

Offline signature verification is sufficient and requires no Spoolis account or API call. You may optionally call GET /api/receipts/{id}/status before the payment stack acts on the $98.00 earned amount under its own authorization policy.

A valid Ed25519 signature proves the receipt is genuine and unaltered. It does not prove that every underlying check can be reproduced forever, that supplied evidence reflects real-world truth, or that payment was authorized or settled. Deterministic checks over durable evidence can be reproducible. A live URL, external API result, or human confirmation may not be.

Read verify a receipt for package and trust-set details. Read when Spoolis decides and when you decide for the responsibility boundary.

Planner modes are a different vocabulary

The planner classifies what a criterion requires as deterministic, ai_assisted, or human_required. These planner modes are not receipt execution methods. There is no external_tool planner mode.

Lower-level attestation verification

The signed attestation is the lower-level verdict underneath the Outcome Receipt. Integrations should normally start with the portable receipt. If you need to verify an attestation directly, select the trust set matching its environment, validate its key ID, digests, expiry, amounts, parties, and authority, then verify the canonical payload with Ed25519. A demo attestation has no production settlement authority.

const { signature, signingKeyId, ...payload } = attestation
const bytes = Buffer.from(canonicalSerialize(payload))
const valid = crypto.verify(
  null, bytes, publicKey, Buffer.from(signature, "base64")
)