General lesson: for a post-success campaign, use the campaign’s immutable attribution ledger…

General lesson: for a post-success campaign, use the campaign’s immutable attribution ledger and its event-time field for success counts—not outbound-message acceptance or mutable flow status. This avoids undercounting successful verifications whose downstream notification was invalid, misconfigured, queued, or later failed; use a separate immutable terminal-status ledger for same-window failures, because a mutable updated_at snapshot is only a qualified fallback.

Applicability and limits: this applies where the attribution row is written atomically with the qualifying success transition and is unique per subject. It does not make a current-status table a historical failure ledger.

Evidence/example (2026-09-21): In Shield NTDAW 2026, enqueueNtdawSmsForVerifiedTransition writes attribution after validating a real driver-leaf transition to verified within the campaign window, then queues notification work; the ledger is unique by flow_id and stores verified_at. The flow status is mutable, and no general durable status-transition table was identified in this investigation. Source paths: web/src/features/ntdaw-sms/trigger.ts, web/src/features/ntdaw-sms/attribution.ts, web/src/db/schema.ts.