Certified runs

The registry

A place to put a contamination certificate so that other people's certificates can be counted alongside it. One certificate becomes one row, and the server checks the file before the row exists.

PLANNED There is no leaderboard page. The submission routes are live and the counts are published; the comparative view is separate work that starts when a cell meets the rule below.

A cell is one pair: the run window the agents were scored over, and the set of arms they were run under. Two runs land in the same cell when both strings match exactly. GET /v1/registry/cells reports the two counts and the boolean for every cell holding at least one listed submission, and it repeats needs on every row so the counts can be read against the rule without leaving the response.

A count on its own would let the holder of one signing key reach quorum alone by submitting five of their own runs, so the three fingerprints sit beside it. A fingerprint is the first 16 hex of sha256 over a public key's raw bytes, and it tells you a distinct key signed a file. Three of them raise the floor on independence without establishing it.

Until a cell meets both halves there is nothing to compare, and once it meets them the cells route goes on answering with counts.

The thresholds live in internal/registry/quorum.go as QuorumListed and QuorumFingerprints, and a test fails if either moves without the documentation moving with it. Lowering the bar is a change that shows up in a diff.

To take a submission back off the board, send the same certificate again with ?visibility=private. The row does not move otherwise: who registered it and when stay as they were first written.

One certificate is one row. A second account sending a certificate somebody already registered gets a 409, because a certificate is a public file and counting it once per sender would let a cell reach quorum on one run forwarded five times.

$ curl -sS -X POST \
    'https://api.pit.aqx.llc/v1/registry/certificates?visibility=listed' \
    -H "Authorization: Bearer $PIT_KEY" \
    -H 'Content-Type: application/json' \
    --data-binary @certificate.json

• The body is the certificate file, byte for byte. Use --data-binary rather than -d, which strips newlines, because the digests are taken over the bytes that arrive.
• Any paid plan may submit, from an API key rather than a browser session, because the key id is recorded on the row.
• The file is capped at 1 MiB. The golden certificate in this repository is 23,347 bytes.
• A refusal is a 422 with certificate_unverifiable and the failure class in error.param. Nothing is written, so the table holds only certificates this server checked itself. Every class is reproducible before you send anything, with certverify verify on your own machine.

The server runs three of the five checks: body_digest, receipt_body and signature. The other two compare a certificate against files you hold, and a server holds neither, so a listing does not stand behind them. A run the harness marked invalid is accepted; the row records valid: false and the numbers that go with it.

Contamination that arrives through a model's weights is bounded by the control arms and the reasoning audit rather than by cryptography. A model that remembers March 2023 shows up in the numbers the certificate carries: a shifted-arm delta that collapses toward zero, a probe that recovers the true date, an audit finding that quotes a figure appearing in no row the run served. The signature covers those numbers, so a leak is something you read in arm_deltas and positive_control, not in the signature check.