Decision trace

The one-line CLI score is for humans. The decision trace is what an agent parses to log, gate, and audit spend.

This is a Developer Preview surface. The shape and its meaning are stable; exact field paths under quote.transactabilityTrace may change during preview.

selat run "<intent>" --dry-run --live-probe --json

Pin with --endpoint / --method / --param when you need a specific endpoint. On the wire the engine emits quote.transactabilityTrace; the JSON dry run surfaces transactabilityTrace top-level. A live probe may invoke the target — only probe endpoints you have confirmed are safe to call.

Attribution buckets

A single blended rate conflates three owners:

Bucket	Owner	What it counts	Upstream paid?
`counterparty`	endpoint	captured payment, then a `5xx` — payment-layer failure after capture	yes → only bucket that should move endpoint reliability
`yourRequests`	agent	a `4xx` — request rejected	often no → fix the request
`settlement`	rail	a `402` / settlement rejection — payment never settled	no → rail/router issue

The network index on the 402 is a counterparty / capture view: paidNum counts captures; successRate is share answered with a 2xx (wire "1" = 1.0). 4xx/402 that never captured do not enter that numerator. The other buckets come from your local ledger (selat history), best-effort over the 90-day evidence window. Quarantine uses a shorter clock — see First-Party Transactability.

Network vs first-party (never blended)

Both are SELAT-observed payment-layer outcomes — never merchant self-report — over different populations:

network — SELAT-routed users; windows under windows; headline prefers recency (24h) while confidence weighs larger samples
firstParty — your captures / counterparty fails

primarySource names which drives signal / primaryCaution (first-party when present). divergence compares them without averaging.

Example shape

Field names in older builds may still say deliveryRate — read that as a success / 2xx-after-capture rate, not delivery proof.

{
  "metric": "transactability",
  "endpointUrl": "https://api.example.com/search",
  "dataStatus": "measured",
  "attribution": {
    "counterparty": {
      "owner": "endpoint",
      "primarySource": "first-party",
      "signal": "below-100pct",
      "network": {
        "scope": "network-wide",
        "window": "7d",
        "successRate": 0.98,
        "capturedPayments": 180,
        "windows": [
          { "window": "24h", "successRate": 0.96, "capturedPayments": 25 },
          { "window": "7d", "successRate": 0.98, "capturedPayments": 180 },
          { "window": "all", "successRate": 0.97, "capturedPayments": 900 }
        ],
        "lastStatus": "200",
        "signal": "ok"
      },
      "firstParty": {
        "scope": "first-party",
        "settled": 24,
        "counterparty5xxFails": 1,
        "successRate": 0.96,
        "sampleSize": 25,
        "signal": "below-100pct"
      },
      "divergence": {
        "networkRate": 0.98,
        "firstPartyRate": 0.96,
        "agree": true,
        "note": "network-wide and your first-party rate agree within tolerance"
      }
    },
    "yourRequests": { "owner": "agent", "firstParty": { "count": 4 } },
    "settlement": { "owner": "rail", "firstParty": { "count": 2 } }
  },
  "primaryCaution": "success-below-100pct",
  "advisories": []
}

Do not treat traces whose only network evidence is successRate: 1 at capturedPayments: 2 as a reliability green light — mark thin samples insufficient. primaryCaution comes from the counterparty bucket only. Prefer cautions named for success / capture rates, not delivery. yourRequests and settlement stay advisories. The endpoint is charged only for what it did. Blending your 4xx into the endpoint rate misleads the agent.

Refunds follow capture

Through SELAT, your payment settles to SELAT first; SELAT then pays the upstream. A refund depends on whether the upstream captured that onward payment — not on the status code. If it did, SELAT has already paid that amount out and has no way to recover it from the upstream, so only SELAT’s own fee comes back.

File a claim. Refunds are never automatic: file one with selat refund claim <quote-id> (or refundClaim() in the Router SDK). Every claim is reviewed before anything is issued.
Uncaptured failure (most 4xx) — refunded.
Captured failure (a 5xx, or a 4xx from an upstream that charges for rejected requests) — SELAT refunds its fee, not the upstream charge. The upstream portion is the same loss you would take paying the merchant directly.

Either way, a 4xx never counts against endpoint reliability. A captured 5xx is the only failure that does: the endpoint took the money and failed to deliver.

Overview

Agentic payments

Transactability

HTTP 402

SELAT Plugins

SELAT CLI

Catalog MCP

SELAT Router SDK

Skills

Glossary

Attribution buckets

Network vs first-party (never blended)

Example shape

Refunds follow capture

​Attribution buckets

​Network vs first-party (never blended)

​Example shape

​Refunds follow capture

Attribution buckets

Network vs first-party (never blended)

Example shape

Refunds follow capture