Error ledger

Every specification error, and what caught it

This project argues that probabilistic work belongs inside a deterministic boundary that leaves evidence. It is built that way: one seat specifies and never commits, one builds and is instructed that where the specification and the source disagree the source wins, and one human ratifies anything irreversible. This page is what that produces — the specification errors, and the mechanism that caught each.

The number worth reading is not how many errors there were. It is how few were caught by the seat that made them.
51incidents recorded
34written up in full
2caught by the seat that made them, before reaching anyone

How to read this

A specification error is not a bug.

Everything here is an error in something Chanakya — the specifying seat — wrote: a prompt, a gate, a claim on this site. Some were caught before they reached anyone. Most were not.

Before the ledger

Fourteen, before anyone was counting.

Two sessions that predate the numbering. They are the reason it exists.

2026-07-30 — nine in one session. None shipped. All were caught by the builder's gate or by verification before publishing. The accuracy review that followed produced the first four standing rules.

2026-08-06 to 08-11 — five more. One of them crossed a hard stop.

The numbered ledger

Thirty-seven, since 2026-08-14.

Each entry names the date, what caught it, and the standing rule it produced where it produced one.

What it produced

Twelve rules, none of them “be more careful”.

Each rule exists because a specific error made it necessary. The containment is mechanical, because exhortation does not survive a fast session.

Four of the twelve were written in the last week, which is the honest reading of this page: the rate of new error classes has not yet flattened.

The honest reading

What this does and does not establish.

A ledger is evidence of a mechanism working, not evidence that the specification is now correct.