Making Decisions

How to identify, frame, and resolve Decisions using the Canopy Method. Reference: METHOD.md for full methodology.

Why Decisions Matter

In AI-augmented work, building is fast. Deciding is slow. The team that makes decisions faster ships faster. The Decision Log exists to make the invisible bottleneck visible.

Most teams lose hours, days, sometimes weeks because:

• A decision needs to be made, but nobody realizes it
• A decision was made, but it wasn't recorded, so it gets re-litigated
• A decision is pending, but nobody knows who should make it
• Multiple decisions are entangled, and nobody has untangled them

The Canopy Method treats every decision as a first-class object: visible, structured, trackable, and linked to the Outcomes it affects.

Identifying Decisions

A Decision exists whenever there is a choice between alternatives that affects how work proceeds.

Signals that a Decision is needed:

• An Outcome is stuck in Define and nobody is working on it
• Two team members have different assumptions about how something should work
• The phrase "it depends" keeps coming up
• Someone says "we should figure out..." or "we need to decide..."
• A build is blocked because the approach isn't clear
• A stakeholder asked a question that doesn't have an obvious answer
• Technology A vs. Technology B
• "Should we include X in scope?"
• "How do we handle edge case Y?"

Common Decision Categories:

• Technology: Which tool, library, service, or platform?
• Architecture: Which pattern, structure, or approach?
• Scope: What's in, what's out, what's deferred?
• Design: How should this look, feel, or behave?
• Business: Pricing, positioning, target audience, partnerships
• Process: How do we work together on this? Who owns what?
• Trade-offs: Speed vs. quality, breadth vs. depth, build vs. buy

Framing a Decision

Every Decision is framed as a question. The question should be:

• Specific enough to have a concrete answer
• Neutral (not leading toward one option)
• Answerable (not philosophical)

Good Decision Questions:

• "Should we use Stripe or Square for payment processing?"
• "Should the booking flow require account creation or allow guest checkout?"
• "Do we build our own scheduling system or integrate with Cal.com?"
• "Should the client portal be a subdomain or a separate domain?"
• "Do we support multiple locations in Phase 1 or defer to Phase 2?"

Bad Decision Questions:

• ❌ "What should we do about payments?" (too vague — what specifically needs deciding?)
• ❌ "Should we use the best payment processor?" (leading — "best" presupposes the answer)
• ❌ "What is the meaning of good UX?" (philosophical, not actionable)

If a question is too vague, decompose it into smaller, specific decisions.

Decision Structure

Every Decision record includes:

Required:

• Question: The choice, framed as a question
• Status: Open → Decided (→ optionally Revisited or Superseded)
• Reversibility: Easy / Moderate / Hard / Permanent

When Decided:

• Decision: What was chosen (one clear statement)
• Rationale: Why this option (the reasoning matters more than the choice)
• Alternatives: What else was considered and why it was rejected
• Decided By: Who made the final call

Optional:

• Review Date: When to reconsider (for evolving situations)
• Linked Outcomes: Which Outcomes this decision affects
• Linked Context: What information informed the choice

Reversibility

Reversibility is the single most important factor in how much time to spend on a decision. The Canopy Method uses four levels:

Examples by Reversibility:

Easy:

• Which CSS framework to use (can swap later)
• Naming conventions (find-and-replace)
• API response format for internal endpoints (versioned, can change)
• Color palette adjustments

Moderate:

• Which cloud provider for hosting (migration is work but doable)
• Database ORM choice (affects patterns throughout, but swappable)
• Auth provider (interfaces are similar, switching is a project but not impossible)
• Pricing tiers (can change, but affects existing customers)

Hard:

• Database engine (PostgreSQL vs. MongoDB — migration is painful)
• Programming language (rewrite is expensive)
• Licensing model (open source vs. proprietary — community expectations)
• Major architectural patterns (monolith vs. microservices)

Permanent:

• Company name and brand
• Published API contracts with external consumers
• Legal agreements and partnerships
• Data that has been shared publicly or with regulators

