Nexus Standards · Trust, Verification and Assurance · Cross-cutting capabilities

Area · listed in the registry (planned)

Software and supply chain

Sets the evidence a risk software release must carry: SBOMs in SPDX or CycloneDX, SLSA build provenance as in-toto attestations, Sigstore signatures, vulnerability exchange in OSV, CSAF or OpenVEX, and archival with SWHIDs, so that engines feeding warnings or triggers are traceable to source. Each artifact of the area carries a UNI (Unique Nexus Identifier).

01Overview

Summary

Area recordTrust, Verification and Assurance
  1. TierCross-cutting capabilities
  2. Registrylisted in the registry · planned
  3. Nexus StandardsNS-12, NS-11, NS-1
  4. Open standards8
  5. Data sources3
  6. Couplings4
  7. Last reviewed17 October 2026

Area profile proposed for the Nexus Standards registry.

UNI
NXS-STD-DC-000003
Status
Proposedlisted in the registry · planned · scope NXQ
Last reviewed
area profile
Cite this page

Nexus Standards (2026). Software and supply chain: area brief, Trust, Verification and Assurance programme. Proposed. https://nexustandards.com/assurance/software-and-supply-chain-standards/ · UNI NXS-STD-DC-000003. Last reviewed 17 October 2026.

Download the profile

Files include the credits and the licence statement and are generated in the browser; no data is transmitted. Downloads require JavaScript.

02Scope

Scope and boundaries

An area of the Trust, Verification and Assurance programme (cross-cutting capabilities). The area profile sets out 4 matters in scope and 3 matters addressed by other areas.

In scope 4

  • SBOM content and format (SPDX 3, CycloneDX 1.6) and licence identification with SPDX expressions
  • Build provenance (SLSA v1.x, in-toto attestations) and keyless or role-key signing (Sigstore)
  • Vulnerability disclosure and exploitability statements (OSV schema, CSAF 2.0, OpenVEX)
  • Source archival and citation (SWHID, CodeMeta, CITATION.cff)

Out of scope 3

  • Secure coding rules for individual languages
  • Commercial software licensing negotiation
  • Penetration testing services

Jurisdictions Application in each jurisdiction is a national decision, taken by the National Standards Council (NSC) with the competent national authorities.

03Earth observation

Electrified and connected activity in West Africa

The map frames West Africa as an example geography for software and supply chain; the frame gives context and is not a statement of where the standards apply. Shown at first: night-time lights, daily (VIIRS Black Marble, VNP46A2, NASA LAADS DAAC) and population density, 2020 (Gridded Population of the World v4.11, NASA SEDAC, CIESIN, Columbia University). The layer drawer adds true colour (VIIRS NOAA-20 corrected reflectance). NASA products are served through NASA GIBS under NASA's open data policy, with acknowledgement; population density is GPW v4.11 by CIESIN, Columbia University, under CC BY 4.0; coastlines, boundaries and place names come from NASA GIBS reference layers (© OpenStreetMap contributors, ODbL) and Natural Earth (public domain). Each layer shows its own observation date; full credits are given under the map. Other sources of the profile, such as OSV.dev vulnerability API and NVD CVE API 2.0, are listed for reference.

The interactive map needs JavaScript; the layer list and sources are below.

Layers 2

Connected activity

Latest available

NASA GIBS / EOSDIS · ASTER GDEM (METI, NASA) · Blue Marble (NASA) · © OpenStreetMap contributors (ODbL) · Natural Earth

Loading the latest NASA imagery.

Drag to move. Ctrl or ⌘ and scroll, pinch or the buttons to zoom; hover for the values under the pointer; reset returns to the region.

Connected activity, framed on West Africa. Layers as NASA publishes them, each with its own date.Satellite and model products as NASA publishes them, each with its own date; indicators, not assessments of any place.

