Can event calculus support planning?

Yes. With a suitable formulation and reasoning method, it can search for event or action occurrences that establish desired conditions.

Must time be represented as integers?

No. Variants support different temporal domains; the chosen representation affects the rules and implementation.

Does a fluent always describe a true-or-false property?

Propositional fluents do, but broader formulations can represent quantities and continuous change with additional machinery.

AI Glossary / Mathematics and optimization / Advanced

Event calculus

Definition

The event calculus is a family of logic-based formalisms for representing events, their effects and what holds at different times. It describes how properties begin, cease or persist as events occur. In AI, it supports reasoning about action and change, such as inferring a system's state from an event history or investigating which actions could produce a desired state.

What it means

Its central distinction is between an occurrence and a property that can remain true over time. An event might be 'switch on', while a fluent might be 'lamp is on'. A fluent is a time-varying property, not necessarily a spoken language or a numerical derivative. Event-calculus rules describe which events initiate or terminate fluents and how unaffected fluents persist. This addresses the frame problem: representing what stays unchanged without writing a separate non-change rule for every unrelated action.

How it works

A simple vocabulary includes Happens(event, time), Initiates(event, fluent, time), Terminates(event, fluent, time) and HoldsAt(fluent, time). A persistence rule says that a fluent initiated earlier holds later if no relevant terminating event occurs in between. Initial-state facts provide another starting point. That reasoning requires explicit assumptions about event occurrences and effects; ordinary first-order implications alone do not justify treating every unmentioned event as absent. Different event-calculus variants use devices such as circumscription or logic-programming semantics and differ in their treatment of time, concurrency and uncertainty.

Three practical examples

A workflow model can infer whether a task remains open after creation, reassignment and closure events.
A robot-planning study can reason about actions that change location or object possession while retaining unrelated state properties.
A system-requirements analysis can check whether an event history is consistent with rules about activation, suspension and restoration of a service state.

Think of it this way

Think of a ledger that records changes to a status instead of rewriting the full status after every moment. A start entry establishes a condition, and a later stop entry ends it. The analogy captures persistence, but event calculus adds formal rules, logical assumptions and potentially richer temporal behavior. An ordinary log file does not become an event-calculus reasoner merely because it contains timestamps.

Worked example

Construct a simple model with the fluent Active(job1). A Start event initiates it, and a Finish event terminates it. A Note event has no effect on it. The initial state is explicitly inactive. The complete event history contains Start at time 2, Note at time 4 and Finish at time 7, with no other initiating or terminating events. Under the simple continuous-time convention described by Shanahan, an initiating event takes effect strictly afterward, while a terminating event still leaves the fluent holding at the terminating instant. Therefore Active holds at times 3, 5 and 7, but not at time 1 or time 8; its holding interval is (2, 7]. The Note at 4 does not interrupt persistence. If a second Start occurs at time 9 and nothing later terminates Active, it holds at time 10. This endpoint convention is stated deliberately: another implementation may use a discrete successor-state or different interval convention. The negative conclusions rely on the declared initial state, complete event/effect description and closure assumptions, not simply on failing to find a positive fact in an arbitrary incomplete database.

Illustrative case study

In a fictional project, Elm Workflow models when a submitted request is under review. Analysts specify initiation, completion and suspension effects and compare inferred states with hand-checked event histories. They discover that two source systems assign different meanings to the timestamp of a completion event. The team resolves that convention before using the logical results in a report. The case illustrates formalizing a process; it does not claim that the model automatically handles missing events or proves the real process complied with every rule.

Common misconceptions and mistakes

Event calculus is not a method for taking mathematical derivatives of event counts. It is also not identical to event sourcing, a software architecture for storing state changes, although the ideas can be used together. Absence of a recorded event is not automatically proof that it never happened. Simultaneous conflicting effects require a declared treatment rather than an accidental processing order. Probabilities, sensor uncertainty and continuous quantities require appropriate extensions or additional modeling; they are not supplied merely by choosing the basic vocabulary.

Business use

Begin with a small domain vocabulary and precise examples of what initiates or terminates each fluent. Define time units, interval endpoints and initial knowledge. Decide whether the event history is complete and how unknown facts should be treated. Test persistence across irrelevant events, conflicting events and gaps in the record. Choose a reasoning implementation whose semantics match the written model, and retain explanations connecting conclusions to event facts and rules. Use the formal model to clarify requirements, while separately validating whether real observations and event timestamps support its assumptions.

Check your understanding

Why does the Note event at time 4 not make Active false in the worked model?

Answer: The event is explicitly assigned no terminating effect on Active, so the fluent persists from its initiation until the modeled termination. Persistence depends on the stated effect and event assumptions.

Related terms

Fluent
Frame problem
Situation calculus
Knowledge representation
temporal reasoning
automated planning

Learn next

add a Suspend event that terminates Active and a Resume event that initiates it, then write the resulting holding intervals. Introduce an unknown event at time 5 and explain which conclusions now depend on completeness assumptions. Keep endpoint conventions explicit throughout.

Sources

Sources: Murray Shanahan, The Event Calculus Explained, https://www.doc.ic.ac.uk/~mpsha/ECExplained.pdf ; Russell and Norvig, AIMA event-calculus corrected page, https://aima.eecs.berkeley.edu/errata/aima-323.pdf . The job-state timeline and fictional workflow study are original. The (2, 7] interval intentionally follows Shanahan's simple-event-calculus endpoint convention.

Previous: Event Next: Event - condition - action