Initiatives

Cross-cutting subsystem groupings. Between Outcome and Phase. Vocabulary discipline: see VOCABULARY.md. Reference: METHOD.md for full methodology.

Definition

An Initiative is a grouping of related Outcomes that together build a coherent subsystem or program. It is larger than any single Outcome but smaller than a Phase. A telephony bridge subsystem. A plugin system. An analyzer-pass program. A 4-phase RBAC build. These are units of intent that span multiple Outcomes and often multiple Phases.

The hierarchy: Milestone > Phase > Initiative (optional) > Outcome. Milestones are release-level (v1.0, v2.0). Phases are time-and-scope boundaries — chunks of plan. Initiatives are subsystem-and-goal groupings — chunks of intent. An Outcome belongs to exactly one Phase and optionally one Initiative.

An Initiative is not a Phase. Phases are bounded plans of work the team committed to in a milestone cycle. Initiatives are bounded goals that may span multiple such cycles. A Phase may contain Outcomes from several Initiatives (bridge + admin + billing all shipped in Phase 7). An Initiative may span several Phases (the plugin system took 11 Phases to mature).

An Initiative is not a Milestone. Milestones are version cuts — the moment a release lands. Initiatives are persistent subsystems within or across releases. The plugin system is not v1.0; the plugin system shipped across v0.4 through v0.9. The Initiative records the goal once; the Milestones record the cut points.

An Initiative is not just tags. Tags filter — they slice the Outcome view. An Initiative is a first-class entity with a goal, success criteria, a single owner, and computed rollup metrics. A reader can ask "are we done with the bridge subsystem?" and the Initiative answers it. A tag can't.

Initiatives have status: active, completed, cancelled. They do not move through Flow stages — the Outcomes inside them do. Completion is computed from the linked Outcomes' Done status, not declared manually. When all linked Outcomes reach Done, the Initiative is computed-complete; the owner confirms with a status change, which closes the rollup.

Field Table

status enum

Phase 14 reconciliation: the original spec had 3 values (active / completed / cancelled). The shipped v7.0 form expands to 5 values to capture in-progress states (planning, paused) and replaces ambiguous completed / cancelled with clearer shipped / abandoned terminology for accountability.

Computed rollup metrics

These are not stored on the Initiative; they are derived from linked Outcomes at read time:

The relationship is many-to-many via the initiative_outcome_links junction table (Phase 14 / CONTEXT.md decision). An Outcome may belong to multiple Initiatives (rare, but supported — e.g. an Outcome that affects both the Telephony Bridge Subsystem and a Compliance Initiative). The original spec proposed a single Outcome.initiative_id FK; the v7.0 form is more flexible and matches the Invariant ↔ Outcome linkage shape from Phase 13.

Link table columns: id, workspace_id (RLS), initiative_id, outcome_id, created_at. Unique on (initiative_id, outcome_id).

This table is the source of truth. Phase 14 derives the Zod schema in @canopy/shared directly from this table.

Examples

Deep example: Howler — Telephony Bridge Subsystem

Howler's voice-AI product depends on a three-part bridge: an inbound bridge that terminates the Twilio / Telnyx connection, a router that decides which agent handles the call, and a conductor that maintains conversation state across multi-turn dialogue. The three pieces were originally tracked as separate Outcomes — HOW-25 (bridge), HOW-26 (router), HOW-28 (conductor) — with no rollup view of "where are we on the bridge subsystem overall." The Weekly Pulse missed the program shape. The audit caught it.

The Initiative record:

Linked Outcomes: HOW-25 (bridge), HOW-26 (router), HOW-28 (conductor).

Why isn't this a Phase? Those three Outcomes belong to a Phase that ALSO contains unrelated work (admin dashboard, billing). The subsystem the three Outcomes together build is the Initiative. The Phase is the time-box of work the Howler clan committed to. The Initiative is the intent that crosses it.

Why isn't this just tags? Tags would filter the Outcome list. The Initiative has a goal, success_criteria, an owner, and rollup metrics. A Howler stakeholder can ask "are we done with the bridge subsystem?" and the Initiative's percent_complete answers. A tag can't.

Audit reference: Howler .tickets/HOW-25-bridge.md, HOW-26-router.md, HOW-28-conductor.md; v7.0 decision in DECISIONS-RESOLVED.md#D-04.

