Do these axioms choose the next action?

No. They constrain choices made within the wider planning problem.

Can a precondition require something to be false?

Yes. An action can imply a negated state condition.

Does an unsatisfiable formula always mean the goal is impossible?

No. The selected horizon or an incorrect encoding may also cause failure.

AI Glossary / Graphs and symbolic AI / Advanced

Precondition axioms

Definition

Precondition axioms are logical statements requiring an action's preconditions to hold whenever that action occurs in a planning model. In a Boolean planning encoding, an action variable at a particular time implies the required state facts at that time. These axioms exclude assignments that schedule an action without its modeled requirements. They form one part of a complete planning encoding.

What it means

An automated planner can translate a planning problem into a logical formula and ask a solver for a satisfying assignment. Some variables describe the world; others indicate which actions occur. Without links between them, a solver could select a release action while also saying that the required approval is absent. Precondition axioms make that combination inconsistent.

How it works

Let Release_t mean that release occurs at step t, and Approved_t mean that approval holds in the state before that step. The axiom Release_t implies Approved_t allows release only when approval holds. If review is also required, write Release_t implies (Reviewed_t and Approved_t).
A satisfiability solver commonly receives this as two clauses: (not Release_t or Reviewed_t) and (not Release_t or Approved_t). For a finite planning horizon, instantiate the appropriate requirements for each action and time step.
Other constraints supply the initial state, goal, effects, persistence of unaffected facts and permitted action combinations. Preconditions constrain whether an action can occur; they do not, by themselves, describe its outcome or require the goal to be achieved.

Three practical examples

A publishing planner encodes that every scheduled release requires both review and approval in the preceding state. A release variable cannot be set to true while either requirement is false.
A robotic planning encoding links each movement action to the robot's required starting location. A proposed move from a rack cannot occur in a state that places the robot elsewhere.
A resource planner discretizes whether a machine is available at each step. Its start-job variable implies availability. Further constraints describe resource consumption and prohibit incompatible simultaneous jobs; availability requirements alone do not establish the entire resource model.

Think of it this way

Imagine reviewing a timetable with a transparent checklist placed over every scheduled activity. Each activity must line up with its required conditions at that moment. The checklist can reject an impossible booking, but it does not create the timetable, specify the activity's results or ensure that the final objective is met.

Worked example

Consider one time step with three Boolean variables: Release, Reviewed and Approved. Release requires both Reviewed and Approved. There are eight possible truth assignments to three Boolean variables.
The axiom Release implies (Reviewed and Approved) permits five assignments. When Release is false, all four combinations of Reviewed and Approved satisfy this implication. When Release is true, only Reviewed = true and Approved = true is allowed. The other three assignments with Release true are rejected.
For example, Release = true, Reviewed = true and Approved = false violates the second clause, because neither not Release nor Approved is true. Setting Approved in the next state does not fix this violation: approval was required in the state before release.
Now consider Release = false, Reviewed = true and Approved = true. This assignment is permitted. Both requirements are satisfied, but the planner need not choose release at this step. Replacing the implication with an equivalence would incorrectly force release whenever both conditions hold, unless that stronger behavior were explicitly intended.
These five assignments describe only the precondition formula, not five complete valid plans. Suppose the goal is Published in the next state. An additional effect rule can connect Release to Published, but the model must also specify the initial state and prevent unexplained changes. Merely asserting Release implies Published does not prevent Published becoming true without a release. Appropriate transition or frame constraints are needed to rule out such unsupported outcomes.

Illustrative case study

In a fictional publishing prototype, an encoding permits a document to be released before approval. Inspection shows that the approval variable exists, but no clause connects it to the release action. The solver has satisfied the formula it received; the missing connection is a modeling error.
The team adds the two precondition clauses and enumerates the eight assignments above. Exactly five remain possible. It then notices that a plan with no release can still claim the publication goal, so it separately corrects the transition constraints. Finally, it checks that an approved document can remain unreleased when publication is not selected. These checks expose different errors rather than treating one successful example as evidence that the whole encoding is sound.

Common misconceptions and mistakes

A necessary condition is not automatically a sufficient reason to execute an action. The reverse implication from satisfied preconditions to action occurrence generally adds an unintended obligation.
Another mistake is confusing time indices: a condition established after an action cannot normally satisfy that action's earlier requirement. Preconditions also do not ensure persistence, explain effects or exclude interference between concurrent actions.
Terminology varies across logical planning formalisms. A predicate meaning 'this action is possible' may be defined by an equivalence with its applicability conditions. That differs from a variable meaning 'this action actually occurs.' Identify the predicate's meaning before judging the correct logical direction.

Business use

Precondition axioms help make automated workflow decisions inspectable. A rejected action can be traced to a missing modeled requirement, while a satisfiable plan can be checked against the complete encoding. Review the translation from operational rules to formulas, particularly action names, time references and negative conditions. Test a missing requirement, satisfied-but-unused requirements and attempts to achieve goals without supporting actions. A solver's success establishes consistency with its formula, so business usefulness still depends on that formula representing the intended process.

Check your understanding

How many assignments satisfy the example's precondition formula?

Answer: Five out of eight.

Must release occur whenever review and approval hold?

Answer: No; the implication allows the action to remain unselected.

Can precondition axioms alone establish a complete plan?

Answer: No; state, transition, goal and other relevant constraints are also required.

Related terms

Precondition
Propositional logic
Implication
Conjunctive normal form
planning as satisfiability
SAT solver
effect axiom
frame axiom
planning horizon

Learn next

Add an initial unpublished state and a publication goal. Compare an encoding that merely states release's effect with one that also rules out publication without a supporting action.

Sources

LaValle, Planning as Satisfiability: https://msl.cs.uiuc.edu/planning/node68.html Poole and Mackworth, Planning as a CSP: https://artint.info/3e/html/ArtInt3e.Ch6.S4.html AIMA glossary, precondition axioms: https://github.com/aimacode/aima-glossary/blob/master/glossary.md

Previous: Precondition Next: Preconditioned stochastic gradient descent