Data: NASA GIBS · ASTER GDEM · Blue Marble · © OpenStreetMap contributors · Natural EarthSources and licences

  • We acknowledge the use of imagery provided by services from NASA's Global Imagery Browse Services (GIBS), part of NASA's Earth Science Data and Information System (ESDIS). Colours redrawn from the published colour map; values averaged into H3 cells where shown (modified). NASA open data
  • We acknowledge the use of imagery provided by services from NASA's Global Imagery Browse Services (GIBS), part of NASA's Earth Science Data and Information System (ESDIS). Colours redrawn from the published colour map; values averaged into H3 cells where shown (modified). NASA open data
  • VIIRS Black Marble night-time lights, NASA Goddard Space Flight Center; distributed by the NASA Level-1 and Atmosphere Archive and Distribution System (LAADS DAAC); imagery via NASA GIBS. Colours redrawn from the published colour map; values averaged into H3 cells where shown (modified). NASA open data
  • Center for International Earth Science Information Network (CIESIN), Columbia University. 2018. Gridded Population of the World, Version 4 (GPWv4): Population Density, Revision 11. NASA Socioeconomic Data and Applications Center (SEDAC). Licensed under CC BY 4.0. Colours redrawn from the published colour map; values averaged into H3 cells where shown (modified). doi:10.7927/H49C6VHW. CC BY 4.0
  • VIIRS near-real-time products (flood, land surface temperature, snow cover, corrected reflectance), NASA LANCE; imagery via NASA GIBS. Colours redrawn from the published colour map; values averaged into H3 cells where shown (modified). NASA open data
  • ASTER GDEM is a product of METI and NASA (ASTER Global Digital Elevation Model V003, NASA LP DAAC); imagery via NASA GIBS. Colours redrawn from the published colour map; values averaged into H3 cells where shown (modified). Cite as: NASA/METI/AIST/Japan Spacesystems and U.S./Japan ASTER Science Team (2019). ASTER Global Digital Elevation Model V003. doi:10.5067/ASTER/ASTGTM.003. NASA open data
  • Made with Natural Earth. Free vector and raster map data @ naturalearthdata.com. Public domain
  • © OpenStreetMap contributors (ODbL), via NASA GIBS (coastlines, boundaries, roads and place names). Colours redrawn from the published colour map; values averaged into H3 cells where shown (modified). ODbL
  • Blue Marble, NASA Earth Observatory; imagery via NASA GIBS. Colours redrawn from the published colour map; values averaged into H3 cells where shown (modified). NASA open data
  • Context on the globe and flat map: coastlines, boundaries, roads and place names from NASA GIBS reference layers (OpenStreetMap data, ODbL, © OpenStreetMap contributors); Blue Marble imagery as an optional base; 3D terrain and the elevation read-out from the ASTER GDEM elevation colour index (5 m to 200 m classes, exaggerated for legibility). Boundaries are drawn as published and imply no position on any territory.
  • Globe: MapLibre GL JS 6.9.1, BSD-3-Clause, © MapLibre contributors.
  • NASA GIBS: We acknowledge the use of imagery provided by services from NASA's Global Imagery Browse Services (GIBS), part of NASA's Earth Science Data and Information System (ESDIS).
  • Optional layers (3 sources in the layer list: live, forecast, observed and context) print their provider credit on the map and here when switched on; forecasts are model output and derived indices are estimates.

Layers and dates

  • Night-time lights, daily: VIIRS Black Marble (VNP46A2), NASA LAADS DAAC · 12 Oct 2026
  • Population density, 2020: Population: CIESIN, Columbia University, Gridded Population of the World v4.11 (2018), NASA SEDAC, CC BY 4.0 · static
  • True colour: VIIRS NOAA-20 corrected reflectance, NASA LANCE · 13 Oct 2026

04Process

The service pipeline

