I𝓔 PC

International 𝓔pistemic Planning Competition

Located @ICAPS 2026 - Dublin, Ireland

June 26 - July 2

Important Dates

Event/Deadline | Date (AoE)

Demo problems provided (smoke tests) | February, 2026

Team registration | March 12, 2026

Domains submission | March 19, 2026

Domain submission deadline | April 23, 2026

Feature stop (final submission) | April 30, 2026

Planner abstract submission | May 21, 2026

Contest run | May - June, 2026

Results announced | During ICAPS (TBD)

General Information

We are delighted to announce the first Epistemic Planning track of the next International Planning Competition (IPC-26), hosted at the ICAPS 2026 conference in Dublin. We invite researchers and practitioners in automated planning, epistemic reasoning, and multi-agent systems to participate and to share this call to all interested parties. The goals of the track are to promote epistemic planning research, highlight challenges in the epistemic planning community, and provide new and interesting problems as benchmarks for future research.

We welcome all interested researchers, students, developers, and practitioners from any research area connected to epistemic planning. Relevant research fields include, but are not limited to:

Automated Planning;
(Dynamic) Epistemic Logic;
Knowledge Representation and Reasoning;
Neuro-symbolic Reasoning; and
Multi-Agent Systems.

A periodic organization of international planning competitions is a well-established practice among major areas of automated planning, such as classical planning, temporal planning, and numeric planning, with the first competition held in 1998. This track aims at narrowing the gap between epistemic planning and the more popular automated planning subfields. We hope this will become a habitual practice in epistemic planning, and that it will help foster collaborations between the epistemic planning and mainstream automated planning communities.

We developed a novel language called the Epistemic Planning Domain Definition Language, or EPDDL (see "The Language EPDDL"), to represent epistemic planning benchmarks. To facilitate the participation to a greater number of people, we also developed a full-fledged parser for EPDDL, which additionally implements type-checking and grounding features. The parser was implemented in the plank toolkit for DEL-based epistemic planning (entirely written in C++17), and it is available at the following GitHub repository.

The plank tool can be used to parse an EPDDL specification and print a ground epistemic planning task in a JSON file (see "Input and Output Format Policy" for all the details).

Moreover, plank implements a validator, which will be used to test the correctness of the solutions returned by competing planners, and can be a useful tool to aid the debug of solvers. To further help the development of planners, we implemented in plank a basic epistemic planner with a simple BFS.

Participants are encouraged to build their implementations on these resources (the plank parser, validator, and baseline planner) to accelerate development and ensure compatibility. Standalone implementations not based on plank are also welcome, provided that they satisfy the input/output format policies.

Calls

Please forward the following calls to all interested parties.

Call for epistemic planning domains.

The Language EPDDL

One of the most well-known frameworks for epistemic planning is Dynamic Epistemic Logic (DEL), which offers a rich and natural semantics for modelling problems in this setting. The high expressive power provided by DEL make DEL-based epistemic planning a challenging problem to tackle both theoretically, and in practical implementations. As a result, existing epistemic planners often target different DEL fragments (or formalisms equivalent to those fragments), and typically rely on ad hoc languages to represent benchmarks, and sometimes no languge at all. This fragmentation hampers comparison, reuse, and systematic benchmark development. We addressed these issues by basing the semantics of the Epistemic Planning Domain Definition Language (EPDDL) on the DEL framework. In this way, we obtain a language that is able to represent a very wide range of epistemic planning benchmarks in a unique format.

Furthermore, we devised EPDDL with the goal of providing a clear way of defining fragments of DEL. In this way, instead of having different languages to represent problem based on different (less expressive) formalisms, we obtain one rich language to define many such formalisms under a unified syntax, enabling a meaningful comparison across different epistemic planners based on different formalisms.

This is achieved by adding to domain and problem a third component of an EPDDL specification called action type libraries (see Official Guideline for all details). A library defines a set of action types (e.g., public announcement, private ontic and semi-private sensing), which can be used in a domain that includes that library to define epistemic actions. The DEL fragment identified by the library is the one comprising all epistemic actions that have one of the types defined in the library (e.g., the fragment made by all public announcements, private ontic actions and semi-private sensing actions).

