Skip to main content
The Transactability score is a reading a human can eyeball on the terminal. The decision trace is the same reading in machine-readable form — the object an agent parses to gate its own spend at runtime.
This is a Developer Preview surface. The shape and its meaning are stable; exact field paths under quote.transactabilityTrace may change during preview.
The SELAT CLI renders the score as a one-line summary for a human — selat run "<intent>" --dry-run --live-probe prints the network reading in the pick preview, before any spend. For an agent that needs to log, annotate, rank, or audit the full reading, add --json to the same free dry run (selat-cli 0.16.12+) and the machine-readable decision trace rides along as transactabilityTrace, next to the plan and the human score line:
For a specific endpoint’s trace rather than a generic pick, pin it — --endpoint <url> (plus --method / --param as needed). On the wire the engine emits the same object as quote.transactabilityTrace; the JSON dry run surfaces it top-level as transactabilityTrace. A live probe may invoke the target endpoint’s method and body — only probe an endpoint you have already confirmed is safe to call. Rather than one blended rate, the trace separates failures by who is actually responsible — because a single “success rate” conflates three different owners: The network index on the 402 measures only the counterparty view: paidNum counts captured payments (see What each reading means), so a 4xx/402 that never settled cannot enter it. The other two buckets come from your own SELAT payment ledger — the record of your paid calls (see selat history) — which the CLI folds in at probe time (best-effort, 90-day evidence window). Pick-time quarantine runs on a separate, shorter clock — see First-Party Transactability. The counterparty bucket carries two independent readings that are never blended. Both are SELAT’s own settlement-delivery observations — never a merchant self-report — but they cover different populations: network is aggregated across all SELAT users; it carries every window the payload has — 24h, 7d, and all — under windows, with the headline window/deliveryRate recency-first (24h) and the confidence weight taken from the widest window’s sample (SELAT-authored; the router emits it from SELAT’s settlement record and strips any merchant-supplied index), while firstParty is your own settled payments. They are different populations over different windows, so their samples are never summed and their rates never averaged. primarySource names which reading drives signal/primaryCaution — first-party whenever it has evidence, because it is your own usage (your inputs, rails, recency), not because the network reading is untrusted. divergence compares the two and marks whether they agree (it is present even when they do, with agree: true); the network-wide reading stays worth weighing as a broader prior, rather than hiding the comparison in one number. See First-Party Transactability for why your own ledger is the authoritative reading.
primaryCaution is resolved from the counterparty bucket only — the agent’s 4xx and the rail’s 402 never move it. Precedence: unmeasured → last-attempt-5xx → delivery-below-100pct → low-confidence-sample → null. The yourRequests and settlement counts surface as advisories instead, so the agent can act on them (“fix my request”, “retry the settlement”) without misreading them as the endpoint being unreliable.
The endpoint is charged only for what it did. In the example above, api.exa.ai/search shows a 0.96 counterparty rate (one real 5xx over 25 captured payments) — the four 4xx and two 402 are pulled out as advisories, not held against the endpoint. A blended rate would have read ~0.83 — 24 delivered over 29 charged attempts, folding your four rejected requests into the endpoint’s record (the two 402s never charged anyone, so even a naive blend has no basis to count them) — and wrongly told the agent to avoid a reliable endpoint.
On a 4xx, you paid SELAT but the upstream never captured — so the charge is recoverable. The yourRequests bucket carries refundable: true (with refundStatus: "coming-soon"); agents will be able to file a refund request for these charges. This is the practical reason a 4xx must never count against the endpoint: it is not the endpoint’s failure, and it is not even a completed payment to the endpoint.