Drift & Reconciliation

Drift occurs when account state diverges across stores: dunning says delinquent, subscription says paid, Stripe says incomplete. Single source of truth plus drift detection mechanisms eliminate disagreement.

Account state is scattered across six stores: subs_dunning, cf_prod, billing_prod, subs_account, subs_customer, and Stripe. Multiple components mutate overlapping subsets with no unified view.

No component reads all six stores. Drift accumulates silently until a customer reports a problem or an audit catches it. The dunning brain is the first component to attempt a unified view.

Accounts stuck in bad-debt drift. Current: 906. Target: 0. Engineering metric — verify if tracked as KR on PM side.

Accounts with inconsistent debt flags. Current: 625. Target: 0. Engineering metric — verify if tracked as KR on PM side.

Accounts with has_no_successful_payment flag. Current: 633. Target: 0. Aligned between PM one-pager and engineering site.

The recompute engine replaces per-event blind handlers with a single component that reads all account state, computes what dunning status should be, and applies the minimal diff. Every event triggers a full re-evaluation. Eliminates drift by design — idempotent, tolerates late webhooks, out-of-order events, and retries.

The target architecture centralizes state resolution. One component gathers all signals, computes what the account state should be, applies the minimal diff, and emits domain events. The dunning brain is the first implementation of this pattern.

Q3 answered: can we read all six stores and produce a coherent view? Yes — drift started dropping immediately. Everything since Q3 extends these two proofs.

No longer advisory — the engine's output now drives real entitlement decisions. The kernel of Customer State is in production.