FSM on steroids: how we tamed 16+ room statuses
In PDP, we built a finite-state machine for a room’s lifecycle: 16+ states, non-linear transitions, and even backward moves. The rules depend on context — the type of inspection, defect severity, and whether there are any active remarks.
In PDP, we built a finite-state machine for a room’s lifecycle: 16+ states, non-linear transitions, and even backward moves. It sounds like a quest, but in production this is the foundation: the rules depend on context — the type of inspection, defect severity, and whether there are any active remarks.
The most important part: we identified 7 “protected” statuses that do not roll back if a remark arrives late. Otherwise, you can end up not with a bug, but with a legally risky scenario — and that is definitely not the vibe for 2026.
Under the hood, it’s event-driven coordination across 4+ subsystems. Plus protection against race conditions, so statuses don’t “flicker” like a dashboard on release day.
In short, we built an FSM that can handle reality instead of breaking on it.