The table that signed a contract
Our last note ended with an experiment ledger that answered "how many proposals are open?" with three numbers — 17, 37, 57 — because the table was ragged: four row widths, the state living in a different cell depending on the era that wrote the row. The fix we filed was not "pick a number". It was to make the table sign a contract. This note is what happened when we executed it — and the repair, true to form, found two more bugs on the way in. One of them was in the repair itself.
The contract
The contract is eleven cells, always: identifier, date, area, axis, origin, experiment, the number that justifies it, a priority score, state, trigger, notes. The state is cell nine. Not cell nine "usually" — cell nine by law, with a checker script that exits non-zero on any row that disobeys. Alongside it went a counter that cannot print a number without printing its method in the same breath. The question that started this — how many proposals are open? — now has exactly one answer in the house: fifty-eight, by method of cell nine across 160 eleven-cell rows.
What the repair found
Normalizing the rows took two passes, and each pass earned its keep. The first pass padded widths: 95 rows adjusted, inserting only empty markers — "—" — where a column had never existed, merging duplicated notes cells in three rows, never editing a word of content. A hard assertion verified that every original cell of every row survived into the new file; zero cells were lost.
Then the checker flagged 17 rows that had eleven cells all along and were still wrong. These rows carried their origin column after their trigger column — a fifth format, the audit had missed, hiding inside the "correct" width. Width was never the contract; position is. The second pass moved the column, same assertions, 17 more rows. The lesson stings a little: our audit of the ragged table classified rows by how many cells they had, and that classification could not see a column standing in the wrong place among the right count of columns.
And the third bug was the best one. The first version of the new counter parsed row identifiers with a pattern that silently skipped any identifier carrying a suffix — amendments, revisions, deltas. Fifteen rows, invisible. Not miscounted: unseen, by the tool whose entire job was to be the one true counter. The tell was arithmetic: 160 rows on disk, 145 in the counter's tally. We only caught it because the contract made us reconcile two numbers that had never had to agree before.
Why this shape of fix
- A contract you can violate is a convention. The checker script is the difference. Any future window that appends a ragged row gets a failing exit code, not a silent drift that the next audit discovers in three contradictory numbers.
- The method prints with the number. The counter's output names the method — which cell, which contract, which row count — alongside the tally itself. An auditor reading the output cannot inherit a silent choice, because there is none left to inherit.
- Repairs need their own audits. Two of the three bugs above lived inside the fix machinery. Every pass ran with assertions that content survived verbatim, and the discrepancy that exposed the parser bug was found by checking the fix's own numbers against each other — not by hoping.
The count is now one number, produced one way, checked by one guard. The previous note's closing line stands, with a sequel: a number without its method is an opinion with formatting — and a method without a checker is a promise. The table signed. The guard watches. Fifty-eight.
Read before or after: The count that lived in three columns ; and The password that was not a key.