# XVI. Reporting

### Part 16 — iVRS (Integrated Value Reporting System)

*(iVRS is the Platform’s “operational truth layer”: a record-valid, handling-aware health and integrity telemetry system that publishes what is known, what is not known, what changed, and what is contestable—without becoming marketing, endorsement, or a compliance claim.)*

#### 16.1 Purpose, Scope, and Design Principles

16.1.1 **Operational truth layer.** iVRS is the operational truth layer for a public-good evidence commons: it reports the health, integrity, safety posture, learning velocity, and measurable impact of the commons in a form that is replayable and contestable under scrutiny.\
16.1.2 **Objectives.** iVRS optimizes for: (a) integrity-by-record; (b) safety and do-no-harm; (c) learning velocity and correctionability; (d) reproducibility and comparability; (e) equity/accessibility; and (f) trust-under-scrutiny across helixes and jurisdictions.\
16.1.3 **Voluntary participation baseline.** Reporting participation is voluntary except where minimum reporting is necessary to preserve record-integrity, handling duties, and lawful minima (e.g., incident disclosures within constraints). Identity disclosure is not compelled beyond lawful/handling requirements.\
16.1.4 **Binding “Not marketing” rule.** iVRS outputs are bindingly non-marketing: every report must include uncertainty, limitations, reliance bounds, expiry, correction status, and non-endorsement. Promotional framing and “selective success” narratives are prohibited.\
16.1.5 **System relationships.** iVRS integrates with CRS (Part 15), PoC (Part 11), ILAs (Part 10), and Quality/Badging (Part 17). iVRS does not override handling or due process and must not imply certification, audit opinion, regulatory acceptance, or operational authorization.

***

#### 16.2 iVRS Data Model and Reporting Units

16.2.1 **Report objects.** Canonical iVRS report objects include: **Guild Reports**, **CCell Reports**, **CERT Reports**, **Convening Reports**, and **Release Reports** (with optional cross-Guild federation reports where designated).\
16.2.2 **Scope fields.** Every report includes scope fields: domain; geography (as permitted); reporting entity or lead-of-record; handling class; reliance bounds; expiry/review date; and correction/supersession status.\
16.2.3 **Evidence links.** Reports must attach evidence links: record pointers; artifact hashes/IDs; review logs; replication logs; decision records; and distribution logs when reporting relies on controlled materials.\
16.2.4 **Time semantics.** Reports must include time semantics: as-of timestamp; reporting period; rolling-window selections; and event timestamps for triggered reports (release, dispute, safety hold, incident).\
16.2.5 **Identity minimization compatible reporting.** iVRS separates identities from role markers: reports use role markers and anonymized/aggregated statistics by default, with identity disclosures only in controlled lanes where lawful/necessary.

***

#### 16.3 Core Metrics Framework (What iVRS Measures)

16.3.1 **Integrity metrics.** Record completeness; decision-record coverage; distribution-log completion (where required); correction discipline; supersession timeliness; misrepresentation incidents; sanctions summaries (public-safe).\
16.3.2 **Safety metrics.** Dual-use screening outcomes; handling escalations; safety holds placed/cleared; leak indicators and containment metrics; targeting-cue suppression actions; incident-mode activations.\
16.3.3 **Quality metrics.** Reproducibility pass rates; replication throughput; benchmark pass/fail distributions; reviewer throughput and calibration; backlog health; defect rates and known-issues status.\
16.3.4 **Learning metrics.** ILA participation and completions; PoC progression and renewal posture; clinic participation; drill participation; time-to-competence indicators; re-training triggered by incidents or rule changes.\
16.3.5 **Equity/access metrics.** Language coverage; accessibility accommodation uptake; scholarship/waiver utilization (aggregate); low-bandwidth participation metrics; geographic distribution in public-safe aggregates; inclusion gaps and seat-completion progress.\
16.3.6 **Operational resilience metrics.** Governance-critical service posture: record store availability; registry availability; role issuance/revocation functioning; correction pipeline health; backlog latency; outage incidents and recovery posture.\
16.3.7 **Community health metrics.** Conduct incidents; protected participation outcomes; anti-retaliation actions; response time metrics; recurrence indicators; moderation workload; safeguarding escalations (aggregate, minimized).

***

#### 16.4 Integrity-by-Record Requirements for iVRS Entries

16.4.1 **Report-valid minimum completeness.** A report is “report-valid” only if it meets minimum completeness: scope fields, evidence links, limitations, uncertainty, reliance bounds, expiry, correction status, and responsible role markers.\
16.4.2 **No silent edits.** iVRS data cannot be silently edited. Corrections require errata or supersession records with diffs, timestamps, reason codes, and linkage to affected outputs and recipients.\
16.4.3 **Traceability.** iVRS must preserve “what changed, why, and by which record,” including method changes, metric definition changes, and reporting-window changes.\
16.4.4 **Distribution log referencing.** When metrics rely on controlled sources or controlled releases, the report must reference distribution logs and access constraints; public-safe versions must be abstracted without leakage.\
16.4.5 **Handling-class inheritance.** Reports inherit handling class from their most sensitive attached object; public-safe summaries are required when controlled/restricted reports exist.

