Declare allowed transitions
Name the states, events, starting state, and valid destination for each application lifecycle.
State tracking
Keep important records on valid paths.
Define the states a record can occupy and the events allowed to move it. Daptin rejects invalid transitions and records the history of accepted ones.
- States
- Events
- History
Explicit progress
Make lifecycle rules visible.
An order should not jump from draft to shipped. A request should not approve itself twice. State tracking makes those rules part of the backend instead of leaving every client to interpret a status field.
Reject impossible moves
Transition endpoints validate the record’s current state before accepting the event.
See how a record arrived here
Transition history preserves the accepted sequence for support, product logic, and review.
Pair validation with actions
Use state tracking for valid movement and named actions for the work surrounding that movement.
Lifecycles people recognize
Make impossible status changes impossible.
Orders
Move from pending to confirmed, shipped, delivered, or cancelled only through the events allowed from the current state.
Tickets
Track open, assigned, resolved, reopened, and closed paths while preserving accepted transition history.
Publishing
Keep drafts, review, scheduled publication, published content, and archival on explicit editorial paths.
Approvals
Prevent a request from skipping review or applying the same one-way decision twice.
Validation and actions
State tracking validates movement; actions perform work.
Daptin stores state-machine descriptions, creates companion state records for enabled tables, checks an event against the current source state, and records accepted transitions.
It does not automatically execute entry or exit handlers. If a transition must reserve inventory, call a provider, or send mail, put that behavior in an explicit action and coordinate the transition there.
Define and verify a lifecycle →