A prototype answers a question
Research prototypes optimize for learning. They compress assumptions, favor iteration, and make an experiment possible. Product systems must additionally support ownership, failure, security, accessibility, observability, change, and users who did not participate in the research.
Prototype
Question
Evidence
Verified learning
Architecture
Product system
Separate evidence from implementation
- Identify what the experiment actually demonstrated.
- Make unsupported assumptions visible.
- Extract stable domain concepts.
- Redesign boundaries around product responsibilities.
- Validate the riskiest operational path.
Build boundaries around change
Experimental model code, data preparation, orchestration, user workflow, policy, and infrastructure should not become one deployment unit merely because they began in one notebook or repository. Boundaries make evidence replaceable and responsibilities governable.
Readiness is multidimensional
| Dimension | Prototype question | Product question |
|---|---|---|
| Correctness | Does the hypothesis hold? | Does behavior remain dependable? |
| Data | Can the experiment run? | Can data be governed? |
| Interface | Can researchers inspect it? | Can intended users understand it? |
| Operations | Can the team rerun it? | Can the system recover safely? |
The architecture carries the uncertainty
Responsible product architecture does not erase research uncertainty. It locates it, instruments it, and prevents it from silently becoming a product promise. That is how a prototype can seed a system without being mistaken for one.