Beats
Durable, outcome-oriented capabilities the system must possess — the stable vocabulary of what a system can do.
Beats
Beats are the stable vocabulary of a system's capabilities. Each Beat describes what the system must be able to do — durably, outcome-first, and independent of how or when that capability gets built.
Durable, outcome-oriented capabilities the system must possess. Beats persist as long as the capability is relevant — they are not one-time tasks, deliverables, or features to be closed and archived.
What a Beat represents
A Beat describes what a system must be able to do, not what needs to be built by a certain date. This distinction is deliberate.
Tasks and features close when they ship. A capability — the thing that makes a system actually useful — continues to matter long after the first version is delivered. A user authentication capability does not stop being relevant because it was first implemented three years ago. It evolves: new authentication methods, new security requirements, new user contexts. The Beat stays open and active, accumulating Beat Versions as the capability advances.
Beats are outcome-oriented: they define the end result the system must achieve, leaving room for how that result is reached to evolve over time. A well-written Beat describes what a user or stakeholder would experience, not the technical mechanism that produces it.
Beats are not tasks
A common source of fragility in delivery systems is conflating capability with work items. When capabilities are expressed as tickets, they get closed, archived, and forgotten — even though the underlying need remains.
The difference in practice:
| Task framing | Beat framing |
|---|---|
| "Build login page" | "Users can securely authenticate and access their accounts" |
| "Add export button" | "Users can extract their data in formats compatible with downstream tools" |
| "Fix search latency" | "Search returns results fast enough that users don't abandon queries" |
The task framing closes. The Beat framing persists and evolves. The capability described in the Beat is still relevant two years later; the task that first addressed it is an implementation detail of a specific moment.
Quality evaluation
Before a Beat can be considered ready for delivery, it must satisfy six quality dimensions: Distinctive, Harmonious, Substantial, Durable, Clear, and Strategically Aligned. This evaluation ensures the Beat is well-formed before Revisions begin.
The dimensions assess whether the Beat:
- stands apart from other Beats without overlap (Distinctive)
- works with the rest of the system rather than against it (Harmonious)
- addresses a capability of genuine, lasting significance (Substantial)
- will remain relevant through the current phase and beyond (Durable)
- can be understood by anyone working in the system (Clear)
- advances the system toward the current Coda (Strategically Aligned)
Beat lifecycle
Beats begin in composing state — identified but not yet quality-gated. Once a Beat satisfies all six quality dimensions, it transitions to composed, and Beat Versions can begin. As Revisions ship and the capability matures, the Beat transitions to live. It remains active for as long as the capability it describes is relevant to the current Coda.
When a capability is no longer relevant — because the Coda has changed, the system has moved on, or the need no longer exists — the Beat can be retired. A retired Beat is not deleted; it becomes part of the record of what the system was and what it needed at a prior stage.
A system with well-formed Beats has a stable vocabulary for capability. Team members at any point in the project can understand what the system must do and why, without reconstructing that understanding from scratch.
Beats and agents
Beats are the primary unit AI agents reason over when evaluating a product corpus. Because Beats are durable, outcome-oriented, and non-overlapping, an agent can hold the entire set simultaneously and reason about relationships, overlaps, and gaps — something no individual human can do at scale once a system exceeds a few dozen capabilities.
When a new feature is proposed, an agent with access to the full Beat set can check for overlap, map interactions with existing Beats, propagate relevant Notes, and propose precise placement — all in a single pass. The quality of that reasoning is directly proportional to the quality of the Beats it reasons over.