The fulfillment layer between authorization and settlement

Strip any payment system down to its skeleton and three questions remain. Authorization: may this actor spend this money? Settlement: how does the money actually move? And between them, a question that is older than either: did the thing being paid for actually happen the way the two sides agreed?

Card networks, bank transfers, stablecoin rails, and agent payment protocols differ enormously in mechanics, but each names authorization and settlement precisely and builds real infrastructure for both.

The middle question has no comparable owner. It is the fulfillment question, and on almost every rail it is answered implicitly: by a human clicking approve, by a delivery scan standing in for satisfaction, by a status code standing in for a judgment, or by the seller reporting their own success.

The industry keeps gesturing at the middle layer

Read payment documentation across rail families and a pattern appears. The fulfillment layer keeps being described, but rarely built.

Card infrastructure describes capture timing that may be tied to delivery confirmation, service completion, or a defined threshold. The mechanics exist: authorize a maximum, capture a final amount, reverse the remainder. What no card specification defines is where the confirmation of delivery or completion comes from. The capture amount is an input the rail accepts, not a fact the rail establishes.

Agent payment protocols include schemes where the buyer authorizes an upper bound and the final charge is decided after the work completes. The deciding logic is explicitly external to the payment protocol. Something has to produce the number, and the payment protocol takes no position on what.

Accounts payable systems expose programmatic approve and deny actions on bills. The action is first-class; the basis for it is not. An approval is a human assertion, and nothing in the system records machine-checkable evidence that the invoiced work occurred.

Usage-based billing meters consumption and settles on the metered figure. But in most implementations the party declaring the usage is the party being paid for it. The meter reading is a self-report.

Each of these is a socket shaped exactly like a fulfillment verdict. A capture amount waiting for an earned number. A resume condition waiting for a verdict. An approval action waiting for a basis. A meter waiting for an independent reading. The rails did not build the layer, but they left room for it, which suggests they know it is missing.

What the layer has to produce

A fulfillment layer worth the name has to do five things, and the order matters.

1. Fix the criteria before the work. What counts as done must be agreed and recorded up front, not reconstructed during a dispute. A judgment against criteria that did not exist when the work started is an argument, not a verification.
2. Require evidence. The verdict must rest on artifacts that were actually examined, with a record of where each came from and how it was captured.
3. Judge independently. The referee cannot be the party being paid, and it cannot be the party paying either. A self-report is not a verification regardless of which side files it.
4. State what was earned, not just pass or fail. Real work has partial outcomes. Ten records ordered, eight acceptable, is neither success nor failure. It is $8.00 of a possible $10.00, and the layer must be able to say so.
5. Sign the result so it travels. The verdict must be a portable artifact that any downstream system can check without trusting the channel it arrived through. A verification result that cannot leave the system that produced it is a marketplace feature, not a layer.

Notice that none of these five requirements mentions a payment rail. That is the point. The fulfillment question is the same whether settlement happens by card capture, bank transfer, stablecoin, or ledger entry.

One artifact, many projections

If the layer is independent, its output can be consumed anywhere a rail left a socket. The same signed record of what was earned can become a capture amount on a card rail, the release condition in a conditional settlement, the basis a program cites when it approves an invoice, the verified figure a usage meter settles on, or the verdict that resumes a paused agent workflow before its payment step runs.

That is the architectural claim of this essay: fulfillment verification should be one layer with many projections, not many layers with one projection each. The alternative, where every rail and every platform grows its own partial verification logic, is the world we already have.

Where Spoolis stands

Spoolis is built on this claim. Spoolis should be the fulfillment layer that sits between authorization and settlement, regardless of the rail. It compiles a task into agreed acceptance criteria, collects evidence, runs verifiers, calculates what was earned, and signs an Outcome Receipt that any system can check against a published key. It does not hold funds, authorize spending, or move money. The rail keeps authorization and settlement; Spoolis answers the question in between.

Stated as product fit: Spoolis is for transactions where payment depends on whether the agreed outcome actually happened.

The honest status of the layer today: deterministic checks and human confirmation are live, AI-assisted evaluation is planned but not live, and external tool checks are reserved but not live. A signed receipt proves the verdict is genuine and unaltered. It does not prove the evidence was true, and it does not make every check reproducible. Those boundaries are stated in the receipt specification rather than smoothed over, because a verification layer that overclaims is worse than no layer at all.

What would prove the bet, and what would break it

The bet is falsifiable. If the fulfillment question turns out to be domain-specific all the way down, so that dataset purchases, research tasks, agent workflows, and invoiced services share no reusable structure of criteria, evidence, and earned value, then the independent layer is unnecessary and the platform-by-platform world is the right architecture.

But if the same small loop keeps fitting, compile criteria, verify evidence, sign what was earned, and the same receipt keeps plugging into sockets the rails already left open, then the middle layer is real, and it was simply never anyone's job to build it until now.