> ## Documentation Index
> Fetch the complete documentation index at: https://selat.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# First-Party Transactability

> Reliability from your agent's own settled payments — the private, authoritative half of SELAT's Transactability signal, read before your agent pays again.

Before your agent pays an endpoint again, it can know whether that endpoint has actually delivered *for it* — not from a merchant's claim, and not from a shared reputation score, but from **your agent's own settled payments**. That reading is **First-Party Transactability**.

<Note>
  This is a **Developer Preview** signal. The reading and its meaning are stable; exact field paths may change during preview. The agent is the reader here — it consumes this at runtime to decide whether to spend. You own the wallet, the funds, and the ledger it is computed from.
</Note>

## The two tiers

First-Party Transactability is the **authoritative** half of a two-tier signal. Its sibling is the network-wide [Transactability Index](/docs/transactability).

|            | Transactability Index (network)                       | First-Party Transactability (yours)                     |
| ---------- | ----------------------------------------------------- | ------------------------------------------------------- |
| Population | aggregated across all SELAT users                     | your agent's own settled payments                       |
| Window     | one or more index windows (24h, 7d, all)              | your recent ledger (rolling 90-day evidence window)     |
| Provenance | SELAT-authored from its settlement-delivery record    | SELAT-recorded from your agent's own settled payments   |
| Privacy    | shared                                                | private — the wallet you own, your ledger, self-custody |
| Role       | fills the gap for endpoints your agent has never paid | drives the decision when your ledger has evidence       |

**Both are SELAT-observed settlement — never a merchant self-report.** SELAT does not fetch a score from any merchant; the router emits the Index from SELAT's own settlement-delivery data and strips any merchant-supplied index off the 402 challenge. So the two tiers differ by *population and locus* — all buyers in SELAT's record versus your agent's own payments in your own ledger — **not** by trustworthiness.

When the two disagree, **first-party wins** — because it is your agent's own usage (your inputs, your rails, your recency), not because the network reading is suspect. The network reading stays worth weighing as a broader prior.

## How your agent reads it

First-Party Transactability appears in the same [decision trace](/docs/transactability/decision-trace) SELAT **computes** from the `402` challenge (plus your local ledger), under `quote.transactabilityTrace`. Inside it:

* `attribution.counterparty.firstParty` is the reading from your own ledger — settled payments, `5xx` delivery failures, and a `deliveryRate`.
* `primarySource` names which reading drives the decision. It is `first-party` whenever your ledger has evidence, otherwise `network`. The two are never blended.
* `divergence` compares the network-wide and first-party readings and marks whether they **agree** (it is present even when they do, with `agree: true`), rather than averaging them away.

Failures are attributed to whoever caused them, so first-party reliability reflects only the endpoint: a `5xx` (the upstream captured payment and failed to deliver) counts against it, while your agent's `4xx` requests and `402` settlement failures are surfaced separately and never charged to the endpoint. See the [Decision trace](/docs/transactability/decision-trace) reference for the full trace shape.

## Reading it today

Reading the **network** score is free — discovery and probing require no account, wallet, or spend. **First-party data is different: it exists only after this wallet has settled calls to the endpoint.** Until then a probe shows the network reading (or `unmeasured`), never a first-party one. Preview a pick with the [SELAT CLI](/docs/selat-cli):

```bash theme={null}
selat run "web search" --dry-run --live-probe
```

The dry run ranks a pick, probes it without paying, and prints the Transactability Score line — the **network** reading from the `402` challenge. For a generic intent the score is often `unmeasured`; to read a specific endpoint's score, pin it (`--endpoint`, `--method`, `--param`) or copy the ready-made probe command [`selat search`](/docs/selat-cli) prints for a ranked pick.

The **first-party** reading lives in the machine-readable [decision trace](/docs/transactability/decision-trace), which SELAT computes from the `402` challenge plus your local ledger. Add `--json` to the same free dry run (selat-cli 0.16.12+) and it arrives as `transactabilityTrace`:

```bash theme={null}
selat run "web search" --dry-run --live-probe --json
```

There `primarySource` names which tier drives the signal — `first-party` whenever your ledger has evidence, else `network` — and the two readings sit side by side, never blended. First-party evidence also shapes ranking directly: your own settled payments and charged failures weigh into every pick `selat run` and `selat search` make, even though the one-line score prints the network view.

## Why it is the authoritative tier

* **It is your agent's own usage.** Same endpoint, but your inputs, your rails, and your recency — the closest available proxy for what your next call will actually get.
* **It cannot be forged or self-reported.** It exists only once your agent has actually paid and SELAT recorded what settled.
* **It is private.** Because your agent pays from the wallet you own, the ledger is yours, on your machine — SELAT never holds it.
* **It is attributed correctly.** Only the endpoint's `5xx` counts against it; your agent's `4xx` are refundable (the upstream was never paid); `402` is a rail issue.

## Honest limits

<Warning>
  **Cold start.** Only endpoints your agent has already paid have first-party data. For everything else the network [Transactability Index](/docs/transactability) fills the gap — that is the point of the two-tier model, not a weakness to hide.
</Warning>

* It is a **signal, not a recommendation** — your agent applies its own bar (a minimum sample, a `deliveryRate` floor, no recent `5xx`).
* Absence of first-party data means *unmeasured*, never *bad*: an endpoint your agent has not paid is simply one you have no first-party history for yet.
* **Memory and punishment run on separate clocks.** Settled history informs the reading for the full 90-day evidence window, but pick-time *exclusion* (quarantine) is driven only by recent charged failures — an endpoint whose recent payments all burned is excluded until that record ages out of the quarantine window (default 30 days, tunable with `selat setup-policy --quarantine-days`) or a payment settles again. Older failures keep informing the rate; they just stop excluding.