# VI. Research Labs

### Part 6 — Research & Lab Operating Model

#### 1. Purpose, Scope, and Operating Posture

1.1 **Purpose.** Establish a global, reproducibility-first research commons that produces **methods, reference implementations, datasets, benchmarks, test harnesses, and education** for web resilience—packaged into decision-grade artifacts that are **contestable, correctable, and safely publishable**.

1.2 **Scope.** The Lab Operating Model governs:\
1.2.1 how research is proposed, executed, reviewed, released, and corrected;\
1.2.2 how datasets and benchmarks are constructed and defended against gaming;\
1.2.3 how open-source and releases are managed with supply-chain integrity;\
1.2.4 how responsible disclosure and do-no-harm publication are enforced;\
1.2.5 how participants join, contribute, and remain in good standing.

1.3 **Operating posture.** The Labs are **R\&D-only** and strictly **non-operational**: no SOC/EOC dispatch, no incident command, no enforcement, no certification, no procurement steering, no regulated advice.

1.4 **System objective.** Produce globally reusable, standards-aligned, enterprise-adoptable building blocks that measurably reduce systemic risk—without creating surveillance infrastructure, exploit enablement, or coercive governance tooling.

***

#### 2. Lab Network Architecture

2.1 **Federated lab network.** The Guild operates a network of independently managed labs contributing under a common constitution. Participation is modular and non-exclusive.

2.2 **Lab types (non-exhaustive).**\
2.2.1 **University and institute labs** (methods, longitudinal research, reproducibility);\
2.2.2 **Independent research labs** (benchmarking, measurement integrity, toolchains);\
2.2.3 **Corporate research participation** (non-procurement, non-endorsement, contribution-only posture);\
2.2.4 **Infrastructure-provider labs** (ecosystem measurement, safety methods, public-good datasets);\
2.2.5 **Public-interest labs** (accessibility, rights, inclusion, integrity measurement).

2.3 **Minimum operating commitments (for “Active Lab” status).**\
2.3.1 named Lab Lead (individual);\
2.3.2 published lab charter addendum aligned to this Charter (scope + boundaries);\
2.3.3 ability to meet reproducibility and release discipline at declared levels;\
2.3.4 adherence to handling classes, COI, and competition hygiene;\
2.3.5 participation in periodic review cycles and correction clocks.

2.4 **Non-exclusivity and neutrality.** No lab affiliation implies endorsement of any employer, vendor, state, platform, or standards agenda. Contributions are evaluated on evidence quality and safety.

***

#### 3. Research Lifecycle and Governance Gates

3.1 **Lifecycle (mandatory).**\
3.1.1 **Proposal** → 3.1.2 **Scoping & threat modeling** → 3.1.3 **Data & method plan** →\
3.1.4 **Build & test** → 3.1.5 **Reproducibility package** → 3.1.6 **Safety and dual-use review** →\
3.1.7 **Peer review & benchmark integrity review** → 3.1.8 **Release record** → 3.1.9 **Monitoring & corrections**.

3.2 **Proposal requirements (minimum).** Each proposal must declare:\
3.2.1 objective and expected public-good value;\
3.2.2 measurement boundary and collection class compatibility (Part 5);\
3.2.3 dataset requirements and minimization posture;\
3.2.4 target artifact family (method, code, dataset, benchmark, test harness, AEP component);\
3.2.5 expected reproducibility level (RS0–RS4) and evidence level (E0–E4);\
3.2.6 threat model and misuse risks, including publishability constraints.

3.3 **Stop-the-line gates.** Work must halt pending review if:\
3.3.1 it risks exploit enablement or coercive capability;\
3.3.2 it violates measurement non-intrusion doctrine;\
3.3.3 it introduces sensitive data beyond policy;\
3.3.4 it triggers benchmark tampering risk or capture indicators;\
3.3.5 it creates legal/rights harm not adequately mitigated.

***

#### 4. Research Ethics and Human Subjects Boundaries

4.1 **Default: no human subjects research.** The Guild does not run human subject studies by default. Where unavoidable (e.g., accessibility user testing), the work must:\
4.1.1 use institutional ethics review (IRB/REB or equivalent) where applicable;\
4.1.2 obtain consent and ensure minimization;\
4.1.3 avoid collecting sensitive attributes unless essential and approved;\
4.1.4 publish only de-identified, aggregate findings.

