The Canopy Method

The methodology for AI-augmented teams. No sprints. No story points. No velocity.

Nine primitives: Outcomes, Decisions, Context, Issues, Signal, Invariants, Initiatives, CrossClanDependencies, LivingProcesses. Vocabulary discipline: see VOCABULARY.md.

What This Is

The Canopy Method is a development methodology that replaces Scrum. It is designed for teams where AI has made building fast but deciding hard. The bottleneck is no longer development capacity — it is decisions and context.

v1.0 shipped five primitives (Outcome, Decision, Context, Issue, Signal). v2.0 (2026-05-24) added four more (Invariant, Initiative, CrossClanDependency, LivingProcess) based on validation against 25 real clans. This file defines the complete nine-primitive set. Everything else references this file. If a practice contradicts what's written here, this file wins.

The Four Values

We value the items on the right. We value the items on the left more.

The Nine Primitives

Every piece of work in the Canopy Method is organized around nine primitives. The first five are foundational (v1.0). The next four (v2.0) handle structural patterns that emerged from auditing 25 real clans:

1. Outcome

The fundamental unit of work. An Outcome is a result that delivers value, not a task to complete.

• Good Outcome: "Customers can book appointments online"
• Bad Outcome: "Build booking API endpoint"
• Good Outcome: "Team can see which decisions are blocking progress"
• Bad Outcome: "Implement decision tracking feature"

Rules:

• Written as a statement that is true when the work is done
• Has 2–5 testable success criteria (when all are true, the Outcome is Done)
• Has exactly one owner (one human accountable — not a team, not "shared")
• Has a priority: Now, Next, or Later (three levels only)
• Is atomic — if it needs decomposition, make multiple Outcomes, never subtasks
• Moves through Flow stages, never sprints
• Has a kind: feature / infra / compliance / content / research / refactor / performance / operations (see OUTCOMES.md)
• May link to an Initiative (cross-cutting subsystem) and to Invariants (standing constraints it must satisfy)

2. Flow

The progression of an Outcome through stages:

Define → Build → Review → [awaiting_approval] → Ship → Done

v2.0 introduces the conditional awaiting_approval stage — used when Outcome.gate.required = true. A human running a Claude Code session may override per-Outcome (the override is recorded for audit). See FLOW-AND-SIGNAL.md.

• Define: Clarifying what success looks like. What are we building? What does "done" mean? What Context do we need? What Decisions must be made first?
• Build: Actively being developed. Code is being written, designs are being created, content is being produced.
• Review: Being tested, validated, or reviewed. Does it meet the success criteria? Does it match the Context?
• Ship: Deploying to production or delivering to the stakeholder. The final step before Done.
• Done: Shipped and verified. Success criteria confirmed. Archived.

Rules:

• There are no sprints. There are no time boxes. There are no cycles.
• Each Outcome moves at its own natural speed. Some take hours. Some take weeks.
• Flow is continuous. Work enters when it's ready, ships when it's done.
• An Outcome can move backward (Ship → Review if issues found, Review → Build if rework needed)
• The only speed metrics are lead time (days from created to shipped) and throughput (Outcomes shipped per week)

3. Context

The living knowledge that informs every decision and every build. Context is the most valuable asset in any project — more valuable than the code, because good context can regenerate code, but code cannot regenerate context.

Types of Context:

• Business Rules: How the domain works. "Subscriptions auto-renew unless cancelled 48 hours before billing."
• Design Principles: Patterns that apply across the project. "All API responses use JSON:API format."
• Constraints: Limits that cannot be violated. "Must comply with HIPAA." "Budget cannot exceed $50K."
• Requirements: What the stakeholder asked for, in their words.
• Prompt Patterns: Reusable instructions for AI tools. "When generating React components, follow this pattern..."
• Decision History: What was decided, why, and what alternatives were considered.
• Reference Material: External documents, specs, research that inform the work.

Rules:

