Technology readiness levels provide a common vocabulary for technical maturity, but they do not measure every risk. A prototype may be technically advanced while manufacturing, regulatory, data, business or user readiness remains low.
What matters most
A TRL claim should be supported by the environment, scale and evidence of the completed test.
Starting and target TRLs must be consistent with the action type and project duration.
System integration can be less mature than individual components.
Operational demonstrations should reflect real constraints, not only controlled laboratory conditions.
Commercial readiness, organisational readiness and regulatory readiness need separate assessment.
A defensible TRL table links each claim to reports, test data, prototypes or independent validation.
Questions to answer before acting
Use these questions to turn a broad topic into a defined decision, test or work package:
- What was tested, at what scale and in which environment?
- Was the whole system tested or only a component?
- What evidence supports the claimed starting level?
- Which non-technical readiness dimension could block adoption?
A practical sequence
- Step 1. Define the system boundary.
- Step 2. List completed tests and their environments.
- Step 3. Assign a cautious starting TRL with evidence.
- Step 4. Define target demonstrations and acceptance criteria.
- Step 5. Track technical and non-technical readiness separately.
Common traps
- Using TRL as a sales slogan
- Averaging mature and immature components
- Equating technical validation with market readiness
Where this fits in the wider system
This topic belongs to the site’s EU programmes and funding pathways pillar. The strongest route normally connects several pillars: a research result may need a testbed, a consortium, an appropriate programme, standards work and a scale-up plan.
Use the planning tools to identify the next uncertainty, then verify the route through the official-source directory.