A request reaches the service with an explicit context; inputs are identified (NS-1) and validated against SPDX specification; the service processes them and writes records with provenance; results are published, resolved and monitored, and a correction flows back through the same path. Nexus Standards applied: NS-12, NS-11, NS-1. 8 operations in 5 phases, built from the area profile: the cards carry its own data sources, indicators, open standards, couplings and, where listed, hazards, and each operation names the Nexus rules it implements (11). Records and artifacts are cited by UNI (Unique Nexus Identifier) and version.

Process · the service pipeline8 operations · 5 phases
Software and supply chain: the service pipelineA request reaches the service with an explicit context; inputs are identified (NS-1) and validated against SPDX specification; the service processes them and writes records with provenance; results are published, resolved and monitored, and a correction flows back through the same path. Nexus Standards applied: NS-12, NS-11, NS-1.
All operations in order (8)
  1. 01

    Request start · Request

    The service covers: SBOM content and format (SPDX 3, CycloneDX 1.6) and licence identification with SPDX expressions, Build provenance (SLSA v1.x, in-toto attestations) and keyless or role-key signing (Sigstore) and Vulnerability disclosure and exploitability statements (OSV schema, CSAF 2.0, OpenVEX).

    Who
    a client, a person or a machine
    Decision rule
    the context is explicit in the request or on the record, never inferred
    Record
    a request naming its context and inputs
    Implements
    NS16-R20
  2. 02

    Identify inputs step · Request

    Every input is resolved before it is used; an unresolved input is a typed refusal.

    Who
    the service
    Decision rule
    inputs are cited by UNI and version
    Record
    inputs resolved to their UNIs and versions
    Implements
    NS1-R5, NS2-R2, NS0-P12
  3. 03

    Validate SPDX gate · Validation

    Open standards of this area: SPDX specification, CycloneDX Bill of Materials (ECMA-424), Supply-chain Levels for Software Artifacts (SLSA) and in-toto Attestation Framework.

    Who
    the service's validator
    Decision rule
    validated against the open standard's own schema or validator where one exists
    Record
    a validation run against SPDX specification and CycloneDX Bill of Materials (ECMA-424)
    Implements
    NS14-R2
  4. 04

    Process model · Processing

    Processing is reproducible from the inputs, the method version and the configuration.

    Who
    the service
    Decision rule
    the method and version are recorded with the result
    Record
    Build provenance (SLSA v1.x, in-toto attestations) and keyless or role-key signing (Sigstore)
    Implements
    NS12-R1
  5. 05

    Write records record · Processing

    Results are written append-only; a correction adds a version.

    Who
    the service
    Decision rule
    every result carries what it was derived from
    Record
    result records with provenance and a record UNI
    Implements
    NS0-P7, NS1-R3
  6. 06

    Publish and resolve step · Publication

    Results are discoverable and citable by UNI.

    Who
    the service
    Decision rule
    writes return the allocated UNI; citations resolve
    Record
    results reachable through the resolver, with the X-Nexus-UNI header
    Implements
    NS1-R5, NS2-R5
  7. 07

    Monitor exercise · Monitoring

    Data sources the service reads: OSV.dev vulnerability API, NVD CVE API 2.0 and Rekor public transparency log. Data sources are listed for reference; live data is displayed once licence review is complete.

    Who
    the monitoring service
    Decision rule
    monitoring records are observations with record UNIs
    Record
    observations of availability, drift and SLSA v1.0 Build L3
    Implements
    NS11-R4
  8. 08

    Correction end · Monitoring

    Products that used a corrected record are listed and recomputed.

    Who
    the data steward
    Decision rule
    a correction never overwrites; dependent results are replayed
    Record
    a correction record that reaches every dependent result
    Implements
    NS1-R3, NS2-R4

Fig.Phases read left to right; each card names the operation, its actor and the record it leaves, and each edge label names the hand-over. Play, step or scrub; the detail panel gives the full text of the selected operation. Sources: SPDX specification · CycloneDX Bill of Materials (ECMA-424) · NS-12: Software, model and AI/ML artifacts · NS-11: Verification and monitoring.

