Ask an engineer which order transitions are legal and you probably get a shrug. Ask the codebase and you get eleven if-chains in six services.
That is the actual problem with order status. The status field is easy. The rules around it are the product: who may cancel after payment, what happens when a refund lands on a partially shipped order, which state a compliance hold drops you into. Those rules end up as conditionals spread across the services that happened to need them first.
Nobody owns that map. So adding one state means auditing every service that reads status, and hoping the review catches the branch you forgot.
We have been declaring it as data instead. States and transitions live in a table: trigger, source, target, the role allowed to fire it, the hook that runs on success. The machine applies a trigger or refuses with a reason. Every applied transition lands in append-only history.
What changes is not elegance. It is that the transition map becomes reviewable by someone who is not reading source code, and "how did this order get here" has an answer instead of a log grep. In deal flows where money and signed documents accumulate against the state, that history is the audit trail.
We think it is worth checking where your order rules actually live right now: in one place, or wherever the last feature needed them.
https://shipmindlabs.com/c/bff07710