• Context is written down, not kept in someone's head
• Context is updated when things change (it is "living" — not write-once)
• Context is searchable and linked to the Outcomes and Decisions it informs
• Before building anything, check Context first
• When you learn something new about the domain, the constraints, or the approach — write it as Context immediately

4. Decision

An explicit record of a choice. Decisions are the actual bottleneck in AI-augmented work — making them visible, structured, and trackable makes teams measurably faster.

Every Decision has:

• Question: The choice framed as a question. "Should we use Stripe or Square for payments?"
• Status: Open → Decided → (optionally Revisited or Superseded)
• Alternatives: What options were considered
• Decision: What was chosen
• Rationale: Why (the reasoning matters more than the choice)
• Reversibility: Easy / Moderate / Hard / Permanent
• Linked Outcomes: Which Outcomes depend on this decision
• Linked Context: What information informed the choice

Rules:

• If an Outcome is stuck, the first question is always: "Is there a Decision blocking this?"
• Reversibility calibrates deliberation time:
  • Easy: Decide now, learn fast. Reverse in hours if wrong.
  • Moderate: Worth a day of consideration. Reversible with some effort.
  • Hard: Take time to get this right. Reversal is expensive.
  • Permanent: Cannot be undone. Thorough analysis required.
• Every Decision is recorded — even small ones. The record prevents re-litigation.
• When a Decision is revisited, the original is preserved (not overwritten) and linked to the new Decision.

5. Signal

AI-generated awareness of project state. Signal replaces status meetings, daily standups, sprint reviews, and velocity reports with always-current information.

Signal includes:

• Activity: What moved between stages today. What shipped. What Decisions were made.
• Attention: What's stuck. What Decisions are pending too long. What needs a human.
• Throughput: Outcomes shipped this week, this month. Lead time distribution.

• Decision Velocity: Average time from Decision opened to resolved.

The Weekly Pulse is a structured async reflection generated every week:

1. Outcomes Shipped
2. Decisions Made
3. Decisions Pending
4. Context Added
5. Blockers and suggested actions

Rules:

• Signal is generated, not reported. Nobody fills out status updates.
• The Weekly Pulse is AI-drafted and human-edited. The human adds judgment and nuance. Total effort: 15–30 minutes.

• Signal replaces 4–5 hours of weekly ceremonies (daily standups × 5 + sprint review + sprint planning + retrospective)

6. Invariant

A standing constraint that applies to all work in scope. Unlike Context.constraint (passive documentation), an Invariant is enforced (compile / deploy / AI-verified / manual) and surfaces violations as Attention Alerts.

Examples: HIPAA patient-data encryption, brand-voice consistency, audit-trail required, no hardcoded hex values, pre-deploy browser-smoke must pass.

Rules:

• Has a defined enforcement mechanism (compile / deploy / AI-verified / manual)
• Has a scope (workspace / project / clan-wide)
• Has a health_status (passing / failing / unknown) updated by the enforcement mechanism
• Auto-links to Outcomes by tag pattern when applicable
• Violations surface as Attention Alerts in the Signal layer

Full spec: see INVARIANTS.md. Origin: v2.0 audit (D-02).

7. Initiative

A cross-cutting grouping of related Outcomes that together build a coherent subsystem or program — larger than any single Outcome, smaller than a Phase.

Examples: Howler's telephony bridge subsystem (router + bridge + conductor), Cortex's plugin system, Plain's analyzer-pass program.

Rules:

• Has a goal and 2-5 success criteria (same shape as Outcome success criteria)
• Has one owner (same accountability rule as Outcome)
• Outcomes link to Initiatives optionally; an Initiative may span multiple Phases
• Initiative-level rollup shows percent_complete, blocked_count, in_flight_count

Full spec: see INITIATIVES.md. Origin: v2.0 audit (D-04).

8. CrossClanDependency