Separating action types from actions also allows to greatly simplify the development of EPDDL benchmarks. In fact, many benchmarks share the same action types, so once the fragment has been defined one can simply focus on writing the actions definitions in the domain.

All details about syntax and semantics of EPDDL are provided in the Official Guideline. Moreover, in the GitHub repository of plank (under the benchmarks directory) are present several examples of EPDDL specifications. For any question or doubt about the usage of EPDDL, please do not hesitate to get in touch with us. We are happy to help!

Epistemic Planners Not Based on DEL

The track also welcomes solvers that are not based on DEL or fragments thereof. Participants whose solver falls into this category may proceed by compiling an EPDDL specification (or alternatively a ground JSON representation computed with plank) to a format that is compatible with their solver's. Recall that, to test whether a plan returned by a solver is valid, participants can avail themselves of the plank validator. We remain at your complete disposal should you need assistance to ensure that your solver is compatible with EPDDL.

Levels of the Epistemic Planning Track

The epistemic planning track at IPC 2026 will host the following three levels. Submitted planners are required to handle at least the Basic level, but do not need to handle the Intermediate and Hard levels. All planners will be evaluated on instances of all handled levels. Planners being able to handle more difficult levels will score higher on the Coverage metric (see "Planners Evaluation Metrics").We refer to the Official Guideline for all details concerning each of the epistemic action types mentioned below.

Basic

Language: multi-agent epistemic logic (propositional connectives + knowledge modalities).
Epistemic states: states represent the knowledge of agents (i.e., they are S5n states).
Epistemic actions: public ontic actions, public and semi-private sensing actions, and public and semi-private announcements.

Intermediate

Language: multi-agent epistemic/doxastic logic with common knowledge/belief (propositional connectives + knowledge/belief modalities + common knowledge/belief).
Epistemic/Doxastic states: states represent either knowledge or beliefs of agents (i.e., they can be either S5n or KD45n states).
Epistemic/Doxastic actions: actions from the basic level, plus private ontic actions, private and quasi-private sensing actions, and private and quasi-private (truthful) announcements.

Hard

Language: same language as the intermediate level.
Epistemic/Doxastic states: any epistemic state of Dynamic Epistemic Logic.
Epistemic/Doxastic actions: any epistemic action of Dynamic Epistemic Logic.

This includes, but is not limited to, untruthful announcements, non-deterministic ontic actions (e.g., a coin flip), faulty sensing actions, and actions with complex observability patterns (e.g., an agent who believes she is privately opening a box, while some other agent is secretly spying on her).

Planners Evaluation Metrics

Submitted epistemic planners will be evaluated according to the following three metrics:

Correctness: solvers with a higher number of correctly solved instances will have a higher score than those with less correct solutions.
Coverage: solvers that handle a greater set of instances will have a higher score than those that handle fewer instances.
Efficiency: solvers that require fewer computational resources (time and space) to find solutions will have a higher score than those require more resources.

The most important metric is correctness, followed by coverage and finally by efficiency. That is, planners that find a higher number of correct solutions will score higher than planners with a higher coverage (or that are more efficient), but with fewer correct solutions. Similarly, planners with a higher coverage will score higher than planners that are more efficient, but can only handle a smaller set of instances.

Registration

To register a team, the participants need to send an e-mail with a subject containing "Registration" to eplanning.competition@gmail.com. The e-mail must contain:

Names of participants,
E-mail contacts,
Github usernames.

Based on that, we will create private repositories under the ipc2026-epistemic organization and add all participants as users with with write access and participants can commit to the repository as they wish until the "feature stop" deadline (April 30, 2026).

Planner Submission

As in previous editions of the IPC, the competitors must submit the source code of their planners that will be run by the organizers on the actual competition domains/problems, unknown to the competitors until this time. This way no fine-tuning of the planners will be possible.

As in the previous IPC 2023, we will use the container technology Apptainer (formerly known as Singularity) to promote reproducibility and help with compilation issues that have caused problems in the past. Following the previous IPC, we will host repositories of planners ourselves. The repositories will be hosted on Github under the ipc2026-epistemic organization, and they will be kept private until the end of the competition, when we make them public, i.e., after the competition is concluded, we plan to make all planners, domains, and all related data accessible from one place.

