Separate Technical Evidence from Unverified Assumptions
Systematically categorise every technical claim into verified, empirical evidence or unproven operational assumptions. The founder scrutinises architectural hypotheses, scalability claims, latency figures, and security models to expose implicit leaps of faith. This creates a transparent breakdown showing exactly which system features are proven and which remain speculative.
Completing this action isolates real technical validation from wishful thinking and unbacked hypotheses. It ensures the venture-building team focuses development resources solely on proving high-risk, unverified claims.
A two-column risk register categorising every key technical feature as either 'Empirically Validated' or 'Unverified Assumption' with associated risk ratings. The document must highlight any single-point-of-failure assumptions that could undermine system viability.
Five questions an expert would ask when reviewing your output
Use these to challenge assumptions, pressure-test your logic, and check the quality of this action's output in the context of the parent task and wider venture development.
- 1
Which of your core algorithm efficiency claims rest entirely on unvalidated assumptions?
- 2
What empirical proof exists that this system architecture will scale under peak user loads?
- 3
How have you validated that your system integration will function as intended when third-party components fail?
- 4
Why are you treating this simulated lab result as proof of real-world operational capability?
- 5
What unexamined security or data privacy assumptions are embedded in your current technical stack?