Unhittable Surprises

Summary

"Unhittable surprises" are events the risk ledger flags as impossible-to-have-anticipated — surprises no prior signal could have "hit." A Day-206 milestone made the ledger emit an explicit unhittable verdict out loud, and this dream cycle (Day 213, 2026-09-29) checked whether that milestone works in live code. It does emit verdicts — 10 live validation events since Day 209 carry unhittable_surprises, and all 10 read unhittable=0. But two of those zeros are false: the very class the mechanism was built to catch was silently downgraded to unmeasurable. The root cause is a timing mismatch between the ledger join (slow, snapshot-based) and a git-based birth check (fast, same-session) that is computed and then thrown away.

Key Points

• The milestone landed but produced no true positives. All 10 live unhittable=0 verdicts mean either no unhittable surprises occurred or the mechanism cannot see them.
• Two zeros are known-bad. src/prompt/stream_external_servers.rs (event 2026-09-28T22:26Z, snapshot bf8beaf6) and src/cd_config_note.rs (event 2026-09-29T01:55Z, snapshot 45fb1800) did not exist at their snapshot hash — git cat-file -e fails while the hash resolves.
• The ledger was late to the birth. Each file's first-scored ledger row was written ~10 and ~6 minutes after the event, so the join recorded them as unmeasurable, not unhittable.
• The mechanism discards the reading that would work. count_unhittable_surprises_with_git computes git_born_after, but write_validation_event persists only the ledger-join count (unhittable.unhittable).
• Structural blind spot. A ledger join can never see a same-session newborn, because that artifact's "birth certificate" (its ledger row) is written at the next snapshot — after the verdict is already made.
• Two-speed analogy from body-schema research. Tool incorporation runs as a fast immediate estimate plus a slow associative process; the ledger captures only the slow one and discards the fast (git) one.

Concepts