A transition can be legal in principle and wrong in the present moment.
A train is allowed to depart a station, but not while a door is open. A payment can be made, but not before required checks succeed. A learner can move to harder work, but not simply because the lesson plan says the class has reached Chapter 5.
The mechanism that asks “is this transition permitted now?” is a guard condition.
Guard conditions are part of the transition logic introduced in How State Machines Work. They convert general permission into current permission.
The Difference Between Rule and Readiness
A rule may say a transition is valid. Readiness says the present state satisfies the conditions needed to use that rule.
For example, a warehouse process may permit a trailer to depart after loading. But the departure transition may be guarded by conditions such as doors secured, manifest complete, weight within limit, driver released and destination documentation available.
“Departure is part of the process” is not enough. The guard decides whether departure is safe and valid this time.
A Guard Is Evaluated at the Edge
Preconditions describe what needs to be true before an action. Guard conditions are the decision logic placed at a particular transition.
The two concepts overlap, but the location matters. The guard sits on the edge between states and asks whether the system may cross.
This makes guards especially useful in systems where the same event can lead to different outcomes depending on current state.
One Event, Different Result
Imagine pressing an elevator button.
- If the lift is idle and healthy, the request may trigger movement.
- If it is already moving, the request may be queued.
- If it is in a fault state, the request may be rejected.
- If emergency mode is active, the normal request may be ignored entirely.
The event is the same. The guards interpret it differently because the current state is different.
Guards Protect Invariants
An invariant is something the system tries to keep true across many transitions.
- A lift car should not move with an unsafe door condition.
- A financial ledger should not violate required accounting relationships.
- A controlled workflow should not bypass required approval.
- A railway should preserve safe separation.
Guards are one way to defend these invariants. Before a transition can threaten the protected condition, the system checks whether the relevant facts still support it.
Good Guards Are Specific
“Proceed if safe” is not a useful guard until “safe” is translated into observable conditions.
A strong guard names what can be checked: pressure within range, authority token valid, destination path clear, required evidence present, prerequisite skill demonstrated.
Specificity matters because vague guards push judgement downstream to whoever happens to be present at the moment of transition.
Guards Can Depend on Several Conditions
Real transition logic is often conjunctive: A and B and C must all be true.
Sometimes it is alternative: A or B may be sufficient. Sometimes it contains exceptions: A is required unless emergency authority C is active.
The more complex the guard, the more important it becomes to make its logic inspectable. Hidden transition rules create inconsistent decisions and difficult failures.
The Override Problem
Some systems permit guards to be overridden.
This may be necessary. Emergency services, maintenance operations and unusual institutional cases sometimes require exceptional authority.
But an override should itself have guard conditions:
- Who has authority?
- What circumstances justify it?
- What additional risk is created?
- What must be recorded?
- How does the system return to normal control?
An unguarded override is not flexibility. It is a hole in the control structure.
Guards Can Fail Open or Fail Closed
What should happen if the guard itself cannot determine the truth?
A system can fail closed: block the transition when assurance is missing. Or it can fail open: allow the transition unless a definite prohibition is known.
The correct choice depends on consequences. Security and safety functions often prefer failing closed. Availability-sensitive systems sometimes need carefully designed degraded modes rather than total refusal.
This is a trade-off between continuity and protection, not a universal rule.
Worked Example: Railway Departure
A simplified departure transition may require:
- train at valid stopping point;
- passenger exchange complete;
- doors closed and proved;
- movement authority available;
- no active fault that prohibits departure.
The event “departure command” is not enough. The transition occurs only when the guard evaluates true.
This is why a railway can be delayed even when the train, driver and timetable all “want” to move. The system protects a more important invariant than punctuality.
Worked Example: Learning Progression
Education often uses calendar progression: the class moves on because time moved on.
A capability-based guard asks a different question: is the learner ready for the next state?
The guard may include correct independent performance, retrieval after delay and successful use under slightly changed conditions. This does not mean students must be perfect before moving forward. It means the transition should be informed by evidence rather than chronology alone.
Worked Example: Institutional Approval
An application may be legally eligible for approval, but the current file may still lack required documents, verification or decision authority.
The guard separates eligible in principle from approvable now.
This distinction is central to public administration, finance, medicine and any system where decisions carry downstream consequences that are difficult to reverse.
Guard Conditions Can Create Queues
When a guard blocks a transition, the item often waits.
Orders wait for inventory. Cases wait for approval. trains wait for authority. Students wait for remediation. Software jobs wait for resources.
A well-designed system therefore does not merely say “blocked.” It records why, identifies what condition must change and routes the item toward resolution.
This connects guard logic to repair routing. Refusal is useful when it tells the system how to become admissible again.
Guards Need Fresh State
A guard is only as good as the information it evaluates.
If the system thinks a door is closed when it is not, the logical rule may be correct while the physical outcome is unsafe. If an approval record is stale, a valid guard can produce an invalid decision.
This is where synchronisation enters. Distributed parts must agree closely enough about current state for guards to make reliable decisions.
Test a Guard Backwards
- Choose a transition that must never happen unsafely.
- Define the invariant it protects.
- List the facts that must be true before crossing.
- Identify how each fact is sensed or proven.
- Ask what happens if the evidence is missing, stale or contradictory.
- Define whether any override exists and how it is controlled.
This turns “the system should know better” into explicit control logic.
A guard condition is the intelligence at the doorway between states: not “can this ever happen?” but “are we justified in letting it happen now?”
Return to How Preconditions Work, How State Machines Work and the master How X Works hub. The next question is harder: what happens when several parts of the same system hold different versions of the current state?