About Spoolis

Acceptance infrastructure for outcome-based software

Spoolis provides the acceptance system between returned work and whatever acts next, recording what counted, and what was earned.

You define what counts, provide the evidence, and choose the judge. Spoolis maintains the acceptance state around that judgment and returns one durable Outcome other systems can act on.

The missing question

Software can increasingly act, buy, sell, and settle on its own. None of that tells another system whether the underlying work satisfied the agreement.

When a transaction is request-shaped, delivery usually proves success. When it is result-shaped, someone has to decide what counted: work can be partial, wrong, or incomplete, and the answer can feed the next automated step. That is where an explicit, portable answer to "what actually counted" starts to matter.

Why this becomes infrastructure

Usage-based software needs metering. Outcome-based software needs an Outcome record.

Software is increasingly able to act, buy, sell, and settle autonomously. As more transactions become result-shaped rather than request-shaped, the economic result itself becomes something software needs to represent explicitly.

If a result matters only inside one platform, it is probably a feature. When the same signed result is consumed across systems, it starts to look like infrastructure. One platform can define, judge, bill, and record outcomes internally; portable Outcomes matter more when those roles live across different systems.

New ways for software to buy things create new things to sell, and new transaction shapes create new infrastructure.

Where Spoolis fits

Authority. May this agent spend?
Selection. What is being bought?
Outcome. Did the work satisfy the agreement? What counted? What was earned? This is Spoolis.
Settlement. Move the money.

How an Outcome is formed

agreement → acceptance criteria → evidence → judgment → earned value → signed Outcome Receipt

Turns an agreement into explicit, checkable acceptance criteria.
Accepts or references the evidence the work produced.
Runs the agreed deterministic checks, or records an agreed authority’s judgment.
Calculates partial earned value: what counted, what was rejected, and why.
Emits a signed Outcome Receipt another system can verify independently.

A simple example

An agent buys 100 company records at $1 per accepted record. 97 satisfy the agreed criteria. 3 do not.

Spoolis records: 97 counted, 3 rejected with reasons, $97 earned, and a signed Outcome Receipt.

A wallet, marketplace, billing system, or another agent can use that Outcome to decide what happens next.

Where this is heading

The simplest Spoolis example is 100 units delivered and 97 accepted. The broader bet is that software will increasingly hire other software for work that is harder to reduce to a delivery event: migrations, procurement, support, finance, and multi-agent workflows. In those systems, a subtask returning is not necessarily the same as a result being safe to build on.

Spoolis doesn't have to be the judge of everything. Customers can keep their own tests, evaluators, telemetry, or human approvals. Spoolis makes the resulting Outcome explicit, signed, and portable.

When Spoolis matters

When the work, the judge, the payer, and the auditor are not all the same system.
When work can be partial and value should follow what actually counted.
When the result feeds a consequential downstream action.
When transactions have less post-payment recourse, so deciding what counted before or alongside settlement matters more.

What Spoolis is not

Not a wallet.
Not a payment rail.
Not general-purpose escrow.
Not a universal reputation score.
Not a marketplace.
Not trying to replace every evaluator.

Spoolis determines and records the Outcome. Other systems keep ownership of wallets, settlement, workflow, and final business decisions. A valid receipt signature proves the record is authentic and unaltered; it does not prove the underlying evidence reflects real-world truth.

What Spoolis is designed to do

Turn agreements and evidence into explicit, portable Outcomes that another system can verify and act on. The current product, its interfaces, and its status live in the developer docs and on the product overview.

What has to become true

Outcome records matter most when they are useful outside the system that created them. The long-term question is whether software increasingly needs a shared, portable way to represent what counted and what was earned. The evidence for and against that thesis is tracked openly on the thesis page.

Who builds Spoolis

Jared Franklin, founder. Jared has spent his career in economic and transaction infrastructure, including PayPal and Bill Me Later, Blispay and Alliance Data, BlockFi, Costanoa Ventures, and Stripe.

Spoolis is a product of Understand My Policy, Inc., which builds software that makes consequential agreements and records easier to inspect, verify, and use.

Canonical resources

Contact

Email support@spoolis.com or use the contact page. Read the privacy policy and terms.