F-001: ~2-4% genuine hash-resolution gap identified across two endurance sessions (root cause not yet determined)

[frank001]

Summary

Two endurance reports (qa/endurance/2026-07-06-7340e45/report.md and qa/endurance/2026-07-07-bb0a1c4/report.md, both §3.5 addenda, 2026-07-08) each independently flagged an increased OpenWSFZ-only hashed-callsign (<...>) rate after F-001 shipped, with two competing explanations left open across both original reports:

1. Structural cold-start floor (expected): F-001's hash table is session-scoped; a hashed reference to a station never directly heard this session is unresolvable no matter how well F-001 works.
2. Genuine effectiveness gap: F-001 fails to resolve hashes it should be able to resolve (correspondent already decoded earlier, same session).

What was found

A long-recommended but never-run triage script (triage_f001_hash_gap.py, written 2026-07-06, executed 2026-07-08) mined both sessions' raw OpenWSFZ ALL.TXT directly:

	07-06 session	07-07 session
Structural (no prior in-session announcement at all)	95.1%	92.5%
Protocol-correct (announcement only after)	1.2%	5.3%
Genuine-gap candidate (announcement decoded earlier, still unresolved)	3.68% (254 lines)	2.12% (106 lines)

Hypothesis 1 dominates in both sessions, as expected. Hypothesis 2 is real but small and consistent in order of magnitude across two independent nights -- not the dominant explanation for either session's elevated hashed rate (that turned out to be a propagation-mode effect, see the same reports' spike-window addenda), but a genuine residual worth a closer look.

What this is NOT

This is not the elevated-rate anomaly itself (that's explained by real propagation-mode shifts on both nights, unrelated to F-001's correctness -- see the reports' spike-window sections). This is a separate, smaller, still-real finding: ~2-4% of hashed lines had everything F-001's table needed and still weren't resolved.

Caveat

The "genuine-gap candidate" classification is a shape-matched proxy (nonstandard-callsign-shape heuristic pairing a known correspondent to an earlier decode), not a confirmed 22-bit hash identity match -- ALL.TXT is text-only and carries no hash value to check directly. Some misclassification in either direction is possible.

Recommended next step (not blocking, not urgent)

A narrower root-cause dive into the specific ~254/106 flagged cases per session -- e.g. instrument the native hash table directly (rather than proxy-matching from ALL.TXT) to determine whether these are a real resolution bug, a table-capacity/eviction effect, an ordering/timing edge case, or proxy misclassification.

Full detail: qa/endurance/2026-07-06-7340e45/report.md §3.5, qa/endurance/2026-07-07-bb0a1c4/report.md §3.5.

🤖 Filed by QA, 2026-07-08