What we will not claim from a beautiful prototype
A strong interface can make a research question legible. It cannot, by itself, prove deployment readiness, safety or business impact.
A prototype has a particular job: it makes an idea concrete enough to discuss, test and improve. That is already valuable. It does not need to pretend to be a deployed system in order to earn attention.
We therefore separate four kinds of evidence in the lab. A live public experience demonstrates that a product can be accessed and operated in its published form. A prototype demonstrates an interaction or workflow. A concept demonstrates a direction. An internal demo may test an idea that is not yet ready for public use.
We also separate interface evidence from outcome evidence. A seeded scenario can show that a map, assistant or report flow behaves as designed. It cannot prove a reduction in incident time, a clinical outcome, a safety improvement or a return on investment without a properly designed evaluation.
This is especially important for public-sector and healthcare work. The NHS Operations Twin materials are clearly labelled as an independent Simam Digital R&D concept using simulated data. That boundary is not a weakness in the work. It tells a future partner exactly what a governed pilot would still need to establish.
The next research question is how to make evidence boundaries useful at a glance, so that a reader can understand what is real today, what is being tested and what would need to be measured before a larger commitment.
Clear evidence boundaries help partners decide what to fund, test or govern next. They protect trust while allowing a prototype to demonstrate real product and workflow potential.
- - Simam public case studies distinguish live experiences, prototypes, concepts and internal demonstrations.
- - The NHS Operations Twin is an independent Simam Digital R&D concept using simulated data, not an official NHS application or NHS-endorsed service.
- - A useful evidence record states the measurement conditions, data boundary, known limitations and next validation step.