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

> ## Agent Instructions
> Prices are US dollars per contract that pays $1: 0.46 means 46 cents. Spread is the Yes ask plus the No ask minus $1. Liquidity grades are deep, tradeable and thin; lists hide thin markets unless include_thin=true. Relations are proven from contract terms, never inferred from wording; a lead marked informational is never executable. Every figure carries a graph_run; read /agents/reading-order first, then /concepts/relations and /concepts/liquidity.

# Accuracy

> How Routeur checks every proven relation against settled outcomes, how the hand-labelled sample is drawn and judged, what the published figures mean, and what releases a proof family for executable leads.

Routeur never infers a relation between two markets from prose. Every
relation is proven from the venues' structured contract terms by exact
arithmetic, and every proof is a claim about outcomes: if the graph says two
markets are equivalent, they must settle the same way. This page is the
record of whether those claims held, and how to read it.

The figures live at `GET /v1/accuracy`,
which needs no API key, and on [routeur.app/accuracy](https://routeur.app/accuracy).
They are rebuilt every half hour by the settlements job.

## What is checked

A proven relation is one of four claims about how two binary markets settle:

| Relation      | The claim                                  | A violation is              |
| ------------- | ------------------------------------------ | --------------------------- |
| `equivalent`  | Both settle the same way                   | One Yes, the other No       |
| `implies`     | If the left settles Yes, so does the right | Left Yes and right No       |
| `contradicts` | Both cannot settle Yes                     | Both Yes                    |
| `overlaps`    | No claim in either direction               | Never; counted, not checked |

Subset and superset edges (`implies` seen from either side) are one relation
type here, checked from whichever side implies the other.

Once **both** markets of a relation have settled, the claim is checked
against the results:

* **consistent**: both settled Yes or No and the claim held;
* **violated**: both settled Yes or No and the claim did not hold;
* **unverifiable**: a side settled scalar or void, or the relation is an
  overlap. Unverifiable pairs are counted so nothing disappears, but they
  never enter a rate.

A violation is never a matter of odds. The relation was proven from the
terms, so a violation means a proof read the terms wrong, a source flag was
wrong, or the venues settled the same question differently. Every violation
is queued for a person to look at.

Settlements come from Kalshi's settled list and archive for Kalshi, and for
Polymarket from the venue's own resolution of every market the graph relates
to a settled Kalshi market, plus the imported archive. A relation is
re-checked when a venue changes a result.

## Proof families

Figures are grouped by relation type and **proof family**, because each
family rests on different source facts and fails in different ways:

| Family      | What the proof rests on                                                                                     | Venues |
| ----------- | ----------------------------------------------------------------------------------------------------------- | ------ |
| `ladder`    | Exact strike bounds on one numeric variable within a venue's event                                          | One    |
| `sports`    | The same game, paired across venues by league, date, settlement scope and teams                             | Both   |
| `econ`      | The same economic release or crypto price, paired across venues by variable, period, observation and source | Both   |
| `exclusive` | A source-asserted mutually exclusive event                                                                  | One    |
| `other`     | Anything outside the named families                                                                         |        |

Each bucket is one relation type, one family, and whether the relation
crosses venues.

## Reading the numbers

For every bucket the record gives:

* `checked`: relations whose markets both settled Yes or No (consistent plus
  violated);
* `violated`, and `violation_rate` = violated / checked;
* `violation_rate_low` and `violation_rate_high`: a 95% **Wilson score
  interval** on the violation rate. Wilson intervals stay inside \[0, 1] and
  are honest at small counts and at rates near zero, where a plain ± interval
  would claim certainty. With 0 violations in 25 checks the upper bound is
  about 13%; with 0 in 300 it is about 1.2%; with 0 in 370 it drops under 1%.
  The interval, not the point rate, is what to read;
* `unverifiable`, and the first and last settlement covered;
* `labels`: how the hand-checked sample was judged (below);
* `wrong_relations_still_live`: relations a reviewer judged wrong that the
  latest graph run still holds. This should be zero; it is alerted on;
* `released`: whether the family has passed the release guard.

The `headline` sums the buckets. Its `violation_rate_high` is the upper
bound over everything checked, which is the single number to quote.

## The hand-labelled sample

Outcome checks only say whether a claim held; they cannot say a proof was
right for the right reason, and they arrive only after settlement. So every
run also draws a **stratified sample** of live relations: up to 20 open items
per bucket, chosen at random from the latest graph with a preference for the
newest relations, never a relation already judged or already queued.

Moderators see the sample, and every violation, in the review queue at
`/mod`, with the proof's evidence, both contracts and how each settled. They
judge each relation **correct**, **wrong** or **unsure**, with a reason.
Precision is correct over correct plus wrong; unsure judgements are shown
but never counted. Labels carry their own Wilson interval.

A relation judged wrong that is still in the latest graph is counted in
`wrong_relations_still_live` and raises an alert, because the graph is
publishing something a person has already found to be wrong.

## The release guard

Kalshi and Polymarket settle a delayed or cancelled economic release by
different rules, so a lead on an economic relation is shown but marked
`informational`: it is never offered as executable, whatever the books say.

A proof family (per venue scope) is **released** when, across its relation
types:

1. at least **25** of its relations have been checked against settled
   outcomes, and
2. either **none** was violated, or the upper bound of its violation rate is
   **under 1%**.

The grapher reads the released set at the start of every run and drops the
informational mark from leads whose family is released. Nothing else changes:
leads still carry every other caveat, and a family that later records a
violation falls back below the guard on the next run. The guard's parameters
are published in the record's `release` section.

## Alerts

Two conditions page the operators: a relation judged wrong that is still
live, and a violation recorded in a family that had been released. Both are
read from the settlements job's report.

## Checking one relation

`GET /v1/relations/{left}/{right}/verification`
returns one pair's verdict and label, with its bucket's figures, stated from
the left market's side. It works after the markets have left the listing,
unlike the proof trail, which is rebuilt from the latest graph.