Technology Readiness Levels Explained: TRL 1–9 with Real Examples

Munich, 14 September 2026 · Nexuswelt Group

TRL is the coordinate the whole European funding system runs on. It determines which instruments are open to you, how a call topic is scoped, and what an evaluator expects to see as evidence. Get it right and the shortlist of relevant instruments narrows to two or three. Get it wrong and you lose a submission cycle.

The official definitions are one line each, which is why they are hard to apply. Below: the nine levels, what each actually looks like in different sectors, how to evidence a claim, and the mistakes that make an inflated TRL visible to an evaluator.

What TRL is, and what it is not

The Technology Readiness Level scale runs from 1 to 9 and measures the maturity of a technology from basic research to proven operation. It originated at NASA and was adopted by the European Commission as the standard reference for scoping calls and assessing progress. The authoritative definitions for Horizon Europe sit in the General Annexes to the work programme; the NCP network also maintains a TRL self-assessment tool built around them.

Three things it is not, each of which produces a specific error:

• It is not a measure of business maturity. Paying customers do not make you TRL 9 if each deployment is manually configured. Revenue and readiness are different axes.
• It is not a measure of intellectual property. A granted patent does not put you at TRL 4 if no prototype exists.
• It is not comparable across disciplines with any precision. TRL 6 in software and TRL 6 in pharmaceuticals describe very different amounts of remaining work, and the scale is self-declared, which is why evidence matters more than the number.

The nine levels

The same level across four sectors

Abstract definitions are hardest to apply at the boundaries. These are the same levels described in four different kinds of work.

Industrial process technology

TRL 3: the chemical mechanism demonstrated on synthetic feedstock at bench scale. TRL 5: the same process running on a real industrial sidestream, with the upscaling barriers identified. TRL 6: a pilot unit at laboratory or demonstration scale performing close to target. TRL 8: a qualified production line meeting specification.

Software and AI

TRL 3: the algorithm outperforms a baseline on benchmark data. TRL 5: it holds up on the customer’s own messy production data rather than a clean dataset. TRL 7: deployed in a live system with real users and real latency constraints. TRL 9: running in production across multiple customers without manual configuration per deployment.

Software teams frequently overstate here, because a working demonstration feels finished. The question that resolves it: does it still work when the data, the load and the users are not the ones you chose?

Medical technology

TRL 4: the device works on bench models. TRL 5: validated on relevant biological material or in animal models. TRL 7: clinical investigation in the intended setting. TRL 8: regulatory approval obtained. In regulated sectors, TRL 8 is a formal gate rather than a judgement – you either hold the approval or you do not.

Energy and hardware systems

TRL 4: a component validated in the laboratory. TRL 6: a scaled demonstrator on a test site under realistic load. TRL 7: installed and running at a host site with real operational demands. TRL 9: units in commercial service with maintenance and performance records.

Which instruments fund which levels

Always check the topic text. Individual topics state their own expected start and end levels, and those override any general mapping.

How to evidence a TRL claim

The claim is self-declared, so what carries weight is the evidence behind it. A defensible claim has four parts:

1. The level, stated plainly, with the official definition it corresponds to.
2. What has actually been done – the tests, the conditions, the results.
3. What has not been done – the specific gap between where you are and the next level.
4. What the project will do to close it, expressed as work in a work package.

Naming the gap strengthens the claim rather than weakening it. A proposal that describes precisely what remains unproven reads as one written by people who understand their own technology. A proposal with no stated gap reads as one that has not been examined.

Where TRL claims go wrong

• Inflation. Claiming TRL 7 with laboratory data. Evaluators read the evidence and the number together, and the mismatch damages credibility across the whole proposal, not just the technical section.
• Inconsistency across the document. If the technical section says TRL 6 but the work plan spends most of the budget on fundamental development, one of the two is wrong and both are visible.
• Confusing business traction with technology maturity, in either direction. A revenue-generating product can still be at TRL 7 if every installation is bespoke.
• Averaging across components. If the core technology is TRL 4 and the packaging is TRL 8, the system is not TRL 6. Assess the critical path, and state the levels separately where it matters.
• Using an adapted scale without saying so. Some sectors and national agencies use modified versions. If you use one, disclose it and map it explicitly to the standard nine-point scale – project officers work from the official definitions.
• Understating to look safe. It happens less often but costs just as much: a topic expecting TRL 5 to 7 will reject a proposal that positions itself at TRL 3.

A quick self-assessment

Answer honestly, and stop at the first no.

How Nexuswelt works with this

TRL is the first thing to establish and the thing most often established too late. Nexuswelt works with companies and research organisations on positioning against real call topics – instrument selection, role definition and the evidence framing that makes a technical claim defensible to an evaluator. The broader starting point is our guide to EU funding for startups, and more on the firm is on the Nexuswelt about page.

Frequently asked questions