05Standards architecture

Foundation, referenced and implementing layers

The standards architecture of this context, from the foundation standards to the open standards referenced (grouped by type of relation) and the services and data sources that build on them.

The interactive view requires JavaScript; the sections below present the same records.

06Nexus Standards

Applicable Nexus Standards

The area profile lists 3 Nexus Standards; the registry lists NS-12 for this area. Each is a proposed standard under development.

  1. 01

    NS-12 · Software, model and AI/ML artifacts (supply chain, model cards, dataset sheets)

    Status: proposed · 4 requirements stated. Read NS-12 · Requirements for this area

  2. 02

    NS-11 · Verification and monitoring (evidence, attestations, zero-trust conformance observation)

    Status: proposed · 6 requirements stated. Read NS-11 · Requirements for this area

  3. 03

    NS-1 · The UNI and the artifact catalog (grammar v0.2: domain, sector, region and environment segments)

    Status: proposed · 10 requirements stated. Read NS-1 · Requirements for this area

07System model and scenario simulator

System model and cascade scenario: Software and supply chain

A system model of this area built from the registry: 5 systems, 4 sectors, 9 controls, 3 feeds, 2 indicators. Select the components to include, choose an initiating hazard and run the scenario. Stress propagates through the hazard relations of the Nexus Hazard Standard (NHS-1), the exposure of each system, the recorded couplings and the sectors that carry the loss; adopted standards dampen transmission and live data sources support detection. All parameters are stated assumptions that the reader can adjust; results are illustrative scenario outputs for exercises and training, not forecasts or risk assessments.

Controls

  • NS-12 Software, model and AI/ML artifacts (supply chain, model cards, dataset sheets)
  • NS-11 Verification and monitoring (evidence, attestations, zero-trust conformance observation)
  • NS-1 The UNI and the artifact catalog (grammar v0.2: domain, sector, region and environment segments)
  • NRS-T8 Software and supply-chain integrity risk
  • NRS-H60 Hazard family: Supply-chain and flow disruption (NHS-1 sys.supply-chain)
  • NRS-A5 Built-in licensing and rights
  • NRS-I7 Intelligence applications: grounded retrieval, reasoning and decision support
  • NRS-C8 Evidence, uncertainty and provenance
  • NRS-H51 Hazard family: Malicious compromise (NHS-1 cyber.intrusion)

Observation

  • OSV.dev vulnerability API (listed for reference)
  • NVD CVE API 2.0 (listed for reference)
  • Rekor public transparency log (listed for reference)
  • Hardened build platform with non-forgeable provenance
  • Project cryptographically signs release artifacts (learning signal, not a ranking)
10Systemic couplings

Systemic couplings

4 couplings link this area to other areas and programmes, each with the mechanism of the link. Select a card on the diagram to trace a coupling.

Diagram · the area and its couplingsProcess diagram
Software and supply chain: systemic couplingsSystemic couplings of Software and supply chain as stated in the area profile: 1 area in Trust, Verification and Assurance, 3 areas in other programmes and 3 programmes reached. Each coupling states the mechanism that links the two areas.

Fig.The area at the left; coupled areas in the same programme, coupled areas in other programmes and the programmes reached to the right.

  1. Deployment servicesOpen Infrastructure and DevelopersDeployment declines an image or package whose signature, SBOM or provenance predicate fails verification, so that supply-chain evidence is enforced at the point of deployment.
  2. Verification and monitoringTrust, Verification and AssuranceSLSA level, SBOM presence and signature validity are clauses in the software supply-chain pack; their attestations are re-evaluated when a new advisory affects a component.
  3. AI, models and agentsDigital, Cyber and AIModel artifacts reuse the same signing and provenance chain, so a model card cites the build provenance of the weights and the training code.
  4. Provenance and evidenceData and Evidencein-toto statements are logged as receipts with inclusion proofs in the transparency log.
