The Canopy Method
← The Method

Flow and Signal

How work moves through the system and how progress becomes visible. Reference: METHOD.md for full methodology.

Flow: How Work Moves

The Stages

Every Outcome moves through these stages. The base path has four stages; the optional awaiting_approval stage activates when Outcome.gate.required = true.

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

Brackets indicate awaiting_approval is conditional — only used when Outcome.gate.required = true. See the awaiting_approval section below for the gate mechanism.

Define

What's happening: Clarifying what success looks like.

Entry criteria:

  • The Outcome has been created with a result-oriented title
  • Priority has been assigned (Now / Next / Later)

Activities:

  • Writing and refining success criteria
  • Identifying and linking relevant Context
  • Surfacing Decisions that must be made before Build can start
  • Identifying the owner

Exit criteria (ready for Build):

  • Success criteria are written and testable
  • Blocking Decisions have been resolved (status: Decided)
  • Relevant Context has been linked
  • An owner has been assigned

Key insight: An Outcome stuck in Define usually means there's an unidentified Decision. The first question is always: "What choice needs to be made before we can start building?"

Build

What's happening: Actively creating the thing.

Entry criteria:

  • Define exit criteria are met
  • Owner is available to work on this

Activities:

  • Writing code, creating designs, producing content, or whatever "building" means for this Outcome
  • Referencing Context for business rules, patterns, and constraints
  • Making and recording smaller Decisions as they arise during building
  • Updating Context when new knowledge is discovered

Exit criteria (ready for Review):

  • The builder believes all success criteria are met
  • The work is in a reviewable state (code committed, design exported, content drafted)

Key insight: Build should be the fastest stage for most Outcomes in AI-augmented teams. If Build is slow, check: is Context insufficient? Are there undiscovered Decisions? Is the Outcome too large (should it be split)?

Review

What's happening: Validating that the Outcome meets its success criteria.

Entry criteria:

  • Builder has indicated the work is ready for review

Activities:

  • Testing against each success criterion (pass/fail)
  • Code review, design review, content review — whatever is appropriate
  • Verifying consistency with linked Context (does it follow the business rules? the design principles?)
  • Identifying issues that require rework

Exit criteria (ready for Ship):

  • All success criteria pass
  • Review feedback has been addressed
  • No blocking issues remain

Possible backward transition:

  • If rework is needed → return to Build with specific feedback

Key insight: Review should be objective, not opinion-based. Success criteria are the standard. If the reviewer and builder disagree, the success criteria need to be sharpened — not the argument won.

Ship

What's happening: Deploying, delivering, or releasing.

Entry criteria:

  • Review exit criteria are met

Activities:

  • Deployment to production (for software)
  • Delivery to stakeholder (for client work)
  • Publication (for content)
  • Whatever "shipping" means for this type of work

Exit criteria (Done):

  • The Outcome is live, delivered, or published
  • Stakeholders can see/use the result
  • Any post-ship verification passes

Possible backward transition:

  • If post-ship issues are found → return to Review

awaiting_approval (Conditional)

What's happening: Held for explicit approval before Ship.

