# XV. Contribution ### Part 15 — CRS (Contribution Recognition System) *(Integrity-first recognition for an open evidence commons; no pay-to-play; no “fame economy”; no authority creation.)* #### 15.1 Purpose, Scope, and Public-Interest Design Goals 15.1.1 **CRS as integrity infrastructure.** CRS is the Platform’s integrity-grade recognition layer for an open evidence commons: it converts verified work into earned standing signals that support safety, quality, and operational reliability of Guild outputs under scrutiny.\ 15.1.2 **Work recognized vs hype prohibited.** CRS recognizes reproducible work, review labor, safety improvements, corrections discipline, and governance-support contributions. CRS must never reward hype, follower counts, media attention, payment, sponsor status, employer prestige, or political influence.\ 15.1.3 **Voluntary-by-default.** Participation is voluntary. Members may remain Observers without penalty. CRS is not a participation mandate and is not used to coerce contribution, attendance, or disclosure.\ 15.1.4 **System relationships.** CRS is coupled to: PoC (Part 11) as a privilege gate; ILAs (Part 10) as competence infrastructure; iVRS (Part 16) as system health metrics; and Quality/Badging (Part 17) as artifact-level markings. CRS never overrides handling, safety holds, or due process.\ 15.1.5 **Non-executing perimeter.** CRS confers no external authority and no operational role outside Platform-limited privileges. It does not create agency, delegation, licensure, certification-of-compliance, procurement eligibility, or any execution-stack authority. *** #### 15.2 Core CRS Concepts and Units 15.2.1 **Contribution Unit taxonomy.** CRS recognizes discrete contribution units, including: methods and method cards; datasets and dataset cards; benchmarks and harnesses; Proof Packs/AEP components; peer review and verification work; clinic facilitation and participation; drills and after-action work; corrections and supersession work; documentation and maintenance work; safety screening and redaction/abstraction work.\ 15.2.2 **Evidence links required.** A contribution counts only when linked to record-valid evidence objects (artifact pointers, review logs, replication logs, decision records, correction records, distribution logs where required) sufficient to replay or audit the contribution’s substance.\ 15.2.3 **Scope tags and Guild routing.** Every credited unit must be routed to a lead Guild-of-record with scope tags. Cross-Guild co-tags are permitted under a no-double-counting rule and federation routing (lead-of-record controls counting).\ 15.2.4 **Handling-class inheritance.** Contributions inherit the handling class of their underlying artifacts. Recognition surfaces must respect handling: public-safe recognition may be abstracted; controlled recognition may be access-logged; restricted recognition may be minimized.\ 15.2.5 **Role-marker separation.** CRS credits are not authority, and recognition is not delegation. Role markers are time-boxed privileges governed by PoC/ILA/handling; CRS is a standing signal only. *** #### 15.3 Recognition Ladders and Standing States 15.3.1 **Standing states.** Canonical CRS standing states: **Observer**; **Active**; **Member-in-Good-Standing (MGS)**; **Advanced Contributor**; **Steward-Eligible**. States are computed and recorded by rule, not by narrative or nomination.\ 15.3.2 **Ladder design.** Each step has: (a) entry thresholds; (b) maintenance thresholds; (c) lapse mechanics; (d) regain conditions; and (e) visibility settings. Thresholds are impact-proportional and include integrity prerequisites (COI hygiene, handling compliance).\ 15.3.3 **Domain overlays.** Councils/Guilds may define domain-specific ladders (e.g., “Benchmark Maintainer-Eligible”) only as overlays consistent with global invariants (no pay-to-play, no employer prominence, no identity coercion).\ 15.3.4 **Time decay and recency weighting.** CRS uses time decay/recency weighting to prevent “once-famous” capture and to reflect current competence and reliability. Decay must be predictable, published, and contestable by record.\ 15.3.5 **Portability across Guilds.** Recognition portability is permitted with a primary-home anchor: recognition may transfer as eligibility signals, but routing/rotation pool eligibility may remain anchored to a primary home for integrity and seat-completion stability. *** #### 15.4 Contribution Classes and Weighting Model 15.4.1 **Class A — Safety-critical.** Measurement safety improvements; handling upgrades; dual-use redaction/abstraction; responsible disclosure routing; crisis narrative safety; stop-the-line support artifacts.\ 15.4.2 **Class B — Reproducibility.** Replication runs; benchmark harnesses; evaluation jigs; environment manifests; method replay packs; reproducibility bug-fixes.\ 15.4.3 **Class C — Evidence packaging.** Proof Pack/AEP templates; admissibility checklists; limitation/risk disclosures; lawful-basis matrices; distribution plan templates; correction readiness checklists.\ 15.4.4 **Class D — Review and contestation.** Peer review; verification runs; red-team reporting formats; contestation participation; dissent/minority report stewardship.\ 15.4.5 **Class E — Convening.** Clinic facilitation; drill facilitation; program committee work; safe-meeting marshal duties; session artifact completion discipline.\ 15.4.6 **Class F — Maintenance.** Schema upkeep; documentation; release notes; deprecation and migration work; known-issues registers; tooling hardening that improves auditability.\ 15.4.7 **Class G — Community safety.** Protected participation support; anti-retaliation actions; accessibility contributions; translation integrity work; safeguarding incident response contributions (non-operational).\ 15.4.8 **Weighting constraints.** Weighting must be: (a) sponsor-neutral; (b) payment-blind; (c) identity-minimization compatible; (d) auditable; (e) safety-biased (safety work must not be structurally under-rewarded). *** #### 15.5 Eligibility Gates (What Must Be True for Credit to Count) 15.5.1 **Minimum record fields.** Creditable units require minimum record fields: scope; limitations; handling election; reliance bounds; expiry or review clock; and artifact pointers sufficient to verify the unit.\ 15.5.2 **PoC prerequisites.** Certain unit types require minimum PoC levels (e.g., PoC2 for review credit; PoC3 for release/correction initiation credit; PoC5 for safety-hold-related acts).\ 15.5.3 **COI and recusal compliance.** COI disclosure and recusal compliance are prerequisites. Self-review and sponsor-influenced review patterns invalidate credit and may trigger clawbacks.\ 15.5.4 **Lawful participation prerequisites.** Sanctions/export controls and local law constraints apply; access denial or restricted handling may prevent certain credits from being earned or displayed.\ 15.5.5 **Provenance and IP hygiene.** Contributions require inbound rights clarity, license hygiene, and provenance integrity (no contamination, plagiarized artifacts, or unauthorized third-party content). *** #### 15.6 Anti-Gaming and Sybil Resistance Controls 15.6.1 **Identity-minimization compatible anti-sybil.** Anti-sybil controls are risk-proportional and compatible with pseudonyms: higher-impact credits require stronger evidence links, stronger review corroboration, and/or stronger account assurances, without mandating public identity.\ 15.6.2 **Duplicate and collusion detection.** Detection targets review rings, mutual-upvote loops, reciprocal low-quality credits, and coordinated manipulation of queues, while preserving privacy via minimized signals and human review.\ 15.6.3 **Rate limits and caps.** Lane-specific rate limits, cooldowns, and caps apply to prevent credit farming and to protect reviewer capacity and integrity.\ 15.6.4 **Proof-of-work evidence.** High-value credits require proof-of-work evidence: replication logs, review rubrics, method deltas, or corrections artifacts that can be inspected and contested.\ 15.6.5 **Clawbacks and sanctions.** Gaming triggers clawbacks (partial/full), reversals, privilege downgrades, and sanctions by record with reason codes and appeal lanes.\ 15.6.6 **Transparency of logic.** CRS anti-gaming logic is documented with public-safe summaries; sensitive detection heuristics are controlled and access-logged to prevent adversarial adaptation. *** #### 15.7 Reviewer Rotation and Independence Protections (CRS-Backed) 15.7.1 **Reviewer pool eligibility.** Eligibility requires standing thresholds, PoC levels, handling readiness, and COI cleanliness.\ 15.7.2 **Rotation algorithms.** Rotation prevents concentration, repeated pairings, and “queue capture,” using auditable assignment rules and diversity constraints.\ 15.7.3 **Independence rules.** No self-review; no single-entity dominance; no sponsor-driven review routing; no reciprocal review barter patterns.\ 15.7.4 **Handling-class gating.** Controlled and restricted review queues require additional handling readiness and, where lawful/necessary, stronger identity assurance tiers.\ 15.7.5 **Overrides and substitutions.** Overrides are permitted only in emergencies, must be record-valid, reason-coded, time-boxed, and subject to post-hoc audit and contestation. *** #### 15.8 Recognition Surfaces (Visibility Without Doxxing) 15.8.1 **Public-safe surfaces.** Public-safe recognition uses role markers, scoped badges, anonymized statistics, and contribution counts by category—never exposing sensitive affiliations or identities by default.\ 15.8.2 **Controlled surfaces.** Controlled recognition includes internal rosters and queue eligibility signals, access-logged and handling-bounded.\ 15.8.3 **Attribution permissions.** Named attribution is opt-in, scoped, expiry-bound, and reversible by record where lawful; role-marker attribution is default.\ 15.8.4 **No endorsement language.** Recognition surfaces include non-endorsement and non-equivalence statements; CRS is not a certification-of-compliance or “approved by” signal.\ 15.8.5 **Right to quiet participation.** Members retain a right to quiet participation: no requirement to publicize, self-promote, or publish identity-linked achievements. *** #### 15.9 CRS and Membership Status Interaction 15.9.1 **Standing effects on role eligibility.** CRS standing can qualify a member for voluntary roles (reviewer, steward, program committee) but cannot override PoC/ILA/handling gates and cannot create guaranteed role assignment.\ 15.9.2 **Lapse and reinstatement.** Lapse rules apply with grace windows; reinstatement may require re-attestation, PoC refresh, and integrity review where incidents occurred.\ 15.9.3 **Restrictions and suspensions.** When a member is Limited/Restricted/Suspended, CRS accrual may pause, visibility may reduce, and certain credits may be held in pending state until dispute resolution.\ 15.9.4 **Alumni/read-only states.** Alumni/read-only recognition persists in archival form with minimized visibility and clear “no authority” labeling; de-listing occurs automatically if removed for cause. *** #### 15.10 CRS Accounting, Auditability, and Integrity Controls 15.10.1 **Authoritative source-of-truth.** Platform records are authoritative for CRS computation; any derived ledger is subordinate and must reconcile to record-valid acts.\ 15.10.2 **Audit logs.** CRS maintains audit logs showing: who was credited; for what unit; on what basis; at what time; under what handling; and with what reviewer corroboration.\ 15.10.3 **Periodic integrity audits.** Periodic sampling audits detect anomalies, conflict patterns, and capture indicators; audits produce public-safe summaries and controlled audit packs as required.\ 15.10.4 **Appeals and corrections.** Members may appeal CRS outcomes through dispute lanes; corrections follow clock-based discipline and supersession rules (no silent edits).\ 15.10.5 **Retention and minimization.** CRS computations minimize identity exposure; retention aligns to handling classes; de-identification and access restriction are preferred where record integrity prohibits deletion. *** #### 15.11 Cross-Guild Portability and “Roaming” Rules 15.11.1 **What transfers vs what doesn’t.** Portable: standing signals, verified unit counts, and competence-linked eligibility indicators. Non-portable: restricted details, controlled artifacts, and any recognition that would leak handling-bounded information.\ 15.11.2 **Primary-home anchor effects.** Primary home anchors certain governance functions (rotation pools, ballot eligibility, seat-completion routing) without becoming a gate to participation.\ 15.11.3 **Cross-Guild contributions.** Cross-Guild contributions require a lead-of-record designation; co-tagging is permitted; double counting is prohibited.\ 15.11.4 **Federation work.** Federation work (WEFH/cyber–AI/supply chain coupling) is credited by federation rules with clear boundaries to avoid “credit laundering” across domains.\ 15.11.5 **Multilingual/accessibility recognition.** Translation integrity work, localization, and accessibility contributions are recognized as first-class units, with handling-aware attribution controls. *** #### 15.12 Sponsor/Partner Interaction Controls (Nonprofit-Compatible; Anti-Capture) 15.12.1 **Permissible sponsor support.** Sponsors may support scholarships, public-interest challenges, and infrastructure costs, subject to firewall rules; sponsors do not control CRS weighting or outcomes.\ 15.12.2 **No influence purchase.** Credits, votes, roles, badges, queue priority, or “standing boosts” cannot be purchased, bundled, or implied by sponsorship or payment.\ 15.12.3 **Disclosure and concentration caps.** Disclosure minima and sponsor concentration caps apply, aligned to Part 5 sponsor guardrails, with influence indicators monitored and mitigated.\ 15.12.4 **Sponsored challenges/bounties.** If permitted, sponsored challenges are neutrally scoped, safety-screened, and governed by record-valid rules; acceptance and recognition remain independent.\ 15.12.5 **Conflict handling.** Sponsor-adjacent contributors must disclose COI; recusals and cooling-off may apply; violations trigger clawbacks and sanctions. *** #### 15.13 CRS Change Control, Governance, and Versioning 15.13.1 **Amendments by record.** CRS rule amendments require impact statements, safety and neutrality review, and contestation windows; changes are recorded with effective dates.\ 15.13.2 **Safeguard-critical constraints.** Anti-gaming, anti-capture, and privacy invariants are safeguard-critical and require enhanced thresholds and safety veto paths.\ 15.13.3 **Backward compatibility.** CRS changes avoid retroactive harm; migrations preserve prior good-faith contributions while preventing exploitation; retroactive adjustments require explicit reason codes and appeal paths.\ 15.13.4 **Emergency abuse patches.** Emergency patches are time-boxed, audited, and followed by after-action reporting and ratification; silent “forever” patches are prohibited.\ 15.13.5 **Public-safe documentation.** CRS updates are documented with public-safe rationale, limitations, and expected effects; controlled technical details are minimized and access-logged. --- # 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/xv.-contribution.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.