> For the complete documentation index, see [llms.txt](https://docs.therisk.global/organization/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.therisk.global/organization/cooperation/nexus-guilds/future-of-web/iv.-coverage.md).

# IV. Coverage

**Where this fits:** all six sectors ([The Model](/organization/model.md)) · [Labs](/organization/programme/labs.md), [Risk Academy](/organization/programme/academy.md) · communities of practice by sector, supplying the questions of the Labs pillar; National Working Groups ([NWG](/organization/governance-in-operation/nwg.md)) · community of practice.

**In brief.** Read against the international frameworks it serves ([UN General Assembly 2015](https://www.undrr.org/publication/sendai-framework-disaster-risk-reduction-2015-2030); [FAO 2014](https://www.fao.org/4/bl496e/bl496e.pdf); [One Health High-Level Expert Panel (OHHLEP) et al. 2022](https://doi.org/10.1371/journal.ppat.1010537)) and the [Nexus Standards](/organization/institutions/nexus-standards.md) that govern its records ([NS-0](https://nexustandards.com/standards/ns-0/), [NS-13](https://nexustandards.com/standards/ns-13/)). "An experiment is exploratory: its results are labelled as such and become evidence only after the Foundry rebuilds and the Universe tests them." (Labs pillar boundary). Ordinary participation has no fee. Paid work, internships and fellowships are separate arrangements, and unqualified contributors never take safety-critical tasks.

{% hint style="info" %}
**Read with the current model (2026-10-21).**

* Everything this page describes is a design in formation. No national, regional or global consortium is recorded as constituted or active; the current service level is R0, information and enquiries ([Status and service levels](/organization/governance-in-operation/status-and-service-levels.md)). Where the text below reads as operation, read it as design.
* Recognition, scoring and validation record what was shown under stated conditions. None is a certification, licence, rating or approval, and no country or institution is ranked.
* Completion is recorded, not credentialed, until [Risk Academy](/organization/institutions/risk-academy.md) has an issuer, an assessment method and a revocation path on record; GCRI Canada is issuer of record ([Risk Academy](/organization/programme/academy.md)).
  {% endhint %}

### Part 4 — Platform Coverage Map: End-to-End Web Stack

#### 1. Coverage Taxonomy

1.1 **System-of-systems definition.** The web is treated as a coupled, multi-layer infrastructure system spanning: naming and addressing, transport and routing dependencies, hosting and compute concentration, application surfaces, identity and trust primitives, software supply chains, data rights and consent mechanisms, AI-mediated interaction, authenticity and information integrity, and accessibility and inclusion.

1.2 **Coverage boundary.** Coverage is limited to lawful, non-intrusive observatory methods and research-grade analysis. The Guild does not conduct operational enforcement, does not run incident command, and does not perform regulated compliance determinations.

1.3 **Measurement unit-of-analysis.** Measurements are organized around canonical “objects” (Part 8) including assets, endpoints, dependencies, certificates, controls, events, incidents, claims, evidence, and determinations—each with provenance, confidence, limitations, and correction pathways.

1.4 **Domains and lanes.** Platform coverage is defined as domains and lanes, each with:\
1.4.1 permitted inputs;\
1.4.2 standard metrics and uncertainty posture;\
1.4.3 artifact outputs (alerts, reports, benchmarks, AEPs);\
1.4.4 default handling class;\
1.4.5 anti-gaming controls and contestability hooks.

1.5 **Cross-cutting invariants.** All domains must comply with: rights safeguards, contestability, privacy minimization, neutrality, correctionability, reproducibility, dual-use safety, and non-execution perimeter.

***

#### 2. Domains and Lanes (v1.0)

**2.1 Core Internet Infrastructure**

2.1.1 **Scope.** DNS/DNSSEC posture; registries/registrars; resolution integrity; authoritative nameserver diversity; CDN/edge dependencies; hosting/cloud concentration; time/NTP dependencies; dependency coupling and single points of failure.\
2.1.2 **Primary outputs.** Dependency maps; concentration indicators; misconfiguration prevalence; outage cascade models (research-grade); time-to-recover statistics (observed); comparative infrastructure benchmarks.\
2.1.3 **Non-equivalence warning.** Infrastructure concentration metrics are not an “availability guarantee” and do not imply operator fault or negligence.

**2.2 Web Security Engineering**

2.2.1 **Scope.** OWASP web/app/API exposure; attack surface measurement; secure headers and policy controls (CSP, HSTS, SRI where observable); authentication/session pattern risk research; observable vulnerability signals; incident and campaign intelligence (research products); measurement of supply chain exposure (by observation, not exploitation).\
2.2.2 **Outputs.** Risk heatmaps; control prevalence baselines; comparative benchmarks; advisory patterns (non-operational); AEPs for security posture determinations.\
2.2.3 **Dual-use limit.** Publication is abstracted to avoid exploit enablement; the Guild does not publish step-by-step exploit playbooks.

**2.3 Software Supply Chain Integrity**

2.3.1 **Scope.** Third-party script prevalence; dependency ecosystems and transitive exposure; SBOM/SLSA adoption signals; signing and provenance patterns; update channel integrity research; drift and dependency churn metrics.\
2.3.2 **Outputs.** Supply chain exposure indices; provenance adoption baselines; third-party script risk profiles (research-grade); reproducible datasets and benchmark batteries.

**2.4 PKI, Certificates, and Trust Stores**

2.4.1 **Scope.** TLS configuration baselines; certificate issuance posture; certificate transparency (CT) signal integration; revocation realities measurement; CA incident intelligence (public sources); root store drift; post-quantum transition readiness hooks (observables only).\
2.4.2 **Outputs.** Certificate hygiene metrics; configuration prevalence; risk posture comparisons; AEPs for PKI determinations with explicit uncertainty and limitations.

**2.5 Privacy, Data Rights, and Consent Systems**

2.5.1 **Scope.** Tracker ecology; cookie and local storage patterns; fingerprinting indicators (observable); consent UX patterns (research-grade); data flow mapping by observable calls; cross-border transfer signals where lawful and inferable; privacy policy structure analysis (non-legal).\
2.5.2 **Outputs.** Privacy exposure heatmaps; consent pattern benchmarks; vendor ecosystem mapping; rights-preserving guidance patterns (non-advice) with non-equivalence warnings.\
2.5.3 **Strict boundary.** Outputs are not legal determinations of compliance and must not be represented as such.

**2.6 Identity, Authentication, and Trust**

2.6.1 **Scope.** Passkey and phishing-resistance adoption signals; session integrity patterns; account recovery safety research; observable fraud patterns; DID/VC interoperability research; identity minimization patterns.\
2.6.2 **Outputs.** Adoption baselines; risk pattern catalogues; comparative benchmarks; AEPs for identity posture determinations (research-grade).

**2.7 AI-on-Web and Agentic Web Risks**

2.7.1 **Scope.** Synthetic content prevalence measurement; bot and agent traffic indicators (research-grade); prompt injection surface patterns; AI API security posture signals; model/system transparency patterns; containment patterns for agentic workflows (observed claims and published configs where available); provenance linkage to authenticity mechanisms.\
2.7.2 **Outputs.** AI risk observatory reports; agentic risk pattern library; authenticity coupling analyses; benchmark batteries for detection methods with anti-gaming controls.\
2.7.3 **Boundary.** The Guild does not publish evasion playbooks; detection methods are disclosed with misuse resistance.

**2.8 Content Authenticity and Information Integrity**

2.8.1 **Scope.** Provenance mechanisms (C2PA and adjacent) adoption signals; credential verification patterns (where public); source attribution and edit-history patterns (where observable); coordinated inauthentic behavior measurement (research-grade); crisis communications resilience patterns; credibility attack resistance without censorship blueprinting.\
2.8.2 **Outputs.** Provenance adoption baselines; authenticity workflow patterns; integrity benchmarks; AEPs for integrity determinations with contestability routes.

**2.9 Web3, Decentralization, and dApps**

2.9.1 **Scope.** Smart contract risk research (from public code and audits); oracle and bridge pattern analysis; governance concentration metrics; wallet/key management safety patterns (education-grade); decentralization measurement approaches; ENS/DNS coupling where relevant.\
2.9.2 **Outputs.** Protocol risk profiles (research-grade); audit intelligence summaries (non-advice); bridge/oracle exposure indices; reproducible datasets and benchmark suites.\
2.9.3 **Boundary.** No trading signals, no market manipulation cues, no operational exploitation guidance.

**2.10 Accessibility and Digital Inclusion**

2.10.1 **Scope.** WCAG conformance research (automated testing limitations disclosed); assistive tech compatibility signals where testable; cognitive accessibility patterns; low-bandwidth and offline resilience patterns; multilingual inclusion indicators.\
2.10.2 **Outputs.** Accessibility benchmarks with error budgets; improvement pattern libraries; inclusion baselines; education labs and reproducible test harnesses.

**2.11 Performance, Reliability, and Resilience Engineering**

2.11.1 **Scope.** Core Web Vitals research; endpoint availability measurement (non-intrusive); outage cascade modeling (research-grade); SLO/SLA pattern catalogues (informational); graceful degradation patterns; dependency shock propagation (observational).\
2.11.2 **Outputs.** Performance benchmarks; reliability indices; incident/outage observatory reports; AEPs for resilience determinations.

**2.12 Standards, Governance, and Regulatory Interoperability**

2.12.1 **Scope.** W3C/IETF/ICANN standards intelligence; standards adoption mapping; policy-to-tech translation hooks (informational only); portability notes; non-equivalence warnings; cross-jurisdiction terminology mapping.\
2.12.2 **Outputs.** Standards trackers; interoperability maps; implementation pattern libraries; research briefs designed for neutral reuse.

**2.13 Measurement, Benchmarks, and Observatory Science**

2.13.1 **Scope.** Sampling methods; bias controls; drift monitoring; confidence interval discipline; longitudinal comparability; error budgets; benchmark anti-gaming; appeals and contestability design.\
2.13.2 **Outputs.** Benchmark frameworks; dataset quality reports; measurement safety standards; reproducibility assets (RS ladder) and evidence sufficiency mappings (E ladder).

***

#### 3. Cross-Cutting Invariants (Mandatory Across Domains)

3.1 **Rights safeguards.** Privacy minimization, non-discrimination, accessibility-first posture, and due process by contestability.\
3.2 **Neutrality.** No vendor preference, no procurement steering, no certification posture, no endorsement lists.\
3.3 **Correctionability.** No silent edits; corrections and supersessions are recorded and distributed with version pointers.\
3.4 **Reproducibility.** Methods, data lineage, and environments are documented to the declared RS level; limitations are explicit.\
3.5 **Dual-use safety.** Abstraction and controlled detail; coordinated disclosure interfaces; “do not deploy if…” gates.\
3.6 **Separation of roles.** Observatory outputs inform; adopters decide and execute under their authority; the Guild does not dispatch, enforce, or operate.

## Sources

1. UN General Assembly (2015). Sendai Framework for Disaster Risk Reduction 2015–2030. A/RES/69/283, 3 June 2015. <https://www.undrr.org/publication/sendai-framework-disaster-risk-reduction-2015-2030>
2. FAO (2014). The Water-Energy-Food Nexus: A new approach in support of food security and sustainable agriculture. Rome: Food and Agriculture Organization of the United Nations. <https://www.fao.org/4/bl496e/bl496e.pdf>
3. One Health High-Level Expert Panel (OHHLEP), Adisasmito, W. B. et al. (2022). One Health: A new definition for a sustainable and healthy future. PLoS Pathogens 18(6): e1010537. doi:10.1371/journal.ppat.1010537. <https://doi.org/10.1371/journal.ppat.1010537>
4. Nexus Standards. NS-0: Constitution and principles. Status: PROPOSED; UNI `NXS-STD-ST-000004`. <https://nexustandards.com/standards/ns-0/>
5. Nexus Standards. NS-13: Open standards development process. Status: PROPOSED; UNI `NXS-STD-ST-000008`. <https://nexustandards.com/standards/ns-13/>
6. GCRI. The Labs pillar home. <https://therisk.global/nexus-labs/>
7. GCRI. Working groups (NWG). <https://therisk.global/consortium/national/nwg/>
8. This documentation: [Governance in operation](/organization/governance-in-operation.md); [The Model](/organization/model.md); [historical labels](/organization/reference.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.therisk.global/organization/cooperation/nexus-guilds/future-of-web/iv.-coverage.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.