Are these the same as the unique-names assumption?

They are closely related, but parameterized actions also need argument-based identity conditions.

Do they prevent repeated actions?

No. The same action term can occur at different points in an execution history.

Are they effect rules?

No. They establish distinctions used when interpreting effect rules.

AI Glossary / Graphs and symbolic AI / Advanced

Unique action axioms

Definition

Unique action axioms are logical statements that distinguish action names and their arguments in an action theory. Typically, different action constructors denote different actions, and two instances of the same constructor are equal only when their corresponding arguments are equal. These identity conditions support precise reasoning about actions and their effects.

What it means

A planning language may contain Move(robot, origin, destination) and Scan(robot, parcel). The different expressions are symbols in a formal model. Ordinary first-order logic does not automatically make every differently written expression denote a different thing.
Unique action axioms supply the intended distinctions. Moving a robot should not accidentally count as scanning a parcel, and moving robot r1 should differ from moving robot r2 when those robots are distinct.
This is an identity issue. Whether two distinct actions may occur at the same time is a separate concurrency or resource constraint. Calling actions different does not, by itself, prohibit their simultaneous occurrence.

How it works

For different action constructors A and B, a typical axiom states A(x)≠B(y) for all permitted arguments. For one constructor A, an injectivity axiom states that A(x)=A(y) implies x=y. With several arguments, equality implies equality of each corresponding argument. The converse follows from ordinary equality reasoning.
A situation-calculus theory combines such identity statements with other components. Preconditions describe when actions are executable; successor-state axioms describe how properties change or persist; initial-state statements describe the starting situation. Unique action axioms help determine which action cases apply.
Suppose an effect rule refers to a=Scan(r,p), but the current action is Move(r,L,M). A cross-constructor inequality rules out that scan case. Without adequate identity information, a reasoning system might retain interpretations in which the terms coincide. Object identity assumptions also matter when comparing two parameterized instances of the same action constructor.

Three practical examples

A warehouse model distinguishes moving a robot from scanning a package. This prevents an equality-based effect rule from treating those commands as the same modeled action.
A document workflow distinguishes Approve(document) from Archive(document). Even if both can occur for one document, their names identify different action types with separately defined consequences.
A scheduling model distinguishes Assign(worker1,task) from Assign(worker2,task) when the workers are known to differ. A separate scheduling rule determines whether both assignments are allowed.

Think of it this way

Imagine a catalog in which each command is identified by its type and parameters. “Move robot 1 to bay M” and “move robot 2 to bay M” are different catalog entries. Knowing that does not tell you whether either command is currently permitted, or whether they can run together.

Worked example

Consider a fictional model with two distinct robots, r1 and r2; two distinct locations, L and M; and one parcel p. Define Move(r,origin,destination) and Scan(r,parcel). All these object domains are explicitly limited to the listed members for this counting example.
There are 2×2×2=8 Move terms and 2×1=2 Scan terms. Cross-constructor inequality and argument injectivity make all ten terms distinct. This counts action terms, not executable choices: a separate precondition might disallow moves whose origin equals their destination.
Let a=Move(r1,L,M), b=Move(r2,L,M), and c=Scan(r1,p). We obtain a≠b because r1≠r2, and a≠c because Move and Scan are different constructors. If Move(r1,L,M)=Move(r1,L,z), injectivity gives z=M.
Now introduce Occurs(action,time) solely to discuss concurrency. Occurs(a,5) and Occurs(b,5) can both be true without contradicting a≠b. If the application permits only one action at time 5, it needs an additional restriction forbidding that combination. Identity axioms alone do not provide it.
If r1 and r2 were merely two names whose distinctness was unknown, the argument-based proof of a≠b would no longer follow. The example therefore makes the object distinction explicit.

Illustrative case study

A fictional robotics team connects two command interfaces to a symbolic planner. One calls a movement action Move, while another calls the same operation Relocate. The team initially declares every action name different without first deciding whether these names are aliases.
That choice turns a naming difference into a modeled action difference. The team reviews its vocabulary and maps genuine aliases to one canonical constructor before generating identity axioms. Commands that really differ retain separate constructors and effect rules.
It then tests identity, executability, and concurrent scheduling independently. Two robots can have different movement actions while still competing for one narrow passage. The passage restriction belongs in the operational model, not in an assumption that their action names are identical. This fictional case demonstrates modeling discipline rather than a reported deployment outcome.

Common misconceptions and mistakes

Unique action axioms do not mean that only one action can happen at a time. Action-exclusion constraints must express that restriction when required.
They do not prove an action can execute, succeeds, or has a particular effect. Those claims require other parts of the theory.
Different action terms do not necessarily lead to different observable states. Two different routes may leave a robot at the same final location, even though their histories differ.
Blanket naming assumptions can mishandle aliases. Decide what each constructor denotes before declaring constructors distinct.

Business use

These axioms help make automated workflows and symbolic plans interpretable and checkable. They are useful when rules depend on exact action identity across several systems. Review command mappings, parameter identity, and aliases when integrating interfaces. Test resource conflicts separately so that a correct identity model is not mistaken for a complete operational safety or scheduling model.

Check your understanding

Why are the two robots' Move actions distinct?

Answer: Their robot arguments differ, and the constructor is injective.

Why are Move and Scan distinct?

Answer: A cross-constructor inequality states that distinction.

Can two distinct actions occur together?

Answer: Identity axioms permit that possibility; separate concurrency rules decide whether it is allowed.

Related terms

Situation calculus
Unique-names assumption
Successor-state axiom
Frame problem
action precondition
action exclusion
equality
concurrency

Learn next

Study how an action theory combines identity, preconditions, and successor-state axioms. Then compare a sequential action model with one that explicitly represents simultaneous actions and resource conflicts.

Sources

Texas Tech University Knowledge Representation Lab, Natural Actions, Concurrency, and Time in Situation Calculus, action-identity axioms: https://www.depts.ttu.edu/cs/research/documents/nacatisc.pdf Liu and Wen, On the Progression of Knowledge in the Situation Calculus, basic action theory components: https://www.ijcai.org/Proceedings/11/Papers/168.pdf AIMA glossary, supplied terminology requiring the identity/concurrency distinction: https://github.com/aimacode/aima-glossary

Previous: Union Of Events Next: Unique key