Research-to-product workflow

1. Research and formalise

Start from papers, standards, official documentation, source code, tests, and explicit project hypotheses. Preserve provenance and distinguish sourced statements from inference. Convert important mechanisms into definitions, invariants, state machines, histories, or other models precise enough to challenge.

2. Make the claim executable or checkable

Use deterministic tests, model checking, formal verification, property tests, simulation, or executable specimens where appropriate. The goal is not to replace implementation with a toy model; it is to expose assumptions and produce a reproducible correctness surface before performance work hides mistakes.

3. Implement behind an explicit boundary

Production code should preserve the contract proved or tested at earlier stages. Shared infrastructure is preferred when it reduces duplication, but research programmes are not forced into one executable when their product boundaries differ.

4. Measure the real system

Benchmarks, traces, crash testing, cache/coherence measurements, compatibility tests, and regression gates determine whether the implementation delivers the intended value. Expected benefits remain hypotheses until this stage produces evidence.

5. Transfer evidence into capability and product claims

Only validated behaviour should be promoted into public capability language. Commercialisation then evaluates differentiation, maintenance, licensing/IP, customer value, time-to-MVP, and portfolio fit rather than assuming every research result should become a standalone product.

The documentation maturity labels expose this promotion boundary to readers.