Skip to content
Technology and data4 min read

TRL 9 and Production Readiness — What the Evidence Should Show

Understand the nine Technology Readiness Levels, the difference between TRL 8 and TRL 9, and how to assess evidence for a specific software deployment.

Technology Readiness Levels, or TRLs, describe evidence of a technology’s maturity. They can help a buyer or project team distinguish an early concept, a tested prototype and a system demonstrated in operational use.

A readiness level applies to a defined technology and its intended environment. It does not establish that the technology fits every new customer or that integration will be straightforward.

What the nine levels describe

The scale originated in aerospace and is now also used in research and innovation programmes. The wording used by a programme should be checked when a formal assessment is required.

LevelGeneral meaning
TRL 1Basic principles observed
TRL 2Technology concept formulated
TRL 3Experimental proof of concept
TRL 4Technology validated in a laboratory
TRL 5Technology validated in a relevant environment
TRL 6Technology demonstrated in a relevant environment
TRL 7System prototype demonstrated in an operational environment
TRL 8System complete and qualified
TRL 9Actual system proven in its operational environment

The distinction between TRL 8 and TRL 9 concerns evidence of successful operation. It is not a rule that one customer means TRL 8 and several customers mean TRL 9. A required number of months or customers should not be invented as part of the definition.

A prototype answers a different question from production evidence

A proof of concept can show that an idea is technically feasible on a limited dataset. A prototype can explore an interface or integration. Production evidence needs to address the intended operating conditions, including failures, exceptions and support.

Ask what was tested, with which data, under what load and in which environment. A successful demonstration may leave questions about permissions, recovery, performance or unusual inputs unanswered.

These are reasons to define the next validation step. They do not make prototyping inappropriate: reducing uncertainty through a bounded experiment can be valuable before committing to a larger implementation.

Evidence to request from a supplier

  • Scope of the claim: which component or system has the stated readiness level?
  • Operating environment: how closely does the evidence match the planned use?
  • Test records: which normal and exceptional cases were assessed?
  • Operational evidence: what happened during actual use, including incidents and corrective work?
  • Documentation: are configuration, interfaces, responsibilities and known limitations recorded?
  • Remaining work: which integrations, migrations or adaptations still need to be designed?

A familiar product may still need substantial project-specific work. Conversely, a custom application can use established components while its overall behaviour remains subject to development and acceptance testing.

Readiness and investment risk

TRL describes one dimension of technical maturity. A business decision also depends on security, usability, maintainability, cost, legal obligations and adoption. A high readiness level does not demonstrate a positive return on investment or remove delivery risk.

A business case should distinguish verified capabilities from assumptions and identify the work needed to close each gap. See NPV and IRR for ways to examine investment assumptions.

TRL in funding programmes

Some research and innovation calls specify starting or target readiness levels. Use the definitions and eligibility rules in the actual call documents. Programme names alone do not establish whether deployment work or a particular maturity level qualifies for support.

The financing glossary entry explains the broader planning question. A funding application still needs its own assessment; no grant eligibility follows automatically from a supplier’s claimed TRL.

How this relates to QA10 projects

QA10 is a venture studio. Q-Dev develops software to an individually agreed scope, and Q-Journey connects process improvement with subsequent software development. There is no blanket claim here that every QA10 component or new project is already at TRL 9.

Q-Dev projects pass through design, MVP, deployment, then training and the start of maintenance. Each stage has a meeting and an agreed acceptance document. The first six months of maintenance are included in the project price. Dates, acceptance criteria and the work still required are agreed for the individual project.

The practical question is what evidence supports the proposed solution for your use. Contact us with the process and operating conditions you need to support.

GLOSSARY

Terms in this article

Clear explanations of the terms you may want to revisit.

Explore the glossary
Back to the knowledge base

From understanding to action Q-Journey

From business processes to practical change

Explore the path from company AI and an audit to software and ongoing development.