How this is built

Driftproof is an instrument, so it is built the way it asks skills to be measured: every change is written down before it is made, checked by something that can fail, and reviewed by something that did not write it. This page describes the method. It shows counts read from the source repository's records as of 2026-09-16, and none of the records' contents.

Criteria before code

Every change starts as a specification that says what it must do, as numbered acceptance criteria, before any code is written. The records hold 36 specifications and 358 acceptance criteria.

Red before green, and red again under mutation

A specification carries a gate, a script that checks its criteria. In this method the gate is written first and run while nothing is built, so it reads red, and those red runs are kept: 18 are on record. Once the work passes, the gate is run again against copies with a violation planted in them, and each planted copy has to turn it red. 35 specifications carry a gate, and their gate files name a planted mutation on 315 lines.

An approver that did not build it

Approval is a separate session. It reads the specification, the gate, the change and the operator's written rules from disk, runs the gate again, and works without the build's context: it receives no account of how the change was made. There are 135 approval records. In 44 of them the approver rejected the work or recorded blocking findings that held the merge, and 11 are outright rejections.

Amendments rather than edits

A published report or a merged specification is amended rather than edited in place: a numbered entry says what changed and why, and the original text stays where it was. The specifications carry 117 amendments numbered in the current format.

A constitution and a decision log

A constitution sets the rules every change is checked against, such as no published number without a receipt behind it. Decisions go into an append-only decision log that records what was chosen, what was not, and why; it holds 151 entries.

Audits from outside, published against the project

Outside audits of the tool are committed as received, and the findings page publishes what each found, what is fixed and what is still open. 2 audit documents are on record.

The counts are taken by scripts/build-facts.mjs at one commit of the source repository, whose records do not reach the public tree. The rule behind each count is in /data/build-facts.json.