A paired-lifecycle entity for work that crosses clan boundaries. Synced via Jungle MCP so both clans see the same dependency from both sides.

Lifecycle: REQUESTED → IN_PROGRESS_BY_THEM → DELIVERED → ACKED → DONE.

Examples: Persona needing a Cortex API key, Howler's TTS-backend dependency on Cortex, ROM Web ↔ Mobile back-port pairs.

Rules:

• Both clans see the same entity with identical state
• State transitions on one side propagate to the other (no one-sided drift)
• Sync failures are observable as Attention Alerts
• Outcomes on either side may link to the dependency

Full spec: see CROSS-CLAN.md. Origin: v2.0 audit (D-01).

9. LivingProcess

An always-on agent or service whose product IS the running process. Council-tier only.

Examples: Cortex Nexus (inference gateway), Jungle Obsidian / Nexus / Webmaster (Council agents), JARVIS (Cortex consumer).

Rules:

• Tracks current_state (running / stopped / restarting / crashed / unknown)
• Tracks last_deploy_at + last_deploy_version for incident reconstruction
• Tracks consumption_metrics (tokens / day, request rate, etc.)
• LINKS OUT to observability tools (Grafana, Datadog, CloudWatch) — does not replicate them
• Outcomes that modify the process (config changes, version bumps) link to it

Full spec: see LIVING-PROCESS.md. Origin: v2.0 audit (D-08).

The Workflow: Processing Any Input

When you receive ANY input — a document, a set of requirements, a business idea, a feature request, a client brief — the Canopy Method processes it through this sequence:

Step 1: Extract Context

Read the input. Identify and record:

• Business rules and domain knowledge
• Constraints (technical, legal, budget, timeline)
• Requirements (what the stakeholder actually asked for)
• Design principles or patterns that apply
• Reference material that should be preserved

Write each as a Context entry. Tag it. Link it to the project.

Step 2: Decompose into Outcomes

Break the input into discrete, result-oriented Outcomes. For each:

• Write the title as a result: "X can do Y" or "System does Z"
• Define 2–5 testable success criteria
• Assign priority: Now / Next / Later
• Tag with relevant labels

Test each Outcome: Is it atomic? (If not, split it.) Is it result-oriented? (If not, rewrite it.) Can you test whether it's done? (If not, sharpen the success criteria.)

Step 3: Surface Decisions

Identify every choice that must be made before or during the work:

• Technology choices
• Design approach decisions
• Scope decisions ("do we include X?")
• Trade-off decisions ("speed vs. completeness")
• Business model decisions

For each Decision:

• Frame as a question
• List alternatives
• Assess reversibility
• Link to the Outcomes it blocks

Step 4: Prioritize

Assign priorities using only three levels:

• Now: Actively needed. Someone should be working on this today.
• Next: Up next when current work completes. Days away, not weeks.

• Later: Important but not urgent. Weeks or months away. Backlog.