Participants can submit their planner to multiple levels from a single repository. In each repository, we only consider the branch ipc2026-epistemic. Feel free to use other branches for development as you wish, but we will ignore them. Any file called Apptainer.<shortname> in the root directory of this branch defines one entry. For the <shortname>, please use the name and variant of your planner as a short identifier (a single word, up to 16 characters long, starting with a letter, using only letters, digits, and underscores). A single entry can participate in multiple levels, see "Apptainer Images" for details.

Input and Output Format Policy

Planners are required to handle either an EPDDL specification, or a JSON representation of a ground epistemic planning task that can be computed using plank. A JSON representation of an epistemic planning task consists of the following data:

General information: number of atoms, agents, actions; requirements of the specification; etc.
Epistemic logic language: set of ground propositional atoms and agents.
Initial epistemic state.
Set of epistemic actions.
Goal formula.

Further details for the JSON representation are provided in the Official Guideline.

Planners are required to print a solution on an output plan file according to the following conventions:

If a plan is found, this has to be formatted as a JSON array, i.e., by a sequence of comma-separated names surrounded by square brackets such as [ act_1, act_2, ..., act_k ].
If no solution is found, the file should contain the null JSON null.

Action names must start with a letter or an underscore, and can only contain letters, digits, underscores and dashes (-).

Apptainer Images

We prepared a demo submission that showcases how to set up the repository and Apptainer scripts. Since this is the fist edition of the Epistemic Track at IPC, we remain available should you need help to set up the Apptainer image. For all questions and issues, please feel free to contact us (see "Organization" and "Contact Information" below).

Your Apptainer recipe files have to specify the following labels:

Name: name of the planner.
Description: a short description of your planner.
Authors: a list of authors, including contact email addresses (Firstname Lastname <firstname.lastname@email.example>)
License: the license under which you publish this code. It has to be permissive enough to allow us to publish the code after the competition.
Your Apptainer recipe must contain all of the following labels describing supported EPDDL features (see Official Guideline for all details on EPDDL requirements). Each label must be set to either yes or no, or if the feature is supported only partially, then set it to partially, followed by the description of what is and is not supported:

Requirement label | Description

SupportsAgentGroups | Definition of agent groups in problems

SupportsCommonKnowledge | ([C. Group] ...) and (<C. Group> ...) in formulas

SupportsConditionalEffects | (when ...) and (iff ...) in actions' effects

SupportsDisjunctiveGoals | (or ...) in goals

SupportsDisjunctiveListFormulas | (or ...) in conditions of list comprehensions

SupportsDisjunctiveObsConditions | (or ...) in actions' observability conditions

SupportsDisjunctivePostconditions | (or ...) in actions' effects

SupportsDisjunctivePreconditions | (or ...) in actions' preconditions

SupportsEquality | (= ...) and (/= ...) in formulas

SupportsEventsConditions | Declaration of event conditions in action types

SupportsExistentialGoals | (exists ...) in goals

SupportsExistentialListFormulas | (exists ...) in conditions of list comprehensions

SupportsExistentialObsConditions | (exists ...) in actions' observability conditions

SupportsExistentialPostconditions | (exists ...) in actions' effects

SupportsExistentialPreconditions | (exists ...) in actions' preconditions

SupportsFinitaryS5Theories | Declaration of initial epistemic states via finitary S5 theory

SupportsFacts | Declaration of facts predicates in domains

SupportsGeneralFrames | General frames for initial states and action types

SupportsGroupModalities | ([Group] ...), (<Group> ...), ([Kw. Group] ...) and (<Kw. Group> ...) in formulas

SupportsKD45Frames | KD45n frames for initial states and action types

SupportsKnowingWhether | ([Kw. ag] ...) and (<Kw. ag> ...) in formulas

SupportsLists | List concatenation and quantification

SupportsListComprehensions | List comprehensions

SupportsModalGoals | ([ag] ...) and (<ag> ...) in goals

SupportsModalObsConditions | ([ag] ...) and (<ag> ...) in actions' observability conditions

SupportsModalPostconditions | ([ag] ...) and (<ag> ...) in actions' effects

