Nexus Standards · NS-1 · Proposed
NS-1
NS-1: The UNI and the artifact catalog (grammar v0.2
NS-1 is a proposed Nexus Standard; the artifacts it governs are identified by UNIs (Unique Nexus Identifier). NS-1 gives every artifact one stable, machine-readable identifier, the UNI (Unique Nexus Identifier), and one catalog record that states what the artifact is, who made it, who publishes it, what rights apply and where it is held. Code, services, schemas, datasets, models, reports, articles, figures, maps, lessons, policies and standards follow the same scheme, so that any agent, developer, researcher, machine or expert reader can find and cite an artifact in the same way across every implementation, organisation, site, language and jurisdiction.
Read a UNI.
Type or paste a Uniform Nexus Identifier: each segment is decoded against grammar 0.2 and the region, when it names a country, is lit on the globe above.
Summary
- Statusproposed
- Responsible scopetrust, authorization and assurance
- Identifier
NXS-STD-ST-000001 - Rules stated10
- Programme areas10
- Source filesrepository
Nexus Standards · proposed
Status of NS-1
Preparatory working draft, circulated for review and comment. Not for implementation. Prepared and circulated by The Secretariat of the Nexus Standards, Global Centre for Risk and Innovation (GCRI Canada) (public@therisk.global), 17 October 2026. Technical review area: TR-02. This document is not a Nexus Standard; it may change without notice and is not to be implemented, relied upon or cited as a Nexus Standard. Its stage is designated only by the Global Standards Council and its technical committees under NS-13. Recipients are invited to submit comments with supporting reasons, and to notify any patent rights of which they are aware. See the notice of circulation.
Electrified and connected activity worldwide
The map is framed on the world as context for the subject of NS-1. 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.
The interactive map needs JavaScript; the layer list and sources are below.
Layers 2
Connected activity
Keyboard, with the map focused
Hold Ctrl or ⌘ and scroll to zoom
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.
Night-time lights and population density, the footprint of electrified, connected activity, framed on World.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
NS-1 among the standards.
Fig.The standards on which NS-1 builds, those that cite it and the programme areas where it applies, from the texts and the registry.
The standard as a process
A producer describes an artifact; its context codes are checked against the registries; the catalog mints the UNI (Unique Nexus Identifier) and keeps the record; the UNI is embedded in the artifact and resolves to its landing page; versions share the UNI, and a withdrawn or replaced artifact keeps its record. 8 operations in 6 phases; each states its actor, its decision rule, the record it leaves and the rule identifiers it implements (10 rules of NS-1 and the standards it applies).
All operations in order (8)
- 01
Describe artifact start · Description
The producer states what the artifact is, which scope publishes it, its category, and only the domain, sector, region and environment segments that are true of all of it.
- Who
- the producer: a person, an institution or an agent under a recorded mandate
- Decision rule
- one UNI per artifact concept; codes classify, they never name a product
- Record
- a draft entry: title, scope, category and the context segments that are true of the artifact
- Implements
- NS1-R1, NS1-R6, NS1-R7
- 02
Check codes gate · Codes
Scope, domain, sector and environment codes are three-letter registry codes; regions are ISO 3166-1 alpha-3 or UN M49. A missing code is proposed, never invented.
- Who
- the catalog validator
- Decision rule
- every segment is a registry code meeting CA-1 to CA-10; a new code enters through an NS-13 proposal and may be used, with its status shown, until adopted
- Record
- a validation result for every segment
- Implements
- NS1-R8, NS1-R10
- 03
Mint the UNI step · Allocation
The catalog returns the next serial for the scope, category and context segments. The serial is never reused.
- Who
- the catalog of the scope
- Decision rule
- UNIs are allocated only through the catalog; never typed by hand
- Record
- a UNI with a six-digit serial for the full prefix
- Implements
- NS1-R2
- 04
Catalog record record · Allocation
One record per UNI says what the artifact is, who made and publishes it, what rights apply and where it lives.
- Who
- the catalog
- Decision rule
- every record carries the required metadata; the legal state defaults to review-required
- Record
- the record: title, scope, category, status, creators, publisher, date, rights, legal state, locations
- Implements
- NS1-R4
- 05
Embed the UNI step · Embedding
Source files carry a header line, documents front matter, datasets a sidecar or metadata key, figures a caption suffix, web pages a meta tag and APIs the X-Nexus-UNI header.
- Who
- the producer, on each surface
- Decision rule
- the UNI is embedded in the artifact itself so that machines and people find the record (section 6)
- Record
- a header line, front matter, sidecar, caption suffix, meta tag or response header
- Implements
- NS1-R5
- 06
Resolve the UNI record · Resolution
The resolver path returns the record; the URN form urn:nexus:uni:<UNI> and the citation forms of NS-2 point to the same record.
- Who
- the resolver (NS-7)
- Decision rule
- a UNI identifies and resolves; it never certifies
- Record
- a landing page for people and JSON for machines at /uni/<UNI>
- Implements
- NS1-R5
- 07
New version step · Resolution
A revision keeps the identifier of the concept; citations of a state cite the version.
- Who
- the producer
- Decision rule
- versions share the UNI and differ in @VERSION
- Record
- the same UNI with a new @VERSION
- Implements
- NS1-R1
- 08
Withdraw or replace end · Retirement
A withdrawn artifact keeps its record and identifier; a replaced one points to its successor, and identifiers that use a retired code stay valid.
- Who
- the publisher of record
- Decision rule
- UNIs are never deleted or reused; a retired code keeps its entry
- Record
- the record kept with status WITHDRAWN, or with supersededBy
- Implements
- NS1-R3, NS1-R9
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: NS-1: The UNI and the artifact catalog.
Purpose of NS-1
The Secretariat of the Nexus Standards maintains and versions the Nexus Standards; the Global Standards Council adopts them. Every implementation, site and agent applies them and does not fork them. A UNI identifies and resolves; it never certifies truth, readiness or authority (NS0-P8).
NS-1 clause by clause
10 clauses and 10 rules as stated in the standard, presented with numbered clauses, stable rule anchors, versions and changes.
Where the standard lives
This repository is the canonical home of the Nexus Standards: the documents under standards/, the machine registry under registry/, the record schemas under schemas/, the STD-scope catalog under catalog/ and the reference CLI under tools/. Implementations, open or proprietary, implement the standard, keep their own catalogs for their own scopes and do not fork the registry; registry/consumers.yaml is the register in which each implementation states its status. This standard specifies behaviour at interfaces and the content of records; it names no implementation and depends on no implementation's internals.
The UNI
Grammar version 0.2 (context segments added 2026-10-16; every v0.1 identifier is unchanged and remains valid).
NXS-<SCOPE>-<CAT>[-<DOMAIN>][-<SECTOR>][-<REGION>][-<ENV>]-<SERIAL>[@<VERSION>] NXS-EWS-DS-000042 dataset 42 of the multi-hazard monitoring and warning class NXS-EWS-DS-KEN-000003 a Kenyan monitoring and warning dataset NXS-GRX-RP-M002-000007@1.2.0 report 7 of the risk data class for Africa, version 1.2.0 NXS-GRX-AR-WAT-CAN-000012 article 12 of the risk data class on water in Canada NXS-GRX-DP-WAT-WUT-CAN-PRD-000001 production deployment 1 of the risk data class for Canadian water utilities (NS-9) NXS-GCR-AR-000015 an article published by GCRI Canada NXS-STD-ST-000001 this standard| Segment | Form | Meaning |
|---|---|---|
NXS | fixed | Prefix. Chosen over NEX because it reads as a code, not a word, and because NEX- is crowded by brands. NXS-S01 to NXS-S20 are also the neutral identifiers of the functional system classes (section 2). |
| SCOPE | three letters | A functional system class (EWS, EOP, SIG, GRX, OPS and the others in section 2), an organisation (GCR, GRF, GRA, NXO) or a cross-cutting scope (STD, LEG, GOV, PRG) |
| CAT | two letters | Artifact category, mapped to Zenodo upload and publication types and to DataCite resource types (section 3); or a risk record kind (OB, SR, IN, ME, BD, CT, CR, AP, SU; NS-3). The two lists never share a code. |
| DOMAIN | optional, three letters | Domain code from registry/domains.yaml (WAT water, ENE energy, FOO food, HLT health, BIO biodiversity, CLI climate, DRR, EWN, HUM, INF, SCH, SEC, ZTA, FNC, DSC, ERM, DRG, AIS, DAT, GSP, PRV, IDF, SFW, NAT, SDP, LIC; proposed: CMP, DTW, SNS, PNT) |
| SECTOR | optional, three letters | Sector code from registry/sectors.yaml (AGR, WUT, EUT, HSY, FNI, TRL, CIT, INM, DTC, PUB, RED, HUO, IGO) |
| REGION | optional | ISO 3166-1 alpha-3 country code (KEN, CAN) or UN M49 area code written as M followed by three digits (M002 Africa, M142 Asia); registry registry/regions.yaml |
| ENV | optional, three letters | PRD production, STG staging, LBX lab, FIX fixture; used by contextual records (NS-9) |
| SERIAL | six digits | Allocated by a catalog or a record allocation authority per full prefix (SCOPE, CAT and context segments); never reused |
| VERSION | optional | Semantic version of an artifact (1.2.0) or the integer recordVersion of a risk record (3; NS-3). The UNI without a version names the concept. |
Context segments. The four optional segments always appear in the order DOMAIN, SECTOR, REGION, ENV. Each is a three-letter code from its registry, and the registries are pairwise disjoint and disjoint from the scope codes and from the M49 form (checked by node tools/nexus-id.mjs catalog validate), so an identifier parses deterministically without separators. The identifier without CAT and SERIAL is the context name: NXS-GRX-WAT-CAN reads as the risk data class, water domain, Canada. Articles, pages, datasets, deployments, dashboards and code about that context carry the context name (NS-16); their UNIs differ only in CAT and SERIAL. A context name is never allocated and never carries a serial; the NS-9 contextual record (DP or PR) is the record of truth for a context.
Machine forms: URN urn:nexus:uni:NXS-EWS-DS-000042; resolver path /uni/NXS-EWS-DS-000042 (an HTML landing page for browsers and JSON for machines by content negotiation; /uni/<uni>.json is always JSON; /uni lists published records); context path /ctx/NXS-GRX-WAT-CAN (every published record of that context); field name uni in every record, API, schema and table.
Existing dotted identifiers (for example data.eo.stac.catalogue) are UNI v0. They are recorded as legacyUni on the new record for crosswalk and are never allocated again.
1.1 Context code allocation
Proposal NXS-STD-PC-000004 introduces this section and is OPEN; the rules apply to every code allocated from now on. Machine form: registry/nexus-standards.yaml identifier.codeAllocation. Check: node tools/nexus-id.mjs catalog validate.
A scope, domain, sector or environment code is a three-letter classification that machines parse and that people need not read. The allocation rules exist so that no code becomes ambiguous, including after future changes in other code lists.
| Rule | Text |
|---|---|
| CA-1 | A code is three capital letters A to Z. It contains no digits and never takes the UN M49 form (M followed by three digits). |
| CA-2 | A code is unique across every registry: scopes, domains, sectors, environments and ISO 3166-1 alpha-3. |
| CA-3 | A code is never one of the following, all listed in registry/regions.yaml, so that a future country assignment cannot collide:<br>• an ISO 3166-1 exceptionally, transitionally or formerly reserved code element;<br>• a code in the user-assigned ranges (AAA to AAZ, QMA to QZZ, XAA to XZZ, ZZA to ZZZ);<br>• an ICAO Doc 9303 nationality code. |
| CA-4 | A code is a mnemonic of the English label: the first letter of the label's head term, followed by consonants that keep the code recognisable. |
| CA-5 | A code is never a product name, a mark, a company name or a stock ticker, and never a word that reads as a brand. |
| CA-6 | One concept per code. Each code has a definition, what it includes and excludes, and the external standards it crosswalks to. |
| CA-7 | Ids are stable, lowercase kebab-case English. Labels are in sentence case. Neither encodes a status. |
| CA-8 | Append-only. A code is never reassigned or deleted. A retired code keeps its entry with deprecated: true and supersededBy. |
| CA-9 | A new code stays PROPOSED, with its proposal UNI, until the Global Standards Council adopts the registry change. An implementation may use a PROPOSED code and shall show its status. |
| CA-10 | Adding a code is a minor, additive registry version. Changing what a code means is a major change and requires a crosswalk. |
Grandfathered: AAP, the scope code of the anticipatory-action class, was allocated before CA-3 and lies inside the user-assigned range AAA to AAZ. It is kept under CA-8.
Technology domains proposed under these rules:
| Code | Id | Label | Crosswalks to |
|---|---|---|---|
CMP | compute | Compute and accelerated infrastructure | ISO/IEC JTC 1/SC 38 and SC 39; ISO/IEC 22123 |
DTW | digital-twins | Digital twins and simulation | ISO/IEC 30173:2023; ISO/IEC JTC 1/SC 41; ISO 23247 |
SNS | sensing | Sensing and measurement networks | OGC SensorThings API and SensorML; W3C/OGC SOSA/SSN; IEEE 1451 |
PNT | pnt | Positioning, navigation and timing | IEEE 1588; ITU-T G.8271 and G.8272; ITU-R TF series; UN ICG |
Sensing and positioning, navigation and timing are separate codes because different communities standardise them: sensor and observation encodings on one side, timing and GNSS profiles on the other. A technology stream that covers both carries SNS and lists PNT as related.
A future quantum-technology code cannot be QTM or QNT, because both fall in the user-assigned range QMA to QZZ. CA-3 catches this kind of collision before allocation.
Scope codes
A system scope names a functional system class: a function that any implementation can provide, described in neutral terms. It never names a product. The code and the neutral identifier are stable and never reused; systemId is the functional class id.
| Code | Neutral id | Functional class id | Functional system class |
|---|---|---|---|
| CMD | NXS-S01 | executive-synthesis | Integrated posture and executive synthesis |
| NST | NXS-S02 | common-operating-picture | Civilian common operating picture |
| DSS | NXS-S03 | decision-support | Decision support, cases and deliberation |
| COR | NXS-S04 | compute-runtime | Compute, nodes and runtimes |
| NXQ | NXS-S05 | software-model-lifecycle | Software, models and capability lifecycle |
| GRX | NXS-S06 | risk-data-provenance | Canonical risk data, records and provenance |
| EOP | NXS-S07 | earth-observation-twins | Earth observation and digital twins |
| EWS | NXS-S08 | monitoring-warning | Multi-hazard monitoring and warning |
| AAP | NXS-S09 | anticipatory-action | Anticipatory action and triggers |
| NET | NXS-S10 | network-continuity | Network topology and continuity |
| OPS | NXS-S11 | instruments-sensing | Instruments, sensors and calibration |
| SIG | NXS-S12 | signal-timing-pnt | Signals, spectrum, timing and positioning, navigation and timing (PNT) |
| the trust and assurance system | NXS-S13 | trust-assurance | Trust, authorization and assurance |
| HUB | NXS-S14 | knowledge-records | Knowledge, records and learning |
| STU | NXS-S15 | composition-workflow | Visual composition and workflows |
| FAC | NXS-S16 | build-signing | Blueprints, builds and signing |
| APP | NXS-S17 | application-lifecycle | Application catalogue and lifecycle |
| RLS | NXS-S18 | participation-agreements | Participants, agreements and protocols |
| POR | NXS-S19 | public-delivery | Public, client and partner delivery |
| LAB | NXS-S20 | research-simulation | Research, experiments and simulation |
Organisations: GCR GCRI Canada · GRF The Global Risks Forum · GRA The Global Risks Alliance · NXO reserved organisation scope for a multi-party consortium (entity under legal review) · ELP and OBS reserved organisation scopes (withdrawn before use; parseable, never issued). Cross-cutting: STD the Nexus Standards themselves · LEG legal, intellectual property and licensing · GOV governance, decisions and policy · PRG programme, waves and work packages · UXK UI/UX kit, design tokens and assets · ALL ecosystem-wide.
Scope codes are classification, not names. Public labels follow the marks policy (governance/OPEN_BOUNDARY_IPR_AND_LICENSING.md, section 7): the trust and assurance system as a code is permitted; "the trust and assurance system" as a public product name is not.
Category codes
| Code | Artifact | Zenodo | DataCite |
|---|---|---|---|
| SW | Software | software | Software |
| SV | Service or API | software | Service |
| SC | Schema or contract | other | Other |
| MG | Database migration | software | Software |
| WF | Workflow | workflow | Workflow |
| MD | Model | model | Model |
| DS | Dataset | dataset | Dataset |
| EV | Evidence record | dataset | Dataset |
| AR | Article | publication / article | JournalArticle |
| PP | Preprint | publication / preprint | Preprint |
| RP | Report | publication / report | Report |
| TN | Technical note | publication / technicalnote | Text |
| DC | Documentation | publication / softwaredocumentation | Text |
| DL | Deliverable | publication / deliverable | Report |
| WP | Working paper | publication / workingpaper | Text |
| BK | Book or chapter | publication / book | Book |
| CP | Conference paper | publication / conferencepaper | ConferencePaper |
| TH | Thesis | publication / thesis | Dissertation |
| PT | Patent | publication / patent | Other |
| ST | Standard | publication / other | Standard |
| PC | Policy or directive (also proposals, NS-13) | publication / other | Text |
| PS | Presentation | presentation | Text |
| PO | Poster | poster | Text |
| FG | Figure | image / figure | Image |
| PL | Plot or visualization | image / plot | Image |
| DG | Diagram | image / diagram | Image |
| PH | Photo | image / photo | Image |
| MP | Map product | image / other | Image |
| VD | Video | video | Audiovisual |
| LS | Lesson or course | lesson | InteractiveResource |
| PY | Physical object | physicalobject | PhysicalObject |
| PA | Participation record | other | Other |
| RS | Programme status record | other | Other |
| DP | Deployment or instance (NS-9 context) | other | Other |
| PR | Programme instance (NS-9 context) | other | Other |
| CL | Clause (NS-10 obligation) | other | Other |
| AT | Conformance attestation (NS-11) | other | Other |
| OT | Other | other | Other |
node tools/nexus-id.mjs export <uni> --format zenodo produces Zenodo deposition metadata and --format datacite produces a record shaped to the DataCite Metadata Schema, so that a catalogued artifact can be deposited, or registered with a DOI, without being described again.
3.1 The public Nexus Registry crosswalk
The registry at therisk.global/nexus-registry/ (publisher GCRI Canada) shows record ids NX-R-nnnnn (programme status), NX-P-nnnnn (publication), NX-E-nnnnn (evidence) and NX-C-nnnnn (participation), each with a version, a hash and a state. Those forms become display aliases of UNIs: NX-R-47092 becomes NXS-GCR-RS-047092; NX-P maps to RP (or to AR, PP or WP when the record says so), NX-E to EV and NX-C to PA. The registry version becomes currentVersion, the hash versions[].digest and the state registryState (REGISTERED, CORRECTION_OPEN, RIGHTS_HOLD, WITHDRAWN). The registry states that no public record has been released yet, so no published identifier is affected. Full rule: registry/nexus-standards.yaml#registryCrosswalk.
The record
Each UNI has one record in a catalog (schema: nexus-artifact-record.v1.json). Required fields: uni, title, scope, category, status, creators, publisherRef, publicationDate, rights, legalState, claimCeiling, locations. Optional fields include region, systemId, legacyUni, description, keywords, language, currentVersion, versions (with the source revision and a SHA-256 digest), relatedIdentifiers (DataCite relation types, so that parts, derivations, supersessions and citations form a graph), supersededBy, workPackageId and context (NS-9).
Assurance fields: legalState defaults to LEGAL_REVIEW_REQUIRED; claimCeiling never exceeds the claim registry (FIXTURE_VERIFIED, IMPLEMENTATION_COMPLETE, INTEGRATED, LAB_OBSERVED); publisherRef is the institution for institutional artifacts. The institution stays publisher of record: ownership of a technology does not make its owner the publisher.
Rules
| Rule | Text |
|---|---|
| NS1-R1 | One UNI shall identify one artifact concept; versions share the UNI and differ in @VERSION. |
| NS1-R2 | UNIs shall be allocated only through a catalog (mint) or a record allocation authority (NS-3); they shall not be typed by hand. |
| NS1-R3 | UNIs shall not be deleted or reused. A withdrawn artifact keeps its record (WITHDRAWN); a replaced one records supersededBy. |
| NS1-R4 | Every record shall carry the required metadata; legalState defaults to review-required; claimCeiling stays inside the claim registry. |
| NS1-R5 | The UNI shall be embedded in the artifact itself so that machines and people can find the record (section 6). |
| NS1-R6 | A regional artifact shall carry REGION; public regional or national use still follows the geographic rules of the marks policy. |
| NS1-R7 | Codes are classification and shall not be used as product names. |
| NS1-R8 | A new scope, domain, sector or environment code shall meet the allocation rules CA-1 to CA-10 (section 1.1) and shall enter through an NS-13 proposal. |
| NS1-R9 | A code shall not be reassigned or deleted; a retired code is deprecated with supersededBy, and identifiers that use it remain valid. |
| NS1-R10 | A PROPOSED code may be used and shall be shown with its status until the registry change is adopted. |
Embedding: how each surface carries the UNI
| Surface | Functional class | How |
|---|---|---|
| Source files | the trust and assurance system | Header comment Nexus-UNI: <uni> |
| Documents and reports | HUB | Front matter uni: or first line Nexus-UNI: <uni> (NS-4) |
| Datasets and products | GRX | Sidecar <file>.uni.json holding the record, or a uni key in STAC and DataCite metadata (NS-3b) |
| Figures and maps | EOP | Caption suffix [<uni>] and image metadata (NS-5) |
| HTTP APIs | the trust and assurance system | Response header X-Nexus-UNI: <uni> on every JSON response whose body carries a uni. An implementation may serve its catalog at GET /api/uni/catalog and GET /api/uni/<uni>, and exports at GET /api/uni/<uni>/export?format=zenodo\|datacite\|schema-org\|codemeta\|citation-cff\|stac\|dcat\|prov, under its own access control. A public resolver serves GET /uni/<uni> for PUBLISHED, non-restricted records with Schema.org JSON-LD. |
| Panels and dashboards | STU | Every projected record carries uni (or a typed pending state) in the panel's provenance and shows it as a link; any cell that holds a UNI links to /uni/<uni> (NS-16 section 7) |
| Passports | GRX | The uni field is the first field of the shared identity section; valid UNIs link to /uni/<uni> and legacy dotted ids are shown unlinked (NS-15 section 2) |
| Landing and trust pages | POR | <meta name="nexus-uni" content="<uni>"> and data-nexus-uni on the component root |
| Content management systems and institutional sites | POR | Content metadata field _nexus_uni (validated), rendered as <meta name="nexus-uni"> and the X-Nexus-UNI header |
| Agents | the trust and assurance system | Mint through a catalog and embed the UNI in every artifact produced |
Every surface in registry/nexus-standards.yaml#surfaces declares its embedding. A surface without a declared embedding is non-compliant. The registry states what the standard specifies; each implementation reports its own status per standard in registry/consumers.yaml.
The open-standards stack
registry/open-standards-stack.yaml fixes the external standards and indexes under the UNI. An implementation crosswalks a record to Zenodo deposition metadata, the DataCite Metadata Schema (4.5 or later), Schema.org JSON-LD (for landing pages and dataset search), CodeMeta 3.0 and the Citation File Format 1.2.0; the reference CLI shows the Zenodo and DataCite mappings (node tools/nexus-id.mjs export). A deposit to Zenodo takes place only after the legal gate (legalState APPROVED, access open or embargoed, an SPDX licence) and is a publication act of the publisherRef institution. The returned DOI is written back as relatedIdentifiers[IsIdenticalTo, DOI], so that the UNI stays the key and the DOI is the citable crosswalk. Every external service an implementation calls requires legal clearance by the implementing institution first.
Surface hooks (NS-6): panels carry uni for every projected record and link it; passports carry the uni field first in the shared identity section; every JSON API response with a uni carries X-Nexus-UNI; the resolver serves landing pages and exports. Risk record UNIs use the NS-1 grammar for new records, with dotted ids kept as legacyUni (NS-3).
Relationship to the other standards and policies
- Marks policy (
governance/OPEN_BOUNDARY_IPR_AND_LICENSING.md, section 7): public display names and trademark safety. NS-1 is the machine layer underneath it; the two do not contradict each other because codes are never names. - Claim ceiling:
claimCeilingon every record never exceeds what the publishing implementation can evidence (NS-11, NS-14). - Legal state and rights:
legalState,publisherRefandrights.licenseare set by the publishing institution from its own legal records. - Record UNIs (NS-3): artifacts are allocated by a catalog (a reconstructable source, served by the resolver); risk records are allocated by the record allocation authority of the implementation that holds them (
registry/nexus-standards.yaml#recordAllocation). - Work packages: every work package lists the UNIs it creates or changes in
evidenceOutputs.
Follow-on work
Drafted (PROPOSED): NS-2 citation and attribution; NS-3 risk record UNIs; NS-3b STAC, DCAT and PROV-O profile; NS-4 structure and drafting with uni front matter; NS-5 figure, map and visualization standard (with the UI/UX kit); NS-9 to NS-16. Specified in this standard: NS-6 surface wiring (section 6) and NS-7 resolver landing pages (section 1). Open: adoption of a record allocation authority by every ingest path of each implementation; NS-7b page meta tags and sitemap profile; NS-8 Zenodo publishing workflow with legal gate, DOI write-back and Software Heritage archival.
Changes between versions
One published version is available (0.1.0); a comparison between versions is shown once a second version is published.
Clause numbers follow the sections of the document; rule identifiers (NS1-R1, NS1-R2, NS1-R3…) are stable anchors. With script enabled, each clause and rule has a permalink and a machine-readable view (YAML and JSON), and the j and k keys move between clauses.
Programme areas that list NS-1
10 programme areas list NS-1.
- Water risk standardsTierNexus domainsStatusplanned
- Energy risk standardsTierNexus domainsStatusplanned
- Food and agriculture risk standardsTierNexus domainsStatusplanned
- Health risk standardsTierNexus domainsStatusplanned
- Biodiversity and nature risk standardsTierNexus domainsStatusplanned
- Climate risk standardsTierNexus domainsStatusplanned
- Research, academia and educationTierSectors and industriesStatusplanned
- Identification (the UNI)TierCross-cutting capabilitiesStatuswired
- GCRI Canada evidence pathwayTierReadiness pathwaysStatusplanned
- Registries and the resolverTierInfrastructure servicesStatusplanned
Recent research on NS-1
Recent peer-reviewed articles, preprints, datasets and reports on the subject of this standard, 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 termspersistent identifier; persistent identifiers; digital object identifier; PID infrastructure; PID graph; DataCite Metadata Schema; in-toto Attestation Frameworkcombined with: research; data; metadata; infrastructure; FAIRDerived from the subject of the standard and its rules, and the external standards of its crosswalk domains.
- 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.
NS-1 in the standards repository
The text, schemas, machine-readable files, registry rows, tests and history behind NS-1, on the main branch of the canonical repository. Text, registry, schemas and catalog are CC BY 4.0; tools and tests are Apache-2.0.
Source text
| File | What it holds | Links |
|---|---|---|
standards/NS-1-identifier-and-artifact-catalog.md | NXS-STD-ST-000001 | Raw · History · Suggest an edit |
standards/INDEX.md | status and document of every standard | History |
Schemas
| File | What it holds | Links |
|---|---|---|
schemas/nexus-artifact-record.v1.json | Nexus artifact record (NS-1) | Raw |
schemas/nexus-clause.v1.json | Nexus clause (NS-10) | Raw |
Machine-readable files
| File | What it holds | Links |
|---|---|---|
machine/nexus-risk-ontology.ttl | Turtle (RDF) · 1 mention | Raw · First mention, line 246 |
catalog/artifact-catalog.yaml | catalog records · 4 mentions | First mention, line 2 |
Registry rows
| File | What it holds | Links |
|---|---|---|
registry/ecosystem-coverage.yaml | Nexus ecosystem coverage register (programme B corpus read) · 214 rows or mentions | Line 58 |
registry/nexus-standards.yaml | Nexus Standards NS-1 - the UNI (Unique Nexus Identifier) and artifact catalog · 17 rows or mentions | Line 2 |
registry/subsites.yaml | Nexus Standards subsites - the systemic architecture of nexustandards.com · 10 rows or mentions | Line 37 |
registry/open-standards-stack.yaml | Open-standards and open-source stack under the UNI · 6 rows or mentions | Line 2 |
registry/risk-standards.yaml | 'Nexus Risk Standards: the systemic catalogue' · 3 rows or mentions | Line 26 |
registry/standard-packages.yaml | Standard packages - one package per external open standard on nexustandards.com · 3 rows or mentions | Line 112 |
registry/domains.yaml | Nexus domains (NS-9 context.domains, NS-10 subject selectors) · 2 rows or mentions | Line 5 |
registry/review-investigations.yaml | Circulation for technical review and comment, and the technical review areas · 2 rows or mentions | Line 58 |
registry/risk-standards.source.yaml | 'Nexus Risk Standards: the systemic catalogue' · 2 rows or mentions | Line 27 |
registry/consumers.yaml | Register of implementations of the Nexus Standards · 1 row or mentions | Line 16 |
registry/dags.yaml | Process and pipeline graphs rendered by the site's DAG component (nxs-dag) · 1 row or mentions | Line 36 |
registry/native/nexus-vocabularies.json | register · 1 row or mentions | Line 3900 |
registry/regions.yaml | REGION segment registry (ISO 3166-1 alpha-3 and UN M49) · 1 row or mentions | Line 11 |
registry/roadmap.yaml | Roadmap of the Nexus Standards to the first official release (target 2030) · 1 row or mentions | Line 32 |
registry/sectors.yaml | Sectors and industries (NS-9 context.sectors, NS-10 subject selectors) · 1 row or mentions | Line 5 |
Tests and validators
| File | What it holds | Links |
|---|---|---|
test/nexus-id.test.mjs | test · 2 mentions | Line 11 |
tools/build-catalogue.mjs | tool or validator | Line 249 |
tools/build-risk-standards.mjs | tool or validator | Line 57 |
tools/build-site-pages.mjs | tool or validator | Line 159 |
tools/export-machine.mjs | tool or validator | Line 128 |
tools/nexus-id.mjs | tool or validator | Line 4 |
tools/validate.mjs | tool or validator | Line 5 |
Change history
| File | What it holds | Links |
|---|---|---|
| Commits to the text | every change to the text | · |
CHANGELOG.md | notable changes, by version | · |
release/manifest.json | release manifest with file digests | in-toto statement |
| Releases | tagged releases of the repository | · |
proposals/NXS-STD-PC-000004.json | Context code allocation rules and four domain codes for technology streams: CMP, DTW, SNS, PNT | History |
proposals/NXS-STD-PC-000005.json | Nexus Risk Standards: the systemic catalogue of 124 risk standards across the risk core, the six anchor nexus streams, technology, finance, policy, development, cross-cutting domains, hazards, intelligence, programme and systems | History |
proposals/NXS-STD-PC-000007.json | Native convergence of the Nexus Risk Standards: every classification derived from the Nexus-native authorities (NHS-1, NIS-1, the Risk Master, the Nexus vocabularies, the Nexus Universe, NXOSI and NRM) | History |
Propose a change
| File | What it holds | Links |
|---|---|---|
| Open a proposal on NS-1 | issue form: target, kind, rationale (NS-13) | Template |
| Issue form: comment | issue form | Template |
| Issue form: errata | issue form | Template |
| Issues that mention NS-1 | open and closed | · |
| Pull request template | what a change must carry: target, kind, rationale, validation | · |
CONTRIBUTING.md | pull requests, sign-off and checks | · |
GOVERNANCE.md | how registry codes and texts change | · |
How NS-1 is developed, and how to take part
NS-1 is developed in the open under NS-13 (the stages and gates of NS-13). Working groups draft, councils decide the reserved matters, and anyone may propose a change, comment, submit an implementation report, object or appeal, without membership or fee.
- Who decides what: the decision-rights matrix.
- The process: stages, gates, review windows and appeals.
- Open gateways and calls: how to propose, comment, join a working group or request activation.
- Develop a standard: the development track and the lifecycle of each standard.
- NS-13 in the canonical repository.
Relation to external standards
NS-1 relates to external standards by identifier, clause number and URL (NS14-R1), and directs the reader to the issuing body.
Recent research and sources
Peer-reviewed articles, preprints, reports and datasets on the subject of this standard, 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
- RFC 6852: Affirmation of the Modern Paradigm for Standards
IETF / RFC Editor · 2013 · Standard - The FAIR Guiding Principles for scientific data management and stewardship
Scientific Data · 2016 · Peer-reviewed - The CARE Principles for Indigenous Data Governance
Data Science Journal · 2020 · Peer-reviewed - Making the rules: the governance of standard development organisations and their policies on intellectual property rights
European Commission Joint Research Centre · 2019 · Official publication - RFC 8141: Uniform Resource Names (URNs)
IETF / RFC Editor · 2017 · Standard - FAIR Data Maturity Model: specification and guidelines
Research Data Alliance · 2020 · Official publication - DataCite Metadata Schema 4.5
DataCite · 2024 · Standard - RFC 2026: The Internet Standards Process, Revision 3
IETF / RFC Editor · 1996 · Standard
Related standards and frameworks
- SoftWare Hash IDentifier (SWHID) Specification V1.2; ISO/IEC 18670:2025
Software Heritage; ISO/IEC JTC 1 - W3C Verifiable Credentials Data Model v2.0
W3C Verifiable Credentials Working Group - Sigstore (Cosign, Fulcio, Rekor)
OpenSSF (Linux Foundation); graduated project March 2024 - DataCite Metadata Schema 4.5
DataCite Metadata Working Group - UN M49 Standard country or area codes for statistical use
United Nations Statistics Division - in-toto Attestation Framework
in-toto project (CNCF) - W3C Decentralized Identifiers (DIDs) v1.0
W3C DID Working Group - Research Organization Registry (ROR)
ROR (California Digital Library, Crossref, DataCite)
Search terms, derived from the subject of the standard and its rules: persistent identifier; persistent identifiers; digital object identifier; PID infrastructure; PID graph; combined with: research; data; metadata; infrastructure; FAIR. With JavaScript enabled, recent works matching these terms are listed from OpenAlex and Crossref.
Risk Academy courses and disciplines
1 course and 2 disciplines of Risk Academy (risksacademy.com) that teach the knowledge and methods of NS-1. Each course lists its level, stream and learning hours.
Courses
Disciplines
The correspondence between courses, disciplines and the Nexus Standards is maintained with Risk Academy and is subject to its academic review.
Programmes, tracks and courses for this standard
GCRI Canada and Risk Academy work on the subject of NS-1 in distinct roles (research and evidence; education and training). Each entry states why it corresponds and the step it offers; each institution sets its own terms of participation.
Research and evidence
GCRI Canada
Research programmes that produce the observations, models and assessments these records describe.
Nexus RegistryMaintains record provenance and registry interoperability.Apply to this programme therisk.globalAll programmes of GCRI CanadaEducation and training
Risk Academy
Courses and disciplines that teach the knowledge and methods practitioners need to apply these standards.
Technology and DataRAT-204 · Intermediate · 19 learning hoursManaging risk data, AI, digital infrastructure and technology risk responsiblyTake this course All courses and disciplinesListed in the education and training section of this pageQuestions and answers.
What is the status of NS-1?
What does applying NS-1 establish?
How is a change to NS-1 proposed?
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.
- GatewayGW-STDSend 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 Nexus Reports community. Curators review it there; the DOI stays yours.
- Nexus 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.
The same subject across the Consortium.
- GCRI Canadatherisk.globalRegistry interoperabilityMethods, data and models
- GRAglobalriskalliance.comData engineering, interoperability and stewardship for financial crime and fraud riskExposure, loss and capital
- Risk Academyrisksacademy.comRisk information standards and interoperabilityWhere it is taught
Around the Nexus Standards.
Take part in the standards.
Governments, regulators, standards bodies, industry, academia and communities are invited to shape the catalogue ahead of its first official release, targeted for 2030: comment on a draft, propose a change, join a working group or host a field exercise.
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.