Constraint Priority Matrix — Input Context
Last updated: February 18, 2026 This file defines what the Constraint Priority Matrix accepts, how to validate each input, and what to do when inputs conflict. It covers only CPM-relevant inputs — for the full document system input manifest, see the master-plan-system project.
Advisor Defaults
Apply to all matrix outputs unless overridden:
| Field | Default Value |
|---|---|
| Advisor name | Kathryn Brown |
| Brand | Advisory OS |
Input 1: Constraint Brief
Source: Client-submitted after running their Constraint Identifier (typically weekly, arrives Friday).
What it provides: The client's self-reported pain in their own words. This is what the client thinks the problem is. The matrix may agree, reclassify, or identify upstream causes the client didn't see.
| Field | Priority | Description |
|---|---|---|
| Constraint description | Required | What the client says is blocking them |
| Context | Recommended | When it happens, how often, what it affects |
| Severity / urgency | Optional | Client's own assessment of how pressing this is |
Validation Rules
- Every constraint needs enough description to categorize and type. If too vague, flag for advisor clarification before processing.
- Client language is preserved for the "Client's Words" field on each constraint entry. Never rewrite what the client said.
- Constraint briefs are the starting point, not the final word. The matrix may reclassify, split, merge, or identify upstream causes the brief didn't surface.
Input 2: Session Transcript
Source: Full conversation text from advisor-client sessions (from Otter or equivalent, after Monday session).
What it provides: Recurrence patterns, upstream/downstream evidence, context that makes accurate typing possible. Constraint briefs tell you WHAT. Transcripts tell you WHY.
| Field | Priority | Description |
|---|---|---|
| Full session text | Required | Complete transcript, not a summary |
| Session date | Required | When the session occurred |
| Participants | Recommended | Who was on the call |
Validation Rules
- Transcripts are read for evidence, not treated as structured data. The matrix extracts what it needs.
- Quotes pulled from transcripts must be verbatim — never paraphrase.
- Speaker attribution matters. If the transcript garbles names, flag it.
- Constraint mentions in transcripts are evidence for typing and pattern detection. They do NOT automatically become constraint entries — the matrix decides what's a constraint.
Input 3: JSON Session File
Source: Structured data parsed from each transcript by the Relay agent.
What it provides: GPS signals, quotes, actions, constraint mentions, recommendations, wins. These accelerate processing and ensure nothing from the session is missed.
| Field | Priority | Description |
|---|---|---|
| conversation.date | Required | Session date |
| conversation.type | Required | Meeting type |
| conversation.summary | Required | Brief session summary |
| conversation.outcomes | Required | Key outcomes/decisions |
| conversation.fullRecap | Recommended | Full narrative recap |
| wins[] | Optional | Client wins surfaced in session |
| actions[] | Required | Action items with ownership (mine/client/team) |
| quotes[] | Recommended | Exact client quotes with context and speaker |
| gpsSignals | Recommended | Position, direction, speed signals (any field may be null) |
| seeds[] | Optional | Products/services discussed |
| constraintMentions[] | Optional | Constraint breadcrumbs (NOT source of truth) |
| recommendations[] | Recommended | Advisor recommendations |
Validation Rules
- conversation.date, type, summary, outcomes — all four required or reject the extraction.
- actions must have owner field (mine/client/team) — flag if missing.
- quotes must be verbatim — never paraphrase, even if they seem incomplete.
- gpsSignals may have null fields — process what's present, ignore nulls.
- constraintMentions are breadcrumbs ONLY — they inform pattern detection but do NOT automatically become constraint entries.
Input 4: Group Session Data
Source: Transcripts, chat logs, or summaries from group coaching sessions (e.g., TPC Momentum Monday) where the client participates.
What it provides: Peer-facing signals that often differ from 1:1 advisor sessions. Clients say different things to peers than they say to their advisor. Group sessions surface: stated annual goals and vision language, behavioral patterns (accountability commitments, reported wins and failures), honest self-assessment under peer observation, and real-time constraint evidence the client may not raise in 1:1 settings.
| Field | Priority | Description |
|---|---|---|
| Session chat log or transcript | Required | The client's contributions — not the full group transcript unless needed for context |
| Session date | Required | When the session occurred |
| Session topic/prompt | Recommended | What the group was asked to discuss — provides context for the client's responses |
| Vision or goal statements | Recommended | Any "2026 is the year ___" or equivalent vision work the client completed |
Validation Rules
- Group session data is evidence, not structured input. The matrix extracts what it needs.
- Client language from group sessions carries the same "Client's Words" weight as 1:1 transcripts. If the client states a goal in a group setting, that language is valid for GPS Direction.
- Vision and goal statements from group sessions are high-priority GPS Direction inputs. If the client has done vision work (e.g., "2026 is the year ___", 18-month vision exercises), those statements should be surfaced to the advisor for Direction confirmation in Process 1. Do not build Direction from inference when the client has stated it directly.
- Group data may contain signals about other clients. Extract only the target client's contributions. Do not cross-contaminate.
- Accountability commitments made in group sessions (e.g., "no rescuing for two weeks") are evidence of in-progress constraint work. Flag these for status updates.
Input 5: Client's Stated Goal or Vision
Source: Any document, transcript, or session artifact where the client has stated their goal for the current year, engagement, or planning horizon.
What it provides: The primary anchor for GPS Direction. This is what the client says they want to achieve — in their own words, not the advisor's synthesis.
| Field | Priority | Description |
|---|---|---|
| Goal statement | Required | The client's stated goal in their own language |
| Source | Required | Where this was captured (group session, 1:1, intake form, vision exercise) |
| Date | Required | When the client stated it |
| Advisor confirmation | Recommended | Whether the advisor has validated this as the current Direction anchor |
Validation Rules
- The client's stated goal is the primary Direction anchor. If the client has done vision work, completed a "year of ___" statement, or declared a goal in any setting, that language becomes the GPS Direction. Advisor synthesis of unstated goals is secondary context — it informs the horizon the Direction unlocks, but it is not the Direction itself.
- If the stated goal and the advisor's assessment of the client's needs diverge, flag the tension. Do not silently override the client's own goal with what the advisor thinks the goal should be. The advisor may adjust Direction — but explicitly, not by omission.
- If no stated goal exists, Direction is synthesized from session evidence and flagged as advisor-inferred, not client-stated. This flag carries through to every "Blocks" field that references Direction.
- Stated goals may evolve. The most recent confirmed statement wins. Prior versions are context, not the anchor.
Input 6: Client Master Plan (Mode 2 and Mode 3 Only)
Source: The client's current Client Master Plan, uploaded at the start of each Mode 2 or Mode 3 run.
What it provides: All prior constraint history, GPS trajectory with change markers, themes, conversation recaps, and notes from every prior session. This IS the accumulated history — it replaces re-feeding old transcripts, briefs, and JSONs.
| Field | Priority | Description |
|---|---|---|
| GPS (Position, Direction, Speed) | Required | Current GPS with history markers |
| Constraints Diagnosed | Required | Full constraint list with status, typing, pattern flags |
| Themes | Recommended | Recurring patterns identified across sessions |
| Conversation history | Recommended | Recaps from prior sessions |
| Team roster | Recommended | Client team members and roles |
Validation Rules
- If the Client Master Plan is missing constraints that were in prior matrix outputs, flag the gap. The matrix inherits whatever the Master Plan carries — gaps propagate.
- GPS on the Master Plan is the baseline for comparison. New GPS signals from the current session are compared against it, not against raw prior transcripts.
- Constraint status on the Master Plan is the starting point. The matrix updates status based on new evidence, not from scratch.
Input 7: Project Plan (Mode 3 Only)
Source: The client's current Project Plan, uploaded at the start of each Mode 3 run.
What it provides: The active build sequence — which builds are planned, their order, timelines, deployment chain steps, owners, and which constraints each build resolves. This is the source of truth for what's already in motion.
| Field | Priority | Description |
|---|---|---|
| Initiative name | Required | What the project plan covers |
| Build sequence | Required | Ordered list of builds with names |
| Build timelines | Required | Dates or week numbers for each build |
| Deployment chain | Required | Steps per build (Design / Review / Implement / QC1 / Train / QC2 / Live / Optimize) |
| Constraints resolved per build | Required | Which diagnosed constraints each build addresses |
| Owners | Recommended | Who does what — advisor, client, team members |
| Current status | Recommended | Which build is active and which deployment step it's in |
Validation Rules
- The Project Plan is the source of truth for build sequence and timing. The matrix does not override or re-sequence builds.
- If a constraint in the Project Plan is missing from the Client Master Plan (or vice versa), flag the gap.
- Build status in the Project Plan may be stale if not recently updated. Use session transcript evidence to determine current status.
Input Availability by Mode
| Input | Mode 1 | Mode 2 | Mode 3 |
|---|---|---|---|
| Constraint Brief(s) | All available | Latest only | Latest only |
| Session Transcript(s) | All available | Latest only | Latest only |
| JSON Session File(s) | All available (if they exist) | Latest only | Latest only |
| Group Session Data | All available (if they exist) | All available since last matrix run | All available since last matrix run |
| Client's Stated Goal / Vision | Required if available — see Direction Gate | Confirm current — see Direction Gate | Confirm current — see Direction Gate |
| Client Master Plan | Not available | Required | Required |
| Project Plan | Not available | Not available | Required |
Input Conflict Rules
When inputs disagree:
| Conflict | Resolution |
|---|---|
| Constraint brief says one thing, transcript says another | Transcript wins for typing and evidence. Brief wins for client's own words. |
| JSON extraction conflicts with transcript | Transcript is source of truth. JSON accelerates processing but transcript overrides if they conflict. |
| Client Master Plan conflicts with new session data | New data updates the Master Plan through the matrix — but flag the change, don't silently overwrite. |
| Project Plan conflicts with session evidence on build status | Session evidence wins for current status. Project Plan wins for sequence and timeline unless the advisor explicitly changes it. |
| 1:1 transcript conflicts with group session data | Neither automatically wins. 1:1 is the advisor-observed context; group data is peer-observed context. Flag the discrepancy for advisor review. Clients may present differently in each setting — both signals are valid. |
| Client's stated goal conflicts with advisor's assessment of needs | Flag the tension. Client's stated goal anchors Direction. Advisor may adjust — but explicitly, not by silent override. |
| Advisor manual input conflicts with any of the above | Advisor wins. Always. |
What This File Does NOT Cover
- How matrix outputs get processed into the Client Master Plan (see master-plan-system)
- How Project Plans or Blueprints are created (see project-plan-system)
- Client profile collection, reference data, or engagement tracking (see master-plan-system)
- Deployment methodology or build sequencing (see project-plan-system)