# XVII. Quality ### Part 17 — Quality System for Membership Outputs *(The Quality System is a governance-grade discipline for “membership outputs” so they can be reused safely under scrutiny. It is explicitly **not** a compliance regime, not assurance, not certification, not licensure, and not regulatory equivalence.)* #### 17.1 Purpose, Perimeter, and Non-Regulatory Posture 17.1.1 **Purpose.** Establish a uniform, record-valid quality discipline for membership outputs so they are comparable, reproducible, correctionable, and safe-to-share under handling constraints.\ 17.1.2 **Binding non-equivalence.** Quality markings are bindingly **not** “certified / approved / compliant / licensed / assured.” Any language implying regulatory status, audit opinion, or supervisory acceptance is prohibited.\ 17.1.3 **Voluntary-by-default.** Badging is voluntary; no member is compelled to request, accept, or display a badge; unbadged outputs remain permissible subject to handling and safety rules.\ 17.1.4 **System linkages.** Quality System is subordinate to Stewardship safety gates and handling classes; safety holds and handling escalations override badging.\ 17.1.5 **Ecosystem integration.** Quality interacts with CRS/iVRS/ILAs/PoC and convening outputs: (a) CRS recognizes the work; (b) iVRS reports quality health; (c) ILAs/PoC gate who can review/issue; (d) convenings generate evidence needed for badges. *** #### 17.2 Scope of “Membership Outputs” Covered 17.2.1 **Artifact classes.** Methods, benchmarks, datasets, models (where permitted), ontologies, schema/lineage rules, evaluation protocols, and admissibility patterns.\ 17.2.2 **Evidence packaging.** Proof Packs/AEP patterns, checklists, templates, determination formats, limitation blocks, correction protocols, distribution log schemas.\ 17.2.3 **Convening outputs.** Briefing notes, clinic results, replication logs, drills and after-actions, hearings summaries, dissent/minority reports.\ 17.2.4 **Software/tooling outputs.** Reference code, test suites, harnesses, environment manifests, SBOM references, release notes, and non-operational runbooks.\ 17.2.5 **Exclusions (hard).** Operational directives; procurement specifications; capital raising materials; exploit instructions; actionable offensive cyber content; intelligence tasking; targeting cues. *** #### 17.3 Quality Ladders and Readiness States 17.3.1 **Lifecycle states.** Draft → Working → Candidate → Released → Deprecated → Superseded (record-valid only; no silent edits).\ 17.3.2 **Two gate families.** “Release candidate” gates (technical completeness and replayability) vs “publication-safe summary” gates (safety/handling and non-amplification).\ 17.3.3 **Minimum completeness thresholds.** Mandatory metadata: provenance, method/environment, limitations/uncertainty, reliance bounds, handling election, expiry/review date, correction path, rights/license clarity.\ 17.3.4 **Expiry and revalidation.** Every readiness state has an expiry posture; higher states require periodic revalidation and change-triggered refresh (e.g., new evidence, new vulnerabilities, revised methods).\ 17.3.5 **Withdrawal/rollback.** Unsafe, erroneous, or misrepresented releases may be withdrawn or rolled back by record; public-safe notices are required when public claims exist. *** #### 17.4 Canonical Badge Taxonomy 17.4.1 **Guild-Reviewed.** Peer review completed under a defined rubric and COI controls; indicates review occurred, **not** correctness, suitability, or compliance.\ 17.4.2 **Lab-Validated / Replication-Verified.** Replication evidence exists in disclosed environments; indicates reproducibility in stated conditions, **not** general validity or real-world performance.\ 17.4.3 **Dataset-Ready.** Documentation/provenance/rights/handling fitness meets minima; does not imply dataset accuracy, bias adequacy, or lawful use in every jurisdiction.\ 17.4.4 **Benchmark-Ready.** Stable test protocol + reproducibility proof; does not imply benchmark completeness, fairness sufficiency, or “best” measurement.\ 17.4.5 **Release-Ready.** Packaging and governance gates met (limitations, correctionability, distribution discipline); does not imply regulatory acceptance or operational authorization.\ 17.4.6 **Operator-Safe Pattern.** Abstracted to avoid targeting cues and exploit detail; indicates safe-to-share pattern, not an operational playbook.\ 17.4.7 **Safety-Screened.** Dual-use screening completed; may carry redaction/delay/partition requirements; not a “safe in all contexts” claim.\ 17.4.8 **Interoperability-Mapped.** Declared alignment to GRIx/schema compatibility fields; not an endorsement of correctness or completeness.\ 17.4.9 **Deprecated / Superseded.** Mandatory display rules: old outputs must show supersession mapping and correction linkages prominently. *** #### 17.5 Badge Scope, Reliance Bounds, and Mandatory Disclaimers 17.5.1 **Scope statement.** Each badge requires a scope statement: artifact identity, version, domain, intended audience, and what was reviewed/replicated (and what was not).\ 17.5.2 **Intended/non-intended use.** Mandatory fields for intended use, non-intended use, and “do-not-use-for” contexts (e.g., operational decisions, procurement, compliance claims).\ 17.5.3 **Limitations/uncertainty/expiry.** Every badge carries limitations and uncertainty tags, an expiry/review date, and a correction path.\ 17.5.4 **Non-endorsement/non-equivalence blocks.** Mandatory disclaimer blocks prohibiting implied endorsement, certification, compliance, licensure, audit opinion, or regulator acceptance.\ 17.5.5 **No-warranty posture.** Badges carry “as-is” posture and decision-responsibility boundary. *** #### 17.6 Eligibility and Role Requirements for Badging 17.6.1 **Who may request.** Badge requests allowed for eligible member states (Active/MGS where required), subject to handling prerequisites and lawful constraints.\ 17.6.2 **PoC prerequisites.** Badge lanes require PoC thresholds by badge type (e.g., reviewers PoC2+, publishers PoC3+, stewards PoC4+, safety gate PoC5 where designated).\ 17.6.3 **COI prerequisites.** COI disclosures and recusal readiness are mandatory; self-review and same-entity domination are prohibited.\ 17.6.4 **Identity posture.** Role markers are default; verified identity only where handling/lawful constraints require it; identity minimization cell controls apply.\ 17.6.5 **Sponsor constraints.** Badges cannot be purchased; sponsor/partner funding cannot influence review outcomes, priority, or issuance decisions. *** #### 17.7 Review Lanes, Governance Routing, and Decision Rights 17.7.1 **Primary Council lane.** Each Guild routes badge decisions through its Primary Council lane; cross-council triggers apply for coupled risks (WEFH, cyber–AI, CI, market sensitivity).\ 17.7.2 **Stewardship safety gate.** Stewardship Committee safety gate is mandatory for dual-use, critical infrastructure, market-sensitive, or rights-impacting materials.\ 17.7.3 **Decision rights taxonomy.** Decisions are record-coded as: Recommend / Approve / Hold / Deny / Require Controlled Release / Require Safety Redaction / Require Replication / Require COI Remediation.\ 17.7.4 **Minority reports.** Dissent and minority reports are preserved and linked to badge decisions; suppression of dissent is prohibited.\ 17.7.5 **Rotation and anti-concentration.** Reviewer rotation rules prevent repeated pairings and entity dominance; overrides are reason-coded and time-boxed. *** #### 17.8 Evidence Requirements for Badge Issuance 17.8.1 **Provenance package.** Sources, lineage, rights/license clarity, handling elections, and constraints; where sensitive, evidence may be controlled with public-safe abstractions.\ 17.8.2 **Reproducibility package.** Instructions, environment manifest, dependency list, hashes/IDs, and any required tooling; “works on my machine” is not sufficient.\ 17.8.3 **Verification/replication logs.** Minimum replication logs and reviewer sign-off metadata; disagreement must be recorded with reason codes.\ 17.8.4 **Safety screening artifacts.** Threat/dual-use assessment, redaction/abstraction notes, disclosure routing notes where applicable.\ 17.8.5 **Limitations + expiry metadata.** Mandatory limitation blocks, uncertainty tags, reliance bounds, expiry/review date, and correction path. *** #### 17.9 Handling, Distribution, and Controlled Release Patterns 17.9.1 **Release class selection.** Badges may attach to Public-Safe releases or Controlled/Restricted releases; badge does not downgrade handling.\ 17.9.2 **Distribution logs.** Where a badge relies on controlled evidence, distribution logs are mandatory and must be referenced by the badge record.\ 17.9.3 **Watermarking/no-forward.** Controlled badge packs require watermarking and “no-forward” constraints; leak response procedures must be callable.\ 17.9.4 **Staged release.** Default pattern: public-safe summary first; controlled annex second; delayed release where market/public safety requires it.\ 17.9.5 **Abstraction/redaction standards.** Critical infrastructure and security sensitivity require abstraction-first publication standards to suppress targeting cues and actionable exploit detail. *** #### 17.10 Badge Validity, Expiry, Renewal, and Revalidation 17.10.1 **Expiry-by-design.** All badges expire by default; durations vary by badge class and domain risk (shorter for fast-changing or safety-sensitive artifacts).\ 17.10.2 **Renewal criteria.** Renewals require rechecking defined fields: provenance updates, dependency changes, new evidence, new known issues, and correction history.\ 17.10.3 **Revalidation triggers.** New vulnerabilities, misuse patterns, major schema changes, corrected data, or materially changed assumptions trigger revalidation or suspension.\ 17.10.4 **Sunset rules.** Dormant artifacts and stale badges sunset; “zombie badges” are prohibited.\ 17.10.5 **Registry display rules.** Registry must clearly display badge status: Active/Expired/Suspended/Revoked/Superseded, with links to correction/supersession records. *** #### 17.11 Correction, Supersession, and Revocation 17.11.1 **Mandatory correction linkages.** Every badge links to a correction path and known-issues register; badges cannot exist without correctionability.\ 17.11.2 **Revocation triggers.** Fraud, misconduct, safety risk, misrepresentation, material error, rights harm, or unlawful content triggers revocation/suspension.\ 17.11.3 **Emergency revocation.** Emergency revocations (stop-the-line) are permitted with mandatory expiry and post-hoc due process review.\ 17.11.4 **Supersession mapping.** Supersession records map old badge → new badge (or withdrawal), with public-safe notices where public claims exist.\ 17.11.5 **No silent edits.** Badge state changes require record-valid updates with diffs, timestamps, and reason codes. *** #### 17.12 Misrepresentation, Brand Safety, and Enforcement Hooks 17.12.1 **Prohibited claims.** Prohibited language includes: “certified,” “approved,” “compliant,” “licensed,” “assured,” “audit opinion,” “regulator accepted,” and equivalents.\ 17.12.2 **Takedown procedures.** Misuse triggers takedown requests across public and controlled channels, registry corrections, and role-marker restrictions where necessary.\ 17.12.3 **Sanctions ladder.** Repeat misuse triggers escalating sanctions: warning → restriction → suspension → removal, with public-safe clarification when public harm occurred.\ 17.12.4 **Public clarification templates.** Standard templates produce non-amplifying clarifications, linking to the authoritative record and correction status.\ 17.12.5 **Third-party misuse reporting SLAs.** Misuse reports have triage SLAs, containment targets, and reason-coded outcomes with appeal links where appropriate. *** #### 17.13 Equity, Accessibility, and Global Participation Controls 17.13.1 **Anti-prestige capture.** Competence-over-reputation is enforced through rubrics, rotation, and evidence requirements; brand/affiliation cannot substitute for evidence.\ 17.13.2 **Accessibility minima.** Badge-eligible documentation must meet accessibility minima (readability, structured metadata, basic translation posture where feasible).\ 17.13.3 **Low-resource pathways.** Alternative pathways support low-resource contributors (scholarships, credit issuance, offline/low-bandwidth documentation options).\ 17.13.4 **Fair workload distribution.** Review load is balanced across geographies/helixes; repeated burdens on the same groups are monitored via iVRS.\ 17.13.5 **Protected appeals.** Appeals and disputes must support protected participation, including identity minimization and anti-retaliation controls. *** #### 17.14 Quality System Audits, Control Testing, and Continuous Improvement 17.14.1 **Periodic audits.** Periodic audits review badge issuance decisions, evidence sufficiency, rubric adherence, and compliance with non-equivalence language rules.\ 17.14.2 **Sampling audits.** Sampling audits re-run reproducibility checks and safety compliance checks on issued badges, including drift detection and environment changes.\ 17.14.3 **Rotation/COI audits.** Audits verify reviewer rotation integrity, recusal enforcement, and absence of entity dominance or review rings.\ 17.14.4 **iVRS alignment.** iVRS dashboards show badge health (issuance, expiry, revocations, correction performance) with uncertainty and limitations baked in.\ 17.14.5 **Improvement loop.** Rule updates occur by record, with impact statements, safety review, notice windows, contestation lanes, and migration plans; emergency patches are time-boxed and ratified after-action. --- # 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/xvii.-quality.md?ask= ``` 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.