Roadmap

anarchie is primarily a learning and experimentation project, so the roadmap optimises for learning something at each step and for always having a working artefact, rather than racing to feature-completeness. Each phase produces something runnable and inspectable.

The detailed roadmap - and the open and deferred work - lives in specs/roadmap.md. This page is a reader-friendly summary of what has shipped and what is planned.

Shipped

Phase 1 - The Reference Model in Rust

Native Rust types for the core Reference Model, with byte-stable canonical JSON (de)serialisation proven idempotent and diff-friendly.

• anarchie info - inspect any Composition file.
• anarchie canonicalise - re-emit canonical JSON.

Phase 2 - The file store and git

A durable, versioned, inspectable store. One git repository per EHR, the working-tree-holds-head convention, and the CONTRIBUTION-as-commit mapping.

• anarchie init - scaffold a deployment.
• anarchie ehr - create and list EHRs.
• anarchie commit - store a Composition as a contribution.
• anarchie cat - read the head or a historical version.
• anarchie log - version history.
• anarchie diff - diff two versions.

Phase 3 - Validation

Reject invalid data at the door. Reference Model invariants are checked against the typed RM tree; archetype constraints are checked against the canonical JSON guided by an Archetype Object Model tree. Validation runs on every commit, so non-conformant data never reaches the git history.

• anarchie validate - check a Composition against the RM and an optional template.
• anarchie template - register Operational Templates as the schema.
• See Validation and Templates for the walkthrough.

Phase 3.5 - Starter templates

anarchie init seeds a deployment with a curated, IPS-aligned set of bundled starter Operational Templates - the full Tier-1 International Patient Summary span (vital signs, problems, allergies, medications, laboratory results, immunisations, procedures, and an encounter note) - so a fresh CDR can store real clinical data immediately. Pass --minimal for an empty CDR.

Phase 4 - Query (AQL)

A query engine over a path-extraction index - the read model (CQRS), rebuildable from the canonical files and never authoritative.

• anarchie index - build or refresh the derived query index.
• anarchie aql - run an ad-hoc AQL query against the index.
• anarchie query - register, list, and run stored (named) AQL queries.

Phase 5 - Services

The store, exposed over the wire.

• anarchie serve - the openEHR REST API over HTTP (binds to localhost).
• anarchie mcp - a stdio MCP server exposing the store to LLM agents.

Phase 6 - Integrity and packs

Store integrity checking, and sets of Operational Templates installable as a unit.

• anarchie fsck - re-validate every stored Composition against the RM (and its template), independent of the index.
• anarchie pack add - install a bundled pack (e.g. ips-core) by name or from a local directory.
• anarchie pack list - list the bundled packs available to install.
• anarchie knowledge inventory - deterministically inventory a local CKM mirror checkout, including provenance, licences, dependencies, and parse limitations.
• anarchie knowledge resolve - apply source policy and hard-dependency closure to produce deterministic knowledge.lock; explain decisions with anarchie knowledge why.
• anarchie knowledge status - report whether the deployment lock is unresolved, current, or stale against its manifest and source checkout.

Designed and planned

No item depends on a later one to be useful. Each is intended to teach something - the next big open question being how much of AQL a DuckDB-over-JSON approach can handle before a bespoke engine is unavoidable.