The Framework

The Beat Arc

Every Beat has its own lifecycle arc. Understanding that arc is how the method works in practice: not as a project-level phase a team enters and exits, but as a progression that each capability follows independently, at its own pace.

The three states

A Beat moves through three states from first identification to active delivery.

---

The arc in practice

1. 1
   A Beat is created

   The Beat enters the system in composing state with a title and initial description. The title should be outcome-oriented — what the system will be able to do — not a task, feature, or deliverable name.

2. 2
   Notes are captured

   Context, constraints, decisions, and guidance that shape the capability are recorded as Notes. These accumulate throughout the arc and preserve the reasoning behind the Beat for anyone who works on it later.

3. 3
   Quality evaluation runs

   The Beat is evaluated against the six quality dimensions. A Beat that fails a dimension is not discarded — it is revised until it can stand on all six.

4. 4
   The Beat transitions to composed

   Its first Beat Version is created, carrying description, scope, and acceptance criteria for the first planned increment of the capability.

5. 5
   The first Revision ships

   The Beat transitions to live. The capability is in production for the first time. This is the beginning of execution, not the end of the Beat's story.

6. 6
   Additional Beat Versions extend the capability

   Each Beat Version represents a planned increment of the capability; each Revision under it is a shippable PR. The Beat remains live and accumulates further Versions for as long as the capability remains relevant to the Coda.

---

Baselining existing work

When Harmonic Composition is introduced to a project that is already in flight, some Beats will have shipped work without having gone through formal quality evaluation. Baselining brings those capabilities into the arc.

What baselining involves:

• Create Beats for capabilities that exist but are not yet documented in the system. Focus on outcome-oriented names — what the system does for its users, not what was built.
• Capture Notes for decisions already made: constraints that shaped the work, choices that were taken, context that future contributors will need. These Notes do not need to reconstruct every historical detail — they need to capture what matters going forward.
• Run quality evaluation against each Beat and refine until it passes the six dimensions. A baselined Beat earns composed status the same way a new Beat does.
• Create Beat Versions that document increments already delivered, so the record reflects what has actually shipped.

Where a baselined Beat enters the arc depends on its current state. A capability that has already shipped enters at live. One that exists but has never had a Revision shipped enters at composed once its first Beat Version is planned. One that is only partially defined may still be in composing. The arc applies going forward — baselining is not a requirement to reconstruct the full history of every past decision.

---

Multiple Beats at different arc positions

In a healthy project, Beats are at different positions in their arc simultaneously. Some are live and receiving new Beat Versions; others are composed and pending their first Revision; others are still in composing state being evaluated.

This is the normal state of a project. It is not a sign of disorder — it reflects the reality that capabilities develop at different paces. The relevant question at any point is not "what phase is the project in?" but "where in the arc is this particular Beat, and what does it need next?"