A technology readiness level (TRL) is useful in a space funding proposal only when the evidence makes its meaning clear. Name the technology, intended application, configuration, environment and completed result behind the current claim. Keep the target level and future test plan separate. A planned campaign explains how you intend to progress; it is not evidence that progress has already happened.
ESA’s summary uses a scale from 1 to 9 and distinguishes laboratory verification, relevant-environment demonstrations, flight qualification and successful mission operations. Use the definition referenced by the particular call. C-LEO and NSIP describe different starting or target maturity expectations, so a generic TRL label cannot determine call eligibility. Technology Readiness Level C-LEO Call 2: ARTES applicant guide C-LEO Call 3: national applicant guide NSIP Call 3 announcement of opportunity
Which readiness boundaries need explicit evidence?
| Boundary | Evidence question | Common overstatement |
|---|---|---|
| TRL 4: laboratory component / breadboard verification | Which functions were verified, on which item and with what laboratory setup? | Calling a single function test a complete product demonstration. |
| TRL 5–6: relevant-environment work | Why is the environment relevant, and how does the item represent the critical functions? | Calling convenient test conditions representative without justification. |
| TRL 7: performance for the operational environment | What performance was demonstrated, on what model and against what operational context? | Treating a booked demonstration as completed evidence. |
| TRL 8–9: accepted for flight / mission operations | What actual system and acceptance or operational record support the claim? | Transferring heritage to a changed configuration without assessment. |
The boundaries above paraphrase the ESA readiness summary; they are not a new assessment standard. A relevant environment is application-specific. The team should explain its selection and any unrepresented conditions, rather than rely on the environment’s name alone.
Worked example: a maturity ledger for a changed antenna board
Fictional example: an antenna team has a revision A bench prototype and proposes revision B for a host demonstration. The following records illustrate evidence states; they do not report actual measurements or award a TRL.
| Claim / item | Evidence state | Assessment and next action |
|---|---|---|
| Revision A command path | Illustrative available bench record: laboratory setup and firmware A | Supports only the tested command path; systems lead lists untested functions. |
| Revision B timing in host integration | Planned test; procedure and host simulator still to be agreed | Integration lead obtains interface revision and defines the timing boundary. |
| Thermal performance | Gap: no representative-environment result in this scenario | Verification lead defines conditions and facilities with the technical authority. |
| Target maturity at project end | Proposed claim dependent on the completed evidence set | Chief engineer reviews configuration, coverage and residual limitations before endorsing the claim. |
A ledger entry should reference the actual report and its version, not merely say “test passed”. Include the configuration record, measurement or analysis basis, conclusion and limits. If the report contains an anomaly, keep its disposition attached. The workbook provides blank rows for these records and the same clearly labelled antenna example.
What happens when the design changes?
Record the difference between the tested item and the proposed item before reusing evidence. A firmware change may affect timing; a new material may affect thermal response; a connector change may affect the interface. These examples are reasons to investigate applicability, not a universal instruction to rerun every test.
Assign a reviewer to decide which conclusions remain supported and which need new work. Keep the earlier evidence available with its original scope. The configuration guide explains how design intent, built state and tested state can be connected. The verification and validation guide helps distinguish meeting a specified requirement from suitability for the intended use.
How should previous R&D results support follow-on funding?
Separate three statements: what the previous project delivered, what outcome has been observed, and what benefit is forecast. A delivered prototype is an output; a documented customer evaluation is an observed event; future sales remain a forecast. State dates and evidence references for each. This prevents the same activity from being presented as completed technical proof and a future deliverable.
Use the gap between current evidence and intended application to define the next work package. Explain why the proposed work changes a decision: for example, whether a customer can proceed to a representative integration trial. Link that gap to the C-LEO technical proposal or NSIP work plan, and use the UK funding route hub to confirm the relevant process.
Try one work package in Arc
Arc connects requirements, interfaces, risks, verification activities and evidence in a programme model. Arc connected programme model Start with one bid commitment, its proposed evidence and the person responsible for the next decision. Engineers remain responsible for the technical judgement; using a tool does not establish eligibility, compliance or a funding award.
Frequently asked questions
What distinguishes TRL 4, 5 and 6 in ESA’s summary?
The progression moves from laboratory verification of a component or breadboard to critical-function verification in a relevant environment, then a model demonstrating critical functions in that environment. Use the applicable programme definition and document what is representative.
Can a planned test support an achieved TRL?
A planned test supports a proposed development path. An achieved readiness claim needs completed evidence and a reasoned assessment of its scope, configuration, environment and remaining gaps.
Does flight heritage transfer to a modified product?
Assess what changed and whether the previous evidence remains applicable. Hardware, firmware, interfaces and operating conditions can change the scope of a heritage claim. Record the reasoning and further work required.
Evaluate Arc
Connect one bid commitment to its engineering evidence.
Try a work package in Arc: organise its requirements, interfaces, risks, verification work and evidence so your team can review the next decision.