Rules

This page covers everything about taking part: who may enter, how many planners and configurations you may enter, what your planner has to produce, what happens when it produces something invalid, how submissions are made, and what may change after the Feature Stop, and how places are awarded.

What the tracks are and how configurations are scored is on the tracks page; where the problems come from is under benchmarks.

Who May Enter

Anyone except the organizers. There is no requirement to be affiliated with a university, to have published on HTN planning, or to have taken part before.

A planner must read HDDL (though we offer some conversion scripts) and produce a plan in the required output format. It does not have to be new, and it does not have to be yours alone – see Building on an Existing System below.

Planners and Configurations

Every team may enter each of its planners in each track with up to two configurations. A planner counts per track because planners may have track-specific versions, possibly built by different people.

The important question is what counts as a planner. We define it as follows:

A planner is defined by its core HTN contribution. Anything taken from the literature and plugged in – e.g., a classical heuristic, a search strategy, a SAT solver, a classical planner – is a configuration.

In the following we give a few examples based on planners from the literature. If in doubt, please contact the organizers.

Heuristic Search and Other Native Approaches

The search engine together with its HTN-specific guidance (if any) makes the planner. Everything else is configuration:

• a classical heuristic plugged into a technique such as relaxed composition – RC(FF), RC(Add), RC(LM-cut), … – are all configurations for the planner “progression + RC”;
• the search strategy – GBFS, weighted A* with any weight, or blind BFS/DFS on the same engine;
• tie-breaking and other efficiency improvements;
• variants in how the same heuristic is computed.

For example:

• Progression search with RC is one planner, e.g. with the configurations GBFS with RC(Add), and weighted A* (w = 2) with RC(FF).
• Progression search with a native HTN heuristic H is another planner, e.g. with weighted A* at w = 2 and at w = 5.

For other native approaches, such as plan-space search, the same principle applies: significant internal differences make separate planners, minor ones are configurations.

Compilation-Based Approaches

This covers every approach that translates the HTN problem into another formalism – e.g., into classical planning, SAT, BDDs, CP/CSP – and hands it to an existing solver.

• The encoding is the planner. Two encodings count as two planners if the compilation technique or the compiled problems differ significantly. Minor variants of the same encoding are configuration.
• The solver the encoding is handed to, and its settings, are configurations.

A translation to STRIPS and a translation to SAS+ are therefore two planners, each with two configurations – for example two different classical planners, or one classical planner in two settings.

Building on an Existing System

You may enter a system if you contributed to it (i.e., one cannot just compete with a system by somebody else without adding a significant scientific/algorithmic contribution). In addition, you must have the right to build on the systems you extend, e.g., under the license under which they have been published.

In case you build on the work by somebody else, we strongly encourage you to inform the authors about it; we also require credit:

• Name the original system and its authors in your abstract, and describe what you changed.
• The planner is listed as a derivative in the results.

Output Format

We have only two different output formats based on track:

• most tracks require a sequence of actions.
• the makespan track requires a partially ordered plan.

In both cases, we also require the sequence of (ground) methods used to obtain the respective plan.

The exact output format is still to be announced, but it will be a refinement of the format used in the two previous HTN IPCs, adding a bit of extra information.

Plan Validity and Disqualification

We check all produced plans and their decompositions. Disqualification in a domain means scoring zero on all instances of that domain.

• An invalid plan means disqualification in that domain, not just on that problem. An invalid plan in a second domain means disqualification from all domains of the track.
• A non-optimal plan. In the optimal tracks, a solution that is valid but not optimal counts as invalid too. Since optimality there is a requirement, entering an optimal track is a claim that every returned solution is optimal.
• Valid makespan plans. In the makespan track, shorter makespans score higher, but optimality isn’t required, so only validity is a requirement. A partially ordered plan is called valid if and only if every linearization is valid.
• A wrong unsolvable. In the unsolvability track, a single unsolvable answer to a solvable problem means disqualification from all domains of the track. There is no certificate for unsolvability, so such an answer has to be taken on trust, and its correctness matters even more than that of a plan, which can always be checked. Invalid plans in this track follow the rules above, so a planner can be disqualified in a single domain only – but only as long as all its unsolvable answers are correct.

Final Ranking

Each configuration is scored as described under how configurations are scored. Places in a track, however, go to planners, not to configurations: each planner is placed by its best configuration and takes at most one place. For example, if the configurations finish in the order P1-1, P2-1, P1-2, P3-1 (planner P1 with configuration 1, and so on), then P1 is first, P2 second and P3 third, while P1-2 takes no separate place; it’s subsumed by the first place due to its other configuration. All configurations still appear in the full results.

Resource Limits

Every planner gets the same budget per problem:

Submitting Your Planner

Submissions are containerized planners with open source code.

• Format: Apptainer. One configuration per .def file, in the repository root.
• Repositories: We will announce where and how your data will be stored. Once the competition is over, the repositories will be made public.
• Testing: your planner must build and solve the sample problems. We will test submissions against them; details of the testing pipeline will be announced.
• Log-check script: for every planner, you also submit a script that checks its output. It receives the domain, the problem, the plan (if any), the planner’s log output and our validator’s output, and reports via its exit code whether the planner behaved as expected. This matters most when no plan was found: our validator then has nothing to check, but your script can spot a crash or an endless loop in the log. You don’t see the benchmark problems until after the competition, and we can neither read thousands of logs nor know what yours should look like, so this is how such bugs get noticed. We look at every run your script flags and tell you what we can without disclosing the benchmarks. The exact interface will be published in time.

Feature Stop and Bug Fixes

Until the Feature Stop, you can change your planner in any way.

After the Feature Stop, only bug fixes are allowed. Submit each fix with a short description of the bug. We review every fix and reject changes that add features or tune parameters, so keep fixes minimal and easy to check.

If a bug shows up only during the competition run itself, we may allow a fix and run the fixed planner again. We decide this on a case-by-case basis, depending on, for example, the significance of the bug and the time left before the results are due.

Planner Abstract

For every planner, you submit one two-page abstract, covering all its configurations and tracks, that describes the system: the approach, what is new, and what it builds on. The first version will be put online after the Feature Stop. It will be replaced by an updated version that can incorporate results after the competition has concluded.

Last updated 6 October 2026.