This page is the entry point to our coverage of the subject. The text explains what each device measures, where each one ceases to be reliable, and what we require before we will repeat a readiness report on this site.
A maturity level is a label, not a verdict
The best-known measure is the technology readiness level. The Big Bang Partnership explains that technology readiness levels are a measurement system used in innovation development to assess the maturity of a particular technology, and that the scale was originally developed by NASA in the 1970s to give a common language to everyone with a stake in a development. NASA uses these levels as a measurement system to assess how mature a particular technology is, evaluating each project against the parameters for each level and assigning a rating based on its progress.
The useful part of the scale is not the value. Technical readiness is the discipline the value forces on a proposition. Assigning a technology to a specific level obliges you to identify the environment in which it was tested, the configuration that was tested, and the evidence that the test happened. The Aerospace Technology Institute explains from the funding side that the scale is not a precision tool:
While our primary objective is to advance technology from a Technology Readiness Level (TRL) of 3 to 6, we acknowledge that TRL definitions can be subjective and the scale imprecise. Consequently, we use TRL definitions as a guideline rather than an absolute metric when evaluating projects.
That warning comes from an organisation that uses the scale to decide where public money goes. Follow it as an instruction: The digit guides the questions. IDC reports that the framework gives organisations a common language for assessing technological risk, planning investment and communicating progress between engineering, management and finance, and that funding bodies including UKRI, Innovate UK and Horizon Europe expect applicants to show that the call matches their current and target level. The scale is a shared set of terms for a funding conversation, and it only works when both sides agree on the definitions.
The nine levels and the evidence behind each one
| Level | Evidence the claim rests on |
|---|---|
| 1 | Basic principles observed and reported, with the underlying research published and open to peer review |
| 2 | Concept or application formulated, with feasibility and benefit documented and no experimental proof available |
| 3 | Analytical and experimental proof of concept for a critical function, with laboratory results validating key predictions |
| 4 | Component or breadboard validated in a laboratory, with the relevant environment defined and performance in that environment predicted |
| 5 | Component or breadboard validated in a relevant environment with realistic supporting elements |
| 6 | Prototype system demonstrated in a relevant, high-fidelity environment |
| 7 | Prototype demonstrated in the operational environment and on the operational platform |
| 8 | Final configuration qualified through test and demonstration against all requirements |
| 9 | The system operated successfully in mission or production conditions |
The level definitions above follow NASA's Technology Readiness Levels and the exit criteria published by the NASA Earth Science and Technology Office.
The second of those sources is useful for one structural reason. It publishes separate hardware and software descriptions against the same levels, alongside the exit criteria that move a project from one level to the next. The software description at a given level does not track the hardware description at the same level. A system comprising hardware and software has two maturity histories, so a single value for the whole system hides the weaker of the two.
A readiness assessment provides more detail than a level
A level states maturity. An assessment tests whether the maturity level survives inspection. The GAO Technology Readiness Assessment Guide reports that technologies which are not as mature as recommended have been the source of programme delays and cost increases, and defines an assessment as a means of evaluating the maturity of technologies and whether they are developed enough to be incorporated into a system without too much risk. The same guide sets four characteristics against which a high-quality assessment can be judged: credibility, objectivity, reliability and usefulness. Oversight bodies also use this log to establish whether the fundamental processes behind an assessment were actually followed.
We use those four characteristics as tests for any fact we publish. A readiness assessment is credible when the reader can inspect the evidence. Objectivity exists when the tester is not the one who gains from the outcome. It is reliable when the same test, repeated, produces the same outcome. It is useful when it changes a decision.
Readiness in software and public services
For software and services, readiness depends on published standards and the ability to operate. GOV.UK collates the government technology standards and guidance around the technology code of practice, which is a set of criteria to help government design, build and buy technology. The collated guidance covers accessibility, API standards, application development, buying technology, the cloud first policy, security standards including Cyber Essentials and ISO/IEC 27001, risk management, and the management of legacy technology.
That collection shows why a single maturity score is insufficient for a service. A service can be technically mature and still fail a readiness test on accessibility, on its dependence on legacy platforms, or on its ability to meet the published security standards it is required to follow. Technical readiness consists of four axes: technology maturity, operational readiness, compliance readiness, and organisational readiness. The final check determines if a team is able to find a fault before a user reports it.
A technical readiness report by WireApps is a fixed-scope audit of a codebase and system health that examines architecture and codebase health, infrastructure and deployment, security posture, test coverage and quality assurance, and operational readiness. It also states that the report is an assessment and not an implementation, with remediation scoped as a separate engagement. We agree with both the scope and the separation. Readiness work supports a choice tied to a time, and an assessor who also sells the fix has a reason to find one.
We can check if it is ready.
The smallest unit of readiness evidence we will accept is a file. A log can be checked, contested and expired.
claim: telemetry ingest survives loss of the primary link
configuration: release 4.2.1, single ingest node, retention as configured
environment: staging, network profile mirrored from production
criteria:
- no acknowledged message is lost during failover
- backlog drains inside the agreed recovery window
evidence:
- test run, 2026-04-11, logs retained in the evidence store
- independent review by a second engineer
verifier: named engineer, not the author of the change
expiry: 2026-10-11
Four fields carry the weight. The configuration identifies the tested version, because a readiness report about a system is a report about a version of it. The criteria were agreed before the test, because criteria written afterwards describe whatever happened. The verifier did not run the test, because self-certification is not assessment. The expiry time exists because environments change, dependencies shift and a promise without an expiry is a declaration about the past presented as though it were about the future.
How this page fits the rest of the set
Every page in this set uses one set of terms, so a term defined here has the same meaning wherever else it appears. Each page has a summary of the pages that continue its argument, and every source we cite is entered once in a single list, so a point on one page can be traced from any other. The chrome around the text is generated from that ledger, so a correction applied in one place appears everywhere that text appears. We correct errors in the body, mark when the correction was made and leave it visible. The publication signs its pages, and the writers stand behind what they publish.
Written and maintained by the editorial team of this publication.
Sources
- Technology Readiness Levels - NASA
- Technology Readiness Levels - NASA Earth Science and Technology Office
- Technology Readiness Assessment Guide: Best Practices for Evaluating the Readiness of Technology for Use in Acquisition Programs and Projects | U.S. GAO
- Government technology standards and guidance - GOV.UK
- Technology Readiness Levels (TRL) | Aerospace Technology Institute
- Technology Readiness Levels (TRLs) and How They Fit with IDC's Process
- Technical Readiness Report: What It Covers and When You Need One | WireApps
- What are TRLs? Technology Readiness Levels Explained - The Big Bang Partnership
