Key Concepts

Coda

The Coda is the destination. It defines what done looks like for the current phase of delivery and gives every subsequent decision a reference point — does this advance toward the Coda, or away from it?

Why a Coda is necessary

Delivery without a defined destination is not delivery — it is indefinite work. The Coda resolves this by making the intended end-state explicit and agreed upon before significant effort begins.

Without a Coda, every decision is made without a reference point. Teams optimize locally — this feature, this sprint, this ticket — but have no reliable way to assess whether their collective work is converging on anything meaningful. The Coda provides that reference.

The Coda is specific: it describes a concrete state of the system, not an aspiration. "Users can manage their account settings" is not a Coda. "A user can update their email, password, and notification preferences without contacting support, and changes take effect immediately" is closer. Favor observable, testable descriptions over aspirational language.

The Coda is resolved: it has been evaluated, discussed, and accepted as the intended destination for the current phase — not just written down by one person and assumed to be correct.

The Coda is phase-scoped

A Coda applies to a phase, not to the entire life of a system. As phases progress and understanding deepens, the Coda may evolve — sharpened by what was learned, adjusted by new constraints, or replaced entirely when the destination changes. This is not failure; it is the expected behavior of a system that is honestly tracking reality.

Each phase should have its own Coda, articulated before Beats are identified and quality-gated. When a phase ends and a new one begins, the Coda is reassessed. What was the destination? What actually shipped? What should the next phase converge toward, given what was learned?

The Coda and Beats

The Coda shapes which Beats are relevant. A Beat that cannot be connected to the current Coda does not belong in the current work.

This relationship runs in both directions:

• A Beat that does not contribute to the Coda should be deferred, modified, or removed from the active set.
• A Coda that has no Beat supporting a critical capability it requires signals that the Beat set is incomplete.

During quality evaluation, the relationship between the Coda and the Beats is explicitly assessed — not just whether each Beat is well-formed, but whether the full set of Beats is sufficient to reach the destination.

The Coda and agents

The Coda is the reference point AI agents use when evaluating every proposed capability. When an agent assesses whether a new feature belongs as a Beat Version under an existing Beat or as a new Beat entirely, the primary question is: does this advance the system toward the Coda?

Without a stated destination, no agent can assess whether a proposed capability actually belongs in the work. The Coda transforms agent evaluation from pattern-matching to directional reasoning.

Establishing the Coda

The Coda is established early in the project, alongside the initial capture of Notes. It should reflect both the desired outcome and the constraints — technical, organizational, or otherwise — that shape what is achievable in the current phase.

A practical starting point: describe the system in the present tense as if the phase is complete. What can it do? What condition is it in? Who is using it, and for what? The more concrete the description, the more useful the Coda becomes as a decision reference throughout delivery.