Sell AI outcomes your
buyers can trust.
Payment protocols prove the agent was allowed to buy.
Recourse proves the seller delivered.
A vendor bills for outcomes — support conversations resolved, leads qualified, meetings that held — and today the vendor also defines, measures and reports them. Recourse is the party neither side employs: both sign one outcome definition, and the count is taken against that definition rather than against whichever dashboard is doing the invoicing.
The vendor defines the outcome, measures it, and sends the invoice.
Outcome pricing is already here. Support agents bill per resolution, outbound agents bill per qualified meeting, and the number on the invoice comes from the seller’s own dashboard — counted by the party being paid, against a definition the buyer never saw written down.
Nobody is arguing that the vendor is lying. The problem is structural: there is no way for an honest vendor to prove the count, which means an honest vendor is priced the same as a dishonest one.
They negotiate the rate down until the doubt is priced in.
They sample the vendor’s numbers by hand, every month, forever.
They put a ceiling on spend regardless of what was delivered.
Every one of those is a good outcome that got paid for as though it might not have happened.
The buyer does not trust the vendor’s dashboard. The vendor cannot prove the count. Nobody is the neutral party.
Five steps, in order, every time.
The same sequence runs for a one-shot deliverable and for a stream of unit outcomes. Each step writes an immutable, signed event; the commitment’s history is the source of truth.
- 01
Terms are hashed and signed.
Runs todayThe vendor writes terms against a public Outcome Standard. Recourse canonicalizes them, takes the SHA-256, and the buyer signs that hash — so neither side can change what was agreed without changing the hash.
- 02
A hold is placed on the parties’ own rails.
Not builtThe buyer instructs a hold on the rail it already uses. No Recourse balance ever holds a party’s money. The manual rail records that the hold was instructed; adapters that actually move funds are not built, so nothing here enforces a release yet.
- 03
Each unit is counted against the terms.
Runs todayUnits are deduplicated against the dedupe key in the terms, filtered to the period, and issued as a signed statement either party can verify. Checking a unit against the standard’s acceptance criteria — deterministic checks, then a rubric model, then a person — is specified and not yet built, so today’s statements say plainly that nothing has verified them.
- 04
Disputes will be ruled with a reason code.
Not builtEither party will be able to dispute inside the window and post a bond, and Recourse will apply the Rulebook to the evidence and issue a ruling citing a rule id and a reason code, with an appeal to a panel. The Rulebook is written and public; the engine that applies it is not built.
- 05
The outcome is written where both parties can check it.
Runs todayEvery event is appended to a hash-chained, signed log, and a Merkle checkpoint commits to the whole log so nothing already published can be quietly rewritten. Sealing a closed commitment, and the party records built from sealed commitments, are specified and not yet built.
Outcome-based contracts, counted by someone neither side employs.
Vendors already bill per resolution, per qualified lead, per booked meeting. What they cannot do is prove the count to a finance team that has no reason to take their word for it. With Recourse the vendor’s pitch changes: pay only for third-party-verified outcomes. The buyer pays nothing to Recourse; the vendor pays 1% of settled value.
Support Resolution
One customer conversation resolved by the vendor's agent without human handoff.
Qualified Lead
One lead delivered that meets the buyer's stated qualification profile and is contactable.
Booked Meeting, Held
One meeting booked by the vendor's agent with an external prospect that the buyer's representative attended and that lasted at least the minimum duration.
CD-0 Custom Deliverable covers one-shot deliverables: the vendor writes the acceptance criteria and Recourse rejects any criterion that is not testable as written.
An agent is a party, not a special case.
The data model treats a company and an autonomous agent the same way: a party with keys, a record, and obligations. An agent key calls the same endpoints an organization calls, holds the same scopes, and signs the same terms hash. There is no separate agent product to migrate to.
/llms.txt says what Recourse is and where everything else is. /llms-full.txt is the whole protocol — states, standards, reason codes, endpoints — in one fetch.
Five calls run a commitment from nothing to a signed record. Every call that moves money is safely retryable, and every error carries a machine code and the call that resolves it.
@recourse/mcp exposes the lifecycle as tools over stdio and reads the API key from its own environment, so the key never enters a prompt.
Every check runs on your side of the line.
A counterparty fetches the chain and the published key, then recomputes every hash and every signature itself. No Recourse code runs in the checking.
Duplicate outcome
Dedupe key matches a previously verified unit; the duplicate is rejected.
Support Resolution
sha256:06c0dd79f36093e9d90cbde1a7f0ae192267b57e6bac189ea6bee07befb75590
The SHA-256 of the canonical standard. Recompute it from the published file and it matches.
What Recourse is not.
No custody.
Recourse instructs holds, releases, and refunds on the parties’ own rails. The funds sit with the rail on behalf of the parties. No Recourse-owned balance ever holds a party’s money.
No guarantee.
v1 does not underwrite the deal. Recourse holds, verifies, rules, and records. It does not pay out a loss, and it is not insurance.
B2B only.
Both parties are organizations. There are no consumer buyers in v1. Agents become parties in the same data model, without a migration.
Every machine ruling carries a reason code, cites a rule, and can be appealed to people. Audit bundles and records are exportable. The rules in force when the terms were accepted govern the commitment.
What a sealed commitment will look like.
Not builtSealing is specified and not built, so no commitment has ever been sealed. This is a drawing of the shape, not a record of anything. The hashes are real: canonicalize the terms below, take the SHA-256, and you get the terms hash printed beside them.
{
"kind": "outcome_stream",
"standard": {
"id": "OS-1",
"version": "0.4.0"
},
"unit_price": {
"amount_cents": 175,
"currency": "usd"
},
"budget_per_period": {
"amount_cents": 500000,
"currency": "usd"
},
"period": "monthly",
"term_periods": 1,
"evidence_source": {
"type": "connector",
"connector": "zendesk"
},
"dispute": {
"buyer_review_window_hours": 120,
"statement_dispute_window_hours": 120,
"evidence_window_hours": 48,
"appeal_window_hours": 72,
"dispute_bond": {
"pct": 2,
"min_cents": 2500,
"max_cents": 250000
},
"appeal_bond": {
"pct": 5,
"min_cents": 10000,
"max_cents": 1000000
},
"path": [
"rulebook",
"panel",
"aaa"
],
"governing_law": "US-DE"
},
"rulebook_version": "0.4.0"
}Event log
sha256:d2144c2f…sha256:ea605fbf…sha256:902b1e69…sha256:85a45b41…sha256:d49a54e7…sha256:eeb44dd8…sha256:684b6191…sha256:cb7eb9e9…sha256:eaaca035…Lifecycle events only. Each unit also writes its own outcome and verification events. Every event is hashed over the one before it, so a missing or altered event breaks the chain.