Measure curation_history where the gap actually is (#325) - #527
Open
realmarcin wants to merge 1 commit into
Open
Measure curation_history where the gap actually is (#325)#527realmarcin wants to merge 1 commit into
realmarcin wants to merge 1 commit into
Conversation
#325 counted curation_history on 2 of 311 records and read it as coverage. That framing does not survive reading the two entries: both record a cross-reference between two ANME/SRB records — same community type, different studies, candidates for consolidation — which git cannot express and no other field holds. It is an event log. A record that has had no such event correctly has none, and backfilling 310 would mean inventing them. So 0.0 is the right threshold rather than a lenient one, and the config now says why instead of reading as a capitulation. The gap is on the writing side, and it is measurable. scripts/audit_writers.py already reports it: 26 tools write record YAML and 16 append nothing. A script that rewrites 300 records in place and leaves no trace is what #325 was pointing at; the low record count is the symptom. This does not fix those 16. It stops the set growing silently and splits it into the two groups a fix treats differently — 7 exempt, each with a written reason (writes research/ or data/, creates rather than edits, or is the mechanism a caller records through), and 9 owed, named individually so the backlog is itemised rather than implied. A new writer in neither list fails, which forces the call when the tool is written. Wiring the 9 needs a shared text-append helper: they are line editors, not YAML round-trippers, so record_curation_event does not reach them. gtdb_ground.py has one, privately. Lifting it into curate/ is the follow-up, deliberately not done here. Mutation-checked: a new script that writes a record and records nothing reddens the gate. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The reframing
#325 counted
curation_historyon 2 of 311 records and read it as a coverage gap. That framing does not survive reading the two entries. Both record a cross-reference between two ANME/SRB records — same community type, different studies, candidates for consolidation — which is a fact about the corpus that git cannot express and no other field holds.curation_historyis an event log, not a coverage metric. A record that has had no such event correctly has none, and backfilling 310 records would mean inventing events. Sothreshold: 0.0is the right target, not a lenient one, andconf/qc_config.yamlnow says so rather than reading as a capitulation.Where the gap really is, measured
scripts/audit_writers.py— which already existed — reports it directly:A script that rewrites 300 records in place and leaves no trace is what #325 was pointing at. The low record count is the symptom.
What this PR does
Not fix those 16 — stop the set growing silently, and split it into the two groups a fix treats differently:
research/ordata/ingredients/rather than records; creates records rather than editing them (git shows a creation in full, which is not true of an in-place edit); or is the mechanism a caller records through (write_validated.py,batch_reporter.py— the latter would double-log, sincellm_repair.py:244already records).A new writer in neither list fails, forcing the call when the tool is written instead of at the next audit. The test reads
audit_writers.py's own output rather than re-deriving "does this write YAML" — two answers to one question means the one nobody runs is the one that drifts.Why the 9 are not fixed here
Structural, not effort.
record_curation_eventappends to a parsed dict; these nine are line editors working onsplitlines()+ regex +write_text. That is deliberate — a YAML round-trip would reflow every record they touch, which is whyterm_remapdescribes itself as "text-only edits".The text-append version already exists as
_append_curation_eventingtdb_ground.py, private, and it already solves the parts that are easy to get wrong: the insertion point (- timestamp:is itself column-0, so an early version inserted above the existing history), idempotence (an unconditional append grew the history every re-run), and a write guard that permits at most one appended entry. Lifting it intocurate/is #526 — worth its own PR, and worth confirming outside its original caller before nine call sites depend on it.Checks
uv run pytest tests/— 2381 passed, 16 skippedjust lint,just validate-scalars— exit 0test_every_writer_is_classified; removing it restores greenCloses #325. Filed #526.
🤖 Generated with Claude Code