TRL levels
EBRAINS Ready uses the nine-level TRL scale of the Horizon Europe work programme (General Annexes), itself derived from the NASA scale standardised in ISO 16290:2013. It reads that scale through the HBP Technology Readiness Level Assessment guide (Velasco et al., 2020), which tailored it to what a research infrastructure actually ships. The official wording was written for physical systems, so terms like laboratory or operational environment need an explicit reading for software. This page gives it.
One scale, four ladders
Software maturity is not one ladder. An installable library, an operated web service, an infrastructure platform and a hardware system reach the same nine levels by different routes, so each is assessed against its own checklist:
| Track | What it covers | How it climbs |
|---|---|---|
| Software | Libraries, command-line tools, desktop applications | Code, then engineering practice, a release, distribution, then stability, documentation and support |
| Service | Web applications, APIs, data services | Code, then a shared test deployment, production, then monitoring, users and reliability |
| Platform | Third-party software EBRAINS operates | Provisioned, then integrated, operational, monitored, then reliable at scale |
| Hardware | Neuromorphic and HPC platforms | The HBP hardware checklist, level by level |
The conditions for each are on the checklist pages.
A checklist states what a level means. A score could hide a hole: a polished repository that was never deployed would still score well. A checklist cannot: a service is not “demonstrated in an operational environment” without one.
Interpretation of environments
| Term | Services (web / API) | Libraries / CLI |
|---|---|---|
| Laboratory | Developer machines and CI: automated tests, local builds | The project’s own CI |
| Relevant environment | Shared non-production deployment: dev/staging on EBRAINS infrastructure, containerised, behind real auth | The EBRAINS Software Distribution’s build and CI — a merged Spack recipe proves the artifact builds against the platform’s dependency stack |
| Operational environment | Production deployment used by real (beta or public) users on EBRAINS infrastructure | The EBRAINS Lab release — listed in the active environment spec means every Lab user can import it |
For hardware platforms the original ISO/NASA wording applies directly through the HBP hardware checklist.
The nine levels, as stages
| TRL | Official definition (Horizon Europe) | Staged reading |
|---|---|---|
| 1 | Basic principles observed | Onboarding floor — the service is registered and its owner has declared what it is (objectives / description, contact, research backing). Never caps: TRL 1 is the entry level, not a hurdle. |
| 2 | Technology concept formulated | Concept and intended applications/users identified — or, cumulatively, the service is already built (working code is past the concept phase) |
| 3 | Experimental proof of concept | Working, inspectable code (or a reachable service) exists |
| 4 | Technology validated in lab | Engineering/development infrastructure: CI, containerisation, tests |
| 5 | Technology validated in relevant environment | Published release / deployed to a shared non-production environment / provisioned & monitored (per track) |
| 6 | Technology demonstrated in relevant environment | In the distribution (software) / production deployment (service) / operational maturity (platform) |
| 7 | System prototype demonstration in operational environment | Operational integration with stability conditions: shipped in the Lab release with a stable API (software); production + monitoring (service/platform) |
| 8 | System complete and qualified | Qualification conditions: complete user & training documentation, thorough testing (software); real users + documentation (service); proven uptime + users (platform) |
| 9 | Actual system proven in operational environment | Sustained operation: real users, sustaining support, active maintenance / proven reliability at scale |
The table is a summary. The conditions that decide each level are on the checklist pages, condition by condition.
Reading rules
- All conditions, in order. A level is reached only when all of its conditions hold, and no level can be skipped. Lower levels are cumulative: a service in production has evidently passed the concept stage, so a built service is never held back at concept levels.
- TRL 1 is the entry level, not a hurdle. There is no TRL 0.
- Waived is not verified. A condition waived for everyone (for example, SLA conditions while EBRAINS has no SLA programme) counts as met, and is always shown as waived.
- Not applicable is left out, not failed. A condition that cannot apply to a service drops out of its level.
- Missing evidence is a gap, not a failure, where a signal cannot be collected for that kind of service (an unanswered hardware question, library download counts). Negative evidence blocks a level; absent evidence does not.
Relation to EOSC onboarding
EOSC service onboarding reads the upper levels operationally: TRL 7 “beta”, TRL 8 “production, system complete and qualified”, TRL 9 “proven in operational environment”. The checklists are compatible with that reading: an EBRAINS service at TRL 8 or above carries the evidence trail EOSC asks providers to show (production deployment, uptime record, documentation, real users).
Relation to ISO 16290
ISO 16290 requires a TRL claim to rest on assessable evidence. Ready applies that literally: every level comes from listed evidence, each item with its source, and every past result can be traced to the rubric version that produced it.