> 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/x.-work-products.md).

# X. Work Products

What the Guild May Publish, How It Is Labeled, and When It Is “Release-Ready”

**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.** What the Guild May Publish, How It Is Labeled, and When It Is “Release-Ready” 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.
* 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.
* Systems are named by their NXS display codes (for example [NXS-RLS](/organization/systems/nxs-rls.md) for participants, agreements, protocols, obligations and lawful handoffs); see [Systems](/organization/systems.md).
  {% endhint %}

### Part 10 — Work Products, Artifact Constitution, and Release System

#### 1. Status, Purpose, and Non-Equivalence

1.1 **Status.** This Part defines the Guild’s canonical work products and the release system that governs publication, distribution, and lifecycle management under validity-by-record.

1.2 **Purpose.** The purpose is to make every output:\
1.2.1 **legible** (what it is, what it isn’t, what it can support),\
1.2.2 **portable** (interoperable across enterprises and jurisdictions),\
1.2.3 **replayable** (reproducibility declared and supported), and\
1.2.4 **safe** (dual-use constrained; rights-preserving; competition-safe).

1.3 **Non-equivalence statement.**\
1.3.1 “Release” means the Guild has met its internal evidence, safety, and documentation gates.\
1.3.2 “Release” does **not** mean certification, endorsement, regulatory compliance, fitness for a particular purpose, or operational authorization.\
1.3.3 “Deployability” is a disclosure about artifact maturity and replayability, not a claim of correctness in every context.

***

#### 2. Canonical Work Product Families

2.1 **Research methods and protocols.**\
2.1.1 measurement methodologies;\
2.1.2 sampling and bias-control protocols;\
2.1.3 analytic test batteries and scoring rubrics;\
2.1.4 validation and replication runbooks.

2.2 **Reference implementations.**\
2.2.1 libraries, SDK components, parsers, normalizers;\
2.2.2 safe scanners and collectors consistent with the Collection Doctrine;\
2.2.3 mapping and ontology tooling;\
2.2.4 reproducible pipelines (with pinned dependencies).

2.3 **Datasets (bounded and governed).**\
2.3.1 benchmark datasets;\
2.3.2 longitudinal observatory datasets;\
2.3.3 redacted exemplars and synthetic datasets where needed for safety;\
2.3.4 labeled corpora for accessibility, privacy, integrity, and security research (subject to strict minimization).

2.4 **Benchmarks and scorecards.**\
2.4.1 benchmark definitions and test harnesses;\
2.4.2 benchmark results (with method and sampling disclosures);\
2.4.3 anti-gaming and drift monitoring outputs;\
2.4.4 comparative scorecards with explicit uncertainty.

2.5 **Assurance & Evidence Packs (AEPs).**\
2.5.1 enterprise evidence packs supporting bounded determinations;\
2.5.2 alert-to-evidence pack packages for downstream tools;\
2.5.3 dispute-ready evidence bundles.

2.6 **Intelligence products (R\&D posture).**\
2.6.1 alerts (bounded, time-limited);\
2.6.2 bulletins and advisories (non-operational);\
2.6.3 dossiers (structured, contestable profiles);\
2.6.4 trend and horizon reports (uncertainty-forward).

2.7 **Education and capacity artifacts.**\
2.7.1 tutorials, labs, reproducible demonstrations;\
2.7.2 curricula and reading lists;\
2.7.3 case studies with redaction discipline;\
2.7.4 governance templates for evidence-first workflows.

***

#### 3. Mandatory Labeling and Artifact Headers

3.1 **Universal labeling rule.** Every artifact must include a front header containing, at minimum:\
3.1.1 artifact name and unique ID;\
3.1.2 version ID and release date;\
3.1.3 handling class (Public-safe / Controlled / Restricted) and expiry where applicable;\
3.1.4 scope statement (what is covered; what is excluded);\
3.1.5 intended users and adoption contexts;\
3.1.6 reliance bounds (R0–R4) and explicit prohibited uses;\
3.1.7 evidence and reproducibility levels (E0–E4; RS0–RS4);\
3.1.8 uncertainty declaration (confidence intervals; known blind spots);\
3.1.9 safety posture (dual-use and rights check statements);\
3.1.10 correction path (how to report issues; clocks; supersession rules);\
3.1.11 distribution log requirement indicator (if Controlled/Restricted).

3.2 **No implied claims.** Labels must avoid language that implies endorsement, certification, compliance determination, or operational authorization.

3.3 **Structured metadata.** Where feasible, artifacts must provide machine-readable metadata aligned to [NXS-GRX](/organization/systems/nxs-grx.md)-Web objects and schema mappings to enable automated governance and enterprise ingestion.

***

#### 4. Deployability Ladder (D0–D4)

4.1 **Purpose.** The Deployability Ladder communicates operational maturity of the artifact *as a research output* and its readiness for adoption *by others under their own authority*.

