Keel Board Model

Keel’s core system story has three layers:

1. This page explains what exists on the board.
2. Roles And Lanes explains who is allowed to move that structure.
3. The Turn Loop explains how those moves create visible state change over time.

Keel uses a strict hierarchy because the board is meant to answer more than "what is someone doing right now?" It must also answer why the work exists, which constraints govern it, and how closure will be verified later.

Everyday language

Objective

Keel term

Mission

The long-running outcome you are trying to achieve across multiple efforts.

Everyday language

Strategic track

Keel term

Epic

A major problem or opportunity inside the mission that deserves its own planning surface.

Everyday language

Tactical campaign

Keel term

Voyage

A planned delivery arc with SRS and SDD constraints before execution begins.

Everyday language

Executable slice

Keel term

Story

The smallest tracked unit that can be started, submitted, accepted, and evidenced.

Everyday language

Research vector

Keel term

Bearing

A discovery move used to reduce fog before you freeze requirements or architecture.

Everyday language

Scheduled contract

Keel term

Routine

Recurring work that pulse can materialize into the board without inventing new scope.

Once the terms are familiar, the board map becomes easier to read. Keel is strict because these objects are meant to stay connected, not because the vocabulary is trying to feel exotic.

Board system map

Direction, planning, execution, and proof stay on one connected path.

Direction

CHARTER.md

Mission

Holds the long-running objective and defines why the rest of the board exists.

Problem framing

PRD.md

Epic

Turns the mission into a defined problem or opportunity with expected value.

Planned passage

SRS.md + SDD.md

Voyage

Locks requirements and design constraints before execution is allowed to start.

Verified move

README.md

Story

Carries the smallest executable slice that can be started, reviewed, accepted, and proved.

Support systems

These objects keep the main lane honest without flattening research, architecture, or scheduled upkeep into delivery stories.

Bearing

Discovery work that reduces fog before you commit to hard planning or implementation.

ADR

Architecture decisions that constrain the route so later stories do not re-litigate core choices.

Routine

Recurring board contracts that materialize work on schedule without inventing new scope.

The core hierarchy

Mission

Own the long-running objective

A mission carries the charter for the outcome you are trying to achieve over time.

Epic

Frame the major problem

An epic creates a PRD-backed problem space inside the mission so tactical work has a strategic parent.

Voyage

Plan before execution starts

A voyage adds SRS and SDD constraints before delivery stories are allowed to run.

Story

Deliver one verified slice

A story is the executable unit that moves through start, submit, and acceptance with evidence attached.

Plain-language job	Keel object	Primary artifact	Why it matters
Long-running objective	Mission	CHARTER.md	Holds the top-level outcome and its boundaries
Strategic problem or opportunity	Epic	PRD.md	Defines the problem and the expected value
Planned delivery arc	Voyage	SRS.md and SDD.md	Freezes requirements and design constraints before execution
Executable slice	Story	README.md	Carries acceptance criteria and proof

Supporting objects

Two other objects matter early:

• Bearing: a research or discovery move that reduces fog before you commit to a hard plan
• Routine: a recurring contract that pulse can materialize into the board on schedule

These are not side notes. Bearings protect the quality of planning, and routines protect the quality of recurring work.

Why the hierarchy is strict

Keel intentionally prevents a "just make a ticket" culture.

The hierarchy exists so the board can answer:

• what objective this work belongs to
• what problem statement justifies it
• what planned constraints govern the implementation
• what evidence will close it

When that chain is missing, the board starts drifting. Keel's doctor and gates are built to surface that drift instead of tolerating it quietly.

State matters as much as structure

Objects are not just nested; they move through states.

• Missions move from definition into active work and eventually into achieved and verified outcomes.
• Voyages are planned before they are started.
• Stories move from backlog into in-progress, then into review and acceptance.

That state model is what makes Keel turn-based. The board is not a flat list of nouns. It is a system of allowed moves.

The next question is who is allowed to make those moves. Read Roles And Lanes next to see how Keel separates strategic authority from delivery execution without splitting the board into separate systems.