Blog
Rebuild only what changed: t27 reuses a spec's verdict until something it depends on moves
[software verdicts only; 570 of 1811 specs still need their own fixes] t27c now keeps a seal next to each verified spec and reuses its verdict while the spec, its imports, its generated code, its test tools and its configuration are unchanged. On master t27c frontier reuses 1241 of 1811 specs, up from 2 on 9 October; an audit reruns one reused spec in 16 per round, and four rounds found no disagreement.
t27 has about 1800 specs, and checking one means compiling it and running its tests. Most of them do not change between two commits, yet every check used to start from zero. Since 9 October, t27c keeps a seal next to each verified spec and reuses the verdict when nothing it depends on has changed. On master it now reuses 1241 of 1811 specs; two days ago it reused 2.
What a seal records
A verdict is a fact about a spec, the specs it imports, the code t27c generated for it, the tools that ran the tests, and the configuration. A v2 seal records each of these, and t27c frontier walks the import graph and answers, for every spec, REUSE or the first part that differs. The toolchain is judged by output, not by version: if a compiler change leaves a spec's generated code byte-identical, its verdict stands.
What moved the number
| Step | Reused | PR |
|---|---|---|
| Seal v2 and t27c frontier | 2 of 1712 | t27#8110 |
| The two hub specs every other spec imports (types, constants) | 424 of 1743 | t27#8177, t27#8209 |
| A re-mint of every spec whose tests pass | 1115 of 1751 | t27#8372 |
frontier reads use a::b::Item and module-less specs correctly | 1151 | t27#8385 |
t27c frontier --reseal: the re-mint as one command | 1173 | t27#8392, t27#8554 |
| Specs that passed and had simply never been sealed | 1241 of 1811 | t27#8700 |
Six fixes to how t27 is translated to Zig (t27#8415, t27#8418, t27#8566, t27#8617, t27#8636, t27#8667) each moved 2 to 9 specs past one compile error. Each one was measured over every .t27 in the repository, and each re-sealed the specs it moved in the same pull request. #8667 alone changed the generated code of 173 specs; the 74 of them that already passed were tested before and after, with identical results.
What keeps a reused verdict honest
- No verdict from nothing: a spec with no test and no invariant is never reused (t27#8374), nor is a suite whose every test ran 0 asserts (t27#8709).
t27c seal --saverefuses to replace a passing seal with one that does not compile, unless forced (t27#8577). A regression is not a re-seal.t27c frontier --auditreruns one reused spec in 16 per round and poisons any seal that disagrees (t27#8559). Four rounds on 10 October reran 259 reused verdicts; all agreed.- A re-mint that would overwrite another spec's seal file writes it back (t27#8392, after the end-to-end run found five such files, t27#8540).
On the board
The same idea runs on silicon. An agent next to each board (t27#8155) replaces driving a board over the network: die C, run over USB/IP for R3-3, took about 2.5 hours, and the first agent run, on die A, took 42 seconds. A cached bitstream (t27#8296) takes a repeat build from 39 seconds to 4 or 5, with every tenth hit rebuilt and compared byte for byte. The board still runs every time; only the build is reused.
What this does not show
A reused verdict is only as good as what its seal records: an input it does not name, or a test that passes by luck, would be missed, which is why the audit keeps rerunning a sample. 570 of 1811 specs are still not reused, and most of them need their own fixes, not more tooling. Twice in this work a pull request merged with a check red that it had caused itself (t27#8415, t27#8667); both were repaired by follow-ups (t27#8418, t27#8672).
What this does not settle
- A reused verdict is only as good as what its seal records: an input the seal does not name, or a test that passes by luck, is missed until the audit reruns that spec.
- Seals written before t27#8709 carry no vacuous count, so a suite of 0-assert tests sealed earlier is reused until the audit or a re-seal finds it.
- 570 of 1811 specs are not reused: 308 have no seal or import a spec that has none, mostly because they do not compile, and 111 have a seal that records a failure or a block. They need their own fixes.
- Hardware verdicts are outside this count: a silicon run still needs the owner's word on the bench, and loading a shared bitstream on a board without a toolchain (P8) is a spec only.
- Twice a pull request of this work merged with a check red that it caused (t27#8415, t27#8667); both were repaired by follow-ups (t27#8418, t27#8672).
Receipts
- t27#8314: the loop's ledger, a frontier measurement at every step · OPEN
- t27#8095: epic, rebuild only what is not yet verified · OPEN
- t27#8110: seal v2 and t27c frontier · MERGED 2026-10-09
- t27#8372: second re-mint, 727 specs · MERGED 2026-10-09
- t27#8385: frontier resolves item-level use and module-less seals · MERGED 2026-10-09
- t27#8392: t27c frontier --reseal · MERGED 2026-10-10
- t27#8700: --reseal tries never-sealed specs · MERGED 2026-10-10
- t27#8374: a verdict needs at least one check that ran · MERGED 2026-10-09
- t27#8709: a fully vacuous suite is no verdict · MERGED 2026-10-10
- t27#8577: seal --save refuses a regression · MERGED 2026-10-10
- t27#8559: t27c frontier --audit · MERGED 2026-10-10
- t27#8667: gen-zig: pointer and slice parameters, 173 specs moved, 74 passing unchanged · MERGED 2026-10-10
- t27#8155: an agent next to each board · MERGED 2026-10-09
- t27#8296: t27c silicon reuses its bitstream · MERGED 2026-10-09
Work with me
Want this kind of check on your own design?
I audit RTL and build independent, bit-exact models, then take the result through synthesis and, when useful, onto an Artix-7 board. The first conformance module is free.