GCRI · Foundry
Twenty technical systems
A technical environment of many systems fails at its seams: two systems each believe they own the same record, an interface changes without notice, or a downstream tool computes its own version of a figure that already exists upstream. The canonical inventory gives each Foundry system one contribution, one boundary and one owner per record type. This page sets out how interface and ownership failures develop and spread, how they are measured, and what system owners and reviewers need to keep the inventory true.
Twenty technical systems on the record.
Twenty technical systems: how the risk develops.
Canonical Foundry system inventory. The dossier below sets out how the risk develops, what is measured, where the data come from, how it is modelled and who decides.
Duplicate ownership
When two systems both write the same kind of record, they diverge silently. Each looks correct alone; the conflict appears only when a decision draws on both and finds two answers to one question.
Interface drift
A field changes meaning, a unit changes, an optional value becomes required. Consumers built against the old contract keep running and produce plausible but wrong output. Versioned contracts with compatibility checks on every build are the standard defence.
Shared dependencies
Many systems depend on one identity service, one message bus, one library or one cloud region. A fault or vulnerability there reaches every dependant at once, which is why dependency maps and software bills of materials matter.
Authority creep
A system built to support a decision begins to make it: a dashboard threshold becomes an automatic action, a draft becomes a release. Boundaries written into each system definition and enforced at policy gates keep support from becoming authority.
Workspace and job console.
The screen a team would use to follow this subject: its measures, states and decisions. Names are examples and values are illustrative.
Workspace and job console
Twenty technical systems · Project space 12 · Cluster east
- Jobs running20Active
- Queue wait, p508minNormal
- Runs today5327
- Quota used, % this month85Watch
Jobs
| J-77261 | Flood model ensemble | Project owner | 00:10:12 | Running |
| J-22526 | Tile render, zoom 0 to 12 | GIS workspace | 00:01:40 | Running |
| J-65648 | Evidence export | Model steward | 00:00:55 | Done |
| J-53084 | Agent tool call batch | Agent sandbox | 00:01:51 | Policy block |
Policy events
- 10:28GateAgent call needs human approval
- 10:33InfoRun record sealed
- 11:58WarnQuota at 80 pct for project
The twenty systems are designed to serve all five domains.
- WaterIn practiceEarth observation and early warning systems serve water work.What a reader can checkSystem purpose
- EnergyIn practiceDecision support and simulation serve energy work.What a reader can checkCapability state
- HealthIn practiceSignal and evidence systems serve health work.What a reader can checkVerification state
System readiness is designed for the Foundry Build and Readiness series. Systems are recorded as declared until verification evidence exists under NS-11 of the proposed Nexus Standards.
- Technical reviews.
- Requirements from users.
How twenty technical systems is modelled, measured and tested.
The model, its assumptions, its data and its uncertainty, in the form a scientist or engineer would check. Structures follow published methods. The values drawn are illustrative, not findings.
Model, equations and assumptions
The model structure used for twenty technical systems, the assumptions it makes and how each is tested.
Ri = f(Hi, Ei, Vi, Ci)hazard, exposure, vulnerability and coping capacityEAL = ∑k pk · Lkover events k with annual probability pkxt+1 = A xt + B ut + εtA carries the couplings, u the shock, ε the error| Assumption | Why it is made | How it is tested |
|---|---|---|
| Hazard and exposure are independent within an event | Keeps the loss integral tractable | Compare with a copula fit on joint records |
| Couplings are linear near the operating point | Lets shocks propagate through A | Perturb beyond the linear range and compare |
| Vulnerability curves transfer between places | Local curves are rarely available | Validate against observed losses where they exist |
- Inputs
- versioned datasets with provenance
- Outputs
- distributions, never single numbers
- Code
- released with the model card and tests
- Reproduction
- same data, code, environment and seed
What is measured, and how well.
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 |
|---|---|---|---|---|
| Record types with more than one declared owner | count | per release | System registry | DECLARED |
| Breaking interface changes detected | count per release | per build | Contract compatibility checks | OBSERVED |
| Components with a current software bill of materials | proportion of deployed components | per build | SBOM generation records | OBSERVED |
| Known exploited vulnerabilities in dependencies | count open | daily | Scans against public advisories | OBSERVED |
| Time to remediate critical dependency vulnerabilities | days | per advisory | Change and release records | OBSERVED |
| Release artefacts with build provenance attestations | proportion of artefacts | per release | Signed build attestations | OBSERVED |
| Systems with a documented boundary and owner | proportion of inventory | quarterly | System registry | DECLARED |
Where the evidence comes from.
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 |
|---|---|---|
| OpenAPI Specification | Machine-readable HTTP interface contracts that can be compared for breaking change | Apache 2.0 |
| Protocol Buffers language specification | Canonical service and message contracts with defined compatibility rules | Open source, BSD-style |
| CycloneDX and SPDX specifications | Formats for software bills of materials, licences and component provenance | Open specifications |
| OSV vulnerability database | Open-source vulnerability advisories keyed to package versions | CC BY 4.0 |
| National Vulnerability Database (NIST) | Vulnerability records with severity scoring | Public domain |
| CISA Known Exploited Vulnerabilities catalogue | Vulnerabilities with evidence of active exploitation | Public domain |
| OpenSSF Scorecard results | Automated checks of security practice in open-source dependencies | Free and open |
Who decides, and what the evidence serves.
Foundry 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 |
|---|---|---|
| System owners | Whether a change to their system’s contract or record ownership may proceed | Compatibility check results; the consumers of the affected contract |
| Security officers | Which dependency vulnerabilities must be fixed before release, and which are accepted with a recorded rationale | Bills of materials matched against advisories; exploitation status |
| Architecture reviewers | Whether a new capability belongs in an existing system or needs a new boundary | Inventory, record ownership map and the proposed contract |
| Contracting institutions | Which systems their agreement covers and what each may do with their data | System boundaries and the record types each one reads and writes |
Outputs this topic produces
- Inventory of systems with contribution, boundary and record ownership
- Interface contracts with version and compatibility history
- Dependency maps and software bills of materials per release
- Boundary statements of what each system must never do
What a system inventory has to answer.
- Which system is the authoritative owner of each kind of record?
- Where does each system’s authority stop, and who decides beyond that point?
- How do systems exchange records without copying and diverging?
- Which shared controls apply to every system, so that trust does not depend on each one’s configuration?
Twenty systems, one line each.
- NXS-CMD (integrated posture and executive synthesis)ContributionCommand home for posture, authority and coordinated response
- NXS-NST (civilian common operating picture)ContributionCommon operating picture for civilian operations
- NXS-DSS (decision cases and deliberation)ContributionDecision briefs, option trade-offs and spatial decision support
- NXS-COR (compute, nodes and runtimes)ContributionCompute control plane across cloud, private infrastructure and edge
- NXS-NXQ (software, models and capability lifecycle)ContributionIngestion, lineage, schema validation and event routing
- NXS-GRX (canonical data, provenance and risk)ContributionRisk ontology, indices and evidence packs
- NXS-EOP (earth observation and digital twins)ContributionObservation catalogue, spectral analytics and scenario twins
- NXS-EWS (multi-hazard monitoring and warning)ContributionWarning support, from hazard signal to authority-ready package
- NXS-AAP (anticipatory action and triggers)ContributionEvidence-triggered playbooks, readiness and action records
- NXS-NET (network topology and continuity)ContributionNetwork topology, route integrity and communications readiness
- NXS-OPS (instruments, sensors and calibration)ContributionObservatory nodes, sensor telemetry and proof of observation
- NXS-SIG (signal, spectrum, timing and PNT)ContributionAuthorised spectrum monitoring and signal integrity
- NXS-NSF (trust, authorisation and assurance)ContributionIdentity, mandate, policy gates and proof receipts
- NXS-HUB (knowledge, records and learning)ContributionCollaboration, knowledge, directory and support desk
- NXS-STU (composition, dashboards and workflows)ContributionComposable dashboards, maps, workflows and agent configurations
- NXS-FAC (blueprints, builds and signing)ContributionBlueprints to tested, signed application releases
- NXS-APP (application catalogue and lifecycle)ContributionApplication catalogue, installation and runtime lifecycle
- NXS-RLS (participants, agreements and handoffs)ContributionProtocols, obligations, handoffs and receipts between institutions
- NXS-POR (public, client and partner delivery)ContributionPublic-safe publication and audience delivery
- NXS-LAB (research, experiments and simulations)ContributionGoverned experiments, reproducible compute and research handoffs
Descriptions are of the design. A system page is not a statement that the system is operating for any tenant.
One trust spine, composed records.
The systems share one trust spine, the NXS-NSF Sovereignty Framework, so identity, policy and receipts work the same way everywhere. Records are composed rather than duplicated: NXS-NST, NXS-DSS and NXS-EWS use The Global Risks Index (NXS-GRX) products instead of inventing their own risk figures, and NXS-POR publishes only what has passed a public-safe release decision. This is ordinary systems-engineering discipline, a single source of truth per record type and explicit interfaces between subsystems, applied to risk work.
Boundaries are part of each definition. DSS supports analysis, but analysis is not the decision. EWS supports forecast verification and warning packages, but issuing warnings stays with authorised parties. AAP evaluates triggers and readiness, but never releases funds or dispatches resources automatically. Rails records instructions and receipts between institutions, and a receipt is not settlement or external acceptance. Labs runs reproducible experiments, and experiment results are not certification.
How it is studied, and what the methods cannot say.
- 01Systems engineeringCanonical system inventory · Contract-first interfaces · Requirements traced to evidenceApplied here
- 02Software and safety-critical systems engineeringFail-closed policy gates · Build provenance and bills of materials · Assurance casesApplied here
- 03High-performance, cloud and edge computingEnsemble scheduling across tiers · Federated execution next to the dataApplied here
- 04Data engineering, interoperability and stewardshipValidation at the ingest boundary · Frozen data cuts for reproducible productsApplied here
Where this page’s references lead.
The bodies and documents this page is read against. Status and editions change; each link goes to the issuing body.
Questions and answers.
Why does every record type have one owner?
What is a software bill of materials?
Why are the systems written in several languages?
Does a system page mean the system is running?
Why exactly twenty systems?
Can I use one system on its own?
Is the Labs system the same as Labs?
Contribute evidence from this page.
Reports is the Consortium’s quarterly publication. What you know about this subject can become evidence, a case or a correction in the next edition, credited to you and published under CC BY 4.0 where it is your own work.
- EmailGateway GW-GCRISend it from this pageEvidence, a correction, a case, a method, a review, a translation or profile input. It arrives tagged with this page, so the editor who owns it receives it.
- ZenodoOpen depositDeposit it and submit to the communityPublish your own record on Zenodo with your ORCID iD, then submit it to the Reports community there. Curators review it; the DOI stays yours.
- ReportsGCRISee every way to contributeThe contribution types, how each is reviewed, what credit you receive, the licence and what is never accepted.
Never send personal data, sensitive infrastructure detail or anything you have no right to share. A contribution is reviewed before use; sending it confers no authorship or editorial rights, and sponsorship never buys a finding.
Bring a method, a dataset or a question.
Information and enquiries are open today. 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.
Legal documents.
Maps, data and figures on this site are shown for context and general information. They are not advice, forecasts or warnings; the limits of the information are set out in the Disclaimers and Data Notices.