Short examples

• Cortex — Plugin System. Eleven Phases of related work: plugin loader, plugin registry, plugin sandbox, plugin marketplace, plugin permissions, plugin lifecycle, plugin versioning, etc. Goal: "Third-party plugins can extend Cortex without modifying core." Pre-Initiative, the program lived only as a README section; rollup required manually scanning eleven Phase summaries. With the Initiative, the system asks once and the system answers.

• Plain — Analyzer-Pass Program. 37+ Outcomes tracked under one informal program name with no first-class grouping. Goal: "All commits flow through automated analyzer passes before merge." The Initiative gives the program a name, an owner, and computed completion across its 37 Outcomes — instead of "we'll know we're done when nobody opens a new pass Outcome for a while."

• MOIMF — RBAC-001. A four-phase build explicitly programmed as a multi-Phase Initiative, but pre-v7.0 the program metadata lived in a README. Goal: "Workspace roles, project roles, and per-Outcome permissions interoperate without override leaks." The Initiative makes the multi-Phase intent first-class: status, owner, rollup, success criteria — same shape as every other Initiative, instead of bespoke README structure.

Anti-patterns

Anti-pattern: Tracking subsystem work as scattered Outcomes with no rollup

Howler tracked HOW-25 (bridge), HOW-26 (router), HOW-28 (conductor) as independent Outcomes. The Outcomes shipped, but there was no single place to ask "are we done with the bridge subsystem?" The Weekly Pulse reported each Outcome's status separately and the program shape was invisible. Cortex's plugin system had the same shape: eleven Phases of related work, no rollup. Plain's analyzer-pass program: 37+ Outcomes under one informal name with no first-class grouping.

The correct framing: one Initiative ("Telephony Bridge Subsystem"), all related Outcomes link to it, rollup metrics surface progress. The Weekly Pulse now answers the subsystem question, not just the Outcome question.

Anti-pattern: Using a Phase as an Initiative

Cortex's plugin system was sometimes referred to as "Phase 7" — but Phase 7 also contained unrelated work (UI redesign, billing). The Phase boundary didn't match the subsystem boundary, so progress on the plugin system was invisible at the Phase rollup. The reverse error also happens: an Initiative that obviously needs three Phases gets compressed into one, and the Phase miss its time-box because the Initiative's scope was wrong for the time available.

The correct framing: the Phase is the chunk of plan committed to in this milestone cycle. The Initiative is the chunk of intent. They can overlap, but they're different shapes. An Initiative that spans Phases sets spans_phases: true and points at its primary Phase; Outcomes in the Initiative may live in other Phases too.

Anti-pattern: Initiative without a single owner

"The team owns the telephony bridge" defeats the same accountability rule as Outcomes. With shared ownership, nobody is responsible for the rollup; the percent_complete metric is computed but nobody checks it; the Initiative's next_milestone_eta slides because no single person tracks the slide.

The correct framing: one human accountable for the Initiative even when the Outcomes inside it have different individual owners. The Initiative owner is responsible for the program shape; the Outcome owners are responsible for their piece.

Cross-refs

• METHOD.md — Initiative joins the 9 method primitives
• OUTCOMES.md — Outcomes belong to Initiatives optionally; Initiatives roll up Outcomes
• FLOW-AND-SIGNAL.md — Initiative-level metrics appear in the Signal layer
• VOCABULARY.md — preferred terms
• PORTFOLIO.md — clan context for Howler, Cortex, Plain, MOIMF
• docs/methodology/validation/VALIDATION.md — 4-clan audit evidence
• docs/methodology/validation/DECISIONS-RESOLVED.md — D-04 origin decision

Relationship to Phase 14

This doc is the contract Phase 14 (Initiative Primitive) must satisfy. The Field Table is the source of truth for:

• The Zod schema in @canopy/shared/initiative.ts
• The Drizzle table in @canopy/db/schema/initiative.ts
• The tRPC procedures in @canopy/api/router/initiative.ts (CRUD + rollup queries)
• The Initiative detail / list UI in apps/web/app/[workspace]/initiatives/
• The initiative_outcome_links M:M junction table (replaces the original Outcome.initiative_id FK proposal — see the relationship subsection above)

If the methodology field set changes after Phase 14 ships, the change starts here.