What Is the Technical Readiness Level (TRL) Scale?
The Technical Readiness Level scale is a nine-point measurement framework for assessing how mature a technology is, from a raw scientific concept to a system that has survived operational use in the real world. If you’ve worked in aerospace, defense, or energy, you’ve seen TRL numbers in source selection criteria, program reviews, and budget justifications. If you’ve watched a program slip after claiming a TRL 7 at Milestone B, you’ve seen what happens when the number is optimistic.
This article defines TRL 1 through TRL 9 with grounded examples, traces the scale’s origin at NASA and its formalization by the DoD, explains how TRL gates connect to acquisition milestones, and covers the companion Manufacturing Readiness Level (MRL) framework. The second half addresses something most TRL guides ignore: requirements maturity as a leading indicator of TRL progression, and why TRL assessments disconnected from requirements traceability are a significant source of program risk.
Where the Scale Came From
NASA engineer Stan Sadin developed the TRL concept in 1974 to give program managers a common vocabulary for technology maturity. The original scale had seven levels. NASA expanded it to nine levels by the 1980s, and that nine-point version is the one that has become standard across the global aerospace and defense industry.
The DoD adopted TRL formally in the early 2000s. The Government Accountability Office (GAO) had been documenting the pattern of programs entering system development with immature technologies for years. In response, DoD embedded TRL requirements into the Defense Acquisition System through DoD Instruction 5000.02. The requirement is explicit: technologies in a Major Defense Acquisition Program (MDAP) must demonstrate minimum TRL thresholds at specific acquisition milestones. TRL is not advisory in DoD acquisition — it is a gate.
TRL 1 Through TRL 9: What Each Level Actually Means
TRL 1 — Basic Principles Observed
The lowest level. A researcher identifies a physical phenomenon or scientific principle that could theoretically be exploited. There is no application yet, just a plausible basis for one.
Example: A physics paper demonstrating anomalous thermal conductivity in a new class of ceramic materials. No hardware. No application. The observation is real; everything else is speculation.
TRL 2 — Technology Concept Formulated
Someone translates the basic principle into a potential application concept. Analysis begins, but no experimental validation has occurred.
Example: An engineer at a propulsion lab proposes that the ceramic material from TRL 1 could serve as a thermal protection system for hypersonic vehicles. Analytical models are developed. No test articles exist.
TRL 3 — Analytical and Experimental Critical Function Proof of Concept
Key functions are tested experimentally, often with surrogate materials or highly controlled laboratory conditions. The tests aren’t representative of real operational conditions, but they confirm the core technical concept is physically credible.
Example: Small coupon samples of the ceramic material are tested in an arc jet facility at sub-scale. The material survives thermal loads that approximate a fraction of the hypersonic entry environment. Critical function demonstrated, but nothing close to a flight article.
TRL 4 — Component and Breadboard Validation in Laboratory
Individual components are built and tested in a controlled laboratory environment. The technology works, but the hardware is not representative of a flight or production configuration.
Example: A full-scale panel of the ceramic thermal protection material is fabricated and tested in a high-enthalpy wind tunnel. Mechanical attachment concepts are tested separately. Subsystem performance is validated in the lab.
TRL 5 — Component and Breadboard Validation in Relevant Environment
The technology is tested in an environment that resembles its intended operational setting — not flight, but not purely laboratory either.
Example: The thermal protection panel is integrated onto a test vehicle structure and exposed to combined thermal and mechanical loading in a test facility that replicates re-entry aerothermal conditions. Fidelity increases; surprises often emerge here.
TRL 6 — System/Subsystem Model or Prototype Demonstration in Relevant Environment
A prototype system — closer to the final design than a breadboard — is demonstrated in a relevant environment. This is the critical threshold for DoD Milestone B. Technologies that cannot demonstrate TRL 6 at Milestone B should not enter Engineering and Manufacturing Development (EMD).
Example: The thermal protection system is demonstrated on a representative structural assembly in a high-fidelity aerothermal test facility. Performance meets specification. Integration with adjacent structures is verified.
In energy programs, TRL 6 might look like a solid-oxide fuel cell stack operating at representative temperature, pressure, and fuel-composition conditions with demonstrated efficiency targets — not in a carefully tuned lab setup, but under conditions that approximate actual power generation.
TRL 7 — System Prototype Demonstration in Operational Environment
A prototype is operated in the actual intended environment, typically on a demonstration platform or pathfinder vehicle. This is the threshold for DoD Milestone C, which authorizes low-rate initial production.
Example: The thermal protection system flies on a hypersonic test vehicle. It survives the flight. Post-flight inspection confirms the material behaved as predicted. This is genuinely hard to fake — the operational environment has a way of surfacing failure modes that no test facility anticipates.
In defense electronics, TRL 7 might mean an AESA radar prototype operating on a flight test aircraft under real-world clutter, jamming, and temperature conditions.
TRL 8 — System Complete and Qualified
The technology is fully developed, integrated into its final form, and has completed qualification testing. It is ready for production. The system has been demonstrated to work as specified in its production configuration.
Example: The thermal protection system has completed qualification testing on the production vehicle, including thermal-vacuum, vibration, and acoustic environments. Hardware is production-representative, not prototype. This level typically corresponds to successful completion of system-level testing prior to initial operational capability.
TRL 9 — Actual System Proven in Operational Mission
The technology has been used in actual operations. This is the only TRL level where the operational environment — with its full complexity, user variability, and mission conditions — provides the evidence.
Example: The thermal protection system has flown on multiple operational missions of the fielded hypersonic vehicle. Post-mission inspections confirm sustained performance within design margins. TRL 9 is not granted by a committee; it is earned by operational history.
How TRL Gates Connect to DoD Acquisition Milestones
The DoD acquisition framework uses three major milestones that gate program progression:
Milestone A (entrance into Technology Maturation and Risk Reduction): Technologies don’t have to be mature at Milestone A, but a credible maturation plan must exist. TRL 4–5 is typical at this point for critical technologies.
Milestone B (entrance into Engineering and Manufacturing Development): Critical technologies must demonstrate at least TRL 6. This is a hard requirement for MDAPs. GAO reviews routinely flag programs that attempt to enter EMD with technologies below this threshold, and the data is consistent: programs that do so almost always experience cost growth and schedule delays.
Milestone C (entrance into Production and Deployment): TRL 7 is the minimum for technologies critical to system performance. At this point, the program is authorizing production investment. Unresolved technical maturity at Milestone C translates directly into production line problems and retrofit costs.
The pattern behind this framework: it is dramatically cheaper to retire risk in the technology maturation phase than in EMD, and catastrophically more expensive to discover immaturity after production begins.
Manufacturing Readiness Level (MRL): The Partner Scale You Can’t Ignore
TRL measures whether a technology works. MRL measures whether it can be manufactured at scale, with acceptable yield, cost, and repeatability. A technology can be fully mature at TRL 9 in a laboratory context and simultaneously be a manufacturing disaster.
The MRL scale, formalized by DoD in the Manufacturing Readiness Level Deskbook, also runs from 1 to 10. The mapping to acquisition milestones mirrors TRL:
- MRL 4–5 at Milestone A: Manufacturing concepts are identified; producibility assessments begun.
- MRL 6 at Milestone B: Prototyping processes demonstrated in relevant production environments.
- MRL 7 at Milestone C: Capability to produce the system in a low-rate production environment demonstrated.
- MRL 8–9 during production: Full-rate production capability established and demonstrated.
- MRL 10: Lean production practices in place, continuous improvement demonstrated.
Example of TRL/MRL mismatch: Advanced composite manufacturing for aircraft structures routinely achieves TRL 7 — flight-demonstrated performance — before MRL reaches 6. The material works. The problem is that lay-up processes require skilled labor that doesn’t scale, cure cycle times are economically unacceptable at production volumes, and inspection methods haven’t been validated for production rates. The F-35 program experienced MRL-related production constraints that contributed to unit cost overruns even after the underlying technologies were technically mature.
In energy, silicon carbide power electronics for grid-scale inverters have followed a similar pattern: TRL 7 demonstrated on pilot installations, MRL 5–6 because SiC substrate yield rates and packaging processes weren’t production-viable at the volumes the market required.
Acquisition decisions made on TRL alone, without MRL assessment, are incomplete. DoD’s Better Buying Power initiatives have been explicit on this point.
Requirements Maturity: The Leading Indicator TRL Assessments Miss
TRL is a lagging indicator. It tells you where a technology is today. It doesn’t tell you whether it will advance, or whether the advancement will hold up when the system has to actually meet a validated requirement.
This is where requirements maturity enters the picture — and where a significant, underappreciated risk lives in most programs.
A TRL 6 assessment confirms that a prototype was demonstrated in a relevant environment. What it does not confirm is whether the requirement the prototype was built to satisfy is stable, traceable, and validated. If the requirement was ambiguous, derived from an incorrect parent, or never formally verified against stakeholder needs, then the TRL 6 number is measuring compliance with the wrong target. The technology is mature. The problem definition is not.
This failure mode appears more often than most program managers acknowledge. Technologies advance through TRL gates while the requirements architecture underneath them remains document-heavy, loosely traced, and unaudited. When the system reaches Milestone B and requirements are reviewed rigorously for the first time, the TRL 6 demonstrations have to be reinterpreted against newly clarified requirements — and often don’t hold up.
Requirements maturity has specific measurable dimensions:
- Are all requirements allocated? Unallocated requirements have no owner, no derived children, and no path to verification.
- Is there bidirectional traceability from stakeholder needs through system requirements to component-level verification methods?
- Have requirements been reviewed and formally baselined, or are they still active with pending changes?
- What percentage of requirements have approved verification methods defined?
Graph-based requirements platforms expose this structure in a way that document-based tools cannot. In a platform like Flow Engineering, requirements exist as interconnected nodes in a directed graph. You can see, visually and programmatically, where allocation is missing, where traceability breaks down, and where verification methods haven’t been defined. An engineer assessing TRL can look at the requirements graph and identify whether the technical demonstration was built against a stable, fully-traced requirement or against a placeholder that will change.
This matters practically: Flow Engineering provides the kind of requirements health metrics — allocation completeness, traceability coverage, verification method assignment — that a technology maturation team can use alongside TRL assessments to form a more complete picture of program risk. A technology demonstrating TRL 6 performance against a 95%-traced, fully allocated requirements set is a fundamentally different risk profile than the same TRL 6 demonstration against a requirements set that is 40% allocated and largely unverified.
Practical Starting Points for Using TRL and MRL Together
For program managers entering Milestone B:
Require technology maturation reports that explicitly cross-reference TRL evidence with the specific requirements each demonstration was designed to satisfy. If the demonstration report can’t cite a baselined requirement, the TRL claim is incomplete.
For systems engineers conducting TRL assessments:
Use requirements traceability as a pre-assessment filter. Before evaluating technical evidence, verify that the requirements driving the demonstration are stable, allocated, and have approved verification methods. Flag any TRL assessment where the underlying requirements are in flux.
For acquisition decision authorities:
Ask for TRL and MRL assessments together, not separately. A TRL-only briefing is an incomplete picture. Require that TRL evidence cite the specific verified requirements each demonstration satisfies.
For technology development teams:
Treat requirements maturity as a parallel workstream to technical maturation. A technology that advances from TRL 4 to TRL 5 while its requirements regress in allocation and traceability coverage has not actually reduced program risk — it has shifted it downstream.
Honest Assessment
The TRL scale is a genuinely useful communication tool. It gives program managers, acquisition authorities, and oversight bodies a common language for a real problem: technologies that look mature in isolation fail when integrated into systems and exposed to operational conditions. The DoD formalization of TRL gates at acquisition milestones represents decades of hard evidence about when immature technologies cause program failures.
The limitation is not in the scale itself. It’s in treating TRL as a self-contained assessment. TRL evidence is always evidence of performance against a requirement. If the requirement is wrong, ambiguous, or untraceable, the TRL number carries false confidence. MRL adds the manufacturing dimension that TRL omits. Requirements maturity adds the problem-definition integrity that both TRL and MRL assume but don’t verify.
Programs that use all three — TRL, MRL, and requirements health metrics — have a materially more accurate picture of where their real risks are and when they are actually ready to advance.