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.
| Level | General meaning |
|---|---|
| TRL 1 | Basic principles observed |
| TRL 2 | Technology concept formulated |
| TRL 3 | Experimental proof of concept |
| TRL 4 | Technology validated in a laboratory |
| TRL 5 | Technology validated in a relevant environment |
| TRL 6 | Technology demonstrated in a relevant environment |
| TRL 7 | System prototype demonstrated in an operational environment |
| TRL 8 | System complete and qualified |
| TRL 9 | Actual 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.
- Technology Readiness Level 9 (TRL 9)A system proven in its operational environment
- Service Level Agreement (SLA)An agreement about measurable service levels
- Service Level Objective (SLO)A measurable target for service reliability
- ObservabilityUnderstanding a system through the signals it produces