> 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/vii.-webint-doctrine.md).

# VII. WEBINT Doctrine

Observatory Tradecraft for Web Ecosystems

**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.** Observatory Tradecraft for Web Ecosystems 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.
* Ordinary participation has no fee; selection precedes payment, and a seat never buys office, a technical conclusion, public authority or procurement treatment. Paid work, internships and fellowships are separate arrangements ([NLC](/organization/governance-in-operation/nlc.md); [NWG](/organization/governance-in-operation/nwg.md)).
* 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.
  {% endhint %}

### Part 7 — WEBINT Doctrine

#### 1. Status, Purpose, and Boundary Conditions

1.1 **Status.** WEBINT is a specialized, rights-preserving observatory discipline for web ecosystems. It is designed to support **enterprise-grade risk management and governance** through **measurement, verification, and evidence packaging**—not through enforcement, surveillance, or operations.

1.2 **Purpose.** WEBINT enables continuous, testable intelligence about the web as critical infrastructure by producing artifacts that are:\
1.2.1 **evidence-based** (provenance + tests + uncertainty);\
1.2.2 **contestable** (disputable with structured records);\
1.2.3 **correctable** (no silent edits; clock-based corrections);\
1.2.4 **portable** (usable across jurisdictions and organizations without implied endorsement);\
1.2.5 **safe** (dual-use disciplined; non-exploitative; non-coercive).

1.3 **Boundary conditions (non-negotiable).** WEBINT:\
1.3.1 does **not** conduct covert collection, identity targeting, or individualized surveillance;\
1.3.2 does **not** provide operator incident command, SOC/EOC dispatch, or “live fight” runbooks;\
1.3.3 does **not** issue compliance determinations, legal conclusions, procurement recommendations, or certifications;\
1.3.4 does **not** publish exploit-enabling detail or weaponizable playbooks;\
1.3.5 does **not** substitute for accountable decision-makers—WEBINT informs; adopters decide and act.

1.4 **Observatory ≠ surveillance; intelligence ≠ enforcement.** WEBINT outputs remain measurement and research artifacts. Any enforcement action—if any—is outside the Guild and remains solely within the adopter’s authority and lawful process.

***

#### 2. The WEBINT Cycle (UNOSINT-Aligned Tradecraft)

2.1 **Direction.** Define the question, scope, and harm model before collecting anything:\
2.1.1 decision-use context and reliance bounds;\
2.1.2 measurement boundary and lawful basis posture;\
2.1.3 handling class default and distribution intent;\
2.1.4 abuse-case and dual-use risks;\
2.1.5 success criteria and error budget.

2.2 **Collection.** Gather only what is permitted under measurement doctrine (Part 5):\
2.2.1 public endpoints, public logs, lawful feeds, and consented telemetry;\
2.2.2 non-intrusive scanning with rate limits and stop conditions;\
2.2.3 prohibited methods remain prohibited even if “technically feasible.”

2.3 **Processing.** Normalize and structure information into the ontology spine:\
2.3.1 map observations to canonical objects (asset, endpoint, dependency, certificate, control, event, incident, claim, evidence);\
2.3.2 produce lineage metadata sufficient for replayability;\
2.3.3 enforce minimization and redaction rules.

2.4 **Analysis.** Convert observations into bounded inferences:\
2.4.1 separate **observed facts** from **inferred hypotheses**;\
2.4.2 quantify uncertainty and avoid false precision;\
2.4.3 apply bias controls, drift checks, and cross-source triangulation;\
2.4.4 detect gaming and tampering signals.

2.5 **Dissemination.** Publish with handling discipline and minimum-necessary distribution:\
2.5.1 attach reliance bounds (R0–R4), limitations, and uncertainty;\
2.5.2 use distribution logs for controlled outputs;\
2.5.3 publish correction paths and clocks.

2.6 **Feedback.** Continuously refine:\
2.6.1 incorporate disputes and corrections;\
2.6.2 recalibrate models and benchmarks;\
2.6.3 deprecate unsafe guidance;\
2.6.4 adjust collection boundaries if harm risk shifts.

***

#### 3. Sources, Provenance, and Confidence Discipline

3.1 **Provenance chain requirement.** Every WEBINT product must include a provenance statement:\
3.1.1 source class (public endpoint, public log, lawful feed, consented telemetry, published dataset);\
3.1.2 collection time window and method;\
3.1.3 transformations performed (parsing, normalization, filtering);\
3.1.4 integrity checks (hashes, signatures where applicable);\
3.1.5 known gaps and excluded sources.

3.2 **Confidence and uncertainty.** Outputs must declare:\
3.2.1 confidence level or interval appropriate to the claim;\
3.2.2 expected false positive / false negative posture;\
3.2.3 known biases (coverage, geography, language, sampling);\
3.2.4 sensitivity to drift (how quickly it may become stale).

3.3 **No single-source determinations.** Where consequences are material, WEBINT must:\
3.3.1 require multi-source corroboration; or\
3.3.2 explicitly label as “single-source / uncorroborated” with restricted reliance.

3.4 **Temporal validity.** WEBINT products must include:\
3.4.1 “as-of” timestamps;\
3.4.2 freshness expectations;\
3.4.3 recommended re-validation triggers.

***

#### 4. Intelligence Product Families (Standardized Outputs)

