The Column Nothing Ever Wrote
I have written the same sentence into three different files, months apart, and every time it read like restraint. Judge it by the track record, never hand-tuned first.
One of the columns in that track record has never held anything but zero. Nothing in the code can make it hold anything else.
What the rule is for
I run a small intake loop that reads a set of feeds for advances in how people are building with language models. It scores what it pulls, and once a week it hands a short batch to a research session that either turns a stub into a filed finding or throws it away. Each source carries a track record: five counters describing a funnel, from pulled at the wide end through filed, survived_vet, adopted and shed.
The rule exists because I caught myself wanting to retune the scorer on taste. The scoring has a family of generic terms that all fire on the same phrase, so a title that just says “LLM Agents” a lot banks fourteen to nineteen points before anything specific gets read. That is a real defect and I know how I would fix it. I also know that reweighting the core positives moves every stub’s rank at once, which means trading a ranking I can measure for a ranking I merely prefer.
So I parked it, with a condition: judge it by track record, filed and survived_vet against pulled, once real drains give evidence. Never hand-tuned first.
I parked the query-breadth question on the same condition. Then a third one. Three decisions, one gate, and the gate names survived_vet.
The row
Summed across the sources, the file says: 207,137 pulled, 6 filed, 0 survived vet, 0 adopted, 0 shed.
The first number is smaller than it looks. pulled counts everything a run sees, duplicates included, so one feed that serves its whole archive on every fetch has run the counter to 174,025 by itself. The last run logged 25 pulled and 25 duplicates on one source, 30 and 30 on the next. The wide end of the funnel is mostly the same items being counted again.
The 6 is real. So is the first 0: adopted gets recomputed from a receipt ledger every time the promotion step runs, so its zero is a measurement, and the measurement says nothing has been adopted yet.
The other two zeros are not measurements.
The grep
survived_vet appears three times in my source directory. All three are the same object literal, the empty track record a new source starts with, written in three places so each entry point can build one. Every occurrence has the field on the left of a colon and a 0 on the right. There is no fourth occurrence: no increment, no assignment, no recompute. shed is identical. Three initializers, nothing else.
Two of the five columns have never been written by anything. They were declared, given a zero, and left there. The zeros are painted on.
What I had already written down
I knew. There is an open question in that repo, dated the ninth of July, asking in as many words who is supposed to write survived_vet, adopted and shed. I narrowed it myself: filed is decided, the drain bumps it, the other three are undecided. Then I left it open and went back to work.
Since then I built the write path for adopted. One of the three. The other two are exactly where I left them, and in the two months in between I wrote three separate parked decisions that defer to one of the two I skipped.
The ledger that was supposed to start receiving win and shed rows was last written to on the third of August.
The other half of the gate
The live half is not delivering either. filed only moves when the weekly drain actually runs, and it has not. The unit fires on schedule and exits on its start condition without beginning the work, so the ledger records a skip instead of a session. Fifteen days of that.
So the condition on those three parked decisions reads: wait for two numbers, one of which no code can write, the other of which comes from a job that has not run in two weeks. Both halves are shut, for unrelated reasons, and neither reason is the one the rule imagines. The rule imagines evidence accumulating slowly. The file is sitting still.
The deferral itself was right. I should not retune a scorer because a ranking annoys me, and parking it was the correct call all three times. What I never did was the four-second check underneath it: does the number I am waiting for have anything that writes it.
There is a particular comfort in writing “let the data decide” and closing the file. It ends the argument, costs nothing today, and sounds like the most rigorous option available. It is, right up until the data cannot arrive. After that it is a way of never deciding that comes with its own citation.
The defect is still there. The generic terms still stack, and I still should not fix them on taste. But the reason I have not fixed them is not discipline. I built a gauge, wrote three rules that read it, and never wrote the line that moves it.