Apply external_authority to AVE-2026-00074, clearing its enum-gap fixture (issue #218) - #220
Conversation
|
Traced this against the actual diff, it holds up completely. The record edit is exactly one line, evidence_basis_engines only, nothing else in the file touched. Confirms the "hand-edited just the one field" claim precisely rather than taking it on faith. The new test through the actual is_floor_basis() logic by hand: with evidence_basis_engines as ["pattern", "external_authority"], len(set(engines)) is 2, so the cardinality floor doesn't apply, and evidence_kind_default isn't semantic_inference either, so is_floor_basis() returns False and confidence_signal() returns None on the early-exit check. That's exactly what test_external_authority_member_clears_the_00074_enum_gap asserts, confirmed mechanically. The part worth separate credit: how the two existing tests got handled. Neither got silently left stale, which would have quietly implied 00074 still looks like this, and neither got deleted just because they described the record's old shape. Both docstrings were corrected to say "pre-#218" and clarify what each test actually pins, the floor behavior in general, the note logic for any pre-vocabulary record, using 00074's old shape as a realistic example rather than asserting something about its current state. That's the harder, more careful edit, recognizing a test's real purpose is broader than the specific record it was modeled on, and fixing the description instead of either ignoring the drift or overcorrecting into deleting a still-valid test. Merging. |
Closes #218.
Both halves of #98 have landed (#213, #214). This is the one remaining piece named in both PRs: AVE-2026-00074 sat at the floor basis because its evidence_basis_engines had no member for "an external authority was queried and returned a determinate answer." The record's detection_methodology already describes probing GitHub's users API, package registries, and RDAP; it just predated the vocabulary.
Change:
records/AVE-2026-00074.json:evidence_basis_enginesis now["pattern", "external_authority"]. The engine set clears the floor, so the consumer-side confidence check stops firing on it, which is the escalation condition named in Add consumer-side confidence signal check for self-reported confidence_baseline (issue #98) #213/Derive verification_basis from a record's own evidence axes (issue #98) #214: the field carries the member, and a re-run fires zero times on a record whose methodology names an authority probe.tests/test_confidence_signal.py: addstest_external_authority_member_clears_the_00074_enum_gapto pin the post-Apply external_authority to AVE-2026-00074, clearing its enum-gap fixture #218 shape (a multi-engine set containing external_authority is not flagged), and updates the two docstrings that referenced the record's pre-Apply external_authority to AVE-2026-00074, clearing its enum-gap fixture #218 shape so the suite stays honest about what it mirrors.Verification (the CI commands, all green):
python scripts/check_confidence_signal.py --json: findings count 0 (was 1, AVE-2026-00074)python scripts/write_verification_basis.py: "All 80 records agree with their derived verification_basis." (exit 0)python scripts/validate_records.py: "All 80 records valid against schema/ave-record-1.1.0.schema.json." (exit 0; two pre-existing researcher-name warnings unrelated to this change)python scripts/check_fixtures.py: "All 80 records have positive and negative conformance fixtures." (exit 0)python scripts/validate_crosswalks.py: 9/9 valid (exit 0)pytest tests/ -q: 428 passed (CI-identical venv withpip install -e ".[dev]")Note: the record file remains non-canonical relative to write_verification_basis.py's serialisation (73 of 80 records on main are), so this change hand-edits only the one field and leaves the file's existing formatting untouched; corpus canonicalisation stays the separate work already named in #98.