The Rule:

Spend decision time proportional to reversibility. Fast decisions on easy-to-reverse choices. Thorough deliberation on permanent ones. Most decisions are more reversible than they feel.

The Decision Process

For Easy/Moderate Decisions:

1. Frame the question
2. List 2–3 alternatives (not exhaustive — just the real contenders)
3. Assess reversibility
4. Decide
5. Record the decision with brief rationale
6. Move on

For Hard/Permanent Decisions:

1. Frame the question precisely
2. Identify all relevant Context (constraints, requirements, business rules)
3. List alternatives with pros/cons for each
4. Identify what you'd need to know to be confident (and whether you can learn it)
5. Get input from affected stakeholders
6. Search for precedent (have we or others made similar decisions before?)
7. Assess impact: which Outcomes are blocked by this? What Context changes if we choose each option?
8. Decide
9. Record the full decision with detailed rationale and alternatives
10. Set a review date if the situation may evolve

Decision Patterns

Pattern: "Two-Way Door"

(From Amazon's decision framework) If a decision is easily reversible (a "two-way door"), make it quickly. Don't apply the same deliberation process to every decision regardless of stakes.

Pattern: "Disagree and Commit"

When the team can't reach consensus on a Moderate decision, the designated decision-maker makes the call, records the dissenting view in Alternatives, and everyone commits. The Decision Log preserves the disagreement without blocking progress.

Pattern: "Time-Box the Decision"

For Open decisions that aren't being resolved, set a deadline: "If not decided by Friday, [default option] wins." This prevents indefinite deferral.

Pattern: "Decide to Defer"

Sometimes the right decision is to explicitly defer. Record it: "We are choosing not to decide this now. We will revisit when [trigger]. In the meantime, we will [interim approach]." This is different from ignoring the decision — it's an explicit choice with recorded reasoning.

Pattern: "Supersede, Don't Delete"

When a decision is revisited and changed, don't delete the original. Mark it as Superseded and create a new Decision that references it. The history of why you changed your mind is valuable Context.

Variant: Multi-Alpha Coalition Decisions

Most Canopy clans run one Alpha per repo. But three clans in the v7.0 audit show multi-Alpha repos:

• Jungle runs three Alphas per .brains/ subdirectory (nexus, obsidian, webmaster)
• Pocket spans two repos with shared Alpha identity
• Trellis has three sub-bundles each with their own Alpha

For these coalition repos, the Decision primitive's Decided By field may carry multiple Alphas, and the rationale should document which Alphas are accountable for which dimensions of the choice.

Coalition Decision Anatomy

A coalition Decision is otherwise identical to a single-Alpha Decision. The differences:

• Decided By: may list 2+ Alpha names instead of one
• Rationale: should clarify what each Alpha is accountable for (e.g., "Jungle Nexus owns the routing decision; Jungle Obsidian owns the registry impact")
• Linked Context: may span multiple .brain/ or .clan-alpha/ directories

The "one owner" rule for Outcomes still applies — coalition refers to Decision-making, not Outcome ownership. A coalition Decision may produce multiple Outcomes, each with a single owner from one of the participating Alphas.

Why This Isn't a New Coalition Primitive

Only 3 of 25 audited clans show this pattern. Promoting it to a first-class primitive would bloat the taxonomy for the 22 clans that don't need it. The Decision template already accommodates the variant — multi-value Decided By, multi-Alpha rationale — without structural change.

The pattern is documented (here) so future coalition-shaped clans know it's legitimate. See docs/methodology/validation/DECISIONS-RESOLVED.md#D-11.

Common Mistakes

Cross-refs

• METHOD.md — Decisions are one of the 9 method primitives
• OUTCOMES.md — Decisions block Outcomes
• CONTEXT.md — Context informs Decisions
• VOCABULARY.md — preferred terms
• docs/methodology/validation/DECISIONS-RESOLVED.md — D-11 (multi-Alpha coalition pattern)