Source: frameworks/kit-blueprint/04-blueprint-quality.md

Blueprint — Quality Checklist

Pass threshold: 90 / 100 When to run: After every create or update before sharing with the client.

Structure (15 points)

#	Check	Points
1	All 9 sections present in correct order	3
2	Single-file HTML with embedded CSS — no external dependencies except Google Fonts	3
3	Header has brand name, doc type, title, dates (prepared + updated), subtitle, status badge	3
4	Footer contains company name, advisor name, "Advisory OS," month/year, updated date	3
5	Responsive: collapses to single column at 768px breakpoint	2
6	Print styles render correctly	1

Tone & Language (25 points)

#	Check	Points
7	Zero internal jargon: no "constraint," "CPM," "upstream," "downstream," "GPS," "Mode"	5
8	Zero constraint IDs visible (no C1, C2, etc.)	3
9	Opening frame uses a direct client quote — not paraphrased	3
10	Opening reframe describes observable situation — does NOT tell client their problem	4
11	Build descriptions are clear to someone who doesn't know the internal methodology	3
12	"What We Need From You" items explain WHY without being demanding	3
13	Questions are framed as collaborative ("We'll work through") not interrogative	2
14	Overall tone is warm, direct, professional — not clinical or casual	2

Content Accuracy (20 points)

#	Check	Points
15	Every build in the blueprint exists in the project plan	4
16	Build statuses match the project plan (active/queued/complete)	4
17	"What Changes" outcomes are accurate to what the builds actually deliver	4
18	Current state items are factually accurate and observable	4
19	Target state items match what the builds will produce	4

Build Cards (15 points)

#	Check	Points
20	Every build card has: number, title, description, "What Changes" outcome	4
21	Active builds have navy left border; queued builds are dimmed	3
22	"This Week" / "Week N" tags are accurate to current date	3
23	Review dates ("Your review: [date]") are present and accurate	3
24	No internal-only information leaked into build cards (no source notes, constraint IDs, owner codes)	2

Deploy Chain (5 points)

#	Check	Points
25	Deploy chain shows exactly 8 steps	2
26	Role colors are labeled with names (not internal codes)	2
27	Explanatory note tells client what THEIR role is in the process	1

Prework & Questions (10 points)

#	Check	Points
28	"Still Needed" items have both what + why	3
29	"Received" items are in compressed green format with acknowledgment	2
30	Open questions include context for what needs to be decided	3
31	Resolved questions show the answer inline in compressed format	2

Timeline (10 points)

#	Check	Points
32	Timeline covers the full initiative from start to completion	3
33	Dot colors are correct: green (complete), navy (current), gray (future)	3
34	Client's review dates and action items are called out	2
35	Timeline entries match build card information	2

Common Failure Modes

Failure	What Happens	How to Fix
Jargon leak	"This addresses the upstream constraint" appears in a build description	Rewrite: "This gives your team [specific outcome]"
Problem-telling	"Your process is broken" in the opening frame	Rewrite: "Your team currently [observable fact]"
Blueprint-plan mismatch	Blueprint shows Build 3 as active but project plan has it queued	Sync statuses from project plan
Missing "What Changes"	Build card has description but no outcome block	Add green-accented outcome: what specifically changes for the client
Stale prework	Client provided something but "Still Needed" wasn't updated	Move to "Received" section
Over-explanation	Three paragraphs explaining a build when one sentence would do	Trim to essential: what it is, what it does, what changes
Internal detail leak	Stakeholder names the client doesn't know, or advisor notes content	Remove anything the client wouldn't recognize or understand