Glossary

One word per concept, across every document and not only the skills. Where a synonym below still appears in older prose, the left-hand column is what the text should say. The full entries follow; this table is the index and the retirement notice.

Two terms admit a misreading, and both are worth stating negatively.

• Spec denotes an Allium specification and nothing else. A story's plan is a plan.
• Persona denotes a Council member and nothing else. The role a session adopts is a System.

Function is likewise reserved: it names a regulatory function, never the role a session adopts.

The smallest unit of executable work. One task should correspond to one PR. Bounded by a concrete size limit as per document types. The full domain treatment — sizing limits, discovered tasks, ready/done — is on the Tasks page.

A coherent user-visible outcome, composed of one or more tasks. The unit of sprint planning. The full domain treatment — themes and epics, sizing, ready/done, cross-sprint continuations — is on the Stories page.

A bounded period of work delivering a set of stories aligned to a sprint mission. Closes with a release.

A one-sentence statement of what the sprint exists to achieve. Used to filter candidate stories.

The artefact a sprint produces when it closes — a tagged build plus release notes capturing the sprint's landed work. The release is the upward signal that work happened (per cybernetic levels information flow). Every sprint cuts a release; not every release ships a version — version-level release decisions sit with System 4.

The named major release target that a version series works towards. A milestone owns the what and why: identity, theme, mission, definition of done, and time horizon. It does not contain sprints — that is the version's job. When the milestone's definition of done is met, the current version series closes and the software cuts the milestone release (e.g. 1.0.0). The next version series then begins.

A release series — a coherent set of sprints producing incremental builds (e.g. 0.0.x, 1.0.x) as it works towards a target milestone. The version name matches the CMake MAJOR component: v0 produces 0.x.x builds; v1 produces 1.x.x builds. A version does not carry a mission statement of its own — that lives in its target milestone.

Deprecated. Identity now lives in the target milestone document, not in the version. See the * Identity section of Milestone v1.0 for the current example.

The durable statement of what ORE Studio is and is not. Used to filter candidate versions, far captures, and feature requests.

A named role a session acts as, in the sense Stafford Beer gives the word: one of the five Systems of a viable system, plus the audit System. Each system document is the priming context an LLM session loads when it takes the role on: its purpose, what to pre-read, which skills to invoke, and what not to do. Systems are role-shaped (descriptive); skills are task-shaped (operational). Systems compose skills; skills do not own Systems.

Capitalised and numbered throughout, so that System 3* is never confused with the system, meaning the ORE Studio software.

A concrete, executable capability — how to do a kind of work — in Claude Code's skill format (doc/llm/skills/<slug>/SKILL.org). Each skill is self-contained: it describes when to use it, the procedure, and any artefacts it expects. A skill is task-shaped: invokable in one session to perform a unit of work. Contrast with System, which is role-shaped: a description of what someone does, listing the skills that role draws on.

A how-to document answering one operational question. Has executable scripts where applicable. Tested by CI.

A named, repeatable composition of recipes and skills into a complete multi-step procedure. Owned by System 2 (Orchestrator) — it coordinates S1 operations into higher-level runbooks. Lives under doc/llm/runbooks/.

A durable factual document about the domain, architecture, or components. Not state, not process — just facts that outlive any sprint.

A transient implementation strategy for a single task or story. Lives next to the work as the * Plan section inside that document. Distilled into the parent story's * Decisions when the work closes; the * Plan section is then cleared. Plans do not outlive their task.

Work spotted in passing while executing another task. Filed without triage in DISCOVERED state; must leave DISCOVERED within one orchestrator session (see lifecycle).

A TODO state, not a folder. Tasks and stories in BACKLOG have been triaged but not started. The product backlog (work not yet pulled into a sprint) lives separately under agile/product_backlog/{inbox,next,deferred,discarded}/ as a tree of captures.

A pre-sprint idea: something we may want to do but have not yet pulled into a sprint as a story. Captures live within the capture document in a sprint, if long-lived. New captures land in inbox/ (untriaged); at triage they move to next/ (candidate for the next version), deferred/ (longer-term wishlist), or discarded/ (explicitly rejected). Captures are not stateful — no TODO keyword, no * Status table. They have only two effective states: pending (the file exists in a bucket) and promoted (the file has been converted into a story). On promotion the file is moved into the appropriate sprint folder and its #+type: flips from capture to story; the :ID: is preserved so existing links keep working.

A short, durable note an LLM session writes for the benefit of future sessions — feedback the user gave, a fact about them, a fact about the work in flight, or a pointer to an external system. One memory per file under doc/llm/memory/; carries #+type: memory and a #+memory_subtype: of feedback, user, project, or reference. Memory captures how to work together; code-derivable facts and architecture belong in knowledge instead.

A formal historical record of a technical investigation. Captures the original problem, the methodology used, paths explored (including failures), and conclusions reached. Designed to preserve knowledge and context for future sessions. See document types for the full contract.

A design document describing what one person is trying to do: the actor, the trigger, the steps, the screens, the entity fields each screen shows, and the operations and messages each step needs. Lives under doc/knowledge/journeys/, one subfolder per group of journeys. The groups are logical topics, not components — a component is an implementation concept, and a journey is grouped by what the person is trying to do.

A user journey is written before anything is built. The journey itself is the definition it becomes, and the state that lets a client resume it is a workflow instance: the journey is not server-side, its state is. Most user journeys keep no such state at all. See Document type: user_journey for the contract, and Journey execution for how a journey is executed.

The TODO keyword on a stateful document's * Status headline. The full vocabulary is DISCOVERED BACKLOG STARTED BLOCKED | DONE ABANDONED (active states left of the bar, terminal states right). Documents that are not stateful (knowledge, recipes, systems, meta) have no Status headline. See lifecycle for transitions.

The * Status headline inside a stateful document. Carries the TODO keyword (state) and four subheadings (** Now, ** Waiting on, ** Next, ** Last touched) that describe the live operational detail. Updated every time an orchestrator or agent acts on the document.

A story in a prior sprint that the current story continues. Captured as #+predecessor: <id> frontmatter plus a Continued from: [[id:...][...]] line in the body. See cross-sprint stories in lifecycle.

A story in a later sprint that picks up where this one left off. Captured as #+successor: <id> frontmatter plus a Continued in: [[id:...][...]] note in * Decisions. Audit verifies bidirectional linkage.

Any LLM process doing work. The general word: use it when the distinction between a session and a delegate does not matter. An agent is not a role, so it names no level; the level designated S1 is called Agent, but that is a System, acted as by a session or a delegate. See execution model for how the roles compose, and S1 Agent for the priming context.

The agent a human is talking to. It has a conversation and an operator, which is what separates it from a delegate.

An agent spawned by another agent to do a bounded piece of work and report back. It has no operator, only a brief. Claude Code calls this a subagent; we say delegate because the relationship is what matters, not the mechanism.

The System 2 LLM session the user has assigned to a story. Forks agents, reviews their output, decides what to do with discovered work. See S2 Orchestrator for the priming context.