Fail-closed policy gates
Every consequential request is evaluated against identity, mandate, purpose and data class; when no explicit decision exists the gate denies, and the denial is recorded.
The Global Centre for Risk and Innovation (GCRI)
Software and safety-critical systems engineering applies rigorous practice where a software fault could reach a decision with real consequences. In this field it means fail-closed defaults, verified builds, known components, tested recovery, and an assurance case that states what has and has not been shown.
GCRI · Established · service level R0
Software assurance is the level of confidence that software is free from vulnerabilities and functions as intended. Where a software fault could reach a consequential decision, it means fail-closed defaults, verified builds, known components, tested recovery and an assurance case that states what has and has not been shown.
Software and safety-critical systems engineering develops software whose failure could cause harm, loss of life or major disruption. It applies rigorous processes to control-system, medical, aviation and infrastructure software. In data and compute and methods and modelling, safety-critical software practice limits the chance that a software fault cascades through physical infrastructure. It informs assurance requirements for automated control in interconnected systems. The canonical description is on the STEM Commons.
Every consequential request is evaluated against identity, mandate, purpose and data class; when no explicit decision exists the gate denies, and the denial is recorded.
Releases are built by a controlled pipeline that signs provenance attestations and produces a software bill of materials, so a deployed artefact can be traced to its source and components.
Claims about a system, such as tenant isolation or kill-switch effectiveness, are argued from evidence in a structured case, with gaps and residual risks stated rather than assumed away.
Each term as this page uses it. Where a standard-setting body defines the term, the wording follows that body.
| Term | Definition |
|---|---|
| Assurance case | A structured argument, backed by evidence, that a system is acceptably safe or secure for a given use. |
| Mutation testing | Introducing small faults into code to check that the test suite detects them. |
| Policy gate | An enforcement point that checks each request against declared rules before it proceeds. |
Urban demand centres and the hubs that anchor digital and data infrastructure, shown for Latin America and the Caribbean as an example geography for this subject.
Data from the source register feeds the methods; calibration and an independent test gate the estimate and its limits; the decision stays with the competent authority.
Fig. 01Nodes carry their type, metrics and state; connectors show what feeds what; the gates are the validation steps; the timeline is one application. Design of the method's use, not a record of a run.
Datasets and records used by software and safety-critical systems engineering on this platform, with the role each plays and the label its values carry. Sources are listed in the source register.
| Data | Role | Label |
|---|---|---|
| Source repositories and review records | Change history and approval | OBSERVED |
| Test coverage and mutation results | Verification depth | OBSERVED |
| Software bills of materials | Component inventory | OBSERVED |
| Vulnerability advisories | Exposure of components | REPORTED |
| Incident and fault logs | Failure analysis | OBSERVED |
Software is verified through reviews, testing to defined coverage criteria and formal proofs where justified. Independent assessment examines the safety case.
| Check | How it is done |
|---|---|
| Deny-by-default tests | Requests without an explicit policy decision are tested to confirm they fail closed |
| Provenance verification | Deployed artefacts are checked against signed attestations before they run |
| Fault injection | Dependencies are failed deliberately to test recovery and isolation |
| Independent assessment | The assurance case is reviewed by an assessor outside the development team |
Complex software interacting with uncertain environments cannot be exhaustively tested. Updates and third-party components introduce new failure paths.
Cybersecurity and Digital Resilience stewards software and safety-critical systems engineering for the Consortium and reviews how it is applied across platforms.
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.