***

#### 16.5 Uncertainty, Limitations, and Reliance Bounds (Mandatory)

16.5.1 **Standard limitation blocks.** Each report type (Guild/CCell/CERT/convening/release) has a standard limitations block with required fields and standardized language; optional additional limitations are permitted.\
16.5.2 **Uncertainty taxonomies.** Reports must tag uncertainty: data gaps; sampling limits; model limitations; context limits; measurement error; bias risk; time-lag risk; and domain-specific uncertainty categories where designated.\
16.5.3 **Reliance bounds fields.** Reports must state intended use and non-intended use, reliance audience, expiry/review date, and correction path (including how recipients will be notified of corrections).\
16.5.4 **Non-equivalence statements.** Reports must state: not certification; not compliance; not audit opinion; not endorsement; not regulatory acceptance.\
16.5.5 **No-warranty posture.** Reports include “as-is” posture and decision responsibility boundaries: users remain responsible for decisions taken under their own lawful authority.

***

#### 16.6 Handling, Privacy, and Sensitive Reporting Controls

16.6.1 **Default public-safe posture.** Public-safe reporting is the default; controlled/restricted iVRS reports are permitted only where justified by handling, lawful constraints, safety risks, or market sensitivity.\
16.6.2 **Identity minimization rules.** Role-marker reporting is default; identity disclosures are minimized, access-logged, and limited to a need-to-know basis with two-person controls where required.\
16.6.3 **Sensitive incident gating.** Security incidents, critical infrastructure sensitivities, and market-sensitive content require elevated gating, delayed release options, partitioned reporting, and narrative safety checks.\
16.6.4 **Youth/vulnerable safeguards.** Where participation is permitted, reporting must suppress identifying information, apply strict minimization, and follow safeguarding escalation requirements.\
16.6.5 **Retention and deletion constraints.** Data minimization and retention schedules apply; deletion requests are honored within record-integrity limits via de-identification, access restriction, and minimization by supersession where deletion is not permissible.

***

#### 16.7 iVRS Reporting Cadence and Event Triggers

16.7.1 **Continuous vs periodic.** iVRS supports continuous telemetry for governance-critical health, and periodic reporting on a monthly/quarterly/annual cadence by report type.\
16.7.2 **Triggered reports.** Triggered reports are required for major releases, material corrections, disputes escalation, safety holds, CERT activations, and material governance rule changes impacting outputs.\
16.7.3 **Convening-linked reporting.** Clinics, drills, evidence rooms, and hearings produce convening reports with required artifact pointers, dissent capture status, and correction clock activation.\
16.7.4 **Incident-linked reporting.** Breach, leak, harassment, and misrepresentation incidents trigger incident reporting under handling constraints; public-safe summaries default unless disclosure is unsafe or unlawful.\
16.7.5 **Emergency Governance Mode.** During emergency mode, iVRS must publish stop-the-line status, holds, scope restrictions, and after-action outputs on time-boxed clocks.

***

#### 16.8 Dashboards, Public Trust Surfaces, and Publication Rules

16.8.1 **Public-safe dashboards.** Public-safe dashboards show aggregate health and integrity metrics, uncertainty indicators, and correction performance without doxxing, targeting cues, or sensitive operational details.\
16.8.2 **Controlled dashboards.** Controlled dashboards are access-logged, expiry-bound, need-to-know, and include explicit reliance bounds and redistribution constraints.\
16.8.3 **Narrative safety rules.** Dashboard narratives and highlights must not amplify panic, expose vulnerable communities, disclose exploitable infrastructure details, or provide market manipulation cues.\
16.8.4 **Attribution permissions.** Attribution is permissioned, scoped, expiry-bound, and revocable by record; role-marker attribution is the default.\
16.8.5 **Misquote/misuse hooks.** Dashboards and reports must include correction links and a misquote/misuse reporting path that routes directly into correction and dispute lanes.

***

#### 16.9 Performance SLAs and Minimum Service Posture (iVRS as Health Monitor)

16.9.1 **Correction clock targets.** iVRS tracks correction performance by severity class (quick errata vs formal supersession), including backlog, time-to-publish correction, and redistribution reconciliation completion.\
16.9.2 **Dispute response targets.** Tracks dispute triage times, escalation triggers, hearing scheduling windows, and completion metrics for reason-coded outcomes.\
16.9.3 **Review throughput minima.** Tracks queue health, time-to-first-review, time-to-decision, reviewer rotation integrity, and backlog transparency minima.\
16.9.4 **Handling breach response.** Tracks containment time, access revocation speed, watermark leak response metrics, and post-incident corrective controls.\
16.9.5 **Governance-critical service SLOs.** iVRS references SLOs for registry, records, roles, audit logs, and correction pipelines, with outages and degradations recorded as iVRS events.

