This is the purpose of the Technology Readiness Level, or technology readiness level - TRL. Originally developed for the space sector and now used in many research, development and innovation programmes, the system describes technological development in nine levels, from the observation of basic principles to a market-ready system validated in an operational environment.
For grant-funded projects, the TRL 3-7 range is particularly relevant. This stage covers the transition from experimental proof of the operating principle, through a laboratory prototype and engineering-scale development, to an integrated system operating in a real environment.
However, TRL does not show how innovative a technology is, nor is it simply a measure of what percentage of the development work has been completed. Higher TRLs indicate that the operation of the technology has been validated in increasingly complex forms, in increasingly realistic environments and with increasingly compelling evidence.
The specific meaning of each TRL varies by sector: it will differ for a pharmaceutical development project, a manufacturing technology project or a software project. The underlying logic, however, is similar: the focus of validation gradually shifts from individual components to the full system, while the test environment moves from the laboratory towards actual application.
Below, we illustrate the key characteristics of TRLs 3-7 using two examples that follow the progression throughout.
TRL 3 - proving the operating principle
At TRL 3, the development has moved beyond a purely theoretical concept. Analytical investigations, laboratory measurements, modelling or simulations begin, with the aim of testing the hypotheses and key parameters underlying the technology.
At this stage, the full system is generally not yet tested. The operation of individual critical components may already be demonstrated, but they do not necessarily yet form an integrated prototype.
Example 3/A: A clear example is the development of a so-called reserve battery - an electrochemical energy source that can be activated when needed - whose different TRL stages can be illustrated well. At this level, the developers were still working with small-volume electrochemical systems, testing different electrode materials, electrolyte compositions and micropumps. The aim was not yet to create a final energy source, but to demonstrate experimentally that the concept could be viable on the basis of the key physical and chemical parameters.
Example 3/B: The situation can be similar in software development. Consider a machine-vision-based defect-detection system developed for industrial production lines. At TRL 3, a theoretical description of the algorithm is no longer enough. The critical image-processing or classification solution must be implemented on experimental data and quantitatively evaluated. For example, it can be demonstrated that the solution can identify a specific type of manufacturing defect with adequate sensitivity. This still does not amount to a complete defect-detection system. Data preprocessing, camera integration, data communication and the user interface may still be separate development elements.
The key question at TRL 3 is therefore: can the fundamental operating principle of the technology be supported by experimental evidence?
TRL 4 - when components become a prototype
At TRL 4, the focus shifts from testing individual components in isolation to integrating them.
The main technological elements are integrated and their combined operation is tested under laboratory conditions. This is already a prototype, but its design or scale does not necessarily yet match the eventual application.
Example 4/A: In the reserve-battery development, this stage brought the physical integration of components to the forefront. Using CAD design and 3D printing, the team created different electrode-holder designs that could be tested and modified in rapid development iterations. The experiments also revealed that the originally assumed application direction was not suitable, so the technological concept itself was modified.
This is an important feature of development around TRL 3-4: success does not necessarily mean that every detail of the original idea is confirmed. It is also a meaningful R&D result if measurements show that an assumption must be rejected and an alternative technical direction proves feasible.
Example 4/B: For the defect-detection software in our example, TRL 4 may be reached when the image-processing algorithm, data-preprocessing module, decision logic and initial user interface already operate together in a single alpha prototype. Testing, however, still takes place in a local development environment using controlled datasets.
The difference from TRL 3 is important: there, we demonstrate that a critical solution works; at TRL 4, we must already demonstrate that the system's key elements work together as well.
TRL 5 - the prototype moves closer to the actual application
The transition between TRL 4 and TRL 5 is not always easy to define clearly, because both levels involve prototypes and testing.
The two levels are distinguished primarily by the degree of system integration and the realism of the testing environment.
At TRL 5, the main components are already integrated, and the system configuration increasingly resembles the intended final solution. Testing must also answer how the prototype behaves under conditions that are relevant to its later application.
Example 5/A: For the reserve battery, this meant a significant increase in scale. The previous 100-millilitre design was first scaled up to a one-litre and then a two-litre system, the components were integrated, and several fundamental engineering solutions were also modified. Performance measurements and balance calculations were also completed, allowing conclusions to be drawn about expected operation in the later application.
Example 5/B: In the software example, at this level we would already expect an integrated end-to-end prototype. The defect-detection system no longer merely processes a few prepared images; it communicates with the camera system, handles the required data formats, forwards the results, and operates with interfaces similar to those of the target environment.
At this stage, the test data should also be brought closer to real application conditions. For example, measuring an algorithm on carefully selected image data is not equivalent to testing it under varying lighting conditions, different part positions, noisy images and changing production parameters.
The decisive question at this level is no longer simply whether the prototype works, but whether it also operates reliably under conditions that meaningfully resemble those of the eventual application.
TRL 6 - when laboratory development becomes an engineering system
At TRL 6, the prototype is larger in scale and more mature, while the test environment must closely approximate the actual operational environment. At this point, not only basic scientific and technological functionality but also engineering feasibility becomes a central question.
Example 6/A: In the reserve-battery example, a 10-litre prototype was built and tested in a natural aquatic environment. This immediately raised issues that had not appeared in the laboratory. The conductivity of water with different salinity levels had to be examined, and suitable insulation for underwater electrical connections had to be developed.
This is precisely one of the main purposes of demonstration in a relevant environment: it can reveal problems that remain hidden in a controlled laboratory environment.
Example 6/B: In software, 'scaling up' does not happen in a physical sense, but there is a direct analogue.
For example, a TRL 6 defect-detection prototype should already be tested under data volumes, production speeds and infrastructure close to those expected in operation. Problems may emerge that were not visible in small-scale testing: processing latency, concurrent requests, network failures, memory usage, interface issues, or incompatibilities between different hardware and software components.
Software TRL assessment guidelines describe TRL 6 as involving a highly developed, integrated prototype, testing on realistic problems under expected loads, and developing system and user documentation.
TRL 7 - the technology enters the real operational environment
At TRL 7, we are already dealing with a near-final, integrated prototype system.
The emphasis is no longer simply on simulating relevant conditions: the technology must be demonstrated in an actual operational environment or one that closely approximates it. The system design is largely final, and one of the main objectives of testing is to identify the remaining engineering and integration risks.
Example 7/A: In the case of the reserve battery, the developers again tested it in a natural aquatic environment at this level, but now as an integrated system. The prototype had to operate despite underwater currents, algae, mussels and other environmental factors. The results were recorded continuously and automatically. At this point, the test validated the operation of the complete system.
Example 7/B: In the software example, at TRL 7 the defect-detection system may already operate integrated into the infrastructure of a real or pilot production line. It receives data from real cameras, works together with other systems supporting production, the expected data structures and interfaces are essentially final, and most critical errors have already been eliminated.
This still does not necessarily mean that the product can be placed on the market without restrictions. TRL 7, however, already provides convincing evidence that the technological system itself works in the environment for which it is intended.
A software system's TRL is not the same as its version number
In software projects, a common misunderstanding is to confuse technological maturity with the state of product development.
A 'version 2.0' is not necessarily at a higher TRL than version 1.0. For example, long-established software may receive a new module containing R&D. The existing system may be operating routinely, while the new technological component is still only at proof-of-concept stage.
A similar situation arises with complex platforms. A system may contain several proven components, but if a new module that is critical to operation has a significantly lower technological maturity, the mature environment alone does not raise the new development to a higher TRL.
A detailed TRL assessment methodology therefore recommends that, in systems comprising components with different maturity levels, the lowest relevant technology maturity should also be taken into account when evaluating the system as a whole. The same methodology specifically emphasises that successive software releases and increasing technological maturity are two separate processes.
What matters is not the TRL number, but the evidence supporting it
At TRL 3, we demonstrate the fundamental operating principle. At TRL 4, we integrate the main components. At TRL 5, we bring the prototype and the test environment closer to the intended application. At TRL 6, the technology is tested in a relevant environment and at realistic scale. At TRL 7, the near-final, integrated system must demonstrate that it can meet the requirements placed on it in an actual operational environment.
The most difficult part of determining a TRL is therefore usually not choosing a number between 1 and 9. The real question is what counts as a laboratory, relevant and actual operational environment for the technology in question, and what evidence is sufficient to consider a development stage complete.
It is therefore worth addressing TRL classification already during the technical planning phase of the project. Correctly defined starting and target TRLs also help determine the necessary experiments, prototypes, validation tasks and milestones.
The TRL system is therefore not intended to make radically different developments directly comparable in technological terms. Rather, it provides a common logic for discussing them: are we dealing with an idea or a solution already supported by experimental evidence; are we testing separate components or an integrated prototype; has the technology been demonstrated in a laboratory, in a relevant environment, or under actual operating conditions? This is why, in many fields, general TRL definitions are supplemented by sector-specific guidelines.
For more information or consulting, please fill in our contact form.