What is acceptance infrastructure?

A vendor's agent returns 100 company records and an invoice. Ninety-six records are complete. Two repeat companies already in your database. One has a malformed URL. One cites a source your team doesn't accept. Somewhere between the response and the invoice, a piece of your code decides what you actually got.

I think of that code as acceptance infrastructure: the system around returned work that records what counted, what failed, what was uncertain, and what was earned. You keep the definition of what counts, the evidence, and the judge. The infrastructure keeps the machinery around that decision consistent.

What acceptance means

Acceptance answers a narrow question: did this particular delivery satisfy the agreement that governed it?

The answer has consequences. A record counts toward an invoice. A code patch becomes eligible to continue toward deployment. A research result gets handed to the next agent. A rejected unit goes back for correction. An uncertain result waits for a person.

That makes acceptance different from testing. A test asks whether software behaves as expected under specified conditions. Testing can supply evidence or even act as a judge, but it doesn't necessarily bind the result to a purchase, preserve the governing agreement, or calculate what the delivery earned.

Acceptance is also different from an eval. An eval measures a model, prompt, system, or output. It might compare variants or track quality over time. Acceptance takes the result of an evaluator, test suite, human review, or other judge and turns it into a production state for one delivery under one agreement.

An evaluator can say, "The answer scored 0.82." Acceptance has to say what that score means here. Did the result count? Was it rejected? Was the judge unable to decide? If 82 of 100 units passed, what amount was earned? Which agreement version produced that answer?

What companies build themselves

Most teams don't begin by deciding to build an acceptance system. They add one check to one workflow. Then the check acquires responsibilities.

A production acceptance path can start accumulating responsibilities like these:

1. Criteria. The team writes down what a result must contain or accomplish.
2. Evidence. The workflow collects the returned data, test output, citations, logs, or human confirmation needed to apply those criteria.
3. Judge glue. Code converts that evidence into the shape expected by a test suite, model, evaluator, rules engine, or person, then converts the answer back.
4. Production state. A boolean becomes accepted, rejected, or uncertain because timeouts and incomplete evidence are not honest failures.
5. Earned value. Partial delivery requires unit counts and arithmetic. Ninety-six accepted records should not silently become either zero or 100.
6. Re-review, corrections, and supersession. A later submission or judgment has to relate to the first without being accepted, charged, or consumed twice.
7. History. Someone eventually asks what criteria, evidence, judge, and result were in force when a decision happened.
8. Consumption. Billing, another agent, an operator, or a workflow needs a stable object to read.

Every part is buildable. The hard part is that the parts have to agree over time. A criteria edit can't retroactively change an old decision. A judge timeout can't masquerade as rejection. A correction can't create a second earned amount for the same unit. A billing job shouldn't have to reconstruct the decision from application logs.

This is why a checker that looked like a small feature can become infrastructure. The decision starts crossing system boundaries.

What stays domain-specific

Three things should stay with the customer.

First, what counts. A useful research citation, a valid insurance document, and a passing code change have different definitions of done. Generic infrastructure should not invent one.

Second, the evidence. The customer knows whether the relevant proof is a test report, a signed event, source URLs, database records, an inspection, or something else. Evidence can be wrong or incomplete. A system can preserve its provenance, but it can't make weak evidence true by wrapping it in a schema.

Third, the judge. The right judge might be deterministic code, an existing evaluator, a model, an external service, a human, or a combination. It depends on the consequence and the domain.

Spoolis never picks your judge. It doesn't replace the expertise that defines a good result. The customer keeps what counts, the evidence, and the judge because those choices contain the actual business judgment.

That boundary matters. If acceptance infrastructure owned the definition of good work, it would become a vertical application with opinions about one kind of work. The useful horizontal layer begins after those choices are yours.

What becomes horizontal

The machinery surrounding the decision repeats even when the work changes:

• binding criteria to the agreement and version under which work was delivered
• recording where evidence came from and which evidence the judge saw
• normalizing different judge responses into a stable contract
• representing accepted, rejected, and uncertain without collapsing the third state
• reconciling accepted units with the amount earned under the agreed rule
• handling re-review, corrections, supersession, and duplicate protection
• preserving history so a later reader can reconstruct the decision
• producing one durable Outcome that another system can consume

Notice what is not on that list: next-action routing or generic orchestration. Spoolis doesn't decide how your workflow should be arranged. It gives your workflow a stable acceptance result. Your code still decides whether to continue, retry, stop, ask a person, or choose another provider.

The distinction is similar to a payment processor returning a durable payment state without owning the customer's fulfillment workflow. Acceptance infrastructure owns the integrity of the acceptance state, not every action around it.

The durable output is the Outcome

An Outcome is the stable result of applying the agreed criteria to the submitted evidence through the chosen judge. It carries enough context for a different system to use the decision without rerunning or reverse-engineering it.