4.2 **Levels.**\
4.2.1 **D0 — Concept / sketch.** Ideas, early notes, non-authoritative drafts; not suitable for enterprise reliance.\
4.2.2 **D1 — Prototype.** Code or method exists; limited tests; suitable for lab exploration only.\
4.2.3 **D2 — Lab-validated.** Replays within a controlled environment; baseline tests; minimal documentation.\
4.24 **D3 — Release-ready (bounded).** Version-locked; documented; peer reviewed; misuse checked; reproducibility declared; suitable for enterprise evaluation and limited adoption.\
4.2.5 **D4 — Enterprise-deployable (governed).** Strong documentation, stable interfaces, conformance tests where applicable, drift and maintenance plan, clear deprecation and security posture; suitable for scaled adoption **without** any implied certification.

4.3 **No equivalence.** D-levels do not equate to regulatory compliance, safety certification, or security guarantees.

***

#### 5. Release Types and Publication Posture

5.1 **Release types.**\
5.1.1 **Research Release.** Methods, prototypes, datasets, and findings intended primarily for research and learning.\
5.1.2 **Benchmark Release.** Public or controlled comparative benchmarks with anti-gaming and drift monitoring posture.\
5.1.3 **Enterprise Evidence Release.** AEPs and supporting pipelines intended for integration into enterprise governance workflows.\
5.1.4 **Safety Release.** Corrections, withdrawals, urgent limitation notices, and deprecations.

5.2 **Publication posture.**\
5.2.1 Public-safe releases must be abstraction-safe and avoid exploit-enabling detail.\
5.2.2 Controlled releases may include greater technical specificity subject to handling, distribution logs, and expiry.\
5.2.3 Restricted releases are exceptional and must justify why disclosure would materially increase harm.

5.3 **Release notes requirement.** Every release must include:\
5.3.1 what changed;\
5.3.2 what remains unresolved;\
5.3.3 known limitations;\
5.3.4 deprecations and migration notes;\
5.3.5 any disputes, dissent, or material corrections since the last release.

***

#### 6. Module Architecture and Artifact Boundaries (v1.0 Posture)

6.1 **Modularity.** The platform is modular; artifacts must declare:\
6.1.1 which module(s) they belong to;\
6.1.2 dependencies and external sources;\
6.1.3 boundary conditions (what they do not do).

6.2 **Non-operational boundary notice.** Module artifacts must include a standard notice: the platform informs; adopters execute.

6.3 **Interface discipline.**\
6.3.1 interfaces must be versioned;\
6.3.2 breaking changes must be announced with transition paths;\
6.3.3 data and model outputs must carry uncertainty and drift indicators.

***

#### 7. Release Gates (Minimum Quality System)

7.1 **Gates for all D3+ releases.** No artifact may be labeled D3 or D4 unless it satisfies:\
7.1.1 version-locking and content addressing (hashing) where feasible;\
7.1.2 documentation completeness (scope, exclusions, reliance, correction path);\
7.1.3 evidence and reproducibility disclosure (E/RS levels);\
7.1.4 misuse resistance review appropriate to domain;\
7.1.5 rights and privacy minimization check;\
7.1.6 competition-safe and procurement-neutral framing check;\
7.1.7 peer review recorded;\
7.1.8 release authority sign-off recorded.

7.2 **Additional gates for Benchmark Releases.**\
7.2.1 sampling disclosure sufficient for comparability;\
7.2.2 anti-gaming controls and tamper indicators;\
7.2.3 drift monitoring plan and recalibration thresholds;\
7.2.4 appeal pathway and dispute clock.

7.3 **Additional gates for Enterprise Evidence Releases (AEPs).**\
7.3.1 explicit uncertainty and error budgets;\
7.3.2 decision-record compatibility and structured metadata;\
7.3.3 audit log and distribution log posture;\
7.3.4 strict prohibited uses and reliance bounds.

***

#### 8. Lifecycle Management: Deprecation, Withdrawal, and Supersession

8.1 **Deprecation.**\
8.1.1 artifacts may be deprecated due to method flaws, drift, safety concerns, or obsolescence;\
8.1.2 deprecation requires a record and a migration path where feasible.

8.2 **Withdrawal.**\
8.2.1 withdrawals are reserved for artifacts that create unacceptable risk or are materially wrong;\
8.2.2 withdrawals must preserve historical access under clear “withdrawn” marking where lawful and safe, with a public explanation scaled to handling class.

8.3 **Supersession.**\
8.3.1 supersession must preserve continuity: the new artifact points back to the prior version;\
8.3.2 citations must prefer the latest valid version;\
8.3.3 longitudinal benchmarks must preserve comparability while preventing reliance traps.

***

#### 9. Attribution, Credits, and Integrity of Authorship

9.1 **Attribution rule.** Authorship and contributor credit must be accurate, consented where required, and compatible with handling classes.

9.2 **No implied endorsement.** Attribution must not be framed as endorsement by an employer, government, vendor, or sponsor.

9.3 **Credit safety.** Where disclosure could create personal risk, attribution may be withheld or role-marked consistent with handling and identity-minimization disciplines.

## 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/x.-work-products.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.