11Data sources

Data sources

3 data sources named in the area profile, each with provider, licence, update frequency and delivery path.

Data sources

Data sources are listed for reference; live data is displayed once licence review is complete.

Live
0
on completion of licence review
Listed in the data register
0
licence terms recorded
Proposed for the register
3
licence terms to be recorded
Delivery
1 governed service · 0 plugin · 0 browser · 0 snapshot · 2 listed for reference
proposed paths in order of preference: governed data service, plugin, direct browser read, build-time snapshot; sources whose terms do not permit reuse are listed for reference only
  • NVD CVE API 2.0for reference

    NIST National Vulnerability Database · continuous

    U.S. Government work (public domain); NVD terms of use

    governed data serviceproposed for the data register

  • OSV.dev vulnerability APIfor reference

    OpenSSF / Google · continuous

    Per-source licences aggregated by OSV.dev (many CC BY 4.0 or CC0)

    listed for referenceproposed for the data register

  • Rekor public transparency logfor reference

    Sigstore (OpenSSF) · continuous

    Public log entries; Sigstore public-good instance terms

    listed for referenceproposed for the data register

12Indicators

Indicators

The area profile names 2 indicators, each with its framework and code.

13Restricted standards

Restricted compatibility profiles

Standards whose text is not openly available are named and linked only. Any compatibility profile is kept on protected pages until an arrangement with the issuing body is in place.

The working group may identify restricted standards relevant to this area; they are listed here by name and link.

14Working group

Working group charter

A proposed charter for this area, open to institutions and experts.

Scope

Maintain supply-chain evidence requirements for risk software, models and data pipelines.

Institutions and experts are invited to charter this working group under NS-13 by filing a public change record. National Working Groups (NWGs) contribute national inputs and field exercises through their National Nexus Consortium (NNC).

Deliverables · 3
  1. NS-12 supply-chain conformance class with executable tests
  2. Profile of SLSA provenance for scientific compute releases
  3. VEX guidance for risk engines with long-lived dependencies
Liaison targets · 4
  • OpenSSF liaison sought
  • OASIS CSAF Technical Committee liaison sought
  • Software Heritage liaison sought
  • CycloneDX core working group liaison sought
15Readiness

Evidence, recognition and capital pathways

What each institution of the ecosystem draws from this area: GCRI Canada, as Secretariat, for evidence; The Global Risks Forum (GRF) for recognition; and The Global Risks Alliance (GRA) for capital.

Evidence pathway

GCRI Canada

GCRI Canada accepts model and engine outputs as evidence only from releases whose source is archived with a SWHID and whose build provenance verifies.

Read the evidence pathway

Recognition pathway

The Global Risks Forum (GRF)

GRF records a programme's software supply-chain posture as attestations with evaluator and time of evaluation, not as a badge.

Read the recognition pathway

Capital pathway

The Global Risks Alliance (GRA)

GRA treats an unsigned or unprovenanced trigger calculation as an operational risk that must be disclosed in the readiness file.

Read the capital pathway

Each institution determines under its own rules what it accepts as evidence; a pathway reading is neither an approval nor investment advice.

16Audiences

Intended users

The area profile identifies 4 user communities.

  1. Software engineers and release managers
  2. Security teams
  3. Research software engineers
  4. Procurement officers buying risk software
17Research questions

Open research questions

3 questions identified as priorities for the working group.

  1. Reproducible builds for scientific stacks with native Fortran, Julia and GPU dependencies.
  2. Keeping VEX statements current for long-lived models whose dependency trees are frozen for reproducibility.
  3. Signing in air-gapped national deployments without the keyless Sigstore flow.
18Hazards and sectors

Hazards, threats and sectors concerned

Hazards and threats 0

This area draws on the hazards of the areas it is coupled with.

Sectors 0

This area serves all sectors through the areas it is coupled with.