***

#### 16.10 Quality Signals and Non-Regulatory Badging Interface

16.10.1 **Badge readiness support.** iVRS supplies operational evidence for badge readiness (e.g., reproducibility pass rates, review completeness) without implying certification or compliance.\
16.10.2 **Expiry-bound indicators.** Quality indicators are expiry-bound and must degrade/expire rather than persist as permanent claims; deprecation signaling is mandatory.\
16.10.3 **Operator-safe pattern indicators.** Operator-safe indicators are abstracted, non-targeting, and include safety disclaimers and non-operational boundaries.\
16.10.4 **Controlled marking disclosures.** Controlled disclosures specify who can see what, why, and under what handling; distribution logs apply where required.\
16.10.5 **Revocation and rollback.** Mis-issued indicators trigger rollback/revocation by record with public-safe clarification where public claims were made.

***

#### 16.11 Interoperability and Standardization of Reporting

16.11.1 **Common schemas.** Common schemas apply across Guilds, aligned to GRIx for lineage compatibility and cross-Guild comparability.\
16.11.2 **Federation reporting.** Cross-Guild federation reports are permitted (WEFH/cyber–AI/supply chains) with lead-of-record designation and no double counting.\
16.11.3 **External framework mapping.** Mapping to ISO/COSO/Sendai/etc. is informational only and must include non-equivalence statements; no implied compliance or certification.\
16.11.4 **API/export posture.** Public-safe exports are permitted by default; controlled exports require access logging, expiry, and lawful/sanctions gating.\
16.11.5 **Versioning/backward compatibility.** iVRS schemas are versioned with backward compatibility rules, migration plans, and clear effective dates.

***

#### 16.12 Governance, Oversight, and Assurance of iVRS

16.12.1 **Stewardship invariants.** Stewardship Committee maintains invariants: not marketing, uncertainty/limitations mandatory, identity minimization, handling-first, and anti-capture controls.\
16.12.2 **Domain Council metrics.** Domain Councils may define domain-specific metrics and thresholds within global constraints, with published definitions and contestation lanes.\
16.12.3 **Trustee oversight.** Trustees oversee audit posture, risk controls, and integrity of iVRS operations (including periodic review of manipulation risk and sensitive reporting).\
16.12.4 **Independent review triggers.** Triggers include capture indicators, repeated reporting failures, systematic anomalies, persistent safety incidents, or evidence of manipulation.\
16.12.5 **COI controls.** COI controls apply to metric ownership, metric interpretation, dashboard narration, and highlight selection; recusals and rotation are required.

***

#### 16.13 Anti-Gaming, Manipulation Resistance, and Incentive Hygiene

16.13.1 **Prohibited behaviors.** Prohibited behaviors include vanity reporting, selective suppression of negatives, metric “polishing,” manipulation of denominators/windows, and narrative purchase by sponsors.\
16.13.2 **Cross-checks.** iVRS cross-checks with CRS, PoC, review logs, correction logs, and distribution logs to detect inconsistent narratives or fabricated performance.\
16.13.3 **Sampling verification.** Reports are subject to sampling and verification protocols; controlled verification can occur without public disclosure of sensitive details.\
16.13.4 **Fraud response.** Fraudulent reporting triggers corrections, clawbacks (where applicable), sanctions, and public-safe clarifications if public trust was affected.\
16.13.5 **Sponsor influence protections.** Sponsors cannot control narratives, highlight selection, metric definitions, or report timing; any sponsor interactions must be disclosed under guardrails.

***

#### 16.14 Disputes, Appeals, and Corrections for iVRS Reports

16.14.1 **Who may challenge.** Any member within scope (and designated external challengers where lawful) may contest a report through defined lanes; protected participation applies.\
16.14.2 **Evidence standards.** Disputes require evidence links, counter-records, or reason-coded objections tied to definitions, data lineage, handling constraints, or methodological flaws.\
16.14.3 **Correction/supersession mechanics.** Corrections occur via errata or supersession records with diffs, timestamps, reason codes, and redistribution reconciliation requirements.\
16.14.4 **Public-safe dispute summaries.** Public-safe dispute summaries are default; controlled annexes are minimized and access-logged; dissent is preserved.\
16.14.5 **Finality and archival.** Superseded reports remain archived with clear status markers; finality is time-boxed by rule (expiry/review) to preserve correctionability and prevent permanent narrative lock-in.


---

# 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/membership/xvi.-reporting.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.