Nexus Standards · Verification and monitoring · Conformance
Verification and monitoring
How an implementer in verification and monitoring demonstrates conformance: a self-assessment against the rules, clauses evaluated from evidence, attestations and a generated report. Each result names its evaluator and the time of evaluation, and each artifact is identified by a UNI (Unique Nexus Identifier).
The programme areas of this tier against the standards they list in the registry; the row for this area sets the initial scope of a self-assessment.
Coverage matrixA filled cell indicates that the area lists the standard in the registry. Status terms are those of the registry.
The map frames India as an example geography for verification and monitoring; the frame gives context and is not a statement of where the standards apply. Shown at first: flood water, 3-day composite (VIIRS Global Flood Product, NASA LANCE); active fires and thermal anomalies, last day (VIIRS NOAA-20 375 m, FIRMS, NASA LANCE FIRMS); and population density, 2020 (Gridded Population of the World v4.11, NASA SEDAC, CIESIN, Columbia University). The layer drawer adds land surface temperature, day, 8-day composite (VIIRS NOAA-20 Level 3, 8-day); night-time lights, daily (VIIRS Black Marble, VNP46A2); and aerosol optical depth, daily (VIIRS NOAA-20 Deep Blue AOD). 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 CISA Known Exploited Vulnerabilities catalogue and OSV.dev vulnerability API, are listed for reference.
The interactive map needs JavaScript; the layer list and sources are below.
Layers 3
Hazards and exposure
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.
Hazards and exposure, framed on India. 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.
Layers and dates
Fig.Subject, clauses, evaluator, attestation and report; decisions of competent authorities remain outside the flow.
An implementation conforms to NS-0 when it:
registry/consumers.yaml truthfully; andlegalState, claimCeiling, status) on every record it publishes.Conformance to NS-0 is a statement by the implementation, verifiable under NS-11. It is not a certification by the Secretariat or by the Global Standards Council.
The first rules of each applicable standard. A self-assessment is a statement by the implementer, verifiable under NS-11.
| Rule | Requirement | Standard |
|---|---|---|
NS11-R1 | A conformance statement shall rest on an attestation, and an attestation shall name an evaluator, a mandate, evidence references and a digest. | NS-11 |
NS11-R2 | Under zero trust, subject and evaluator shall be distinct, and production evaluations shall run outside the subject's trust boundary. | NS-11 |
NS11-R3 | Missing or unresolvable evidence shall yield INDETERMINATE or REFUSED, never PASS (NS0-P12). | NS-11 |
One attestation is recorded per clause, per subject, per evaluation (AT category, append-only). Results: PASS; FAIL; INDETERMINATE (evidence missing or unresolvable); NOT_APPLICABLE (the subject was outside the clause's selectors at that instant); REFUSED (the evaluator lacked a mandate or the evidence was not accessible; the refusal is itself recorded). An attestation carries a canonical digest and, optionally, a signature; certifiesTruth is always false. A later attestation supersedes an earlier one for the same clause and subject, and the history is kept.
Crosswalks: an attestation can be exported as a W3C Verifiable Credential under the Verifiable Credentials Data Model 2.0 (subject: the contextual UNI; issuer: the evaluator; evidence: the refs), as an in-toto attestation (for software subjects) or as a PROV-O activity (NS-3b). The Nexus attestation remains the key and the record of truth.
Monitoring is continuous evaluation together with observation records. For each bound policy and context, the monitoring service records (a) the latest attestation per clause, (b) coverage (which clauses have no current attestation, and why), (c) drift (a change in a subject's records that invalidates an attestation) and (d) the availability of evaluators and evidence sources. Monitoring records are observations with record UNIs. Dashboards and panels are projections of them and show the timestamp and the evaluator for every value; no verdict is stored.
A conformance report for a context is generated, not written: policy by policy and clause by clause, with attestation UNIs, evidence refs, conformance levels (NS-10 section 3) and the honesty fields. Reports are catalogued artifacts (RP) and may be published (NS-8) only when their legalState allows. A report does not say "certified" or "compliant" except when it quotes an authority decision by reference.
A context (NS-9) or artifact claims a relation to an external standard only through a clause set (NS-10) that cites that standard and is evaluated (NS-11). The claim is displayed as "implements clauses derived from <standard> (n of m with a current PASS)", with attestation UNIs. It is never displayed as "compliant with" or "certified to" unless a decision of the body entitled to say so is referenced. Where a body operates its own certification, conformance under the Nexus Standards is explicitly not that certification.
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.
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.
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.