# How verification works Canonical HTML: https://spoolis.com/docs/verification. This page is also available in machine-readable Markdown. Follow an agreed criterion from evidence and verifier to result, earned value, and signed receipt. ## The verification flow Spoolis is for transactions where payment depends on whether the agreed outcome actually happened. Each check follows criterion -> evidence -> verifier -> result -> economic rule. Spoolis determines earned value and signs the Outcome Receipt. A wallet, marketplace, payment system, or configured integration may verify and consume it, then act under its own authorization and settlement policy. ## Who runs the check? Schema acceptance does not mean an executor is live. deterministic, live: fixed code and inputs produce a fixed evaluation. The result proves what the code found in those inputs, not that the evidence reflects real-world truth. human_confirmed, live: an authorized person confirms the criterion. Spoolis records the confirmation and applies the agreed economic rule. external_tool, reserved and not live: this receipt value is reserved for a named external system. No planner path or executor emits it today. ai_assisted, planned and not live: the current executor returns an uncertain verdict instead of an AI-assisted result. If Spoolis cannot support a criterion with an available verification method, it does not invent a verdict. ## Method and provenance Method says who or what resolved a condition. Evidence provenance records origin and capture facts. It is not a trust score. Missing provenance means unknown origin. Spoolis does not assign universal assurance labels. ## Deterministic verifier registry 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. Missing or unreadable input does not pass. Each verifier returns an explicit reason when a check fails. - 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. ## Verify the receipt In the canonical example, 100 enrichment records at $1.00 per accepted record produce 98 accepted, 2 rejected with reasons, and $98.00 earned. Verify the signed receipt with @spoolis/receipt-verifier, optionally call GET /api/receipts/{id}/status, then let the payment stack act on earned under its own policy. Offline signature verification remains sufficient. [Verify a receipt](/docs/verify-receipt) for package and trust-set details. [When Spoolis decides and when you decide](/learn/when-spoolis-decides-and-when-you-decide) for the responsibility boundary. ## Planner and attestation boundaries Planner modes are deterministic, ai_assisted, and human_required. They are not receipt execution methods, and there is no external_tool planner mode. The signed attestation is the lower-level verdict underneath the Outcome Receipt. A demo attestation has no production settlement authority.