Cross-document findings across the full foundation corpus — contradictions, gaps, and structural issues, ranked by priority.
Foundation document §4 — "Who We're Building For" — is precisely scoped: VC partners and analysts at early-stage funds. The Getting Started PRD lists additional target users including accelerator program managers and operators running internal intake processes. These represent meaningfully different use cases: accelerators evaluate for cohort fit rather than investment, and internal operators are not running VC due diligence workflows.
This may be an intentional expansion, a forward-looking inclusion that got written into a PRD prematurely, or a sign that the product's value proposition is being broadened without a corresponding strategy decision. Any of these is a reasonable explanation — but the explanation doesn't exist in writing anywhere.
The Product Strategy document defines a clear three-phase engineering sequence: Phase 1 delivers Speed and Consistency to establish Trust (the minimum bar for adoption); Phase 2 adds Conflict Detection to create Differentiation; Phase 3 builds Thesis Calibration to create the Moat. This is the most concrete articulation of what gets built in what order and why.
The Road to Launch section in the foundation document lists technical prerequisites and go/no-go conditions but makes no reference to this sequencing. A reader of the foundation document alone — including an engineer scoping launch work — would not know that Phase 1 is the only commitment for launch and that Phases 2 and 3 are post-launch. This is a significant gap: it means the build sequence lives in a supplementary document rather than the source of truth.
Cross-referencing the credit cost table in the Trial Credits PRD against the three-task onboarding checklist in the Getting Started PRD:
NEO welcome interaction → 1–3 credits × 2–3 turns ≈ 4–9 credits
Task 2: Form creation → 5 credits
Task 3: Workflow activation → 5 credits
Task 3: Workflow run with AI → 10 credits
Total: ~24–29 credits consumed by onboarding alone
A user who completes the mandatory onboarding arrives in the product with roughly 70–75 credits remaining out of 100. Whether this is acceptable depends on a deliberate decision about what a "successful" trial looks like. The issue is that this calculation has never been made explicitly. There is no floor on post-onboarding credits, no mention in either PRD of this tradeoff, and no conversion metric that accounts for how much of the trial gets used before a user can freely explore.
The pitch deck's Market slide presents a headline "TAM — VC + Angels" figure combining VC funds and 150,000 active angel investors. Angels are used to inflate the addressable market for an investor audience — but there is no angel-specific pricing tier, no onboarding flow designed for solo investors, no product differentiation for the angel use case, and no credit or workflow pricing calibrated to their deal volume or team size.
The foundation document's beachhead is early-stage VC funds. The tam_growth_stage_analysis.html document explicitly recommends expanding TAM via firm type (multi-stage, PE, family offices, corporate VC) rather than by individual investor type. Angels are not mentioned in that analysis. Including them in the pitch deck TAM without a corresponding product or go-to-market rationale is a credibility risk in a detailed investor conversation.
The foundation document's Road to Launch section states that "sources designated as live at launch are connected with real production coverage — not demo data, not manual lookups." This implies a designated list exists. It does not. §17 lists all 25 authorized data sources without any launch-status designation. The data_source_pricing.html document identifies "biggest budget items to defer until post-launch" in procurement terms, but that is a cost analysis, not a launch-status decision.
The absence of a launch/post-launch split across the 25 sources creates a gap in the go/no-go checklist: there is nothing to check against. It also makes the Road to Launch statement unverifiable, which is a problem both internally (for engineering) and externally (if a technical investor asks which data sources are live).
The Financial Forecast Readiness Plan (37% overall readiness, with red scores on customer acquisition, operating expenses, and balance sheet) is an important internal artifact — it documents exactly what is and isn't modelled. But the foundation document contains no link to it and no mention that a forecast readiness assessment exists. A reader of the foundation document would not know this gap analysis exists, and an engineer or investor who only read the foundation doc might not know how incomplete the financial modelling is.
The tam_growth_stage_analysis.html document reaches a specific, useful conclusion: do not add growth-stage VC (Series B+) as a near-term TAM expansion segment; expand instead via firm type. This recommendation is not surfaced in the foundation document's Market section, not mentioned in Open Questions, and not visible in the pitch deck's market slide rationale. The analysis exists in an appendix that most readers will never see.
The pitch deck's Market slide shows three TAM figures: a conservative early-stage VC figure, a VC + Angels combined figure, and an "Extended TAM — With Adjacent Segments" that adds PE firms, corporate VC, and family offices. This is a standard investor deck technique — show the immediate market, then show the expansion. The risk is that the foundation document's beachhead strategy is the early-stage VC figure, and nothing in the pitch deck makes clear that the adjacent segments require a different product, different pricing, and different go-to-market. A skeptical investor who asks "what's your go-to-market for PE firms?" does not have an answer in any current document.
The foundation document uses anchor IDs like id="s11" for the section displayed as "Section 12" and id="s17" for the section displayed as "Section 18 — Authorized Data Sources." The numeric offset is consistent throughout (anchor ID = displayed number − 1). This does not break any current links, but it creates silent confusion when adding new sections or when cross-document links reference a section number: a link to "#s17" does not obviously point to §17. If sections are ever renumbered — for example, by inserting a new section early in the document — these anchors and all cross-document links that reference them by section number would break.
id="data-sources") for anchors that are referenced externally, since semantic IDs are stable across renumbering.