Outcome-Based Pricing

The Verified-Outcome Contract

A provider advertises one price for one predicate. When the call runs, the caller's payment is held, not spent. The kernel evaluates the declared predicate over the exact bytes delivered to the caller and settles the hold one of two ways: the full price is captured on a pass, or the entire hold is released to zero charge on a failure or an unevaluable output. There is no partial capture, no attempt fee, and no prepayment. Zero or full is the only settlement.

A verified-outcome request pins four values exactly: billing_unit = "verified_outcome", quoted_units = 1, quoted_cost == outcome_price, and settlement_mode = HoldCapture. The verified_outcome unit carries a typed VerifiedOutcomeRequestV1 extension on the MeteredBillingContext; that extension is required for this unit and forbidden on every other billing unit. Its canonical body uses schema chio.outcome.request.v1 and binds the listing, provider-binding, pricing, predicate, optional SLA, and trusted receiver-binding digests. A matching identifier without a matching digest is rejected before the tool ever runs.

The pricing and predicate records are provider-signed and live in the pure chio_listing::outcome module. chio.outcome.pricing.v1 binds pricing_id, provider_id, the predicate_id and its digest, outcome_price: MonetaryAmount, failure_mode: zero_charge, an optional sla_digest, and its issued_at / expires_at window. Every signed record uses RFC 8785 canonical JSON with deny_unknown_fields and a versioned schema id.

{
  "settlementMode": "hold_capture",
  "quote": {
    "billingUnit": "verified_outcome",
    "quotedUnits": 1,
    "quotedCost": { "units": 250, "currency": "USD" },
    "issuedAt": 1752192000,
    "expiresAt": 1752192900
  },
  "verifiedOutcome": {
    "schema": "chio.outcome.request.v1",
    "listing_id": "lst_soc2_review",
    "listing_digest": "b7c1...",
    "provider_binding_digest": "9af0...",
    "pricing_id": "prc_soc2_pass_250",
    "pricing_digest": "d21e...",
    "predicate_id": "pred_soc2_ok",
    "predicate_digest": "4f88...",
    "sla_digest": "e903...",
    "receiver_binding_digest": "1c7d..."
  }
}

The verifiedOutcome block is resolved through trusted stores by these digests. It is never accepted from GovernedTransactionIntent.context or any other free-form field. Field casing above is illustrative; the MeteredBillingContext envelope serializes in camelCase as on the pricing page.

The Deterministic Predicate

A predicate is a non-empty AND-list of assertions carried by schema chio.outcome.predicate.v1, which also binds predicate_id, provider_id, and an issued_at / expires_at window. Each assertion carries one RFC 6901 JSON Pointer pointer and exactly one comparator. The empty pointer selects the whole document. All assertions must hold for the output to pass.

Evaluation returns Passed, Failed { reason }, or Unevaluable { reason }. Both Failed and Unevaluable produce zero charge; the distinction is receipt evidence only. Invalid escape sequences, duplicate assertions, non-integer ordered operands, numeric overflow, missing targets (other than exists), invalid JSON, and unknown comparators are deterministic errors. There is no JSONPath, regex, WASM, floating-point comparison, user code, or model-judged outcome in v1.

{
  "schema": "chio.outcome.predicate.v1",
  "predicate_id": "pred_soc2_ok",
  "provider_id": "did:chio:c87a...",
  "assertions": [
    { "pointer": "/status",        "eq":     "complete" },
    { "pointer": "/findings/0/id", "exists": true },
    { "pointer": "/rows_reviewed", "gte":    1000 }
  ],
  "issued_at": 1752192000,
  "expires_at": 1752278400
}

The example asserts three things about the delivered JSON: a /status equal to complete, the presence of a first finding at /findings/0/id, and at least 1000 rows reviewed. The comparator token is the assertion key here for readability; the on-wire serde layout of an assertion is not part of this illustration, only the pointer-plus-one-comparator shape and the exact comparator vocabulary above.

Hold, Capture, Release-on-Failure

Verified-outcome settlement runs only over MeteredSettlementMode::HoldCapture against a rail proven to support a genuine reversible hold. The kernel authorizes an unsettled hold for exactly outcome_price, dispatches the call, and evaluates the predicate over the frozen post-guard output_ready bytes before they are delivered. Those exact bytes are then delivered and acknowledged, and only after acknowledgement is the hold settled: a pass drives a full Capture(outcome_price); a failure, an unevaluable result, or a canceled delivery drives a Release(VerifiedContractualZeroCharge). Settlement can never precede the delivery acknowledgement, and the bytes hashed for evaluation are byte-for-byte the bytes durably accepted at the receiver boundary.

After the provider accepts the call the settlement table is exhaustive. A valid acknowledgement with Passed is disposition acknowledged and Capture(outcome_price); a valid acknowledgement with Failed or deterministic Unevaluable stays acknowledged but takes a zero-charge Release(VerifiedContractualZeroCharge). An anchored Cancelled proven by VerifiedReceiverNoDelivery is disposition cancelled, verdict Unevaluable { reason: delivery_cancelled }, and a zero release. A durable pre-delivery contractual zero that never opened a slot is not_attempted with a stored zero-charge verdict and a zero release. Anything missing, invalid, pending, or divergent is delivery_unknown: the hold stays frozen and no receipt is emitted. No other combination may capture, release, or emit an outcome receipt.