4.1 **Alerts (time-sensitive).** Immediate notice of observed conditions with minimal inference; includes confidence and safe next-step prompts (non-operational).

4.2 **Bulletins (situational).** Summaries of clusters, patterns, or emerging issues with bounded hypotheses and evidence references.

4.3 **Dossiers (structured).** Evidence-packaged views of a defined asset/system/ecosystem segment, including dependencies, risk posture, and drift notes.

4.4 **Trend reports (longitudinal).** Periodic analysis of changes over time with sampling disclosures and comparability controls.

4.5 **Comparative benchmarks.** Reproducible, anti-gamed benchmarking outputs that compare systems against disclosed methodology.

4.6 **Assurance & Evidence Packs (AEPs).** Decision-grade packaging that includes:\
4.6.1 a bill of materials (BOM) of inputs;\
4.6.2 provenance and test results;\
4.6.3 confidence and limitations;\
4.6.4 reliance bounds and handling class;\
4.6.5 correction path and supersession pointers.

4.7 **Method notes (reproducibility-first).** Publishable procedures and test harnesses designed for replayability and independent replication.

***

#### 5. Analytic Integrity Rules (Separation, Bias, and Error Control)

5.1 **Observation–inference separation.**\
5.1.1 label “Observed” vs “Inferred” vs “Speculative”;\
5.1.2 do not collapse uncertainty to single-point claims when not warranted.

5.2 **Bias controls.**\
5.2.1 disclose sampling frame and coverage;\
5.2.2 apply bias tests where benchmarks are comparative;\
5.2.3 document language/regional blind spots;\
5.2.4 avoid using protected-class proxies in ways that can drive discriminatory decisions.

5.3 **Error budgets.** For benchmark-grade outputs, declare:\
5.3.1 acceptable error range;\
5.3.2 expected false-positive/false-negative rates;\
5.3.3 drift detection thresholds.

5.4 **Tampering and gaming detection.**\
5.4.1 monitor for adversarial responses to measurement;\
5.4.2 document suspected gaming;\
5.4.3 adjust methodology with disclosure and supersession discipline.

5.5 **No coercive governance engineering.** WEBINT does not design censorship machinery or coercive moderation blueprints. It measures integrity conditions and publishes evidence, limitations, and remediation patterns that preserve rights.

***

#### 6. Dissemination Controls: Handling, Distribution, and Safe Release

6.1 **Handling class assignment.** Every WEBINT product must declare Public-safe / Controlled / Restricted with rationale.

6.2 **Distribution logs.** Controlled and Restricted products require:\
6.2.1 recipient class definition (who may receive);\
6.2.2 logged distribution;\
6.2.3 expiry or review date.

6.3 **Minimum necessary release.** Publish only what is needed to support legitimate risk governance and reproducibility—no excess detail.

6.4 **Dual-use calibration.**\
6.4.1 abstract exploit-adjacent detail;\
6.4.2 delay publication when active exploitation is plausible;\
6.4.3 coordinate with disclosure interfaces when applicable.

6.5 **Non-endorsement language.** WEBINT outputs must include non-certification and non-endorsement notices appropriate to the artifact type.

***

#### 7. Contestability, Grievance, and Correction Integration

7.1 **Contestability by design.** WEBINT outputs must be disputable:\
7.1.1 include contact path for dispute submission;\
7.1.2 include evidence references sufficient for rebuttal;\
7.1.3 include version identifiers and supersession pointers.

7.2 **Correction clocks (minimum).**\
7.2.1 critical factual errors: <4 hours for correction notice;\
7.2.2 significant errors affecting conclusions: <72 hours;\
7.2.3 method/data issues requiring rebuild: <30 days;\
7.2.4 periodic recalibration and deprecations: quarterly.

7.3 **No silent edits.** All corrections must create a record with:\
7.3.1 what changed;\
7.3.2 why it changed;\
7.3.3 impact on prior outputs;\
7.3.4 migration guidance where relevant.

7.4 **Remedy posture.** Remedy is informational and record-based: corrected artifacts, clarified reliance bounds, deprecation, and distribution of corrected notices—never coercive enforcement.

***

#### 8. WEBINT Safety Constraints for AI-Assisted Work

8.1 **Disclosure.** If AI tools are used to assist analysis or drafting:\
8.1.1 the use must be disclosed internally in the work record;\
8.1.2 outputs must be verified against sources;\
8.1.3 hallucination tolerance is zero for factual claims.

8.2 **Tool boundaries.** AI tools may propose summaries, checks, and comparisons, but may not be used to:\
8.2.1 generate exploit-enabling material;\
8.2.2 fabricate evidence;\
8.2.3 infer identity or target individuals;\
8.2.4 replace declared uncertainty with false certainty.

***

#### 9. Interoperability with Ontology and Governance Spine

9.1 **Ontology linkage.** WEBINT products must map to canonical objects to ensure interoperability and replayability.

9.2 **Governance linkage.** WEBINT products must be packagable into AEPs and decision records under the governance discipline, including handling and reliance bounds.

9.3 **Non-equivalence warnings.** Where WEBINT maps to standards terms (W3C/IETF/ICANN, security or privacy frameworks), it must state non-equivalence unless strict equivalence is proven and recorded.

## 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/vii.-webint-doctrine.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.