# IX. Governance

### Part 9 — NRM Governance Discipline

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

1.1 **Status.** This Part defines the mandatory governance discipline (“NRM posture”) for how the Guild turns web observables into publishable findings, benchmarks, and enterprise-grade Assurance & Evidence Packs (AEPs) under validity-by-record.

1.2 **Objective.** The objective is to ensure every consequential output is:\
1.2.1 **testable** (methods and criteria are explicit),\
1.2.2 **traceable** (lineage and provenance are recorded),\
1.2.3 **contestable** (appeals and disputes are structurally supported),\
1.2.4 **correctionable** (no silent edits; supersession discipline), and\
1.2.5 **safe** (rights-preserving, dual-use controlled, competition-safe).

1.3 **Boundary conditions (mandatory).** NRM discipline governs records, evidence, and releases. It does not:\
1.3.1 command operational response;\
1.3.2 determine legal compliance;\
1.3.3 substitute for enterprise risk acceptance processes;\
1.3.4 create certification, endorsement, or procurement preference;\
1.3.5 authorize surveillance or enforcement.

***

#### 2. The NRM Operating Loop (Web Domain Implementation)

2.1 **Loop.** The Guild operates a six-phase loop, applied to web intelligence:\
2.1.1 **Sense** (measure and observe under the Collection Doctrine),\
2.1.2 **Evidence** (package observables + tests + provenance),\
2.1.3 **Scenario** (model plausible impacts and coupling pathways),\
2.1.4 **Decision** (issue a bounded determination only where permitted),\
2.1.5 **Route** (deliver evidence and recommendations as non-executing artifacts),\
2.1.6 **Learn** (update benchmarks, methods, and controls via correction discipline).

2.2 **Gates.** Movement between phases requires explicit gates:\
2.2.1 a recorded scope statement;\
2.2.2 a handling class election;\
2.2.3 declared reliance bounds;\
2.2.4 quality ladder assignments (Evidence Sufficiency, Reproducibility);\
2.2.5 misuse resistance and rights impact checks.

2.3 **Separation of roles.** Measurement, analysis, review, and release authority must be separable functions, even if performed by the same individual in small-scale contexts, by requiring distinct records and reviewer attestations.

***

#### 3. Record Types and Validity-by-Record Rules

3.1 **Validity principle.** Any output presented as Guild output must be supported by a valid record chain. Records are the governing substrate. No record chain, no Guild output.

3.2 **Canonical record types (minimum).**\
3.2.1 **Direction Record** (purpose, scope, intended users, exclusions).\
3.2.2 **Collection Record** (methods, windows, rate limits, lawful basis posture, minimization decisions).\
3.2.3 **Processing Record** (normalization steps, deduplication, enrichment rules, tool versions).\
3.2.4 **Analysis Record** (tests run, criteria, uncertainty disclosure, bias controls).\
3.2.5 **Review Record** (peer review notes, red-team findings, safety and rights checks).\
3.2.6 **Release Record** (artifact list, hashes, labels, handling class, reliance bounds, distribution log).\
3.2.7 **Correction Record** (errata, withdrawal, supersession, remediation notes).\
3.2.8 **Dispute Record** (challenge submission, evidence, outcome, dissent entries).\
3.2.9 **Benchmark Method Record** (methodology, sampling, anti-gaming posture, drift controls).\
3.2.10 **Benchmark Result Record** (computed outputs with method + version pinning).

3.3 **Distribution log requirement.** All controlled or restricted releases require distribution logging (who received, when, what handling class, expiry where applicable), consistent with the Guild’s handling discipline.

3.4 **Authority marking.** Every determination-grade statement must carry:\
3.4.1 issuing role marker;\
3.4.2 scope and time validity;\
3.4.3 reliance bounds;\
3.4.4 correction and contestation path.

***

#### 4. Decision Records (Bounded Determinations)