Priority is about sequence, not importance. Everything in the system is important (or it shouldn't be there). Priority answers: "What do we work on first?"

Step 5: Flow

Outcomes enter Define. They flow through Build → Review → Ship as work progresses. Decisions are made as they surface. Context is updated as knowledge grows. Signal is generated automatically from the activity.

No sprints. No ceremonies. No estimation. Just flow.

What Does NOT Exist in the Canopy Method

These are not optional features that haven't been built yet. These are deliberate exclusions. They represent practices that the Canopy Method explicitly rejects:

• Sprints / Cycles / Iterations: Time-boxing is artificial. Work flows at its natural speed.
• Story Points / Estimation: Estimation is theater in an AI-augmented world. Measure what actually happened (lead time, throughput), not what you guessed would happen.
• Velocity Charts: Velocity measures the wrong thing. Throughput and lead time measure the right thing.
• Burndown / Burnup Charts: Artifacts of sprint thinking. Replaced by throughput trends and lead time distribution.
• Subtasks / Child Items: Outcomes are atomic. Decompose into multiple Outcomes. Hierarchy creates hiding places for scope creep.
• Multiple Assignees: One owner per Outcome. Shared ownership means no ownership.
• Daily Standups: Replaced by Signal's activity feed. Always current. Never a meeting.
• Sprint Planning: Replaced by continuous prioritization (Now / Next / Later).
• Sprint Review / Demo: Replaced by the Weekly Pulse.
• Retrospective: Replaced by Decision Log review. "What did we decide? What would we decide differently?"
• Scrum Master / Agile Coach roles: The methodology is simple enough that it doesn't need a dedicated practitioner.

• Coalition primitive (multi-Alpha per repo): Documented as variant in DECISIONS.md (D-11). Too rare (3 clans) to bake into core taxonomy.
• OperationalConcern primitive: Continuous SRE work = Outcomes with kind: operations + Invariants for SLO commitments (D-10).
• Replicated observability tooling: LivingProcess links OUT to Grafana / Datadog. Canopy is the entity layer.

Vocabulary

Use Canopy Method vocabulary. The full canonical list lives in VOCABULARY.md; the most common confusions are below.

Enforcement: npm run check:vocab runs against docs/methodology/ and apps/site/app/. Drift fails CI.

Cross-Surface Coherence — Canopy's Blue Ocean

The Canopy Method maps identically across CLI, web SaaS, API, marketing site, and AI coding agents. Same vocabulary, same semantics, same field shapes — everywhere.

• CLI commands use Canopy primitive names. No surface-specific aliases.
• Web UI labels match methodology doc terms exactly.
• tRPC API types are generated from the same Zod schemas the methodology Field Tables define.
• Marketing site (apps/site/) is updated in lockstep with methodology docs — canopymethod.ai never drifts from docs/methodology/.
• AI coding agents read CLAUDE.md and honor the same primitives the web UI honors.
• Team-adoption CLI (Phase 19) scaffolds docs/methodology/ + .canopy/ + CLAUDE.md together — what the team reads is what the AI agent honors.

This is the strategic moat: no other PM methodology enforces vocabulary discipline across all surfaces. Drift is treated as a method failure, not a translation choice.

See VOCABULARY.md for enforcement; the COH-* requirements in .canopy/REQUIREMENTS.md for the formal coherence gates.

Applying the Method to a New Project

1. Read the input material completely
2. Extract Context (business rules, constraints, requirements, reference material)
3. Decompose into Outcomes (result-oriented, atomic, testable)
4. Surface Decisions (what must be chosen before work can proceed)
5. Prioritize (Now / Next / Later)
6. Begin Flow (Define → Build → Review → Ship)
7. Signal continuously (what shipped, what's stuck, what needs a decision)
8. Pulse weekly (AI-generated summary, human-edited, 15–30 minutes)
9. Honor Invariants continuously (a violation is a method failure, not just a bug)
10. File CrossClanDependencies when work crosses clan lines (do not use informal asks)

The method works the same whether the project is a software product, a client engagement, a book, a community initiative, or any other complex endeavor that requires coordinating work toward outcomes.

Cross-refs

Depth docs: OUTCOMES.md (v2.0 kind / is_retroactive / blocked_on), DECISIONS.md (multi-Alpha variant), CONTEXT.md, BUGS.md (v2.0 diagnostic_state), INVARIANTS.md, INITIATIVES.md, CROSS-CLAN.md, LIVING-PROCESS.md, FLOW-AND-SIGNAL.md (v2.0 awaiting_approval + 5 new reporting surfaces), VOCABULARY.md, CLAUDE.md, PORTFOLIO.md.

Methodology evolution record: validation/VALIDATION.md (v7.0 audit, 25 clans), validation/DECISIONS-RESOLVED.md (15 resolved decisions that drove v2.0), MIGRATION-clan-alpha-to-canopy.md (migrating from the older .clan-alpha/ format).