This is _bmad-output/planning-artifacts/implementation-readiness-report-2026-09-22.md, the plan this mind was built from, published as it is written with
one change: the owner's name is replaced with "the owner". Every FR, AC, NFR, AR and story tag on this
site links to the place here that defines it.
stepsCompleted: [1, 2, 3, 4, 5, 6] status: complete readiness: READY documentsAssessed:
- _bmad-output/planning-artifacts/prd.md
- _bmad-output/planning-artifacts/architecture.md
- _bmad-output/planning-artifacts/epics.md
- _bmad-output/planning-artifacts/ux-design-specification.md
duplicatesFound: none shardedVersionsFound: none
Implementation Readiness Assessment Report
Date: 2026-09-22 Project: Human42
Document Inventory
All four documents exist as whole documents. No sharded versions, so no duplicate-format conflict to resolve.
| Document | File | Size | Last modified | State |
|---|---|---|---|---|
| PRD | prd.md | 356K | 2026-09-21 23:24 | stepsCompleted through step-12; 163 FRs; tools/check-prd.py passes 9/9 |
| Architecture | architecture.md | 96K | 2026-09-21 23:05 | status: complete, "READY FOR IMPLEMENTATION" |
| Epics & Stories | epics.md | 208K | 2026-09-22 00:07 | stepsCompleted: [1, 2, 3, 4]; 7 epics, 90 stories; tools/check-epics.py passes 18/18 |
| UX Design | ux-design-specification.md | 96K | 2026-09-21 23:24 | workflowComplete: 2026-09-21 plus two recorded post-completion revisions |
No missing documents. All four required types are present.
Supplementary artifacts the four documents depend on
Not discovered by the search patterns, but named as inputs by epics.md and architecture.md and therefore in scope for the assessment:
_bmad-output/design-artifacts/ux-verification-spine.md_bmad-output/design-artifacts/roster-design.md_bmad-output/design-artifacts/agent-examples/{amygdala,daydreamer,sunk-cost}.md_bmad-output/design-artifacts/observatory-mock.html— a running mock Story 2.15 ports rather than reimplementscompliance/README.mdandcompliance/registry.json— the working FR125-FR127 implementation
Context carried into this assessment
The four documents changed materially on 2026-09-21 and 2026-09-22:
- The PRD went 155 -> 163 requirements across four additions: the pairing layer (FR153, FR154), visitor participation (FR155, FR156), the implementer (FR157, FR158) and the prohibited classes with the bar (FR159, FR160).
- Brain regions became modulators rather than scorers; the roster ships whole.
- FR83 moved from Stage 4 to Stage 2; FR8 and FR79a gained build stages.
- An adversarial review of
epics.mdproduced 46 findings, of which 44 were valid. The story count went 71 -> 90 as a result.
Architecture and the UX specification were updated alongside each change, but only where the change was noticed, which is the class of gap this assessment exists to find.
PRD Analysis
Extraction is mechanical, from prd.md at 2026-09-21 23:24, and cross-checked against tools/check-prd.py. The full text of every requirement is in the PRD, which remains the contract; the operative clause of each is already indexed in epics.md's Requirements Inventory, built from this same document. This report records the extraction and its verification rather than reproducing 356K of source, and says so plainly rather than calling a copy a summary.
Functional Requirements
163 requirements. 8 Growth-tagged, 155 in the MVP. Numbered FR1 to FR160 with no gaps, plus three lettered requirements that trace and stage on their own account: FR55a, FR56a, FR79a.
Growth-tagged and outside the MVP build: FR36, FR41, FR53, FR66, FR72, FR86, FR105, FR106.
Non-Functional Requirements
84 rows across 9 categories. The PRD states NFRs as measured rows rather than numbered items; epics.md numbers them NFR-P1 to NFR-V5 so stories can cite them. 83 carry an explicit verification gate, and five carry two, so the class counts sum to 88 rather than 83.
| Category | Rows | Gate class | Count | |
|---|---|---|---|---|
| Performance | 20 | Launch gate (blocks t0) | 12 | |
| Security and Containment | 13 | Per release (blocks a merge) | 45 | |
| Reliability and Durability | 11 | Drill (weekly or quarterly) | 5 | |
| Scalability | 8 | Monitored (reported in the digest) | 26 | |
| Integration | 8 | |||
| Operability and Portability | 7 | Ungated: Reliability's "Loss of the world | ||
| Accessibility | 6 | is the only unacceptable outage" — a posture | ||
| Cost | 6 | rather than a measurement | ||
| Reproducibility and Observability | 5 |
Additional Requirements
- 57 acceptance criteria in the PRD's own appendix, which states that "Downstream stories inherit them."
- 94 parameter rows across 5 tables, which the appendix declares is a build artifact: "the schema for the substrate config file that lives outside the repository's write path."
- 11 user journeys, every requirement tracing to at least one.
- 6 build stages, every MVP requirement staged in exactly one.
- Compliance, technical constraints and integration requirements in Domain-Specific Requirements; platform requirements in Web Application Specific Requirements, including the 28-feature thought vocabulary and the one-file agent contract.
PRD Completeness Assessment
Internally consistent on every check available. Verified mechanically rather than by reading:
| Check | Result |
|---|---|
| FR numbering | FR1-FR160, no gaps, 3 lettered |
| Every FR traces to a journey | pass |
| Every MVP FR has a build stage | pass |
| Every MVP FR is classified t0 or deferred | pass — 93 at t0, 62 following, summing to 155 |
| Dangling FR references | none |
| Dangling AC references | none |
tools/check-prd.py | 9 of 9 pass |
One minor defect found. The Parameters appendix states its own contract — "Columns: the default at launch, the bounds the substrate enforces, and who may change it" — and of 94 rows, **one has no owner in its "Changed by" column: Launch roster**. Defensible in substance, since a launch roster is not a tunable after launch, but it is the appendix failing its own stated rule and it is the only row that does. Recorded rather than fixed here, since this workflow assesses rather than edits.
Traceability into the epics is clean: no requirement exists in the PRD and not in the epics inventory, none exists in the inventory and not in the PRD, and none exists in the PRD without appearing in at least one story.
Epic Coverage Validation
Coverage Statistics
| Total PRD functional requirements | 163 |
| Covered by at least one story | 163 |
| Covered inside an acceptance criterion rather than only in prose | 163 |
| Coverage | 100% |
| Requirements in the epics but not in the PRD | none |
Coverage is asserted by tools/check-epics.py, written during the preceding workflow precisely because no tool had ever read this document. It runs two distinct checks here: that every requirement appears in a story, and that it appears inside that story's acceptance criteria rather than merely in its prose. The second exists because a requirement can be name-dropped in a story title and never actually pinned by a criterion, which an adversarial review found in nine places before the story set was rebuilt.
Missing Requirements
None. No functional requirement in the PRD is absent from the story set.
Requirements carried by more than one story
Sixteen requirements are cited by two or more stories. None is a duplicate or a split responsibility; each is a deliberate seam where one requirement is enforced at more than one point, or built in one epic and surfaced in another. Listed because an assessment that reported only the total would hide them.
| FR | Stories | Why more than one |
|---|---|---|
| FR4 | 3.5, 6.1 | The refusal surface exists in Epic 3; moderation itself goes live in Epic 6 |
| FR8 | 3.5, 6.2 | Held status shown at the box; the held queue built with moderation |
| FR13 | 3.5, 6.4 | The session token is issued at injection; its purge is a retention story |
| FR22 | 4.1, 4.3 | The validator enforces the modulator shape; the roster is what has one |
| FR39 | 4.5, 4.6 | Standing moves on attribution; attribution is its own zero-sum rule |
| FR57 | 3.6, 3.17 | The permalink's content, and the SSR runtime that renders it |
| FR60 | 1.2, 3.9 | The about panel is drafted as a Stage 0 lead-time task and ships in Epic 3 |
| FR61 | 1.2, 6.3, 6.5 | Same: drafted in Stage 0, referenced by the bar, gated at t0 |
| FR71 | 5.12, 5.18 | Named in the verdict story, built by its own |
| FR77 | 3.8, 5.17 | The sponsorship link ships in Epic 3; its money reaches the ledger in Epic 5 |
| FR80 | 5.2, 5.6 | Account creation, and the identity an account owed a share must add |
| FR84 | 5.7, 5.17 | The public aggregate, and sponsorship appearing on it as its own line |
| FR147 | 5.6, 7.2 | Paying in credits now; the payout rail a Growth channel would need |
| FR152 | 2.7, 3.7 | The third terminal state resolves in the ballot; the class is assigned on the page |
| FR159 | 2.12, 3.2, 3.5, 6.1 | Three enforcement points by design — implementation, graduation, intake — plus the refusal variant |
| FR160 | 3.2, 3.5, 6.3 | The bar's refusal surface, and the bar itself |
FR159 is worth reading twice. The requirement states it is "enforced three times, because a text, a decision and a piece of work are three different things", so two of its enforcement points deliberately live four epics before the requirement's own stage. That is a designed inversion rather than a traceability defect, and both affected epics carry it as a note.
Coverage Matrix
163 rows, generated from the documents rather than transcribed. Covered means the requirement is cited inside a story's acceptance criteria.
| FR | Story or stories | Status | |
|---|---|---|---|
| FR1 | 3.5 | covered | |
| FR2 | 2.9 | covered | |
| FR3 | 5.12 | covered | |
| FR4 | 3.5, 6.1 | covered | |
| FR5 | 3.5 | covered | |
| FR6 | 3.5 | covered | |
| FR7 | 3.5 | covered | |
| FR8 | 3.5, 6.2 | covered | |
| FR9 | 3.5 | covered | |
| FR10 | 6.2 | covered | |
| FR11 | 5.3 | covered | |
| FR12 | 6.4 | covered | |
| FR13 | 3.5, 6.4 | covered | |
| FR14 | 2.3 | covered | |
| FR15 | 2.3 | covered | |
| FR16 | 2.3 | covered | |
| FR17 | 2.4 | covered | |
| FR18 | 2.4 | covered | |
| FR19 | 2.5 | covered | |
| FR20 | 2.7 | covered | |
| FR21 | 2.7 | covered | |
| FR22 | 4.1, 4.3 | covered | |
| FR23 | 4.7 | covered | |
| FR24 | 4.7 | covered | |
| FR25 | 4.7 | covered | |
| FR26 | 5.11 | covered | |
| FR27 | 4.4 | covered | |
| FR28 | 2.11 | covered | |
| FR29 | 2.11 | covered | |
| FR30 | 2.16 | covered | |
| FR31 | 2.11 | covered | |
| FR32 | 2.17 | covered | |
| FR33 | 5.10 | covered | |
| FR34 | 5.11 | covered | |
| FR35 | 5.10 | covered | |
| FR36 | 7.1 | covered | Growth |
| FR37 | 2.13 | covered | |
| FR38 | 2.13 | covered | |
| FR39 | 4.5, 4.6 | covered | |
| FR40 | 5.13 | covered | |
| FR41 | 7.3 | covered | Growth |
| FR42 | 4.1 | covered | |
| FR43 | 4.1 | covered | |
| FR44 | 4.2 | covered | |
| FR45 | 4.2 | covered | |
| FR46 | 4.8 | covered | |
| FR47 | 4.4 | covered | |
| FR48 | 4.4 | covered | |
| FR49 | 4.4 | covered | |
| FR50 | 4.8 | covered | |
| FR51 | 4.8 | covered | |
| FR52 | 4.1 | covered | |
| FR53 | 7.4 | covered | Growth |
| FR54 | 3.2 | covered | |
| FR55 | 3.3 | covered | |
| FR55a | 3.1 | covered | |
| FR56 | 3.4 | covered | |
| FR56a | 3.6 | covered | |
| FR57 | 3.17, 3.6 | covered | |
| FR58 | 3.10 | covered | |
| FR59 | 3.1 | covered | |
| FR60 | 1.2, 3.9 | covered | |
| FR61 | 1.2, 6.3, 6.5 | covered | |
| FR62 | 3.9 | covered | |
| FR63 | 3.8 | covered | |
| FR64 | 5.13 | covered | |
| FR65 | 3.6 | covered | |
| FR66 | 7.5 | covered | Growth |
| FR67 | 5.12 | covered | |
| FR68 | 5.12 | covered | |
| FR69 | 5.12 | covered | |
| FR70 | 5.12 | covered | |
| FR71 | 5.12, 5.18 | covered | |
| FR72 | 7.3 | covered | Growth |
| FR73 | 5.1 | covered | |
| FR74 | 5.1 | covered | |
| FR75 | 1.7 | covered | |
| FR76 | 1.7 | covered | |
| FR77 | 3.8, 5.17 | covered | |
| FR78 | 5.2 | covered | |
| FR79 | 5.2 | covered | |
| FR79a | 5.4 | covered | |
| FR80 | 5.2, 5.6 | covered | |
| FR81 | 5.7 | covered | |
| FR82 | 5.1 | covered | |
| FR83 | 3.5 | covered | |
| FR84 | 5.17, 5.7 | covered | |
| FR85 | 5.7 | covered | |
| FR86 | 7.2 | covered | Growth |
| FR87 | 1.10 | covered | |
| FR88 | 1.6 | covered | |
| FR89 | 1.2 | covered | |
| FR90 | 1.4 | covered | |
| FR91 | 1.4 | covered | |
| FR92 | 1.5 | covered | |
| FR93 | 1.5 | covered | |
| FR94 | 2.14 | covered | |
| FR95 | 5.13 | covered | |
| FR96 | 1.10 | covered | |
| FR97 | 6.5 | covered | |
| FR98 | 5.13 | covered | |
| FR99 | 5.13 | covered | |
| FR100 | 1.10 | covered | |
| FR101 | 5.13 | covered | |
| FR102 | 5.14 | covered | |
| FR103 | 1.11 | covered | |
| FR104 | 5.14 | covered | |
| FR105 | 7.5 | covered | Growth |
| FR106 | 7.5 | covered | Growth |
| FR107 | 2.2 | covered | |
| FR108 | 2.10 | covered | |
| FR109 | 2.5 | covered | |
| FR110 | 5.10 | covered | |
| FR111 | 2.5 | covered | |
| FR112 | 4.5 | covered | |
| FR113 | 4.5 | covered | |
| FR114 | 1.11 | covered | |
| FR115 | 1.11 | covered | |
| FR116 | 5.5 | covered | |
| FR117 | 4.8 | covered | |
| FR118 | 5.10 | covered | |
| FR119 | 5.9 | covered | |
| FR120 | 5.14 | covered | |
| FR121 | 4.5 | covered | |
| FR122 | 3.11 | covered | |
| FR123 | 3.5 | covered | |
| FR124 | 3.11 | covered | |
| FR125 | 1.8 | covered | |
| FR126 | 1.8 | covered | |
| FR127 | 1.8 | covered | |
| FR128 | 3.9 | covered | |
| FR129 | 1.9 | covered | |
| FR130 | 4.9 | covered | |
| FR131 | 1.9 | covered | |
| FR132 | 1.8 | covered | |
| FR133 | 1.8 | covered | |
| FR134 | 2.1 | covered | |
| FR135 | 2.1 | covered | |
| FR136 | 2.6 | covered | |
| FR137 | 2.6 | covered | |
| FR138 | 2.7 | covered | |
| FR139 | 2.7 | covered | |
| FR140 | 2.7 | covered | |
| FR141 | 2.8 | covered | |
| FR142 | 2.8 | covered | |
| FR143 | 4.6 | covered | |
| FR144 | 3.2 | covered | |
| FR145 | 3.3 | covered | |
| FR146 | 5.5 | covered | |
| FR147 | 5.6, 7.2 | covered | |
| FR148 | 5.3 | covered | |
| FR149 | 5.3 | covered | |
| FR150 | 5.6 | covered | |
| FR151 | 3.8 | covered | |
| FR152 | 2.7, 3.7 | covered | |
| FR153 | 2.10 | covered | |
| FR154 | 4.9 | covered | |
| FR155 | 5.8 | covered | |
| FR156 | 5.8 | covered | |
| FR157 | 2.12 | covered | |
| FR158 | 2.12 | covered | |
| FR159 | 2.12, 3.2, 3.5, 6.1 | covered | |
| FR160 | 3.2, 3.5, 6.3 | covered |
Assessment
Coverage is complete and is the strongest part of this planning set. It is also, on its own, the weakest possible assurance — 100% functional-requirement coverage was true of the previous story set too, while the verification spine, the live diff stream, the CI topology and nine of thirteen UI components were entirely unbuilt. A requirement map cannot see a deliverable that no requirement names. Steps 4 and 5 are where that is tested.
UX Alignment Assessment
UX Document Status
Found. ux-design-specification.md, 96K, workflowComplete: 2026-09-21, carrying two recorded post-completion revisions. Twelve of fourteen workflow steps produced content; steps 5 and 7 were skipped with reasons in frontmatter. It is unusually load-bearing for a UX document, because the engine repository is private and "the interface is not a window onto the product. It is the product's entire visible body."
UX to Architecture alignment: good
The architecture took its front-end decisions from this document rather than beside it, which is why they agree.
| UX asks | Architecture answers |
|---|---|
| "One state model, two renderers, DOM first" — "five obligations discharged by one build" | SvelteKit chosen so the DOM renderer and the permalink are one codebase; build order inverted deliberately |
| Custom design system, "the substrate's own vocabulary" | sv scaffold with every add-on declined; go-blueprint rejected partly because "scaffolding Tailwind would import exactly the opinion the design spent its length removing" |
| First view under 5 seconds on a reference phone | Svelte over React on that single axis — "roughly 47 KB against React's 156 KB, spent directly against" that gate |
| Canvas 2D with a DOM layer above carrying all text | Adopted; WebGL named as an upgrade threshold |
| One derived breakpoint, no tablet strategy | Deferred to architecture as a measured value |
Alignment Issues
1. The UX specification does not know the roster became two kinds. modulator and scorer appear zero times in it, against 20 and 11 in the PRD. Brain regions became modulators on 2026-09-21, after this document completed. It is not cosmetic: the spec's four-state hue model assumes every bubble can be seated, and a modulator never is — it casts no vote, so it never shows a projection and, at a reveal, it has nothing to snap to. The spec already describes that exact silhouette for a recused author ("its bubble simply does not snap, and that absent snap is how recusal reads"), but a modulator holds it permanently rather than for one vote, and roughly a quarter of the launch roster will be one. Impact: the canvas stories inherit an unstated case. Recommend one paragraph in the spec's visual grammar and an acceptance criterion on Story 3.3.
2. Two documents state opposite rules about agent hue, and a story implements the losing one. The verification spine holds VI-2, Reserved gamut as a per-release check: "Substrate colour is unreachable from any agent value. Asserted as band membership in a perceptual colour space, not as a palette list." The UX specification withdraws exactly that: "That reservation is withdrawn. It contradicts the requirement that a projection is the bubble's own hue, which is precisely an agent painting itself in record colour as a claim." Story 3.16 builds the verification spine. Impact: a per-release check would fail a behaviour the design requires. The UX document is the later and better- reasoned of the two and should win; the spine's VI-2 needs striking or rewriting to assert motion rather than gamut, which is what actually partitions the two voices.
3. The specification contradicts itself on its own evidence base. The mock is described as revised "about thirty times" in Design Direction and "about fifty iterations" in Completion. Minor, but a story briefly depended on the larger figure before it was reworded, and this document opens by insisting its counts are mechanical.
Warnings
Not a conflict, but an open decision that blocks a story. The PRD's Stage 2 prose still reads "committee seating, which lights the 7 to 15 agents on the focused idea and dims the rest", while the UX specification and FR55 both hold that "no bubble greys." These are compatible — dimming is lowered lighting, greying is drained hue, and FR54 itself uses "dimming" — so this is not the contradiction it first appears to be. What is genuinely open is the adjacent question AR-X6 records: whether lit now means focused rather than seated, and whether focus defaults to the largest gathering. Those were the sweep's inferences rather than the owner's decision, and Epic 3 already carries a blocking note requiring confirmation before Story 3.2 is accepted.
Nothing else in the four post-completion PRD additions needs a UX surface. The implementer has no interface. Fit is measured and never displayed, deliberately — it is excluded from the tracked-signal list precisely so it cannot be optimised toward. FR155 and FR156's visitor bubbles and FR159/FR160's refusal variants were folded into the specification on 2026-09-21 and are recorded in its frontmatter.
Assessment
Aligned on everything architectural, with three documentation defects and one open owner decision. Only issue 2 could cause a build failure, and it would surface as a per-release check contradicting a designed behaviour rather than as anything silent.
Epic Quality Review
Validated against create-epics-and-stories standards. Findings are ordered by severity, and the ones that are deliberate deviations are labelled as such rather than excused — the standard is still the standard.
🔴 Critical
C1. Epic 1 is an infrastructure epic, which this standard forbids outright. The red-flag list names "Infrastructure Setup — not user-facing" and "Setup Database" as examples of what an epic must not be. Epic 1, "The substrate holds, before anything thinks", is sixteen stories of event store, broker, certificates, registry, cage, CI runners and hardware, and no human being can see any of it.
Why it stands anyway, recorded so a later reader can overturn it: the PRD makes this a gate rather than a phase — "No agent acts before all five are green. Brainstem before cortex" — and the reason is containment rather than sequencing: "The blast radius of the worst case is hardware the owner is willing to lose." Until the tiers are split, mind-authored and stranger-authored code has nowhere safe to run. Its outcome is also a named Success Criterion (the Month 0 gate) with a named user, and its done-condition is demonstrable rather than a milestone: "a container on the runner tier can reach nothing on the owner's personal network." Splitting it to manufacture user value would invent a delivery the PRD forbids.
This was raised and accepted during epic design. It remains a standards violation and is reported as one.
🟠 Major
M1. Story 3.5 carries twelve functional requirements — four times the median. "The one place a visitor puts something in" holds FR1, FR5, FR6, FR7, FR9, FR13, FR83, FR123, FR159, FR160 and the error-code envelope, across eight Given clauses. It is the injection box, the two substrate statements, rate limiting, intake shedding, the session token, the refusal notice, queue-position status, the copy registry and the eleven error codes. That is not one dev session. It grew to this size when the session token and the error envelope were added to close two gaps, and closing a gap by enlarging a story that was already the largest was the wrong move. Recommendation: split three ways — the injection box and its substrate copy; intake limits, shedding and the session token; the refusal notice and the error envelope. No forward dependency is created by doing so.
M2. Four more stories carry six or five requirements each. Story 5.13 ("Ten minutes on a Sunday") bundles the digest, the status page, incident issues, event-log query, the audit trail, automatic kill and judge sampling — six requirements and seven operator surfaces, of which the digest alone is a week. Story 5.12 bundles five verdict requirements plus the OpenAPI description. Story 2.7 bundles the denominator, the three seat behaviours, the compute wait and the constitutional void. Story 1.8 bundles the registry, its re-fetch, the capability matrix, licence class and commercial ceilings. Recommendation: split 5.13 at minimum. The other three are cohesive enough to defend, but should be sized by whoever picks them up rather than assumed.
🟡 Minor
m1. The starter-template rule is satisfied in two places rather than one. The standard says that where architecture specifies a starter, Epic 1 Story 1 must set it up. The architecture specifies two different answers: the backend takes none (*"go mod init, with the layout drawn from the tier topology"*) and the front end takes a real one (npx sv@0.17.0 create observatory). Story 1.1 does the first. The second is in Story 2.15, because the architecture is explicit that "the front-end scaffold is not needed until Stage 1's throwaway observatory." Deliberate, sourced, and a deviation from the letter of the rule.
m2. Two acceptance criteria still use a subjective predicate, both defensible: Story 3.16's "reads as a sentence in the text view" and Story 2.15's render-grader criterion, which pairs the subjective half with a machine- graded one and explicitly excludes the owner's judgement from being an AC.
Compliance checklist
| Check | Result |
|---|---|
| Epic delivers user value | 6 of 7 — Epic 1 fails, deliberately (C1) |
| Epic can function independently | pass — no epic requires a later one to work |
| No forward dependencies between stories | pass — asserted by check-epics.py |
| Stories appropriately sized | fail — 1 severe (M1), 4 borderline (M2); median is 2 FRs |
| Database tables created when needed | pass — no story creates schema upfront |
| Every story has a user story and Given/When/Then | pass — 90 of 90 |
| Traceability to FRs maintained | pass — 163 of 163 |
| Starter template set up in Epic 1 Story 1 | partial (m1) |
Acceptance criteria quality
421 Then/And lines, 228 of them containing a measurable value (54%). For comparison, the previous story set measured 30 of 298 (10%) when an adversarial reviewer counted it, which is what prompted the rebuild. Only two lines now carry a subjective predicate.
Assessment
Structurally sound, with one accepted violation and one real sizing defect. Nothing here blocks implementation. M1 should be fixed before anyone picks up Story 3.5, because a twelve-requirement story is where scope silently goes missing.
Summary and Recommendations
Overall Readiness Status
✅ READY, with six issues to fix and one decision to take
Nothing found blocks Stage 0 from starting. Two issues should be closed before the stories they affect are picked up, and one open decision blocks a single story in Epic 3.
Findings by severity
| Finding | Where | Action | |
|---|---|---|---|
| 🔴 | Epic 1 is an infrastructure epic, which the standard forbids | Epic quality C1 | Accept. The PRD makes it a containment gate, not a phase. Recorded as a standing violation so it can be overturned rather than forgotten |
| 🟠 | Story 3.5 carries 12 requirements — four times the median | Epic quality M1 | Fix before it is picked up. Split three ways |
| 🟠 | Story 5.13 bundles seven operator surfaces | Epic quality M2 | Fix, or size it explicitly when picked up |
| 🟠 | The verification spine and the UX spec state opposite rules on agent hue | UX alignment 2 | Fix. Strike or rewrite VI-2; the UX document is later and better-reasoned |
| 🟡 | The UX specification never learned the roster became two kinds | UX alignment 1 | Fix: one paragraph plus an AC on Story 3.3 |
| 🟡 | The UX spec contradicts itself on the mock's iteration count | UX alignment 3 | Trivial; pick one |
| 🟡 | One parameter row has no owner in its "Changed by" column | PRD analysis | Trivial; Launch roster |
| ⏸️ | Three UX inferences need the owner's confirmation | UX warnings | Decide. Blocks acceptance of Story 3.2 only |
Critical issues requiring immediate action
None. The single 🔴 is an accepted, documented deviation rather than a defect, and the two 🟠 that matter are story-sizing problems in Epics 3 and 5 — neither of which is reached before Stage 0 and Stage 1 are done.
What this assessment could not tell you
Stated plainly, because the most valuable finding of the preceding workflow was exactly this kind of blindness.
Requirement coverage is 100% and that is nearly worthless on its own. It was also 100% for the story set that preceded this one, while the verification spine, the live diff stream, the CI topology and nine of thirteen UI components were entirely unbuilt. A requirement map cannot see a deliverable that no requirement names. What caught those was an adversarial reviewer with no stake in the work, and then tools/check-epics.py, which now asserts against the architecture's package tree, the UX specification's components and the NFR gate classes rather than against requirement numbers alone.
This assessment inherits that limit. It can compare documents against each other; it cannot tell you whether the four of them together describe a system that works. Story sizing is judged from requirement counts and criterion weight, which is a proxy. Whether ninety stories is the right decomposition of this product is not a question any of these checks answers.
Recommended next steps
- Split Story 3.5 before Epic 3 begins. Twelve requirements in one story is where scope goes missing quietly.
- Resolve the gamut conflict. The verification spine's VI-2 asserts a reserved gamut the UX specification explicitly withdrew; Story 3.16 builds the spine, so a per-release check would fail a behaviour the design requires.
- Confirm or overturn the three UX inferences (AR-X6) before Story 3.2 is accepted. Overturning changes its acceptance criteria and a PRD sentence together.
- Teach the UX specification about modulators — one paragraph, plus an acceptance criterion on Story 3.3 for the bubble that never snaps.
- Split Story 5.13, or size it deliberately when it is picked up.
- Begin Stage 0. Nothing above touches Epic 1, and its checkpoint is the one gate the PRD says nothing proceeds without.
Final note
This assessment identified 8 issues across 3 categories — one accepted standards violation, two story-sizing defects, four documentation defects, and one open owner decision. None blocks implementation starting. Two should be closed before the epics they sit in are reached.
The planning set is in unusually good shape for a reason worth naming: it was attacked by something that had no stake in it, and the things that attack found are now asserted by two checkers that will outlive the session that wrote them. tools/check-prd.py holds nine invariants over the PRD; tools/check-epics.py holds eighteen over the breakdown, including the four sources a requirement map cannot see. Both pass.
Assessed: 2026-09-22 · Assessor: implementation-readiness workflow, Human42 · Documents: prd.md, architecture.md, epics.md, ux-design-specification.md
Addendum — 2026-09-22: four documentation defects closed
Fixed after the assessment, in the order the report recommended. The two story-sizing defects (M1, M2) and the open owner decision are not closed and remain the outstanding work.
UX alignment 2 — the gamut conflict. Closed. ux-verification-spine.md's VI-2 was rewritten from "Reserved gamut" to "Reserved application, not reserved gamut", with the original text and the reason for the change recorded in place. It now asserts who applied a hue, never which hue it is: an agent may project any hue including one inside the stance ramp, the validator rejects a file declaring a stance colour, an outcome colour or a ramp, and every substrate-drawn hue is applied to a whole gathering in one frame by a paint context that exposes no way for an agent value to reach it. The one band that remains a band is the agent identity floor at chroma >= 0.10, which is a floor on agents rather than a reservation for the substrate. A per-release check would no longer fail a behaviour the design requires.
UX alignment 1 — modulators. Closed. The UX specification's colour system gained a paragraph: a modulator holds a size, a hue and a shimmer, is never seated, never projects, and at a reveal has nothing to reveal, so it lives permanently in the first state of hue. It is the silhouette the document already described for a recused author, held always rather than for one vote. Explicitly not marked as a modulator, because that would be a fifth channel and because a reader who notices it never snapping has learned something true. Story 3.3 gained the matching acceptance criterion.
UX alignment 3 — the mock's iteration count. Closed. The specification said "about thirty times" in Design Direction and "about fifty iterations" in Completion. Harmonised to fifty, with the disagreement recorded in frontmatter rather than silently resolved.
PRD analysis — the unowned parameter. Closed. Launch roster now names Owner in its "Changed by" column, so all 94 parameter rows satisfy the appendix's own stated contract. (Repaired on a second pass: the first edit produced a five-column row, which the column-count check caught.)
Still open after this addendum: M1 (split Story 3.5), M2 (split Story 5.13), and the three UX inferences awaiting the owner's confirmation. C1 stands as an accepted violation.
Addendum 2 — 2026-09-22: both sizing defects closed
M1 — Story 3.5. Closed, split three ways. It owned ten requirements against a median of two. Now:
- 3.5 The one place a visitor puts something in — the box, its two substrate statements, and the copy registry that no self-change may edit (FR1, FR5, FR83, FR123)
- 3.6 Who is speaking, how often, and what happens when there is too much — the HMAC session token, per-session and per-address limits, intake shedding, and injected-thought status (FR6, FR9, FR13)
- 3.7 Nothing fails silently — the eleven error codes and the refusal notice with its variant list open (FR7)
M2 — Story 5.13. Closed, split two ways.
- 5.13 Ten minutes on a Sunday — the weekly digest and the status page, generated from the same substrate numbers so no two views disagree (FR101)
- 5.14 The surfaces you reach when the Sunday was not normal — incident issues, event-log query, the audit trail, automatic kill, and judge sampling (FR64, FR95, FR98, FR99, FR40)
Epic 3 went 17 to 19 stories and Epic 5 18 to 19, with everything after each split renumbered. 93 stories. No duplicate identifiers, every epic contiguous from .1, and no story depending on a later one.
Sizing after the splits
Measured as requirements a story owns — its epic matches the requirement's build stage — rather than requirements it merely names, since a story that cites a later epic's requirement to say when something arrives does not implement it.
| Before | After | |
|---|---|---|
| Largest story | 10 owned (3.5) | 6 owned (5.12) |
| Stories owning 5 or more | 5 | 4 |
| Median | 2 | 2 |
| Mean | — | 1.8 |
The four remaining at five or six are cohesive rather than bundled: 5.12 is the verdict path, 5.14 is the operator's abnormal-week surfaces, 2.7 is one vote's resolution, 1.8 is one registry. Each should still be sized by whoever picks it up rather than assumed, but none is the kind of story where scope goes missing.
Status after both addenda: all six fixable issues closed. What remains is the one accepted violation (C1, Epic 1 as an infrastructure epic) and the one open owner decision (the three UX inferences blocking acceptance of Story 3.2).
Addendum 3 — 2026-09-22: the last open decision, taken
The three UX inferences are confirmed as documented, so AR-X6 is closed and Story 3.2 is unblocked. Greying the unseated remainder is retired; lit means focused rather than seated; focus defaults to the largest gathering.
The middle one was queried rather than recorded, because the owner's phrasing was "lit means focused or seated" while every document says lighting follows focus rather than seating. The difference is not editorial. With 5 to 10 votes live at once and committees of 7 to 15, lighting every seat takes the lit and fully animating count from 7-15 to 35-150, which reopens two frame-rate requirements written against one lit committee — including NFR-C5's "seating holds the lit, fully animating count at 7 to 15 however far the roster grows, so a larger roster costs more in the dimmed field and nothing in the committee." Confirmed as focused-only, so no requirement, NFR or parameter moves.
Story 3.2 now states the rule and the reason together, and names the third state explicitly: a seated agent on an unfocused idea is gathered rather than lit — drawn to its idea and shimmering, showing no vote colour.
Assessment status: closed
| Fixable issues found | 6 |
| Fixable issues closed | 6 |
| Open owner decisions | 0 |
| Accepted standing violations | 1 — C1, Epic 1 as an infrastructure epic |
Nothing is outstanding but the one deviation that was accepted on the record.