The Global Centre for Risk and Innovation (GCRI)
Labs and foundry reports record technical tests: prototypes, software, sensors, data pipelines and procedures exercised under stated conditions. Test evidence is easy to overstate, because a passed test under controlled conditions is read as readiness for use. This page sets out how test reports are structured, reviewed and archived, how readiness levels are evidenced rather than declared, and what such evidence can support for those deciding whether to adopt or fund a technology.
GCRI · Established · service level R0
Technical test reports record prototypes, software, sensors, data pipelines and procedures exercised under stated conditions. Test evidence is easy to overstate, because a test passed under controlled conditions is read as readiness for use, so reports register protocols, archive code and configuration, and publish negative and inconclusive results.
Where people and networks concentrate, the exposure through which shocks travel between systems, shown for the United Kingdom and Ireland as an example geography for this subject.
The working screen behind this subject: its structure, terms and states. Names are placeholders and values illustrative.
Labs and foundry series · Annual synthesis · Edition 7
| Annual synthesis | Global | Data check | 81 | W10 |
| Country profile 7 | Country | Peer review | 97 | W16 |
| Water outlook | Sectoral | Drafting | 32 | W38 |
| Methods note 4 | Methods | Released | 100 | done |
Technical test and readiness evidence. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
A test establishes behaviour under the conditions tested, with the inputs, environment and version used. Reports that omit those conditions invite readers to generalise beyond them.
Technology readiness levels are often self-assigned. Without the evidence each level requires, a readiness claim moves from test report to procurement decision unchecked.
Failed and inconclusive tests are seldom written up, so the published record overstates success rates and others repeat tests that have already failed.
Software and hardware change after testing. A result cited without the version tested is attached to a system that may no longer exist in that form.
Each term as this page uses it. Where a standard-setting body defines the term, the wording follows that body.
| Term | Definition |
|---|---|
| Test protocol | A document fixing a test's conditions, procedure and pass criteria before it is run. |
| Inconclusive result | A test outcome that neither supports nor rules out the claim tested. |
| System under test | The exact version and configuration of what was tested, which a result applies to. |
Each indicator carries its unit, its cadence, the kind of source behind it and the evidence label a value would carry. No values are shown: a programme supplies them under its own authority.
| Indicator | Unit | Cadence | Source type | Label |
|---|---|---|---|---|
| Test protocols registered before testing | percent of reports | per report | Registry records | OBSERVED |
| Test reports with archived code, data and configuration | percent of reports | per report | Repository deposit records | OBSERVED |
| Readiness level claimed and evidence attached | level claimed; yes or no for evidence | per report | Report and evidence annex | DECLARED |
| Negative and inconclusive results published | count per period | annual | Series catalogue | REPORTED |
| Version of the tested system identified | percent of reports | per report | Report metadata | OBSERVED |
| Independent technical review completed | yes or no, with reviewer role | per report | Review record | DECLARED |
The topic as a computational graph: named sources feed the methods, an evidence review gates the outputs, and the decisions stay with the authorities that hold them.
Fig. 02Nodes carry their type, two metric rows and a state; connectors show what feeds what; dashed frames name the owners; the timeline is the cadence. Design of the pipeline, not a record of a run.
Named public datasets and institutional records, each with its licence class. Sources by agreement are used only under their terms and never republished.
| Source | What it gives | Licence class |
|---|---|---|
| Zenodo | Archived test data, configurations and software releases with DOIs | Metadata CC0, licence per record |
| Software Heritage | Preserved source code at the exact revision tested | Code under its own licence |
| OSF Registries | Pre-registered test protocols and analysis plans | Metadata CC0, licence per registration |
| protocols.io | Published step-by-step methods with versions and DOIs | Licence per protocol, mostly CC BY |
| NIST National Vulnerability Database | Known vulnerabilities for software components under test | Public domain |
Nexus Reports prepares evidence. The decisions below are taken by the authorities named, under their own rules, and never by the platform.
| Who decides | The question | Evidence this page serves |
|---|---|---|
| Procurement and adoption boards | Whether a tested technology is ready for a pilot or operational use | Readiness evidence annexes, test conditions and known limitations |
| Innovation funders and programme managers | Whether to fund the next stage of development | Readiness level with its evidence, negative results and open risks |
| Technical review panels | Whether a test report is complete and its conclusions follow from the evidence | Registered protocols, archived data and version identifiers |
| Standards and conformity assessment bodies | Whether test methods are suitable for a future standard | Documented test procedures and their reproducibility |
Technical claims about tools and systems need evidence that others can inspect. A system that is said to work under stress should show the test that proved it, the conditions of the test and what failed. Publishing that evidence, including negative results, guards against overstated readiness and helps institutions judge what a tool can and cannot do.
Three series report evidence from building, testing and observing.
Results from completed protocols, including null and negative results.
Evidence about Nexus Foundry systems against stated readiness criteria, never as certification.
Signals from monitoring, labelled by source and confidence, prompting analysis rather than action.
The series follows the logic of test and evaluation practice in engineering: a claim is only as good as the protocol that tested it, and readiness is always readiness for something specific. A tool that has passed a laboratory test is not ready for field use, and a system that worked in one exercise has not shown that it will work in every setting. Editions state these limits next to each result.
Each result cites a protocol registered before the test, so outcomes cannot be selected after the fact.
Test conditions are described; results from a testbed may not transfer to live operation.
Readiness is assessed against criteria for a stated next step. It is not approval, bankability or certification.
Observatory signals state their source, coverage and false-alarm characteristics where known.
The current service level is R0: information and enquiries. An enquiry receives a reference and names the next step; applications, payments, compute allocations and registrations open only when their team, terms and review capacity exist.