Every proposal promises TRL advancement. Few budget for what it really involves. Having made this journey with research code many times, here is our honest accounting.
TRL 4 → 5: the rewrite nobody wants to admit
Research code optimises for the paper deadline. Reaching a "relevant environment" means dependency pinning, deterministic builds, tests, error handling for inputs the authors never imagined, and usually a partial rewrite. Rule of thumb: as much engineering effort as produced the original prototype.
TRL 5 → 6: integration is the project
Your component now meets the other partners' components. Interface contracts, message schemas, versioning discipline and a shared integration environment with continuous testing are what distinguish consortia that demo on time from those that demo slides. This is why we push for an integration work package with teeth, starting no later than month 6.
TRL 6 → 7: the operational environment fights back
Site networks that block your ports. Cameras mounted where the light is wrong. Users who use the system differently than the requirements said. TRL 7 is reached through deployment rounds, deploy, measure, harden, repeat, not through a single heroic installation. Budget at least two full rounds per pilot site.
TRL 7 → 8: evidence, or it didn't happen
The difference between "we demonstrated it" and TRL 8 is the evidence package: documented KPI results against the pre-registered baseline, reproducible deployment from scratch, operations documentation, and a component set a third party could actually adopt. That package is also the foundation of every exploitation claim in your final review.
Planning a proposal and want this realism in your work-package structure? That's exactly the role we take.