A Settled capture creates no outstanding obligation atom; a Pending capture, still under a Passed verdict, may open one immutable chio_credit::obligation::ObligationAtom with an ObligationDisposition set to per_call, reconciled only against its existing capture idempotency key.

Two-Stage Delivery Acknowledgement

Charging for a result requires proving the caller actually received that result. Returning the output and a receipt in one ToolCallResponse is not durable delivery acknowledgement. Delivery instead runs as a two-stage commit across a ReceiverDeliveryAnchor that sits outside the receiver's own SQLite and mailbox backup-and-restore domain.

1. Anchor stage. Once the final post-guard bytes and their digest are frozen at output_ready, the receiver verifies the binding, creates the exact external Pending slot, stages the bytes, and compare-and-swaps the anchor Pending -> Acknowledged with rollback-independent blob availability. That transition is signed as chio.outcome.delivery-checkpoint.v1.
2. Local stage. The receiver finalizes its local view, checks the anchor's trusted delivery_accepted_at against both record validity windows and the rail capture deadline, signs chio.outcome.delivery-acknowledgement.v1, and only then exposes the bytes to the agent. The local protocol is LocalStaged -> AnchorAdvanced -> LocalFinalized; exposure is forbidden until the anchored Acknowledged state and the local view agree.

Once anchored, acknowledgement validity is historical and permanent: a later wall-clock expiry of a record or a key does not invalidate an acknowledgement that was valid at its delivery_accepted_at. The cancel branch is symmetric. When the anchor compare-and-swaps Pending -> Cancelled and proves no blob was exposed, the receiver signs chio.outcome.delivery-nonacceptance.v1 and a private verifier constructs VerifiedReceiverNoDelivery, which releases the hold to zero. A missing, timed-out, or unreachable acknowledgement is neither: it is delivery_unknown, the hold stays frozen, and no receipt is emitted until recovery reads the external anchor and resolves the state.

The kernel-signed receipt metadata, schema chio.outcome.verdict.v1, binds the digests that decided the outcome (listing, provider-binding, pricing, predicate, quote, and eligibility), the tagged delivery_disposition and delivered_output_digest, the verdict and reason_code, an sla_attribution of provider | caller_policy | platform, and the charged_amount with its rail_authorization_ref. It cannot be filled from a tool-server self-report.

SLA-Breach Evidence

A provider may sign an SLA commitment, chio.outcome.sla.v1, that binds a max_failure_bps <= 10_000, a minimum_sample_count > 0, a window_seconds > 0, and a fixed window anchor. The corresponding evidence record, chio.outcome.sla-breach.v1, proves a provider's failure rate over a complete receipt-log range: its numerator and denominator are both proven from the exact closed interval derived from that SLA's anchor and window cadence, so a submitter cannot cherry-pick a favorable subrange.

The verifier, not the submitter, applies the fixed eligibility selector (provider_binding_digest, listing_digest, pricing_digest, predicate_digest) across the whole range. It pins the receipt-checkpoint authority key and epoch from trusted configuration, requires a global unresolved dispatch_started count of zero, and partitions every accepted request into three counts that must sum exactly to accepted_count.

{
  "schema": "chio.outcome.sla-breach.v1",
  "provider_id": "did:chio:c87a...",
  "sla_digest": "e903...",
  "selector": {
    "provider_binding_digest": "9af0...",
    "listing_digest": "b7c1...",
    "pricing_digest": "d21e...",
    "predicate_digest": "4f88..."
  },
  "interval": { "effective_at": 1752192000, "expires_at": 1752278400 },
  "receipt_range": { "first_position": 4120, "last_position": 4488 },
  "unresolved_dispatch_started_count": 0,
  "accepted_count": 3,
  "provider_attributable_count": 3,
  "caller_policy_excluded_count": 0,
  "platform_excluded_count": 0,
  "provider_failure_count": 1,
  "failure_bps": 3333
}

Attribution is strict. provider_attributable_count counts only an unmodified delivered provider output that passes or fails the predicate, invalid provider JSON, or a post-acceptance provider incident. A guard block or a byte-changing redaction is caller_policy; delivery, guard-runtime, evaluator, store, and ordering failures are platform. Those rows stay visible and counted in their excluded partitions but enter neither the provider numerator nor the denominator.

The display value is failure_bps = provider_failure_count * 10_000 / provider_attributable_count, computed with checked u128 arithmetic. The value is at most 10,000, and it never saturates. Breach authority never reads the floored display value; it uses the exact checked cross-product provider_failure_count * 10_000 > max_failure_bps * provider_attributable_count, and only when provider_attributable_count >= minimum_sample_count. So one provider failure in three attributable requests breaches a 3,333 bps maximum, while one in four does not breach an exact 2,500 bps maximum.

See Also

• Pricing Models & SLAs for the four standard metered models and the HoldCapture settlement mode this contract builds on.
• Autonomous Pricing for how a provider sets the outcome_price it stakes on the predicate.
• Parametric Insurance for the coverage that consumes chio.outcome.sla-breach.v1 as its trigger.
• Reconciliation & Watchdog for the general authorize/capture/release hold lifecycle the outcome settlement specializes.