Entry criteria:

  • Review exit criteria are met (all success criteria pass)
  • Outcome.gate.required = true (the Outcome is gated)
  • Outcome.gate.override is NOT true (human hasn't bypassed)

Activities:

  • Approver receives notification with link to Outcome detail
  • Approver reviews the Outcome and either approves or rejects with reason
  • The Outcome detail surface shows pending approval state with assignee + age

Exit criteria:

  • Approved (ready for Ship): Outcome.gate.status = approved → transitions to Ship
  • Rejected (return to Build): Outcome.gate.status = rejected with rejection_reason → returns to Build for rework

Per-Outcome override: A human running a Claude Code session can set Outcome.gate.override = true (with override_reason and override_by recorded) to skip this stage even when required. This is the practical-iteration escape valve — the gate enforces in production but doesn't block dev throughput. The override is permanently recorded for audit; subsequent governance review can challenge it.

Why a stage AND a field (per D-03): The flow stage gives Signal something to aggregate (the Approval Gate Queue — see below). The field lets per-Outcome configuration drive when the stage applies, plus the override mechanism. Two complementary mechanisms, not duplication.

Origin: the v2.0 audit found 4 clans needed approval gates (Jungle npm-publish, MOIMF Alpha Verdict APPROVED/WARNING/BLOCKED, Limb Mandrill to Human Council, Webmaster Council-tier deploys). See docs/methodology/validation/DECISIONS-RESOLVED.md#D-03.

Done

The Outcome has shipped and been verified. It moves to the completed archive. It's no longer visible on the active board but remains in history for Signal and Pulse reporting.

Flow Rules

No Sprints

There are no time boxes. An Outcome enters Define when it's identified and ships when it's ready. Some Outcomes flow from Define to Done in a day. Some take three weeks. Both are fine. The speed is the speed.

No WIP Limits (But Use Judgment)

The Canopy Method doesn't impose formal WIP limits, but the principle is clear: finish things before starting new things. If one person has 5 Outcomes in Build, they're context-switching too much. Limit Now priorities to 1–3 per person.

Backward Flow is Normal

Outcomes can move backward. Ship → Review (post-ship issue found). Review → Build (rework needed). Build → Define (scope unclear, needs more Decision-making). This is not failure — it's the system working correctly.

Stage Transitions Emit Events

Every stage change is recorded as a Signal Event. This powers the Signal dashboard, the Weekly Pulse, throughput metrics, and lead time calculations. No manual status updates needed.

Calendar Anchors vs Work Cadence

Work cadence stays continuous-flow internally. There are no time boxes.

For stakeholder communication, however, calendars exist. Board meetings, regulatory submission deadlines, App Store review windows, quarterly investor updates — these are real, and the method does not pretend otherwise.

The accommodation: Milestone.calendar_anchor: date (optional). A Milestone may carry a calendar anchor so it appears on the Calendar-Anchored Roadmap (a stakeholder-facing report). The work cadence inside the Milestone does NOT become time-boxed. The Milestone is finished when its Outcomes are Done; the calendar anchor is when it is REPORTED.

Example: Trellis has Q2 / Q3 / Q4 2026 Township of Rose Board agendas. FirstContactGaming has iOS / Android App Store submission gates. These show up as Milestone.calendar_anchor dates for stakeholder reporting, but the Outcomes inside flow at their natural speed.

This is not sprints returning. Sprints time-box WORK. calendar_anchor time-boxes REPORTING. The distinction is non-negotiable.

See docs/methodology/validation/DECISIONS-RESOLVED.md#D-06.

Timestamps Are Automatic

  • started_at: Set when Outcome first enters Build
  • shipped_at: Set when Outcome enters Ship
  • completed_at: Set when Outcome enters Done
  • These timestamps compute lead time automatically

Metrics: What We Measure

Lead Time

Days from Outcome created to Outcome shipped.

This is the primary speed metric. It measures how long it takes for a result to go from "we identified this" to "it's live."

Lead time includes Define time, Build time, Review time, and Ship time. It measures the whole system, not just the building part.

Shorter lead time = faster delivery. Track the distribution (average, median, p90), not just the average.

Throughput

Number of Outcomes shipped per time period.

Usually measured weekly. "We shipped 7 Outcomes this week." Simple. Meaningful.

Throughput increasing over time with stable lead time = the team is getting more efficient. Throughput increasing with increasing lead time = the team is taking on bigger Outcomes.

Decision Velocity

Average time from Decision opened to Decision resolved.

Fast decision velocity = fast everything else, because decisions are the bottleneck.

Track this at the workspace level. If decision velocity is slow, investigate: are decisions too big? are the wrong people being consulted? is reversibility not being assessed?

What We Do NOT Measure

  • ❌ Story points (don't exist)
  • ❌ Velocity in points (meaningless)
  • ❌ Sprint commitment vs. completion (no sprints)
  • ❌ Burndown rate (no burndowns)
  • ❌ Lines of code (not a measure of value)
  • ❌ Hours worked (not a measure of output)

Signal: How Progress Becomes Visible

Signal is the intelligence layer. It observes what's happening and makes it visible without anyone writing status reports.

Activity Feed (Real-Time)

Generated automatically from stage transitions, decisions, and context changes:

  • "Outcome 'Customers can book online' moved from Build to Review" — 2h ago
  • "Decision 'Stripe vs. Square' was resolved: Stripe Connect" — 4h ago
  • "Context 'HIPAA Requirements' was updated" — yesterday
  • "3 new Inbox items received from Portal feedback" — today
  • "CrossClanDependency 'Persona API key from Cortex' moved from IN_PROGRESS_BY_THEM to DELIVERED" — 1h ago
  • "Invariant 'HIPAA patient data encryption' health changed from passing to failing" — 30m ago
  • "Outcome 'Customers can book online' entered awaiting_approval (approver: name)" — 2h ago
  • "LivingProcess 'Cortex Nexus' deployed v3.2.1" — 4h ago

Attention Alerts

AI-generated flags for things that need human attention:

  • Stale Outcome: "OC-015 has been in Define for 5 days. Average Define time is 2 days. Is there a blocking Decision?"
  • Pending Decision: "DEC-008 'Build vs. Buy scheduling' has been Open for 72 hours. Reversibility: Moderate — target resolution: today."
  • Review Waiting: "OC-022 has been in Review for 3 days with no reviewer activity."
  • SLA Warning: "Inbox item #047 is approaching its 24-hour response deadline."
  • Invariant Violation: "Invariant 'HIPAA patient data encryption' is failing — 3 violations in last 24h."
  • Stalled CrossClanDependency: "CCD 'Persona API key' has been in REQUESTED for 8 days. Cortex side has not acknowledged."
  • Blocked Approval Gate: "Outcome 'v2.1 release' has been in awaiting_approval for 5 days. Approver: name."
  • LivingProcess Degraded: "Cortex Nexus health: degraded. p95 latency 340ms (threshold 200ms)."
  • Issue Awaiting Evidence: "Issue 'iOS network failures' has been in diagnostic_state: awaiting_evidence for 14 days."

Throughput Dashboard

Visual summary:

  • Outcomes shipped this week / this month / trailing 30 days
  • Lead time distribution (histogram)
  • Decision velocity trend
  • Flow stage distribution (how many Outcomes in each stage right now)

Weekly Pulse: The Async Ceremony

The Weekly Pulse replaces sprint review, sprint planning, retrospective, and daily standups — all of them — with one 15–30 minute async practice.

How It Works

1. Auto-Generate (Friday) The system compiles the week's events into a structured draft:

  • Outcomes Shipped (list with owners and lead times)
  • Decisions Made (list with summaries)
  • Decisions Pending (list with age and urgency)
  • Context Added (new knowledge this week)
  • Blockers (stuck items with AI-suggested actions)
  • Metrics (throughput, lead time, decision velocity for the week)

2. Human Edit (Friday, 15–30 min) The team lead or project owner reviews the draft and adds:

  • Narrative context that AI can't provide ("The client changed direction mid-week, which is why lead times are up")
  • Priorities for next week
  • Celebrations, acknowledgments, concerns
  • Any information the team needs that isn't captured in the data

3. Publish The edited Pulse is published to:

  • The Signal dashboard (permanent record)
  • Email to team members
  • Optionally: the Portal (for client visibility)

What Pulse Replaces

Scrum Ceremony Time/Week Canopy Replacement
Daily Standup (15 min × 5) 1h 15m Signal Activity Feed (always current, zero meetings)
Sprint Planning 1–2h Continuous prioritization (Now/Next/Later)
Sprint Review / Demo 1h Weekly Pulse (shipped Outcomes listed with context)
Retrospective 1h Decision Log review + Pulse "concerns" section
Total 4–5+ hours 15–30 minutes

Reporting Surfaces (v2.0)

The Signal layer aggregates events into structured reports. v1.0 shipped: Activity Feed, Attention Alerts, Throughput Dashboard, Weekly Pulse. v2.0 adds five new surfaces (per D-13), each tied to a primitive or workflow:

Cross-Clan Dependency Report

Lists every incoming and outgoing CrossClanDependency entity for the current clan, with state (REQUESTED / IN_PROGRESS_BY_THEM / DELIVERED / ACKED / DONE), age, and aging-bucket badges. Used to answer "what's pending from other clans?" and "what are we still owed?"

See CROSS-CLAN.md for the underlying primitive. Phase 18 implements the surface.

Stakeholder Briefing Variants (of the Weekly Pulse)

The Weekly Pulse already exists. v2.0 adds three lens variants chosen at generation time:

  • technical — for engineering leadership; emphasizes throughput, lead time, decision velocity, infra Outcomes, Invariant health
  • business — for business leadership; emphasizes feature / content Outcomes, customer-facing milestones, hidden infra and refactor
  • regulatory — for compliance / audit readers; emphasizes compliance Outcomes, Invariant violations, retroactive backfill, audit chain completeness

Same underlying data, three different filters and emphases. Each lens uses Outcome.kind to decide what to surface vs hide.

Invariant Health Dashboard

Pass / fail status per Invariant, last-checked timestamp, violation count over the last 30 days, drill-through to specific violation events. Used by compliance officers, security reviewers, brand auditors. Anchored in INVARIANTS.md.

Approval Gate Queue

Lists every Outcome currently in awaiting_approval stage, with approver, age, and Outcome detail link. Aggregates across the workspace so approvers see ALL pending requests in one place rather than per-Outcome notifications. Tied to the awaiting_approval stage above.

Risk Heat-Map

Aggregates Attention Alerts into a prioritized risk view:

  • Invariant violations (health_status: failing)
  • Stuck Outcomes (in Define / Build / Review beyond expected duration)
  • Blocked gates (Outcomes in awaiting_approval beyond expected duration)
  • Stalled CrossClanDependencies (no state transition in N days)
  • LivingProcess degradation (health_status: degraded or unhealthy)

Renders as a heat-map with severity × confidence axes. Used for executive-level risk visibility.

Method spec vs platform implementation: This section specs the surfaces canonically. The platform (Phases 18+) implements them. If platform implementation lags, the surfaces are still part of the methodology spec — they describe what Canopy MEANS, not just what's built.

Flow Anti-Patterns

Anti-Pattern: "Everything is Now"

If more than 3 Outcomes per person are marked Now, nothing is actually Now. Reprioritize. Be honest about sequence.

Anti-Pattern: "Define Forever"

Outcomes stuck in Define usually mean an unidentified Decision. Surface it, frame it, resolve it.

Anti-Pattern: "Build but Never Review"

If Outcomes pile up in Review, the bottleneck is review capacity, not build capacity. Address this by making Review expectations explicit in success criteria.

Anti-Pattern: "Review Ping-Pong"

If Outcomes keep bouncing between Build and Review, the success criteria were probably too vague. Sharpen them before the next Build cycle.

Anti-Pattern: "Ship Means Done"

Ship is not Done. Ship means deployed/delivered. Done means verified and accepted. Don't skip the verification step.

Anti-Pattern: "Ghost Outcomes"

Outcomes that exist in the system but nobody is actively working on, thinking about, or even aware of. Archive or delete them. If they matter, they'll come back.

Anti-Pattern: "Status Meeting Anyway"

If the team is holding status meetings in addition to using Signal and Pulse, something is wrong. Either Signal isn't providing enough information (fix Signal), or the meetings are serving a social function (reframe them as something other than status).

Cross-refs