Source: frameworks/kit-constraint-priority-matrix/02-constraint-priority-matrix-terminology.md
Constraint Priority Matrix — Locked Terminology
Last updated: February 18, 2026 This file is the canonical reference for constraint typing and pattern language. Upload to every project that processes, displays, or references constraints. If terminology in any other file conflicts with this document, this document wins.
Constraint Types
| Type | Emoji | Definition | Example |
|---|
| Upstream | ⬆️ | A root-cause constraint. Solving this reduces or eliminates downstream constraints. These are highest-leverage. | No standardized month-end close process — causes late financials, reactive firefighting, founder as bottleneck |
| Downstream | ⬇️ | A symptom constraint. Caused by one or more upstream constraints. May self-resolve as upstream constraints are solved. Do not solve directly unless upstream is blocked. | Founder pulled into every review cycle (caused by no process owner upstream) |
Constraint Type Modifiers
Modifiers are applied alongside the Upstream/Downstream type to provide additional diagnostic precision. A constraint is always typed Upstream or Downstream first, then modified if applicable.
| Modifier | Emoji | Definition | When to Apply |
|---|
| Behavioral | 🧠 | The constraint is a pattern of human behavior — not a missing system, tool, or process. Behavioral constraints operate independently of whether a system exists. They require a different kind of solve: protocol + accountability + identity shift, not just system design. A behavioral constraint may be upstream (the behavior causes downstream symptoms) or downstream (the behavior is caused by a missing system). | The constraint describes what someone does (or doesn't do) rather than what doesn't exist. Examples: rescue pattern, avoidance behavior, identity-driven overwork, delegation resistance. |
Why this matters: A system constraint and a behavioral constraint can both be upstream of the same downstream symptoms — through different mechanisms. If you only diagnose the system gap, you build infrastructure that the behavior overrides. If you only diagnose the behavior, you ask someone to change without giving them a system to change into. When both are present, they are parallel root causes and typically require a combined solve.
Parallel Root Causes
When two or more upstream constraints feed the same downstream symptoms through different mechanisms (e.g., one structural, one behavioral), they are parallel root causes. This matters for three reasons:
- Solve design: Solving one without the other produces partial resolution. The downstream symptom partially clears but doesn't fully resolve.
- Solve Together testing: Parallel root causes often pass all three Solve Together tests because addressing both in the same window creates a reinforcement loop.
- Initiative structure: A combined initiative that addresses both parallel root causes is more effective than two sequential initiatives, because each solve reinforces the other.
Flag parallel root causes in the Pattern Summary and note them in the rationale for both constraints.
Pattern Flags
| Pattern | Emoji | Definition | When to Flag |
|---|
| Recurring | 🔁 | Same constraint surfaces across multiple sessions or constraint briefs. Not a one-time event — it keeps showing up. | Constraint appears in 2+ sessions or briefs |
| Escalating | 📈 | Constraint is getting worse over time. Each cycle it goes unsolved, the impact grows. NOT "compounding" — use "Escalating." | Evidence of worsening impact across sessions |
| Same Root Cause | 📦 | Multiple constraints trace back to one missing system, capability, or decision. NOT "cluster" — use "Same Root Cause." When the root causes are parallel (one structural, one behavioral), flag both as Same Root Cause and note the parallel mechanism. | 3+ constraints share a single upstream cause (or parallel upstream causes) |
| Solve Together | ↔️ | Two constraints that are NOT in a causal chain (not upstream/downstream of each other) but amplify each other's solve value when addressed together. Must pass ALL THREE tests: (a) Does solving A make the solve for B more effective? (b) Does solving B make the solve for A more effective? (c) Does a shared time window make combined solving create a multiplier that sequential solving wouldn't? NOT "synergy" or "synergistic" — use "Solve Together." | Passes all three tests above |
| Conditional Solve Together | ↔️❓ | Two constraints that appear to pass the Solve Together tests but cannot be fully confirmed because one constraint has Unknown status. The pair is flagged for confirmation once the status gap is resolved. Include a status check question in session prep. | Solve Together tests suggest a pass, but one constraint lacks sufficient data to confirm |
Retired Terms — Do Not Use
| Do Not Use | Use Instead | Why Changed |
|---|
| Synergy / Synergistic | Solve Together ↔️ | Too vague. "Solve Together" is specific and action-oriented. |
| Compounding | Escalating 📈 | "Compounding" implies mathematical growth. "Escalating" matches how constraints actually behave. |
| Cluster | Same Root Cause 📦 | "Cluster" describes proximity. "Same Root Cause" describes the actual relationship. |
Constraint Tiers
| Tier | What It Means | Action |
|---|
| Tier 1 | Highest leverage. Upstream. Solve now. | Active initiative — build and deploy |
| Tier 2 | Important but dependent on Tier 1 progress or secondary in impact. | Queue — build when Tier 1 creates the foundation |
| Tier 3 | Real but downstream. Will partially or fully resolve as upstream systems deploy. | Monitor — track but don't build for directly |
| Tier 4 | Will self-resolve or is too low-leverage to warrant direct effort. | Park — document but take no action |
Constraint Status
| Status | What It Means |
|---|
| Open | Active, unsolved |
| In Progress | Being addressed by a current initiative |
| Monitoring | Expected to resolve as upstream deploys — watching |
| Unknown | Insufficient data to determine current status. Last evidence is stale or absent. Requires a status check before the constraint can be tiered, sequenced, or used in Solve Together testing. |
| Resolved | Solved and holding |
| Resolved — Holding | Solved in a prior cycle, confirmed still resolved |
Unknown Status Rules
- A constraint is Unknown when the most recent evidence is too old to reliably infer current status AND no other data source provides a more recent signal.
- Unknown is not a permanent status. Every Unknown constraint must generate a status check question in session prep. The goal is to resolve it to Open, In Progress, Monitoring, or Resolved within one session.
- Unknown constraints cannot be tiered with confidence. Assign a provisional tier with the rationale "pending status confirmation" and note that the tier may change once status is established.
- Unknown constraints cannot complete Solve Together testing. If a pair involves an Unknown constraint, flag it as Conditional Solve Together (↔️❓) pending status confirmation.
- The absence of evidence is not evidence of a problem. If a constraint was last observed working and simply hasn't been discussed since (e.g., due to a change in session focus), Unknown is the correct status — not Open or Stalled. Do not diagnose from silence.
Usage Rules
- Every project that references constraints must use these exact terms and emoji.
- If a transcript, JSON, or constraint brief uses a retired term, translate it to the correct term before processing.
- Pattern flags are assigned by the Constraint Priority Matrix. Downstream projects (Master Plan, Project Plan, Blueprint, SOP) inherit flags — they do not reassign them.
- Constraint numbers are assigned by the Matrix and are persistent. Once C1 is C1, it stays C1 across all documents for that client.
- When displaying constraints in client-facing documents (Blueprint), strip all typing language (upstream/downstream, tiers, pattern flags). Use the client's own words instead.
- When a constraint carries the 🧠 Behavioral modifier, the "Deployment Approach" field must address the behavioral mechanism — not just the system gap. Protocol, accountability structure, and identity shift are valid deployment elements for behavioral constraints. "Build a system" alone is not sufficient.
- When parallel root causes are identified, note them explicitly in both constraints' rationale and in the Pattern Summary. Do not collapse parallel root causes into a single constraint — they require distinct diagnosis even though they feed the same downstream symptoms.