---
title: "Calibration"
method: GET
path: "/v1/calibration"
---

# Calibration

`GET /v1/calibration`

## Request

- Base URL: `https://api.anteproof.com` (the document declares no server; this is the origin it was published from)
- URL: `https://api.anteproof.com/v1/calibration`
- Auth: none declared

The transparency record: latest calibration snapshot per domain
plus EVERY launch-gate evaluation ever run, verdicts included —
failing runs are part of the audit trail, not something to hide.

A run whose report names a family in
`calibration.UNTRUSTED_RESOLUTION_FAMILIES` is published as a run and
withheld as a measurement. The row keeps when it ran, its domain,
family, as-of date, horizon, forecaster version and verdict; every
statistic in its `report` is JSON `null` (never 0, never an omitted
key) and the row carries a `withheld` block with
`reason: "resolutions_untrusted"` saying why. `reasons` goes with
them, as a whole list, because those strings quote the same figures in
prose. `withheld` is `null` on every row still published, and rows for
trusted families — the `rollup_threshold` news-tone record included —
are returned exactly as stored.

That the runs stay visible is deliberate and is the honest half of
the story: we ran our own backtest, found the GH Archive series under
those resolutions had collapsed, and withdrew the numbers. Deleting
the rows would hide the withdrawal too.

Withheld per ROW, not per latest row: `proof._gate_withheld` reads
only the newest evaluation (`ORDER BY id DESC LIMIT 1`), and the
withdrawn runs are history. This matches /v1/risk, /v1/proof and the
calibration page exactly — one endpoint must not publish a number the
next one withholds.

## Response `200`

Successful Response

- object

---

[API](https://skmtc.dev/anteproof/apis/anteproof-api.md) · [All operations](https://skmtc.dev/anteproof/apis/anteproof-api/llms.txt) · [OpenAPI document](https://skmtc.dev/anteproof/apis/anteproof-api/revisions/c0d5ac701f1e?raw)