Skip to main content
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. 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: 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: 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.