The load-bearing detail in that ordering is where the idempotency key is born. It is generated in the insert, stored on the row, reused forever, and handed to `provider.charge` as an option [16]. Its lifetime is the payment's, not the attempt's, and that is the only reason an `unknown` row is safe to touch again. Retrying is non-destructive if and only if the provider deduplicates on a key you chose before the first call. If your provider does not honour keys on that endpoint, you get the state machine and no way to advance it, and you are back to matching on the reference you stored for reconciliation [17].
The argument for putting this in the type rather than in a team convention is the one I would use at review: the enum is what queries filter on and what dashboards group by [7]. The alternative is already in most schemas, where a `failed` row with a null `provider_ref` sometimes means no response arrived and sometimes means no call was made, and the one person who knows which is which takes that knowledge with them when they change teams [4].
Count the retrofit. The old status column carried two useful values [c1b], the new type carries six [6], so four states arrive that nothing in your reporting layer has ever seen [1]. The post concedes the correction is awkward to retrofit [5], and awkward is right, because a backfill has to decide, row by historical row, which of the old `failed` records were requests that never went out at all.
That leaves `classify(err)`, and the source text breaks off at "Note what classify is allowed to r" without giving the mapping [15]. The mapping is the safety property. A 400 with a body is `rejected`, because the provider answered. A reset connection is `unknown`, because nobody did; writing `failed` there records, in durable storage, a fact about the provider's ledger that you are not in a position to state, when the money may have moved 200 ms ago [2]. I would insist the default arm return `unknown`: an error class you have not classified yet is, by construction, one you have no information about. The three histories the post describes are indistinguishable from where you stand [10], and they only stay that way if the code declines to guess.
`expectedResolutionBy` is the small field that makes the design operable. Setting it to `addBusinessHours(now, 2)` at insert time [17] gives a sweeper a WHERE clause, so `unknown` is a queue with a deadline instead of a bucket that grows. The row exists before the side effect, which is what the post means by write-ahead logging with the business as the log [14]. The payoff is that recovery becomes a scan rather than an interview.
