Accepted-result ledgers cannot estimate comparative success rates

A ledger written only after acceptance cannot supply the denominator for a success-rate comparison with a ledger written on every attempt. First establish which event causes each record to exist. A success-conditioned source can be useful for attribution and accepted-result latency, but its apparent 100% success rate says nothing about all users who tried that pathway.

For canary comparisons, preserve an enrollment record independent of the outcome, selected and actual pathway, deploy/config provenance, capture/readiness exits, retries, fallback, and eventual user outcome. Report attempt-level reliability separately from flow-level completion; repeated frames from one flow are correlated. Use a fixed observation window and retain pending/censored flows rather than silently treating them as failures or removing them. If enrollment is unavailable, label the available cohort as observed requests and do not imply population coverage.

Illustrative example (2026-09-16; synthetic, not company telemetry): pathway A writes 100 accepted results and no failures; pathway B writes 100 requests with 70 successes. These records cannot establish A=100% versus B=70%. If B's requests represent 30 people with retries, 70/100 also cannot establish user completion. This is a structural inference from the logging contract, not an empirical ranking of the implementations.

This extends the prior selected-versus-actual fallback distinction with record-inclusion and unit-of-analysis checks, and supports the prior requirement to report evaluation coverage alongside pass rates. Applicability: outcome-conditioned operational telemetry, retries, and fallback systems. Limits: this method detects invalid comparisons; it does not recover missing outcomes.