In Spoolis, the signed form is an Outcome Receipt. Its versioned schema binds the agreement and verification plan to condition results, an evidence digest, the overall result, optional unit counts, and the earned amount. The receipt also names its environment and carries an Ed25519 signature.

The signature proves that the signed record came from a trusted signing key and wasn't altered. It does not prove that the original evidence perfectly described the real world. It does not authorize payment. It does not prove that payment happened. Those are separate claims.

That narrowness makes the Outcome useful. A billing system can read the accepted count or earned amount. A retry worker can inspect rejected units. An agent can decide whether its own policy permits continuation. A person can review uncertain conditions. Each consumer applies its own authority and action rules to the same result.

Corrections matter here too. A consumer may verify the receipt offline, while an optional status check can report that it is current, superseded, or unknown. The original signed record remains inspectable instead of disappearing into a mutable results row.

The Outcome is the handoff point. Acceptance happens once. Downstream systems don't each need their own interpretation of what happened.

How is acceptance infrastructure different from an evaluator?

An evaluator produces judgment. Acceptance infrastructure makes that judgment usable in production.

The evaluator might score an answer, run tests, compare a result to a rubric, or ask a person to decide. Acceptance infrastructure binds that answer to the governing criteria and evidence, preserves uncertainty, computes accepted units and earned value, manages correction history, and produces the durable Outcome.

The evaluator is a component. It can be swapped when the customer chooses. The acceptance system is the stable layer around it.

For more on who retains that choice, read Who decides what counted?

Who uses acceptance infrastructure?

The immediate users are teams buying or depending on work that still needs judgment after delivery.

That might be an agent buying a batch of records, a workflow receiving research from another service, a marketplace reconciling a milestone, or an internal system deciding whether a generated code change can move forward. The provider can be software or a person. The consumer can also be software or a person.

What matters is the shape of the transaction:

• delivery is not enough to prove success
• the acceptance decision affects money or another consequential action
• the result may cross more than one system
• partial or uncertain work must not collapse into a simple success response

The When to use Spoolis guide starts with the same dividing line: is delivery itself the outcome, or does the result still have to be judged?

When you do not need it

Sometimes an if statement and a database column are the right architecture.

If you have one judge, one database, and one workflow, a boolean may be enough. If failure has no financial or operational consequence, you may not need versioned acceptance history. If all work is indivisible, retries never overlap, and nobody outside the service consumes the result, a separate system adds ceremony without much value.

A two-cent API request that either returns or does not return often does not need an acceptance layer. Delivery is the outcome. The transport status and ordinary application checks can do the job.

You also might keep acceptance internal because the judgment is central to your product. That is a reasonable ownership choice. The question isn't whether your team can build this. It is whether the repeated machinery deserves a separate boundary.

How it differs from adjacent systems

Evals

Evals help measure and improve models, prompts, and systems. They may supply the judge for acceptance. They usually don't own the agreement version, economic reconciliation, correction history, or durable result consumed by billing and other systems.

Billing and metering

Billing systems count events, apply prices, issue invoices, and maintain balances. Acceptance sits before that work when the event itself is disputed or seller-defined. It produces the accepted event, count, or earned amount that billing can meter.

Orchestration

Orchestrators schedule work, manage dependencies, and decide which step runs next. Acceptance supplies a state they can branch on. It does not replace the orchestrator or decide the workflow.

Payment rails

Payment rails authorize, move, and settle money. An Outcome can tell a payment consumer what was earned, but it neither grants spending authority nor proves settlement. Payment is one possible consumer of acceptance, not the category itself.

Why this category is appearing now

I think four changes are exposing the same missing layer.

First, outcome-based pricing makes the acceptance question economic. If a seller charges for a resolved conversation or an accepted record, someone has to decide which event earned the price.

Second, larger and chained agent workflows amplify bad inputs. One service's returned work can become another service's paid input before a person sees it. A durable acceptance result gives the next participant something more precise than "the previous call succeeded."

Third, acceptance increasingly affects consequential actions. Software may release money, continue a workflow, grant access, or submit another purchase. The decision needs clearer provenance when the cost of a wrong branch rises.

Fourth, new transaction designs are separating delivery, evaluation, and settlement roles. ERC-8183, for example, specifies an agentic-commerce job protocol with client, provider, and evaluator roles around escrow and completion. That is one concrete signal, not proof that crypto defines this category. The broader problem exists anywhere returned work needs an independent decision before another system acts.

I don't know how much of acceptance will become shared infrastructure and how much will stay inside vertical products. I do think the repeated machinery is now visible enough to name.

Go deeper

• Run the quickstart to move from criteria and evidence to an Outcome.
• Walk the browser demo to inspect a signed sandbox receipt.
• Read What comes after usage-based software? for the pricing argument that led here.