When to use Spoolis

One rule decides it: is delivery enough to know what to pay? If "it was delivered" is enough to know what to pay, you probably don't need Spoolis. If delivery can be wrong, incomplete, or only partly acceptable, you probably do.

Most software purchases are atomic, meaning the response itself is the product: one request, one response, done. Result-shaped work is different. There, "it showed up" and "it was good enough" are different facts, and only the second one tells you what to pay.

Bucket 01Works today

Result-shaped work whose acceptance is deterministic: same input, same verdict, no judgment call. This is the boring, high-volume end of the spectrum, and it is where verification earns its keep first.

• Data enrichment (agent → API). Buy records and pay for the ones that pass the agreed schema and domain checks.
• Code and QA (agent → service). The agreed test results are submitted as evidence and checked.
• Structured document processing. Pay per correctly processed document.
• Unitized tasks (agent → agent). Pay for the units that pass.

Bucket 02Good fit as verifier coverage expands

Same shape as bucket 01, but acceptance leans on judgment or a human confirmation rather than a purely mechanical check. The agreement is expressible; automated coverage is still growing, so today these often resolve with a person confirming in the loop rather than end to end.

• Research and briefs. Required sub-questions covered, sources cited, a confirmation step. Structural checks are mechanical; whether it answered may still route to a person for confirmation.
• Milestones (agent → business). Some criteria are checkable now; others name a human decision authority in the agreement.
• Multi-hop workflows (agent → agent → agent). Some handoffs are deterministic, some need review.

Spoolis can run deterministic checks against supplied evidence, record confirmation from a named person with decision authority, or use an external judge explicitly declared by the agreement. AI-assisted verification is live for one checker, claim_cited, which checks whether supplied text evidence supports a stated claim with code-verified citations.

Bucket 03Skip it

Delivery itself is the product, or there's nothing to resolve. Adding a verification layer here is pure overhead.

• Simple API call. The response is the product.
• Inference or search. You got the answer the moment it arrived.
• Content or access. Either you have it or you don't.
• Open-ended time. Nobody agreed on what done means.
• Nothing objective to resolve. No explicit criterion, no evidence, and no person with decision authority that could settle the result.

A worked anti-example: an agent buying a single news article for a few cents. Mechanically it would fit (the agreement names the article, the delivery is the evidence, a deterministic check confirms it), but it fails on three counts. The economics: checking costs more than a bad unit does, and when verification does not pay for itself you should not use it. The shape: one all-or-nothing unit, where our value concentrates in partial counting, like 100 records where 97 qualify. And it is an information good, so inspecting it before paying means you already have the value, an old problem no verification layer makes disappear. The honest mitigations, payment committed up front with release gated on the verdict, content commitments, reputation, exist, and the gated settlement path covers the first, but the better answer for cheap single-unit content is simply not to add an acceptance layer at all.

Compare fit across common use cases

The decision in one pass

1. Is the response itself the product? If yes, skip it.
2. Can you say what accepted means before the work starts? If not, skip it, or write the criteria until you can.
3. Is that check mechanical? If yes, it works today. If it needs judgment or a confirmation, it fits as coverage expands.
4. Should payment, routing, or reputation follow the result? If yes, that is what the Outcome Receipt is for.