Many failures begin with an action that was technically possible but not yet safe to perform.
A train can move before every door is confirmed closed. A payment instruction can be sent before an account is sufficiently funded. A student can begin algebra before basic number operations are stable. A building project can start before design interfaces are resolved.
The mechanism that separates “possible” from “ready” is the precondition.
A precondition is something that must already be true before a particular transition, decision or operation is allowed to proceed. In the How X Works library, preconditions matter because systems do not change state safely by sequence alone. They change safely when each step begins from a valid starting state.
A Precondition Is a Claim About the Present
Every action assumes something about the world before it acts.
“Open the valve” assumes the downstream path can receive flow. “Approve the loan” assumes identity, affordability and policy conditions have been satisfied. “Submit the exam answer” assumes the work is complete enough to represent the student’s intended solution.
Preconditions make those assumptions explicit.
- State precondition: the system must already be in a particular state.
- Resource precondition: required capacity, energy, money, data or material must be available.
- Authority precondition: the actor must have permission or legal power.
- Safety precondition: protective conditions must be satisfied before movement or release.
- Knowledge precondition: necessary information or prerequisite capability must already exist.
Preconditions Prevent Invalid Transitions
A system can often be described as a set of states connected by possible transitions.
The important word is possible. Not every transition should be legal from every state.
You should not be able to “complete delivery” before dispatch. A lift should not open its doors between floors. A student should not be moved into independent practice if the teacher has no evidence that the method was understood. A legal decision should not be treated as final before the required process has occurred.
Preconditions protect the logic of the sequence.
Necessary Does Not Mean Sufficient
A common mistake is to treat one satisfied precondition as proof that the next action should occur.
Having enough money may be necessary for a purchase, but not sufficient if identity verification has failed. A train being at the platform may be necessary for boarding, but not sufficient if the platform screen doors are not aligned. A learner knowing multiplication tables may be necessary for some fraction work, but not sufficient for understanding ratio.
Systems often require a set of preconditions to be true simultaneously.
Preconditions Can Be Hard or Soft
Some preconditions are hard gates. If they are not satisfied, the operation must not proceed.
Others are soft conditions that alter risk rather than create an absolute prohibition.
- Hard: safety interlock engaged; identity verified; required approval obtained.
- Soft: recommended staffing level met; confidence above a threshold; preferred stock buffer available.
The distinction matters because overusing hard gates can make a system brittle, while treating every condition as soft can make it reckless.
Readiness Is a Bundle, Not a Mood
People often describe systems as “ready” without saying what readiness means.
A better approach decomposes readiness into checkable preconditions.
For a warehouse shipment, readiness may include item picked, quantity verified, packaging complete, shipping label valid, carrier capacity allocated and dispatch window open.
For a learner, readiness for a harder topic may include prerequisite concepts, fluent basic operations, relevant vocabulary and the ability to execute the previous method without heavy prompting.
Readiness becomes useful when it can be observed.
Preconditions Can Become Stale
A condition verified earlier may no longer be true when the action occurs.
Inventory was available at 9:00 but allocated elsewhere at 9:05. A route was clear when planned but blocked before departure. A student could solve a method yesterday but cannot retrieve it today. A security credential was valid before permissions changed.
This creates a freshness problem: how close to the transition must the precondition be checked?
Fast-changing states require recent verification. Slow-changing states can often be cached longer.
The Cost of Checking Matters Too
Verifying every possible precondition continuously would be expensive.
Systems therefore choose what to check, when to check it and how strongly to trust prior evidence.
This is a design trade-off between assurance and friction. Too little checking permits invalid transitions. Too much checking slows normal operation and can create queues of its own.
The correct verification budget depends on consequence. A spelling suggestion can tolerate more uncertainty than an aircraft safety interlock.
Worked Example: A Payment
Before a payment can safely move, several conditions may have to hold:
- the account exists;
- the payer is authenticated;
- the instruction is valid;
- the amount is available or authorised;
- the recipient details are acceptable;
- the transaction does not violate relevant controls;
- the payment rail is available.
Notice that the mechanism is not “press button → money moves.” The button initiates a request to test a set of preconditions before the state can change from proposed payment to accepted payment.
Worked Example: Learning Algebra
Before a student can use algebra independently, several preconditions often matter: comfort with number operations, understanding of equality, reading symbols, following multi-step transformations and recognising what remains invariant when an equation is manipulated.
If one of these is unstable, the learner may appear to be “bad at algebra” when the true problem is that the transition into algebra was attempted from an invalid starting state.
That is a diagnostic advantage of precondition thinking. It asks not only “What went wrong?” but “What had to be true before this step could work?”
Preconditions and Thresholds Are Related but Different
A threshold is a cut-off at which a value changes category or triggers action. A precondition is a requirement that must be satisfied before a transition is permitted.
The two often meet. A precondition might be “temperature below 80°C,” where 80°C is the threshold. But the concept of precondition is broader because it can include categorical facts such as “approval granted” or “door closed.”
See How Thresholds Work for the deeper logic of cut-offs, state transitions and hysteresis.
Preconditions and Algorithms
Algorithms frequently depend on preconditions even when the user never sees them.
An algorithm may assume the input is sorted, the data type is valid, the graph is connected, the denominator is non-zero or a resource exists. If the precondition is violated, the algorithm may return nonsense, fail or behave unpredictably.
This is why How Algorithms Work includes correctness and edge cases. Correctness is always conditional on the assumptions under which the algorithm was designed.
Civilisation Is Full of Preconditions
Complex societies are built from permissioned transitions.
A building becomes occupiable only after required conditions are met. A law becomes operative through defined constitutional and administrative steps. A medicine moves from research into use through evidence and regulatory gates. A traveller crosses a border when identity and entry conditions are satisfied.
These gates can feel bureaucratic when everything is normal. Their purpose becomes clearer when we ask what unsafe state they are preventing.
The Reverse Test
To discover missing preconditions, start from the desired state and work backwards.
- Define the next valid state.
- Ask what must already be true for that state to be entered safely.
- Ask which of those conditions can change quickly.
- Identify how each condition is verified.
- Define what happens when one is false.
- Define who can override the gate, if anyone.
This backward pass often exposes hidden dependencies that a forward process diagram skips.
A Good Gate Explains Its Refusal
When a precondition fails, the system should ideally say which one.
“Cannot proceed” is less useful than “identity not verified,” “capacity unavailable,” “prerequisite not demonstrated” or “approval expired.”
Explainable refusal reduces repair time. The user knows which state must change before trying again.
A precondition is civilisation saying: before we change the world, prove that the starting state can safely support the change.
Continue through How Mechanism Mapping Works and the master How X Works hub. The next layer is state machines: how valid states, events and guarded transitions become a working control structure.