19Registry

Registry listing and depth pages

This area is listed in the registry (status: planned; scope NXQ; 3 crosswalk domains). It has five depth pages and a register crosswalk of its domains.

Crosswalk graph · software and supply chainNexus Standards registry
Software and supply chain: crosswalk to external standards58 nodes on four orbits (Nexus Standards and implementing repositories at the centre, then domains, external standards and issuing bodies), joined by 69 recorded relations.
Nexus StandardsDomainsExternal standardsIssuing bodiesImplementing repositories

1 Nexus Standards · 3 domains · 33 external standards · 21 issuing bodies · 0 implementing repositories. Relations (adopt, profile, crosswalk, cite) are as recorded in the register; names and standards remain with their stewards.

Crosswalk graph58 nodes and 69 links from the registry of external standards, programme areas and implementations (registry/external-standards.yaml, registry/consumers.yaml. Relations (adopt, profile, crosswalk, cite) are shown as recorded in the register.

Areas carry no geography of their own; the map shows where the bodies that issue the area's external standards are based.

Standards globe · Software and supply chain: issuing bodiesNexus Standards registry
Seats of the bodies that issue the external standards in the registerA plate carrée world map with Natural Earth coastlines, H3 resolution 2 hexagons at the public seats of 13 issuing bodies and one dot per seat. 33 register entries.
Issuing bodies' seats (13)H3 cells, resolution 2 (5); darker, more register entriesProgrammes, repositories and standards: not mapped
Issuing bodies and their seats (13)
BodySeatRegister entries
NISTGaithersburg, Maryland, United States8
ISO/IEC JTC 1/SC 27Geneva, Switzerland4
OASIS Cyber Threat Intelligence TCWoburn, Massachusetts, United States2
OpenSSFSan Francisco, California, United States2
FIRST CVSS Special Interest GroupCary, North Carolina, United States1
IETFWilmington, Delaware, United States1
ISO/TC 292Geneva, Switzerland1
OASIS CSAF TCWoburn, Massachusetts, United States1
OpenAPI Initiative (Linux Foundation)San Francisco, California, United States1
OpenSSF (Linux Foundation)San Francisco, California, United States1
OpenVEX community (OpenSSF project)San Francisco, California, United States1
OWASP CycloneDX; Ecma International TC54Geneva, Switzerland1
SPDX project (Linux Foundation); ISO/IEC JTC 1San Francisco, California, United States1

Issuing bodies are shown at the city of their public seat. The 1 programmes, 0 implementing repositories and 19 Nexus Standards have no location and are not mapped · 8 issuing bodies have no single public seat and are listed without a location: CodeMeta project; Citation File Format project; JSON Schema organization; World Customs Organization; International Atomic Energy Agency; United Nations General Assembly; and others

Standards globe13 issuing bodies with a public seat and 33 register entries, shown on H3 cells at resolutions 1 to 4. Seats are placed at city coordinates; programme areas, implementations and standards have no location and are not drawn. A static plate carrée map is shown where scripts are unavailable.

20Sources

Sources

4 references from peer-reviewed and official publications cited in the area profile, linked at the publishers' own sites.

21Research hub

Recent research on this area

Recent peer-reviewed articles, preprints, datasets and reports on the subject of this area, retrieved at the time of reading from open scholarly metadata services (OpenAlex, Crossref, DataCite, Zenodo, arXiv, Europe PMC, OpenAIRE Graph) with search terms composed from the registry. Each work is listed with its authors, venue, year, type, open-access status and licence, and links to its DOI or landing page. Sources not yet enabled for live display on this site are listed for reference and are not queried.

Search termssoftware supply chain; software bill of materials; open source software security; SPDX specification; CycloneDX Bill of MaterialsDerived from the title and scope of the area, the NHS-1 hazards it names and the open standards it lists.

  • OpenAlexlisted for reference; not queried
  • Crossreflisted for reference; not queried
  • DataCitelisted for reference; not queried
  • Zenodolisted for reference; not queried
  • arXivlisted for reference; not queried
  • Europe PMClisted for reference; not queried
  • OpenAIRE Graphlisted for reference; not queried

No source is enabled for live display on this site yet: the sources are listed for reference and none is queried. Once the publisher of record enables a source after its terms are reviewed, recent works are listed here. Metadata and links only: title, authors, venue, year, type, open-access status and licence as each source records them; works are listed for orientation, not reviewed or endorsed.

23Across the network

Programmes, tracks and courses for this area

GCRI Canada, The Global Risks Forum (GRF), The Global Risks Alliance (GRA) and Risk Academy work on the subject of this area in distinct roles (research and evidence; governance, policy and convening; capital, finance and markets; education and training). Each entry states why it corresponds and the step it offers; each institution sets its own terms of participation.

24Key terms

Key terms

UNI
Unique Nexus Identifier: a persistent identifier that resolves an artifact to its record.
proposed
A draft in the open development process that the Global Standards Council has not yet adopted. Each area profile is a proposal to the Nexus Standards registry.
adopt
Relation in which the external standard is used as published and values are validated against it.
profile
Relation in which a Nexus profile narrows or extends the external standard for a defined use, validated with the issuing body's own tools where these exist.
crosswalk
Relation in which Nexus clauses are mapped to parts of the external standard by clause number, without reproducing its text.
change record
A public record of a proposed change under NS-13, decided by the editors with written reasons.
attestation
An evaluator's recorded result for one clause and one subject under NS-11.
liaison sought
A liaison the working group intends to request from the issuing body; a liaison is established only when the body confirms it in writing.
26Research

Recent research and sources

Peer-reviewed articles, preprints, reports and datasets on the subject of this area, retrieved at the time of reading from open scholarly metadata services (OpenAlex and Crossref) and listed with authors, venue, year, type and access status, with a link to each work. Curated references and related standards are listed first; recent works matched by subject follow and are listed for orientation.

Curated references

Related standards and frameworks

Search terms, derived from the title and scope of the area: software supply chain; software bill of materials; open source software security. With JavaScript enabled, recent works matching these terms are listed from OpenAlex and Crossref.

27Questions

Questions and answers.

What is the status of the Software and supply chain area?
The area profile is a proposal to the Nexus Standards registry, and the area is listed in the registry. Standards are adopted by the Global Standards Council after last call; in each country, adoption is a decision of its National Standards Council (NSC).
How are data sources presented?
Each data source is listed with its provider, licence, update frequency and delivery path, and links to the provider's own publication.
How can this brief be amended?
Through a public change record under NS-13: a proposed amendment to the area profile or the registry, decided by the editors with written reasons.
NRNexus Reports gateway · GW-STD

Contribute to Nexus Reports from this page.

Nexus 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.

Nexus Standards
Nexus Standards

Contribute to Software and supply chain

Institutions and experts are invited to propose amendments, join the working group or propose data sources. National participation is organised through each country's National Nexus Consortium (NNC) and its National Working Groups (NWGs); competent national authorities are engaged through official channels.

Status and use. The Nexus Standards are proposed standards developed through an open process under NS-13 and published for voluntary use; they do not constitute certification, accreditation or regulatory approval, and adoption remains a decision of the Global Standards Council and, in each country, of its National Standards Council. A UNI (Unique Nexus Identifier) identifies an artifact; it does not certify it. Names of standards bodies and their standards belong to their stewards and are used only to identify the documents; no text of an external standard is reproduced here. Nexus Standards is not affiliated with, endorsed by or certified by any standards body named here.

Licences: CC BY 4.0 for standards text, registries, schemas and data; Apache-2.0 for reference code. External standards are cited by name, number and link under their own licences. Third-party data, libraries and fonts keep their own licences: see Third-party notices.

Skip to toolbar