# VII. WEBINT Doctrine

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


---

# Agent Instructions: Querying This Documentation

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

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.therisk.global/organization/cooperation/nexus-guilds/future-of-web/vii.-webint-doctrine.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.