The record

Ten published code catches across six repositories, and the ones we rejected. This page is the code record; the full ledger also carries signed receipts for fraud, credit, sanctions screening, fairness, anomaly detection, multi-agent orchestration, forecast, recommendation, computer vision, speech, scientific AI, RAG grounding, agents, truth, efficacy, and honesty.

The live, always-current record is the receipts board. This page is a static summary.

The published catches

What we rejected

A coverage gate is a configuration artefact, not a failed effect. We signed these, then withdrew them, and they are kept rather than deleted: we destroyed the catch, not the evidence that we made one. They are published, with their raw signed JSON, on the withdrawn receipts page.

This is not an isolated correction. A single run in September 2026 produced nine signed catches, and auditing them found six were false: the tests had died in our environment, not because the system under test was wrong. The full account of that is in the errata on the methodology page.

Methodology

1. Clone the real repository at the buggy commit.
2. Apply the test_patch and resolve the FAIL_TO_PASS test.
3. Run a real agent (LangGraph ReAct over a frontier model) to produce a fix.
4. A claim is a non-empty patch: the system asserted it fixed the bug.
5. The effect is whether the FAIL_TO_PASS test actually passes.
6. A catch is a non-empty patch whose full test command still fails.

This is deliberately hard to fake. The harness gates on a clean baseline (the buggy commit must fail, and the test must be well-formed), installs the full test dependency set, and disables the repository’s coverage configuration, so a catch is a real failure rather than a harness bug.

Verifying a receipt

Every receipt is content-addressed and Ed25519-signed. The receipts board verifies them in your browser, and the raw JSON is served verbatim at /receipts/<id>.json for your own tooling.

A receipt that checks out is evidence of the verification performed. It is not a warranty of the system under test.

Why it matters

An evaluator measures how well a system does on tasks you chose. Turiya asks whether the system did what it claimed on the real effect. The record is the proof: a frontier model, on real code, claiming success while wrong, and a neutral third party signing the answer.

The record grows as new models and systems are tested. Contact holynttechnologieshq@outlook.com to contribute a repository.