4.2 **No profiling posture.** The Labs do not build identity dossiers, behavioral surveillance tooling, or individual targeting systems.

4.3 **Rights and discrimination controls.** Research must be designed to avoid:\
4.3.1 discriminatory outputs or proxy discrimination;\
4.3.2 harmful labeling of protected groups;\
4.3.3 coercive measurement regimes that chill expression or association.

4.4 **Accessibility as a research norm.** Releases must strive for accessible documentation, reproducible tutorials, and inclusion pathways for low-resource environments.

***

#### 5. Data Governance for Datasets and Measurement Outputs

5.1 **Dataset governance objective.** Ensure datasets are lawful, minimized, provenance-safe, bias-audited, refresh-disciplined, and fit for reproducible benchmarking without enabling abuse.

5.2 **Dataset classes and access tiers.**\
5.2.1 **Open datasets** (public-safe; minimal risk; broadly shareable).\
5.2.2 **Controlled datasets** (restricted distribution; higher abuse risk; logged access).\
5.2.3 **Restricted datasets** (minimal distribution; safety-sensitive; strict handling controls).

5.3 **Dataset requirements (minimum).** Every dataset must include:\
5.3.1 source provenance and licensing posture;\
5.3.2 collection doctrine compliance statement (Part 5);\
5.3.3 minimization and redaction methods;\
5.3.4 bias and representativeness notes;\
5.3.5 drift expectations and refresh cadence;\
5.3.6 known limitations and non-equivalence warnings;\
5.3.7 correction path and version lineage.

5.4 **Retention and deletion.**\
5.4.1 store only what is needed for RS-level reproducibility and contestability;\
5.4.2 prefer aggregated series and hashed pointers for sensitive aspects;\
5.4.3 define deletion and aggregation rules that preserve auditability.

5.5 **Dataset integrity and tamper resistance.**\
5.5.1 content-addressed packaging (hashes) for immutable releases;\
5.5.2 signed manifests for release bundles;\
5.5.3 integrity checks for drift, poisoning signals, and anomalous changes.

***

#### 6. Secure Build, Release, and Supply-Chain Integrity

6.1 **Supply-chain objective.** Prevent toolchain compromise, dependency poisoning, and release tampering, and provide enterprise-adoptable provenance.

6.2 **Minimum build discipline (required for Release-Ready).**\
6.2.1 dependency pinning and review;\
6.2.2 SBOM generation for releases;\
6.2.3 signed artifacts and provenance metadata;\
6.2.4 controlled release permissions (maintainer model);\
6.2.5 reproducible build targets where feasible;\
6.2.6 vulnerability scanning and remediation posture.

6.3 **Provenance and attestation.**\
6.3.1 releases must reference method version, toolchain version, and environment;\
6.3.2 test results and quality gates must be linked to the release record;\
6.3.3 where controlled data exists, release bundles must respect handling classes and access tiers.

6.4 **No endorsement.** Release availability does not imply certification, compliance conclusion, or “approved vendor” status.

***

#### 7. Reproducibility Standard (RS0–RS4) and Lab Expectations

7.1 **RS0 — Concept only.** Narrative, hypothesis, or design note; not replayable.\
7.2 **RS1 — Method described.** Procedure documented; partial artifacts may exist.\
7.3 **RS2 — Code available.** Code + instructions; limited environment capture.\
7.4 **RS3 — Replay bundle.** Code + data access instructions or substitute datasets + environment spec + runbook + expected outputs.\
7.5 **RS4 — Independent replication.** Verified replication by an independent lab with recorded deltas and corrections.

7.6 **Minimum declarations.** Every artifact must declare its RS level and what is required to achieve the next level.

7.7 **Replication sprints.** The Guild shall run periodic replication sprints to move high-value artifacts toward RS3/RS4 and publish replication outcomes (including failures) with correction discipline.

***

#### 8. Research Quality Gates and Review System

8.1 **Quality gates (baseline).** Before a Release-Ready designation, the work must pass:\
8.1.1 **method review** (soundness, bias controls, non-equivalence notes);\
8.1.2 **measurement safety review** (non-intrusive, rate-limited, stop conditions);\
8.1.3 **dual-use and do-no-harm review** (abuse case analysis, publication calibration);\
8.1.4 **benchmark integrity review** (anti-gaming posture, drift expectations);\
8.1.5 **reproducibility review** (runbook validity, environment spec, replay evidence).

