Documentation

The Episodic documentation set, sorted by what it is for

Seventy-five documents, categorised by type and audience so a reader can find the right one without knowing the repository layout.

Start here

Four documents cover most first questions.

Documentation lives in the Episodic repository and is linked rather than copied, so nothing here can fall behind the source. Where a document is itself a plan or a decision record, the category says so - a design that was accepted is not a description of running code.

If you want the supported user-facing path first, start with the users' guide and then branch out to the task-specific pages.

For this published companion's route map, read the df12 site users' guide.

By category

75 documents across 6 categories.

Orientation

Guide For: Everyone 5 documents

Start here. What the project is, how it is laid out, and where delivery stands.

  • Repository layout explains the repository tree, ownership boundaries, and path conventions.
  • Documentation style guide defines the writing, formatting, and document-type conventions for project documentation.
  • Users' guide describes supported user-facing behaviour and externally visible workflows.
  • Developers' guide gives maintainer-facing build, test, lint, extension, and contribution guidance.
  • Roadmap tracks phased delivery work, dependencies, and acceptance criteria.

Product and system design

Design For: Technical evaluator 5 documents

The platform model, its interface contracts, and its operational shape.

User and integration guides

Guide For: Developer 7 documents

Working guidance for the dependencies and testing surfaces the platform integrates.

Architecture and engineering references

Reference For: Maintainer 6 documents

Background material behind recurring engineering decisions.

Decision records

Decision record For: Maintainer 16 documents

Accepted decisions, each with the context that forced it.

All 16 documents

Execution plans

Execution plan For: Maintainer 36 documents

Implementation plans for individual roadmap tasks. Historical once the task lands.

All 36 documents

How to read the set

Three distinctions that decide whether a document describes reality.

  • Guides describe supported behaviour. The users' guide is the closest thing to a statement of what works. It is explicit about being under construction.
  • Designs describe intent. The system design is thorough and largely unimplemented. Read it for the model, not the feature list.
  • Decision records and execution plans are historical. An accepted ADR records what was decided and why. An execution plan describes how one roadmap task was approached and stops being current the moment it lands.

Run the code · Read the API reference · Check delivery state