Contents
A research implementation may answer an important scientific question without yet being ready for routine use by other people. Moving it into production requires a clear account of what has been demonstrated, which assumptions still apply and what engineering work surrounds the scientific capability. Preserve the evidence while making the resulting software usable and supportable.
Establish a reproducible baseline
Identify the code version, dependencies, configuration and permitted data needed to reproduce representative results. Record the environment and any manual steps that influence the output. Ask someone beyond the original author to follow the procedure so undocumented assumptions become visible.
Retain expected results and the method used to compare them. Where outputs vary, have the scientific owner define an appropriate tolerance and interpretation. Engineering changes need a baseline that can reveal unintended changes without pretending every valid computation must produce identical bytes.
Separate scientific claims from software behaviour
Document the conditions under which the research result was evaluated and the limits of that evidence. Identify the inputs, populations or operating conditions that have not been assessed. Keep a named scientific reviewer involved when product requirements extend beyond the original work.
Define software acceptance separately: valid input handling, repeatable execution, safe failure and understandable output. Passing those engineering checks does not validate a scientific conclusion. Equally, a promising research result does not establish that the surrounding application can be operated reliably.
Design the workflow around the intended user
Observe how the intended user would prepare inputs, run the analysis and interpret the result. Identify which steps currently rely on the researcher's judgement. Decide what can be explained in the interface and what requires training, review or a restriction on use.
Specify the treatment of incomplete or unsuitable inputs and results outside the supported range. Give users enough context to understand uncertainty and limitations. Avoid hiding an unresolved scientific decision behind a simplified screen or a single confident-looking score.
Create clear boundaries around the research capability
Separate the scientific computation from input preparation, user access, storage and delivery of results where that makes the system easier to verify. Define the interfaces and keep representative tests at those boundaries. This allows changes in the surrounding product to be assessed without casually altering the scientific implementation.
Review resource requirements, execution time and failure recovery using representative workloads. Decide how interrupted or repeated work is handled. Include dependency management and the ability to recreate the deployed environment in the engineering plan.
Resolve use permissions and operating responsibilities
Inventory the code, datasets, models and external services involved. Have the responsible institutional or professional reviewers confirm the permissions and terms relevant to the proposed use. Record unresolved questions before making a commercial commitment; do not infer permission from technical access alone.
Name who maintains the software, investigates failures and reviews changes to scientific behaviour. Agree how issues are escalated between engineering and research specialists. Plan documentation and knowledge transfer so routine support does not depend entirely on the original researcher.
Release within an explicit evidence boundary
Choose a bounded first use with defined users, inputs and acceptance conditions. Gather engineering and scientific review evidence separately, then bring both into the release decision. Identify limitations that must remain visible and the conditions that would require pausing use or reassessing the product.
Review actual operation against the assumptions made during development. Keep changes to models, data preparation and interpretation traceable. The transition is complete only for the scope that has been verified and assigned ongoing ownership; future uses need their own assessment.
A transition example: a research analysis becomes a supported service
Imagine a fictional research script that processes laboratory measurements after a researcher manually cleans the input. Preserve a baseline: code revision, dependency versions, permitted fixture, preparation steps, expected outputs and a tolerance defined by the scientific owner. An authorised colleague reproduces it in a recorded environment. Variability must be explained, not hidden by asserting byte-for-byte identity where that is inappropriate.
The product transition adds explicit input validation, a supported preparation workflow, access controls, queued execution, recoverable failure and an explanation of the output’s limits. Test missing units, an unsupported instrument format, interrupted execution and repeated submission. Keep the scientific computation behind a clear interface so surrounding engineering changes can be checked against the baseline.
Maintain two acceptance records: scientific validity for the stated conditions, reviewed by qualified domain owners; and software behaviour and operation, reviewed by engineering and product owners. A passing deployment test does not validate the scientific claim. UKRI’s open-research guidance supports transparency and reproducibility while recognising restrictions. Confirm the actual permissions and award terms before distributing code, inputs or results, and assign maintenance beyond the original researcher.
How this relates to Veda Software’s work
Encounter illustrates expert knowledge becoming a managed customer and operational workflow. This is adjacent product-transition evidence, not a research validation, laboratory implementation or claim that Veda created underlying science.