8.2 **Peer review posture.**\
8.2.1 review may be open or controlled depending on handling class;\
8.2.2 dissent is recorded (no forced consensus);\
8.2.3 reviewers rotate to reduce capture and cartel risk.

8.3 **Bias and error budgets.** High-impact metrics require published error budgets (false positive/negative posture) and uncertainty intervals.

***

#### 9. Responsible Disclosure Interfaces (Research-Only Routing)

9.1 **Responsible disclosure posture.** Labs may receive and process vulnerability reports for research and measurement purposes, but do not act as operational command.

9.2 **Routing discipline.**\
9.2.1 where feasible, route to appropriate operators, CERT/CSIRT channels, or public programs;\
9.2.2 do not publish exploit-enabling detail;\
9.2.3 maintain handling class discipline;\
9.2.4 use correction clocks for errors in public outputs.

9.3 **Emergency safety.** If imminent harm is reasonably suspected, the Lab applies stop-the-line and escalates to designated disclosure pathways under controlled handling.

***

#### 10. Open Source Policy and IP Hygiene

10.1 **Open-by-default, bounded by safety.** The Guild publishes as open source and open education by default, except where dual-use, rights harm, or legal constraints require restriction.

10.2 **Contributor attestations.** Contributors must:\
10.2.1 affirm rights to contribute;\
10.2.2 disclose conflicting obligations;\
10.2.3 avoid importing restricted or proprietary code/data improperly.

10.3 **License hygiene.**\
10.3.1 standard licenses are used consistently;\
10.3.2 third-party dependencies are tracked and disclosed;\
10.3.3 datasets carry explicit licensing and usage constraints.

10.4 **No contamination posture.** If a contribution risks IP contamination or restricted transfer, it is rejected or quarantined pending review.

***

#### 11. Roles, Minimum Controls, and Lab Accountability

11.1 **Lab Lead.** Owns scoping discipline, boundary adherence, delivery of reproducibility, and response to disputes.

11.2 **Release Steward.** Ensures build integrity, provenance, packaging, and correct labeling.

11.3 **Dataset Steward.** Owns dataset lineage, minimization, licensing, refresh cadence, and drift monitoring.

11.4 **Benchmark Steward.** Owns benchmark methodology, anti-gaming controls, and appeals posture.

11.5 **Integrity Steward interface.** Labs must comply with Guild stop-the-line decisions and participate in incident/correction workflows.

11.6 **Records discipline.** Each lab maintains:\
11.6.1 proposal records;\
11.6.2 run manifests for major measurement events;\
11.6.3 review outcomes (including dissent);\
11.6.4 release records and correction logs.

***

#### 12. Deliverables, Designations, and Release Labels

12.1 **Artifact families.** Labs may produce:\
12.1.1 methods and measurement procedures;\
12.1.2 reference implementations and libraries;\
12.1.3 datasets and benchmark suites;\
12.1.4 test harnesses and conformance checks (research posture);\
12.1.5 reports, education labs, and reproducible tutorials;\
12.1.6 AEP components where applicable.

12.2 **Designations (internal quality markings).**\
12.2.1 **Guild-Reviewed** (review complete; limitations disclosed);\
12.2.2 **Lab-Validated** (tests executed; method behaves as claimed within error bounds);\
12.2.3 **Release-Ready** (reproducibility + safety + integrity gates passed);\
12.2.4 **Dataset-Ready** (lineage + licensing + drift controls + redaction complete);\
12.2.5 **Benchmark-Ready** (methodology + anti-gaming + appeals posture complete);\
12.2.6 **Enterprise-Deployable** (deployability posture only; not certification; includes clear operational boundary notice).

12.3 **Mandatory labeling.** Every artifact must include: scope, limitations, uncertainty, reliance bounds, handling class, and correction path.

***

#### 13. Participation Norms for the R\&D Commons

13.1 **Anti-hype rule.** Claims must be bounded by evidence and declared uncertainty. No theatrical marketing masquerading as research.

13.2 **Respectful collaboration.** Harassment, intimidation, coercion, or misrepresentation triggers enforcement.

13.3 **Competition-safe behavior.** Labs must comply with safe-meeting scripts and prohibited-topic posture; the R\&D commons is not a coordination venue for pricing, market division, or labor collusion.

13.4 **Global inclusion posture.** Labs shall maintain pathways for low-resource participants (documentation, minimal tooling options, and reproducible “lite” tracks where feasible).


---

# 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/vi.-research-labs.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.