When does verification actually pay for itself?

Verification sounds obviously useful until you remember that verification is itself another thing you have to pay for. So I wanted to know where the line actually is.

If the work is almost always right, or nothing expensive happens after a bad result slips through, a check is just overhead. We measured both sides of that line with real money.

The model

Bad work that slips through as "done" keeps costing you: another API call, another agent, a payment, a retry, or human review. The value of checking first is one line of arithmetic.

savings = rejected units × downstream cost − verification cost

Nothing about that formula is unique to Spoolis. Any orchestrator can bolt on checks, and many should. Spoolis's job is producing a neutral, signed result that a different system can gate on, per unit, without trusting the executor's own logs.

What we ran

Reference workflows we designed, run as real transactions. The acceptance criteria were frozen before execution. A control arm ran the downstream paid step for every delivered unit, because the work "looked done". A gated arm paid Spoolis to verify first and ran the downstream step only for accepted units. The downstream steps were real paid calls to Massive, a market-data API we bought from like anyone else.

These are reference workflows with failures we injected (a missing required field). The defect rates were chosen, not observed in anyone's production.

What happened

At 20% defects, cost per accepted result was 18.8% lower with the gate.

At 10%, it was 8.8% lower.

At 5%, 4.3% lower.

At 1%, 0.7% lower.

At 0%, verification simply added the cost of the check.

Each run has a signed receipt and published evidence. All five land on the formula, so you can compute your own answer before running anything. And because verification is priced per job rather than per unit, larger batches push the break-even defect rate down; the 100-unit batch still came out ahead at 1% defects.

Where it stops making sense

At 0% defects, Spoolis added exactly the cost of the check.

The same thing happened when nothing downstream cost money. There was nothing to prevent, so verification was just another expense.

That is useful to know. If a workflow sits below break-even, it probably should not use Spoolis. That is the line we wanted to measure.

Partial delivery

A second reference test priced the overpayment version, the one unitized verification already implements. 100 records delivered at $0.01 each, 17 rejected against the frozen criteria. Paying for delivery costs $1.00; paying the signed earned value costs $0.833 including the $0.003 verification. Overpayment avoided: $0.167.

The verification was a real paid production call; the seller payment is arithmetic from the signed earned-value result, not a real transfer. A clean batch, 0 of 100 rejected, again priced the gate as pure cost.

What this shows

• The mechanism works end to end with real money: rejected work stopped triggering paid downstream actions.
• The break-even boundary is measurable, and it improves with batch size.
• Cost per accepted result, not cost per check, is the number to evaluate verification against.

What it does not show

• Customer savings, or real-world defect rates. Every number here is a reference workflow with injected failures.
• Anything about subtle failures: plausible-but-wrong values, false rejects, deep production cascades.
• Human-review savings. That needs a real review queue, not a benchmark.

The next test

Not another synthetic benchmark. The useful next measurement runs beside a real acceptance workflow: change nothing in production, observe deliveries for a couple of weeks, measure the real defect and uncertain rates and what accepted work actually triggers, and compute the break-even. If the workflow sits below the line, the report says "don't use Spoolis for this", and that report is still useful.

Have a workflow with rejected batches, QA review, partial payment, or downstream spend that depends on work being right? Talk to us.

Notes

Method for every run: agreement frozen before execution, control arm versus gated arm, real paid verification over x402, signed Outcome Receipt per run. Verification prices observed: $0.0011 to $0.003 per job, quoted before execution per the pricing model. Downstream price in the gate tests: $0.01 per unit per call. The percentages are specific to these reference shapes; the formula is how they transfer. The gate pattern itself is in continue only with accepted work.