Red Nucleus · Innovation · 16 July 2026
The MVP document pack
Four working documents that define, govern and feed the BD Prospecting Tool build — written from the meeting record, verified against the bd_module codebase, and stress-tested by an independent audit before circulation.
✓ Sol-audited, findings applied
✓ Code-verified against the repo
✓ Ready to circulate
The pack
The four documents
Each one is a working file with a version, an owner and a change log — not a slide. The HTML editions are being produced one by one; the markdown source is live today.
✓ Forward-ready01 · v0.2
Requirements
Product Requirements Document
The single numbered definition of what the MVP must do — every requirement traces to a meeting, every gated item cites a recorded decision.
- Every gated requirement cites a decision ID — nothing rests on "we sort of agreed"
- §6b: the honest delta between today's watchlist-only code and the discovery MVP
- §7 maps the MVP onto Yuping's five-layer data-hub architecture
✓ Forward-ready02 · v1.1
Governance
Decision Register
Every project decision with its status, evidence and owner — plus the open questions that still need an answer. Statuses are held to evidence, not optimism.
- Four honest statuses: decided · near-settled · proposed · open
- Audit-corrected: five statuses were downgraded when the evidence didn't hold them
- The D-O list doubles as the chase list for the next round of meetings
✓ Forward-ready03 · v1.1
Discovery
ICP Persona Template
The standard capture sheet each division fills in — so three sessions produce three compatible, machine-encodable profiles the matching engine can actually run.
- Every ★ field carries gate-or-weight, a 1–5 weight, and a missing-data rule
- Anti-profile section captures the lookalikes to exclude — as structured rules
- Worked win / don't-chase examples calibrate the "top-10 smells right" test
✓ Forward-ready04 · v1.3
Data governance
Data Source Registry
The governed list of everything the tool reads — regulatory, financial, news and the BI vendor feed — each with owner, licence posture and status.
- Verified line-by-line against the live collectors in the
bd_module repo
- Team survey responses merged; two responses still being chased
- States plainly what is governance target vs what the code enforces today
4documents
45numbered requirements
49decisions + open items
33governed data sources
3independent audits passed
The red thread
How the pack fits together
Nothing here is free-standing — each document is derived from the record upstream of it and feeds the one downstream.
From the record to requirements
Meeting extracts M00–M05→
Scope synthesis→
Requirements backlog→
PRD v0.2
Six consolidated meetings become the scope authority, the now / gated / later backlog, and finally numbered requirements.
Requirements governed by decisions
PRD v0.2⇄
Decision Register v1.1
Every gated requirement in the PRD cites a D-number; every open D-O item points back at the requirement it blocks.
Fed by discovery and data governance
Division ICP sessions→
ICP Template v1.1→
PRD FR-07 matching
Team survey + code audit→
Source Registry v1.3→
PRD §6 ingestion
The two feeder documents make the PRD executable: profiles the matcher can encode, and sources the pipeline is allowed to read.
