Journal — 2026-09-19 (run 2 of the day)
This was the fourth scheduled run of the "Routine," the unattended process that drafts, checks, and publishes entries for the TKG English Learner's Dictionary. Nobody reads this in real time; it is the record for the owner (Tom) to catch up on later. The Routine's mode selector (tools/next_mode.py) forces a "lint" run every five runs regardless of what else is due, because it is the only mode that steps back and looks at the project's own health rather than adding new content. This was that run.
Start-of-run housekeeping
No pull request was open from a previous run, so there was no stranded work to merge. Five old branches from earlier sessions were still sitting on GitHub (this tool set can create and read branches but cannot delete them). Three were already fully absorbed into main and logged in earlier journals. Two more — from pull requests #4 and #5, both of which the owner closed by hand outside the normal merge button, but whose content had already reached main by a different path — now show as "differing from main" when compared file-by-file, simply because later runs have gone on to edit those same dictionary entries further. That is expected drift, not lost work, and both branches were already flagged for the owner in earlier runs, so nothing new needed logging. Four leftover bookkeeping files from finished runs were cleaned up.
The main work: reviewer precision
Every entry in this dictionary is checked by two AI "reviewers" (different language models than the one drafting) before it is accepted. Each reviewer raises "issues" — possible problems with a definition, an example sentence, a pronunciation, and so on — and a run of the Routine has to read every serious one and decide whether the reviewer is right (fix it), wrong (reject it, with a reason), or genuinely unclear (flag it for the owner). Over time, some categories of issue from a given reviewer turn out to be right so rarely that reading them is wasted effort — the project calls this "noise."
This run measured, across all 798 such decisions logged since the project began, which categories are noisiest. Five combinations of reviewer and issue-type were wrong more than 70% of the time, on at least twenty decisions each — a large enough sample to trust:
- One reviewer's complaints about "too few examples on a phrase" or "this example states a checkable fact" (right only 16% of the time, 44 decisions)
- The same reviewer's complaints about missing grammar patterns for a word (right 27% of the time, 75 decisions)
- The same reviewer's complaints that a word's set of meanings ("senses") was split up wrong (right 29% of the time, 48 decisions)
- The other, less reliable reviewer's version of the same "examples" complaint (right only 5% of the time — 4 out of 83 — the noisiest pattern found so far)
- That same reviewer's complaints about entries having an unnecessary explanatory note (right 24% of the time, 21 decisions)
Following the project's own rule for this ("a family under 30 percent for a role over twenty or more decisions is turned off"), I changed the review tool (tools/review_panel.py) so that issues in these five categories are now automatically downgraded to "no problem found" before a future run would ever see them and have to spend time re-deciding the same kind of false alarm. I added three small automated tests to make sure this filtering works correctly and doesn't accidentally suppress issues from other reviewer/category combinations. I wrote up the full numbers and reasoning in the project's wiki (wiki/notes/reviewer-precision.md) so a future run — or the owner — can see exactly why these were switched off and reconsider later if the picture changes.
This part of the run cost nothing: it only read existing records, no new AI calls were needed.
Other checks
I ran the project's full battery of automated consistency checks — word-count limits on key files, broken internal links, whether every dictionary entry still validates against its schema, whether cross-references between entries point somewhere real, and the full test suite (292 tests, all passing). Everything passed. Along the way the cross-reference and vocabulary checks turned up nothing new and wrong, only the usual, already-expected list of "this entry mentions a word that doesn't have its own dictionary entry yet" — that's just the normal backlog of future work, not a defect.
One small thing worth the owner's eventual attention, not urgent: two of the dictionary's own core function-word entries (most and other) use a word in their very first definition — "article" and "additional" respectively — that isn't itself in the dictionary's own approved word list for definitions. This is a soft rule, not an error, and fixing it means rewriting a definition, which under this project's rules has to go through the full drafting-and-review pipeline rather than a quick edit during a lint pass. I left it noted in NEXT.md for a future review run to pick up.
I also checked that the project's internal wiki (its knowledge base of house-style rules and decisions) has no orphaned or broken pages — everything referenced from the index actually exists, and nothing exists that isn't indexed. Clean.
What's next
The biggest queue of work is 34 dictionary entries still waiting for a formatting pass (adding bold/italic marks to certain words inside their prose, a house-style rule adopted a few days ago) — that's the natural next "review" run. Behind that, more new entries to draft, and a slowly growing list of words that other entries reference but that don't exist yet. Spend today: $0.33 of the $5.00 daily cap, none of it from this run.