Source: frameworks/kit-blueprint/01-blueprint-context.md
Blueprint — Context & Inputs
Required Inputs
1. Approved Project Plan (Primary Source)
The project plan is the single source of truth. The blueprint DERIVES from the project plan — it never contains information the project plan doesn't have.
| Field | Priority | What Goes Into Blueprint |
|---|
| Build cards | Required | Simplified: name, description, outcome, review date |
| Current vs Target state | Required | Rewritten in client-friendly language |
| Deploy chain | Required | Simplified to show client's role in the process |
| Prework items | Required | "What We Need From You" — still needed + received |
| Timeline | Required | Week-by-week with client's review/action dates |
| Constraint framing | Required | ONE opening quote + reframe (not the full constraint analysis) |
| GPS | Reference only | Informs the opening frame but is NOT shown to client |
2. Client Reference Data
| Field | Priority | Description |
|---|
| Client name | Required | For personalization and header |
| Company name | Required | For branding and footer |
| Team member names | Required | Only those the client would recognize — no internal-only contacts |
3. Latest CPM (Reference Only)
| Field | Priority | Description |
|---|
| Primary constraint quote | Required | The opening quote that grounds the work |
| Constraint reframe | Required | Factual, observable reframe (not diagnosis) |
Content Filtering Rules
The blueprint is derived from the project plan, but NOT everything transfers. This is the filter:
What Goes IN the Blueprint
| Project Plan Section | Blueprint Equivalent | Transformation |
|---|
| Current State vs Target | "Where You Are vs Where We're Going" | Rewrite for client: observable facts, no jargon |
| Build cards | "What We're Building" | Name, description, outcome, review date. Drop: constraint IDs, owner tags, source notes |
| Deploy chain | "How Each Build Gets Deployed" | Show role names (not owner tags). Client sees their review step |
| Prework (Still Needed) | "What We Need From You" | Keep item + why. Drop: build reference codes |
| Prework (Received) | "What We Need From You" (received list) | Compressed acknowledgment |
| Open questions | "Questions We'll Work Through" | Client-facing framing. Drop internal decision context |
| Timeline | Timeline | Simplified. Client sees review dates and what's happening |
What Stays OUT of the Blueprint
| Project Plan Section | Why It's Excluded |
|---|
| Matrix Validation Banner | Internal constraint analysis methodology |
| GPS | Internal advisor tracking |
| Constraints section | Internal classification system |
| Themes section | Internal pattern analysis |
| Stakeholder cards | Internal team management |
| Evidence/quotes | Internal documentation |
| Product constraints | Internal coaching notes |
| Notes | Internal advisor observations |
| Actions | Internal task tracking |
| Build source notes | Internal rationale |
| Constraint IDs (C1, C2) | Internal reference system |
Input Priority Hierarchy
When inputs conflict:
- Reference data wins for names and spellings
- Project plan wins for build content, statuses, and scope
- CPM provides the opening constraint frame only
- Previous blueprint provides continuity for received/resolved items
Tone Rules
These are not optional. They are structural requirements.
- Warm and direct. Not clinical, not casual. Professional respect.
- No internal jargon. No "constraint," "CPM," "deploy chain," "upstream/downstream," "Mode 1/2/3."
- Never tell the client their problem. Frame around observable situations and what the builds address.
- No selling. The client already bought. This is a progress document, not a pitch.
- Factual, not evaluative. "Your team currently tracks hours in spreadsheets" not "Your time tracking process is inefficient."
- Respect intelligence. Don't over-explain. The client knows their business.