4.1 **When permitted.** A Decision Record may be issued only to express a bounded determination about:\
4.1.1 a measurement outcome;\
4.1.2 a risk finding within stated uncertainty;\
4.1.3 a benchmark result;\
4.1.4 a release eligibility decision (e.g., “Release-Ready”).

4.2 **Decision Record minimum fields.**\
4.2.1 decision statement (plain language + structured form);\
4.2.2 authority marker (role + review chain);\
4.2.3 scope, exclusions, and assumptions;\
4.2.4 time window (as-of, validity duration);\
4.2.5 evidence references (AEP ID(s), dataset IDs, test harness IDs);\
4.2.6 uncertainty declaration (confidence intervals, false positive/negative posture);\
4.2.7 reliance bounds (R0–R4 label + explicit “prohibited uses”);\
4.2.8 handling class and dissemination controls;\
4.2.9 dissent register link (if any);\
4.2.10 correction path and triggers.

4.3 **No implied compliance.** Decision Records must not be framed as regulatory compliance determinations or operational directives.

***

#### 5. Assurance & Evidence Packs (AEPs)

5.1 **Definition.** An AEP is the Guild’s sealed, enterprise-grade evidence package that:\
5.1.1 binds observables to tests and methods,\
5.1.2 discloses uncertainty and limitations, and\
5.1.3 supports contestability and correction.

5.2 **AEP structure (minimum).**\
5.2.1 **Cover sheet** (AEP ID, version, date, handling class, reliance bounds).\
5.2.2 **Claim set** (what is asserted; what is not asserted).\
5.2.3 **Scope and sampling** (what was measured, where, and how).\
5.2.4 **Method bill of materials (BOM)** (tools, versions, parameters, test harness IDs).\
5.2.5 **Observables bundle** (raw or summarized, with redaction rules disclosed).\
5.2.6 **Evidence and tests** (results, thresholds, pass/fail logic where applicable).\
5.2.7 **Lineage and provenance** (source pointers, transformations, hashes).\
5.2.8 **Uncertainty statement** (confidence intervals, error budgets, known blind spots).\
5.2.9 **Rights and safety review** (privacy minimization, dual-use check, competition safety).\
5.2.10 **Conclusions (bounded)** (risk findings framed as bounded statements, not directives).\
5.2.11 **Correction metadata** (correction clocks, triggers, supersession rules).\
5.2.12 **Contestability** (how to dispute; what evidence is required; response timelines).

5.3 **AEP sealing rules.**\
5.3.1 AEPs must be version-locked; any changes require supersession.\
5.3.2 AEPs should be content-addressed (hash) and signed for Release-Ready and above.\
5.3.3 AEPs must reference GRIx-Web objects and ontology versions.

5.4 **AEP reliance discipline.** AEPs must embed “safe-use” language, including:\
5.4.1 “no single-source decisions,”\
5.4.2 “independent verification required,”\
5.4.3 explicit prohibited actions based solely on the AEP.

***

#### 6. Evidence Sufficiency Ladder (E0–E4)

6.1 **Purpose.** The ladder standardizes what evidence can support what level of claim.

6.2 **Levels.**\
6.2.1 **E0 — Unverified observation.** Raw signals; not suitable for claims beyond “observed.”\
6.2.2 **E1 — Basic verification.** Minimal checks; suitable for low-stakes triage.\
6.2.3 **E2 — Corroborated evidence.** Multi-source verification; suitable for enterprise internal use with caution.\
6.2.4 **E3 — Audit-ready evidence.** Method-pinned, replayable core components; suitable for board-level reporting and external assurance contexts (still non-certifying).\
6.2.5 **E4 — Benchmark-grade evidence.** Strong anti-gaming controls, robust sampling disclosure, drift controls; suitable for public comparative publication with error budgets.

6.3 **Mandatory disclosure.** Every AEP and benchmark output must declare its E-level and what the level does and does not permit.

***

#### 7. Reproducibility Ladder (RS0–RS4)

7.1 **Purpose.** The ladder communicates what can be replayed and by whom.

