Outcome-Based Pricing

A provider signs one price against one predicate

The provider signs two records separately. chio.outcome.pricing.v1 binds one predicate, by id and digest, to one outcomePrice and one failure mode. OutcomeFailureModeV1 has a single variant, zero_charge, so a pricing record can declare no other behavior on a failure.

The caller asks for that price on a governed request. Its metered billing context uses the billing unit verified_outcome and carries a typed VerifiedOutcomeRequestV1 extension, which names the listing, provider binding, pricing, predicate, optional SLA, and receiver binding by id and digest, never by body. Before any money moves, the kernel’s validate_verified_outcome_request requires:

• the unit and the extension together, in both directions: the unit requires the extension, and any other billing unit that carries the extension is denied;
• the settlement mode MeteredSettlementMode::HoldCapture, hold_capture on the wire;
• quoted_units equal to one, and max_billed_units equal to one when the caller sets it;
• an extension whose own validate passes.

A request that fails any of these is refused with GovernedTransactionDenied before a hold exists.

Read more in Pricing models, which covers the metered models and the HoldCapture settlement mode.

The kernel holds the price before dispatch and settles after delivery

Verified-outcome calls settle through a payment rail that supports a reversible hold: authorize reserves funds without settling them, capture settles the full amount once, and release removes the reservation without a charge. Rails plug in as optional modules. The hold is what stops spend before dispatch.

1. Eligibility. The kernel resolves every referenced record by exact digest and signs chio.outcome.eligibility.v1 with the delivery acknowledgement deadline, the rail capture deadline, and the receiver binding.
2. Hold. It authorizes an unsettled hold for exactly outcomePrice and records it before dispatch.
3. Evaluation. After the tool returns and the output guards run once, the kernel freezes the final bytes and evaluates the predicate over the JSON parsed from those same bytes. Nothing may change the output after evaluation.
4. Delivery. The receiver stages the bytes, signs its acknowledgement, and only then exposes them to the agent.
5. Settlement. The kernel captures or releases the hold as the disposition requires, then signs one receipt that binds the charge, every digest, the verdict, and the rail reference.

Capture always follows the receiver’s acknowledgement, so the caller pays only for bytes it durably holds. A lost acknowledgement or an unresolved delivery state freezes the hold until recovery resolves it, and only resolved delivery evidence releases it.

Read more in Reconciliation, which covers the authorize, capture, and release lifecycle.

The predicate is a short AND-list over the delivered JSON

chio.outcome.predicate.v1 carries between one and 256 assertions, and every one must hold. Each has one RFC 6901 JSON Pointer of at most 2048 characters, where the empty pointer selects the whole document, and exactly one comparator, tagged by kind. Two assertions with the same canonical bytes are rejected.

{
  "schema": "chio.outcome.predicate.v1",
  "predicateId": "<64-hex, derived over the body without predicateId>",
  "providerId": "<the provider this record was signed for>",
  "assertions": [
    { "pointer": "/status",        "comparator": { "kind": "eq",     "value": "complete" } },
    { "pointer": "/findings/0/id", "comparator": { "kind": "exists" } },
    { "pointer": "/rows_reviewed", "comparator": { "kind": "gte",    "value": 1000 } }
  ],
  "issuedAtUnixMs": 1752192000000,
  "expiresAtUnixMs": 1752278400000
}

On the wire an assertion is { "pointer": ..., "comparator": { "kind": ..., "value": ... } }, and exists has no value member. The published schema states the three shapes as a oneOf and bounds an ordered operand to the I-JSON safe integer range. The comparator set holds no JSONPath, regex, WASM, floating-point comparison, user code, or model judgment, so two evaluators reach the same verdict on the same bytes.

evaluate_outcome_predicate takes the predicate and the output bytes and returns a verdict, the output digest, the predicate id, and the predicate envelope digest. The verdict is Passed, Failed { assertion_index, reason }, or Unevaluable { reason }, and a failure names its deciding assertion by index.