SupportsModalPreconditions | ([ag] ...) and (<ag> ...) in actions' preconditions

SupportsMultiPointedModels | Multiple designated worlds and events

SupportsNegativeGoals | (not ...) and (imply ...) in goals

SupportsNegativeListFormulas | (not ...) and (imply ...) in conditions of list comprehensions

SupportsNegativeObsConditions | (not ...) and (imply ...) in actions' observability conditions

SupportsNegativePostconditions | (not ...) and (imply ...) in actions' effects

SupportsNegativePreconditions | (not ...) and (imply ...) in actions' preconditions

SupportsOnticActions | Non-trivial effects in events' postconditions

SupportsPartialObservability | Non-public action types

SupportsStaticCommonKnowledge | ([C. Group] ...) and (<C. Group> ...) in formulas containing only static predicates

SupportsTyping | User defined primitive types and composite types

SupportsUniversalGoals | (forall ...) in goals

SupportsUniversalListFormulas | (forall ...) in conditions of list comprehensions

SupportsUniversalObsConditions | (forall ...) in actions' observability conditions

SupportsUniversalPostconditions | (forall ...) in actions' effects

SupportsUniversalPreconditions | (forall ...) in actions' preconditions

To improve reproducibility, we require Apptainer images to be self-contained and licensed appropriately.

The recipe should copy the content of the repository into the container at the start of the build. In particular, do not clone repositories in the recipe.
If you use third-party libraries, either install them through standard package managers (apt, yum, pip), or copy them into the repository. Please do not use git submodules to include dependencies.
If possible, use explicit versions. For example, do not use ubuntu:latest as your base image but pick a specific version. If you install packages through pip, pick specific versions of those packages.
If your build depends on closed-source libraries that require a license, please contact us.
If you use a portfolio of existing planners, it is up to you to get permission from the authors of the portfolio components and give appropriate credit and licensing. We recommend contacting the planner authors.

In addition to reproducibility and licensing issues, we ask that you make your image as small as possible using the following tricks:

Use a multi-stage build where one stage is used for compiling the planner and one for running the planner. Copy the compiled planner from the first stage to the second, and only copy/install the files that are required at runtime. The size of the compilation stage then does not matter, and the second stage can be limited to contain only essential files.
Strip binaries after compilation.
Use small packages. For example, use python-minimal instead of python if possible.

Bug Fixing Policy

When a competition team registers (see above), we create a private repository and add competitors as users with write access. We will provide a set of baseline benchmarks that teams can use to conduct preliminary smoke tests before the "feature stop" deadline (April 30, 2026). After the "feature stop" deadline, we allow competitors to send only a pull request with bug fixes. We will review every pull request with its accompanying description of the bug fix to make sure that no big changes or parameter tuning is committed to the repository.

To help us with the debugging process, in contrast to previous years, planner authors will be responsible for detecting if the run of their planner and our analysis of the results was successful. After the feature stop deadline, we will run all planners on all tasks and give the participants access to the results of their planners. For each run, the data will contain the log files of the planner, measured time and memory consumption, exit code, and our conclusion about what this means in terms of solving the instance. We ask participants to check their results for any errors. If an error was caused by a bug in the planner, please send a pull request on GitHub with a detailed description of the bug and the fix. If the error was on our side (e.g., malformed EPDDL), let us know as soon as possible. We will do at least two rounds of preliminary tests starting after the "feature stop" deadline (exact timeline of tests TBD).

Planner Abstract Submission

All competitors must submit an abstract (max. 300 words) and an up to 8-page paper describing their planners. After the competition we ask the participants to analyze the results of their planner and submit an extended version of their paper. An important requirement for IPC 2026 competitors is to give the organizers the right to post their paper and the source code of their planners on the official IPC 2026 web site, and the source code of submitted planners must be released under a license allowing free non-commercial use.

Organization

Competition Organizers:

Alessandro Burigana, Free University of Bozen-Bolzano, alessandro.burigana@unibz.it
Francesco Fabiano, University of Oxford, francesco.fabiano@cs.ox.ac.uk

Contact Information

Please direct any inquiries and questions to I𝓔PC's mail: eplanning.competition@gmail.com

Page updated

Google Sites

Report abuse