Does adding a precondition solve every failure?

No. The system must still establish that condition or choose another action, and failures may have other causes.

Can a precondition already exist as a state variable but still be missing?

Yes. It may be represented in the state vocabulary but omitted from a particular action's requirements.

Not when the required condition remains false and the model keeps ignoring it. A justified preparation or plan change is needed.

AI Glossary / Graphs and symbolic AI / Intermediate

Missing precondition

Definition

A missing precondition is a necessary condition for an action that has been left out of the action's model. The planner may therefore treat the action as available in a situation where it cannot actually succeed. Correcting the omission requires representing the requirement and checking or establishing it before execution.

What it means

An action can need more than an explicit instruction to run. A machine may require a loaded input, a service may require a valid session, or a workflow may require a prerequisite status. If the model leaves out one of those requirements, a plan can be valid according to the model but invalid in the real process.
The term concerns an omitted requirement, not merely a known requirement that is currently false. That distinction matters when diagnosing a failure. A planner that correctly reports a known precondition as unsatisfied has recognized a constraint; a planner using a missing-precondition model has not represented that constraint adequately.

How it works

A planner tests an action's listed preconditions against the current modeled state. Leaving out a genuine requirement makes that test too permissive. The planner may choose an action earlier than it should or omit a preparation step needed for success.
When execution fails, model revision may add the missing requirement. The revised plan then needs an action that establishes it, a different route to the goal, or a report that the goal is not currently achievable. Evidence is needed to identify the requirement: one failed attempt alone may also reflect a transient fault or incorrect observation.

Three practical examples

A printing model can omit the requirement that paper be loaded, producing a plan that tries to print with an empty tray.
A digital workflow can omit a required approval status before a transition is allowed.
A robot action can omit the requirement that an object be within reach before a grasp is attempted.

Think of it this way

Think of a recipe that tells you to bake a mixture but omits the requirement that the oven be heated. The written steps can be followed while the expected result fails. The analogy is limited because formal preconditions have explicit truth conditions, and not every practical preparation is equally necessary under every action definition.

Worked example

Consider an invented printer model with predicates JobQueued, PaperLoaded, PrinterReady, and Printed. All four are already part of the model's state vocabulary. Initially JobQueued and PrinterReady are true, while PaperLoaded and Printed are false.
The incomplete Print action requires JobQueued and PrinterReady and produces Printed. It does not list PaperLoaded as a precondition. According to this model, the one-action plan Print is valid: both listed requirements hold, and the modeled effect achieves the goal.
The real printer, however, needs paper. With the tray empty, the job cannot produce a printed page. The problem is not that the planner chose a false listed requirement; it is that an important requirement was absent from the list.
Suppose LoadPaper is an available action requiring PrinterReady and producing PaperLoaded. After adding PaperLoaded to Print's preconditions, the repaired plan is LoadPaper followed by Print. The first action establishes the missing condition, and the second can then achieve Printed under the remaining assumptions.
If LoadPaper is unavailable because no supply exists, adding the precondition does not magically create a solution. The planner should identify the blockage or find another modeled printing option.
The example also distinguishes a state omission from an action omission. PaperLoaded was already represented, so the repair adds a requirement to Print rather than inventing an entirely new state variable. If the model had no way to express paper availability, representation expansion would be necessary too. Any consumption of paper during printing would be a separate effect-modeling issue.

Illustrative case study

In a fictional document service, Maple Workflow models publication as requiring a completed draft but omits a required review status. The real service rejects an attempted transition. Developers initially retry the same plan without changing its assumptions.
After checking the service's process rules, the team adds the review requirement and represents the legitimate review step. This invented case illustrates that repeated execution does not repair a systematically incomplete action model. It does not suggest bypassing the service requirement or assuming that every rejection has the same cause.

Common misconceptions and mistakes

A missing precondition is not the same as an unsatisfied precondition. The former is absent from the model; the latter can be correctly represented and false in the current state. Both can prevent execution, but they call for different diagnoses.
Do not infer a universal prerequisite from one failure without checking alternative causes. Nor should a new precondition be added so broadly that it blocks actions that can legitimately succeed without it. Requirements may depend on context, making a conditional model more appropriate than one unconditional rule. The repair must match the actual action semantics.

Business use

Use the concept when reviewing automated workflows, planning agents, and action interfaces. Compare modeled applicability with real process requirements. Document which conditions are checked by the planner, which are checked by the executing system, and how rejected actions are reported.
When an omission is confirmed, revise the action definition and reconsider existing plans that relied on it. Ensure the system can observe or establish the new condition; an unobservable predicate may require a belief-state or sensing treatment. Preserve a clear difference between a model correction, a temporary state update, and an authorized preparation action.

Check your understanding

Why is Print considered applicable by the incomplete model even when PaperLoaded is false?

Answer: Applicability checks only the listed preconditions. Since PaperLoaded is omitted, its false value does not block the action in that model, although it blocks real printing.

Related terms

Precondition
Execution monitoring
Missing effect
Missing state variable
action model
applicability
planning
model revision
preparation action
replanning

Learn next

Take a short workflow and list the prerequisites for each step. Mark which prerequisites are represented, observable, and currently true. Then remove one from a test model and explain the invalid plan it permits, before restoring the requirement and finding a valid preparation sequence.

Sources

Russell and Norvig, Artificial Intelligence: A Modern Approach, indexed textbook passage on missing preconditions: https://aihouse.univ-eloued.dz/wp-content/uploads/2024/11/1-Arti-ficial-Intelligence-A-Modern-Approach.pdf Carnegie Mellon University, original classical-and-motion-planning assignment, action-model correctness context: https://www.cs.cmu.edu/~07380/assignments/planning/

Previous: Missing effect Next: Missing state variable