Two keys sign delivery, so the charged bytes are the bytes received

An anchor signs the chio.outcome.delivery-checkpoint.v1 records, and a receiver signs the terminal record. OutcomeReceiverBindingV1 hashes the anchor’s identity, key, and epoch together with the receiver’s into one receiverBindingDigest. The eligibility record carries that digest, so the pair of keys that may speak for a delivery is fixed before the call runs.

A checkpoint chain is exactly two records: pending at sequence one, then acknowledged or cancelled. An acknowledged record carries a blob digest equal to the output digest. The receiver builds its chio.outcome.delivery-acknowledgement.v1 from that checkpoint: it copies the acceptance time from the anchor’s trusted clock, so acceptance cannot be backdated, and requires finalOutputDigest to equal durableBlobDigest.

chio.outcome.delivery-nonacceptance.v1 is the matching record for a canceled checkpoint. Two kernel-signed records classify what happened to the bytes: chio.outcome.output-provenance.v1 sets a provenanceClass of provider or caller_policy, and chio.outcome.contractual-zero.v1 records a zero charge that never opened a delivery slot.

Read more in Delivery checkpoint rules.

The evidence decides the amount and who carries a zero

assess_outcome_price takes the delivery evidence, the verified pricing record, and the kernel-signed eligibility record, and returns an OutcomePriceAssessmentV1. It first checks that eligibility and pricing agree on the pricing id and digest, the provider, the predicate id and digest, the SLA digest, and the price. Then the delivery evidence picks the disposition the figure draws: FullPrice, ZeroPrice, or Indeterminate.

Evidence also decides attribution. An acknowledged delivery takes provider or caller_policy from its provenance class, so a guard block or a byte-changing redaction attaches to the caller’s policy. A canceled delivery is platform. A pre-delivery zero splits on its reason: output_blocked is caller_policy, and output_mutation_after_evaluation is platform.

An Unknown delivery returns Indeterminate with no verdict or attribution. Its assessed amount of zero neither settles nor waives the obligation; the hold stays frozen until the delivery evidence is recovered. On the kernel side, a resolved outcome carries one SettlementDispositionV1, Capture { amount }, ContractualZeroCharge { currency }, or NotApplicable, and the receipt’s chio.outcome.verdict.v1 projection binds it to the evidence that produced it.

Read more in Assessment by delivery evidence.

An SLA commitment turns failure rates into checkable evidence

A provider may sign one further record. chio.outcome.sla.v1 states the failure rate it commits to, max_failure_bps, over a fixed window with a minimum sample count. The pricing record references it by slaDigest, the eligibility record carries the same digest, and the assessment refuses to proceed when the two disagree. The anchor and the window fix the cadence: validation rejects an anchor later than effectiveAtUnixMs and a window that would overflow past the anchor.

A breach is proven with chio.outcome.sla-breach.v1. It covers the exact closed interval the anchor and cadence define, so a submitter cannot choose a favorable subrange, and it carries a complete range proof over every receipt in that interval. Only provider-attributable requests enter the rate; caller-policy and platform outcomes stay counted in their own partitions.

breach when
  provider_failure_count × 10,000 > max_failure_bps × provider_attributable_count
  and provider_attributable_count >= minimum_sample_count

One provider failure in three attributable requests breaches a 3,333 bps maximum; one in four does not breach an exact 2,500 bps maximum. A breach artifact is evidence submitted to governance and moves no funds.

A passed verdict proves the predicate held

Passed means the delivered JSON satisfied the predicate the provider signed, within the comparator set: JSON Pointer targets, canonical-byte equality, and integer ordering. Factual correctness and objective value rest on how well the buyer’s chosen predicate captures them. The receipt records what the kernel decided and charged; the mediation boundary covers what any receipt can establish about the world.

Next: price a call by its quantity