Runir: Representations for Generalized Planning in C++ and Python

Runir is designed to address several challenges in the integration of learning and planning based systems:

1. Dataset construction from planning tasks and classes of tasks over a common planning domain.

2. State Model Representations that expose a task's dynamics in a representation suitable for relational learning.

3. Symbolic feature languages with formal syntax, semantics, parsing, generation, and evaluation.

4. Generalized policy evaluation on planning examples with explicit access to policy failures and counterexamples.

5. Equivalence abstractions for comparing states and tasks through graph, object-graph, and equivalence-graph representations.

Runir is the learning and representation layer for the planning-and-learning ecosystem. Tyr provides the planning backend: PDDL/formalism objects, task repositories, state repositories, successor generation, search algorithms, and Python bindings. Runir builds on top of that backend to make planning tasks inspectable and learnable, not only solvable.

Components

• runir::graphs: typed graph data structures, static/dynamic graphs, BGL adapters, shortest paths, strongly connected components, topological sort, color refinement, Weisfeiler-Lehman certificates, and nauty-backed graph isomorphism certificates.
• runir::datasets: task classes, per-task search contexts, state graphs, annotated state graphs, object graphs, and equivalence graphs built from policies such as identity or graph-isomorphism reduction.
• runir::kr::dl: description-logic constructors, grammars, CNF grammars, denotations, evaluation, parsing, formatting, and grammar factories.
• runir::kr::ps: rule-based generalized policies over typed features, conditions, effects, policy parsing, policy factories, and policy execution on annotated state graphs.
• pyrunir: Python bindings for the same components with stubs.

The native CMake package exports runir::core as the aggregate target and component targets such as runir::graphs, runir::datasets, and runir::kr. The Python package is pyrunir.

Dependencies

• Python 3.11 or newer.
• pyyggdrasil >= 0.6.1, < 0.7 for shared third-party native dependencies.
• pytyr >= 0.7.4, < 0.8 for Tyr planning, formalism, search, and C++ headers/libraries.
• pypddl >= 1.7.1, < 1.8 through Tyr/PDDL parsing infrastructure.
• pypddl-datasets >= 0.0.17, < 0.1 for the PDDL benchmark data used by the C++ test and profiling fixtures (resolved from its cache at CMake configure time).
• scikit-build-core for Python wheel builds.

The shared workspace layout, layered install order, and the common build-from-source and CMake-integration patterns are documented in the Planning and Learning build instructions; the sections below cover runir/pyrunir-specific details.

Build C++

Install Runir's native dependency providers into the active Python environment, then configure CMake with their native prefixes:

python -m pip install 'pyyggdrasil>=0.6.1,<0.7' 'pypddl>=1.7.1,<1.8' 'pytyr>=0.7.4,<0.8' 'pypddl-datasets>=0.0.17,<0.1'

cmake -S . -B build

cmake --build build -j4

CMake discovers the installed provider packages automatically through cmake/bootstrap_pyyggdrasil.cmake (which locates pyyggdrasil and adds its native prefix to CMAKE_PREFIX_PATH; find_package(yggdrasil) then resolves the rest of the chain) and links against the yggdrasil::yggdrasil and tyr::core targets. To point at different prefixes explicitly:

cmake -S . -B build \
  -DCMAKE_PREFIX_PATH="$(python -m pyyggdrasil --prefix);$(python -m pypddl --prefix);$(python -m pytyr --prefix)"

CMake options:

Single-config CMake builds default to Release. On GCC and Clang, Debug builds use -Og with debug symbols, RelWithDebInfo keeps frame pointers and disables LTO, and Release LTO uses GCC LTO or Clang ThinLTO. Editable installs and wheels disable RUNIR_USE_LLD and RUNIR_ENABLE_LTO by default for build reliability.

Run tests from a build configured with -DRUNIR_BUILD_TESTS=ON:

ctest --test-dir build --output-on-failure

Install Runir from a configured build directory with:

cmake --install build --prefix=<path/to/installation-directory>

Build Python

python -m pip install .[test]
pytest python/tests

Python Serialization

pyrunir.serialization exposes the native serializers with caller-selected dictionary tables shared with Tyr. See the serialization output reference.

Template and include rules

Headers and templates follow the template and include rules maintained in yggdrasil.

CMake Integration

This section covers pyrunir-specific paths and targets; the general pattern for consuming the native prefixes from CMake is in the common CMake integration instructions.

The Python package pyrunir installs Runir's native headers, shared libraries, and CMake package config under pyrunir.native_prefix(). Use pyrunir.cmake_prefix() and pyrunir.cmake_dir() (or python -m pyrunir --prefix / --cmake-dir from the shell) to locate them. Downstream CMake projects should include the native prefixes of pyrunir and its native package dependencies in CMAKE_PREFIX_PATH:

cmake -S . -B build \
  -DCMAKE_PREFIX_PATH="$(python -m pyyggdrasil --prefix);$(python -m pypddl --prefix);$(python -m pytyr --prefix);$(python -m pyrunir --prefix)"

Runir exports the runir::core aggregate target and component targets such as runir::graphs, runir::datasets, and runir::kr.

Intended Workflow

Runir is designed for experiments where a learning system needs structured access to planning behavior:

1. Parse and instantiate tasks with Tyr.
2. Build state graphs or equivalence graphs with Runir datasets.
3. Define symbolic features in a KR language such as description logics.
4. Build or parse a generalized policy over those features.
5. Execute the policy on examples and inspect failures or counterexamples.

Extended policies support query features and Action rules for selecting complete action tuples and checking declared effect contracts. Their proof search combines lazy Choose exploration with incremental AND/OR success propagation. See KR evaluation storage for result bindings, view lifetimes, and internal rule evaluators.

Indexical concept policies are available as the separate icp family, with Ext features, Load and Crule effects, concept histories, and greedy or universal execution.

This keeps low-level planning mechanics in Tyr while giving learning code a high-level, typed interface for representations, abstractions, and policy evaluation.