A technology can be mathematically proven to work in a simulation while remaining completely unfit for a real-world environment. Conversely, a system may operate successfully in the field for months despite having no formal theoretical documentation. These two states are reconciled by the distinction between functional existence and maturity: one is a matter of "does it work?", while the other is a matter of "under what conditions, and with what repeatability, does it work?".
Consider a deployment of a new hydrogen-sensing array in a residential heating network. The engineering team has a sensor that triggers an alarm when hydrogen is present: a clear "success" in a laboratory. However, when installed in a semi-detached home, the sensor triggers false alarms due to humidity fluctuations and kitchen fumes. The technology works, but its maturity is low. To move from a laboratory curiosity to a marketed product, the team must transition through specific, verifiable stages of validation. This progression is tracked using the technology readiness level (TRL) framework.
The TRL Scale
The TRL framework provides a standardised vocabulary to describe the maturity of a technology, moving from basic scientific research to full operational deployment. While the scale is universal, the specific evidence required to move between levels varies by sector.
| TRL | Phase | Primary Objective | Validation Requirement |
|---|---|---|---|
| 1–3 | Knowledge Development | Concept Validation | Analytical studies and lab-scale proof of concept |
| 4–6 | Technology Development | Functional Validation | Prototyping in relevant or representative environments |
| 7–9 | Business Development | Operational Validation | System qualification and successful real-world operation |
Knowledge Development (TRL 1–3)
The early stages of the TRL scale focus on moving from a theoretical observation to a physical proof of concept. At this stage, the risk is primarily scientific: the team is testing whether the laws of physics or logic support the proposed solution.
- TRL 1: Basic principles are observed. This is the translation of scientific research into applied R&D, often existing only as paper studies.
- TRL 2: The technology concept is formulated. Practical applications are identified, though they remain speculative without experimental proof.
- TRL 3: Active R&D begins. This requires analytical and laboratory studies to physically validate predictions. A proof-of-concept model is typically constructed here to demonstrate the critical function.
Technology Development (TRL 4–6)
Once a concept is proven viable, the focus shifts to integration and environmental fidelity. The goal is to move the technology out of a controlled "perfect" environment and into one that mimics the stresses of the real world.
- TRL 4: Basic validation in a laboratory. This involves integrating basic components to ensure they work together in a low-fidelity environment.
- TRL 5: Validation in a relevant environment. The fidelity increases; components are integrated with realistic supporting elements to simulate the operational environment.
- TRL 6: Demonstration in a representative environment. A high-fidelity prototype is tested in a simulated operational setting. According to the Aerospace Technology Institute, this may involve ground-based tests or flight demonstrations depending on the system's complexity.
For those managing these transitions, understanding the Technical Readiness Framework: What Good Looks Like helps in defining the specific exit criteria for each level.
Business Development (TRL 7–9)
The final stages focus on whether the technology is reliable, compliant, and manufacturable. Many engineering-led projects fail because they mistake a working prototype (TRL 6) for a deployable product (TRL 9).
- TRL 7: Demonstration in an operational environment. The prototype is installed in the actual location of use (e.g., a pilot plant or a specific aircraft) to verify system integration.
- TRL 8: Technology is qualified through test and demonstration. The system is proven to work in its final form under expected conditions. This stage often includes regulatory certification and "flight qualification".
- TRL 9: Actual system proven through successful operations. The technology is deployed in the market, produced at full rate, and qualified through real-world operational experience.
Sector-Specific Adaptations
The TRL scale is a guideline. Different industries apply the same numbers to different milestones. In the pharmaceutical sector, for example, TRL 6 typically corresponds to Phase 1 clinical trials to demonstrate human safety, while TRL 9 is the actual distribution and marketing of the drug.
The EURAXESS documentation highlights that these levels are often self-declared and vary significantly between hardware development and drug discovery.
Strategic Application of TRL
Integrating TRL into project management requires more than just assigning a number; it requires a gap analysis between the current state and the target deployment.
- Define the technology: Establish a precise description of the innovation and its intended application to prevent "scope creep" during validation.
- Evaluate against criteria: Compare current progress against the documented TRL requirements for the specific sector.
- Identify gaps: Determine exactly what evidence is missing to move to the next level (e.g., moving from a lab test to a relevant environment test).
- Document findings: Maintain a rigorous record of experimental results and validation tests to provide an audit trail for investors or regulators.
Limitations of the TRL Model
While TRL is an essential tool for risk management, it has blind spots. It measures technical maturity but ignores commercial and organisational readiness. A project can reach TRL 8 (technically complete) but fail because the business model is unproven or the organisation lacks the capability to support it.
The Software Engineering Institute (SEI) report, An Alternative to Technology Readiness Levels for Non-Developmental Item (NDI) Software, notes that TRLs can "blur" different aspects of readiness into a single number and fail to account for software aging or the criticality of a specific module to the overall system. This is why TRL should be paired with other frameworks, such as the Technical Capability Maturity, Explained model, to assess if the organisation can actually execute the deployment.
Sources
- Technology Readiness Levels (TRL): Guidance on TRL definitions and their application in aerospace.
- Technology Readiness Levels: Comparison of TRL applications in pharma versus hardware.
- An Alternative to Technology Readiness Levels for Non-Developmental Item (NDI) Software: Analysis of the limitations of TRL when applied to software.