7.2 **Levels.**\
7.2.1 **RS0 — Not reproducible.** Narrative only; discouraged except for controlled briefings.\
7.2.2 **RS1 — Partially reproducible.** Methods described; some dependencies missing.\
7.2.3 **RS2 — Internally reproducible.** Guild can replay with retained assets.\
7.2.4 **RS3 — Independently reproducible (bounded).** Third parties can replay with disclosed runbooks and accessible assets (subject to safety constraints).\
7.2.5 **RS4 — Benchmark reproducible.** Full reproducibility posture including sampling, drift controls, and anti-gaming defenses.

7.3 **Reproducibility exceptions.** Where safety or lawful restrictions prevent disclosure, the artifact must:\
7.3.1 state the restriction;\
7.3.2 provide the maximum safe detail;\
7.3.3 provide an alternative validation pathway (e.g., trusted replicators under controlled handling).

***

#### 8. Correction Clocks, Supersession, and No-Silent-Edits

8.1 **No silent edits rule.** Any correction to a published Guild artifact requires:\
8.1.1 a Correction Record, and\
8.1.2 an updated version with supersession pointers.

8.2 **Correction clocks (minimum).**\
8.2.1 **<4 hours:** critical safety errors (misuse enabling detail; high-impact false claims).\
8.2.2 **<72 hours:** material defects (method errors, significant false positives/negatives).\
8.2.3 **<30 days:** non-critical but substantive improvements (expanded sampling, improved mapping).\
8.2.4 **Quarterly:** systematic updates (benchmark recalibration; taxonomy evolution; drift responses).

8.3 **Supersession discipline.**\
8.3.1 superseded artifacts remain accessible with clear “superseded” marking;\
8.3.2 citations must point to the latest valid version, with historical pointers preserved;\
8.3.3 deprecations must include migration guidance where applicable.

***

#### 9. Contestability, Grievance, and Remedy

9.1 **Right to dispute.** Any affected party may submit disputes regarding:\
9.1.1 factual accuracy of observables;\
9.1.2 methodological fairness or bias;\
9.1.3 identity/ownership claims;\
9.1.4 benchmark methodology or anti-gaming posture;\
9.1.5 misrepresentation of Guild outputs by third parties.

9.2 **Dispute minimum requirements.**\
9.2.1 scope and artifact IDs;\
9.2.2 claimed error type;\
9.2.3 proposed correction;\
9.2.4 supporting evidence.

9.3 **Remedy types.**\
9.3.1 correction;\
9.3.2 retraction/withdrawal;\
9.3.3 supersession with revised method;\
9.3.4 publication of dissent;\
9.3.5 limitation notice where uncertainty cannot be resolved.

***

#### 10. Routing and Non-Executing Handoffs

10.1 **Routing definition.** “Route” means packaging outputs so adopters can act under their own authority, without the Guild directing operational action.

10.2 **Permitted handoffs.**\
10.2.1 evidence delivery to enterprise tooling (SIEM/SOAR/GRC/ticketing);\
10.2.2 benchmark and method publication;\
10.2.3 non-binding risk briefs with reliance bounds;\
10.2.4 standards mapping notes and portability guidance.

10.3 **Prohibited handoffs.**\
10.3.1 operational incident command instructions;\
10.3.2 exploit enablement;\
10.3.3 “call to action” directives framed as mandates;\
10.3.4 procurement steering.

***

#### 11. Minimum Controls for High-Impact Outputs

11.1 **Trigger.** An output is “high-impact” if it can plausibly:\
11.1.1 materially affect safety, rights, access, market behavior, or reputations;\
11.1.2 drive large-scale defensive action;\
11.1.3 influence public policy debates or standards agendas.

11.2 **Additional controls.** High-impact outputs require:\
11.2.1 E3+ and RS2+ unless explicitly justified;\
11.2.2 documented anti-gaming posture;\
11.2.3 red-team and misuse resistance review;\
11.2.4 rights impact check;\
11.2.5 elevated release authority sign-off 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/ix.-governance.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.