# XII. Economics

### Part 12 — Utility Credits and Access Economics

*(Non-Financial Utility; No Vote-Buying; Voluntary-by-Default)*

#### 12.1 Purpose, Scope, and Non-Financial Nature

12.1.1 **Credits as access/participation utilities.** Utility Credits are non-financial access utilities used to (i) meter scarce platform resources (compute, secure rooms, review capacity), (ii) recognize recorded service labor, and (iii) route members into structured learning and evidence workflows. Credits are not money, not securities, not investment instruments, not dividends, not “points” convertible to value, and not a mechanism to purchase influence.\
12.1.2 **Perimeter alignment.** Credits never authorize operational action, procurement activity, enforcement, intelligence tasking, regulated execution, or any binding representation. Credits only gate platform services and participation privileges within the non-executing boundary.\
12.1.3 **Voluntary participation baseline.** Earning and spending credits is optional unless a member affirmatively opts into a role or lane that is credit-metered (e.g., access to a secure sandbox, a limited-seat clinic). Lack of credits cannot terminate baseline membership.\
12.1.4 **Relationship to other systems.** Credits interact with subscriptions (add-on services), scholarships (need-based allocation), PoC and ILAs (competence gates for sensitive lanes), CRS and iVRS (integrity/health metrics), badges (expiry-bound trust markers), and handling classes (visibility and distribution constraints).\
12.1.5 **Reliance bounds and public-safe descriptions.** All credit descriptions must avoid financial framing. Public-facing definitions must include mandatory disclaimers: non-transferable by default, no cash-out, no governance influence purchase, and subject to expiry and revocation by record.

***

#### 12.2 Credit Types and Canonical Definitions

12.2.1 **eCredits (Engagement Credits).** Non-financial units earned for recorded participation and service: clinics, drills, structured reviews, steward duties, program support—measured by time-boxed, reason-coded records and integrity checks.\
12.2.2 **pCredits (Publication Credits).** Non-financial units earned or allocated for publication-ready work: method cards, dataset/benchmark documentation, release notes, translation integrity, corrections/supersession work, and post-publication reconciliation.\
12.2.3 **vCredits (Verification Credits).** Non-financial units earned or allocated for verification labor: replication runs, peer review, evaluation protocol checks, audit-style integrity checks (without “audit opinion” language), and contestation/hearing participation.\
12.2.4 **NUCs (Nexus Utility Compute Credits).** Metering units for compute and tooling capacity (sandbox time, quotas, rate-limit lifts, replication harness usage), bound by security controls, lawful constraints, and handling-class segmentation.\
12.2.5 **Optional domain labels (if any).** If domain “tokens” exist, they are labels only and must remain non-transferable by default, non-tradable, non-cashable, with explicit prohibition on secondary markets and financial promotion.

***

#### 12.3 Design Principles and Invariants (Non-Derogable)

12.3.1 **Non-transferability by default.** Credits are non-transferable by default, non-sellable, non-assignable, cannot be pledged, cannot be collateralized, cannot be converted to fiat/crypto, and cannot be redeemed for cash-equivalent value. Exceptions, if any, must be narrowly defined by record and never create a market.\
12.3.2 **No vote-buying / no influence purchase.** Credits cannot be used to buy votes, vetoes, seats, agendas, speaker slots, badge issuance, reviewer assignments, dispute outcomes, or any governance privilege. This is a safeguard-critical, non-derogable prohibition.\
12.3.3 **Anti-gaming and sybil resistance.** Earning and spending are protected by rate limits, evidence linking (artifact pointers), reviewer validation thresholds, anomaly detection, rotation rules, and clawbacks for fraud.\
12.3.4 **Handling-aware credit logic.** Controlled and Restricted work may generate credits without public disclosure of sensitive details; public reporting is aggregated and identity-minimized.\
12.3.5 **Equity and accessibility.** Credits must support low-resource participation: non-monetary earning options, scholarships/waivers, low-bandwidth pathways, and accessibility accommodations as first-class allocation uses.\
12.3.6 **Market and procurement neutrality.** Credits cannot be used to steer vendors, shortlist solutions, recommend procurement, or create deal-room advantages. Any attempt triggers neutrality enforcement and sanctions.

***

#### 12.4 Earning Rules (What Activities Generate Credits)

12.4.1 **Eligible eCredit activities.** Recorded service activities: attendance and participation in clinics/drills; structured governance support; moderated sessions; time-boxed committee work; steward duties; calibrated review participation; dispute/hearing participation where assigned.\
12.4.2 **Eligible pCredit activities.** Publication-grade work: method cards; dataset cards; evaluation harness documentation; release notes; translation integrity; corrections and supersession drafting; redistribution reconciliation and misquote correction support.\
12.4.3 **Eligible vCredit activities.** Verification labor: replication runs; peer review; evaluation protocol adherence checks; documentation audits; red-team *reporting format* checks (not exploit development); contestation review lanes with reason-coded outputs.\
12.4.4 **Eligible compute stewardship credits.** Work that improves reproducibility and safe tooling: environment manifests, SBOM hygiene, sandbox hardening contributions, reproducibility tooling, rate-limit optimization, and integrity logging improvements (without enabling abuse).\
12.4.5 **Ineligible activities.** Marketing, recruitment spam, paid speaking for influence, lobbying, procurement steering, sponsor promotion, political campaigning, and any activity that substitutes hype for evidence.\
12.4.6 **Evidence requirements for earning.** Credits are earned only via record-valid logs that include artifact pointers, scope/timebox, role marker of the contributor, handling election, reviewer validation where required, and reason-coded outcomes. No off-platform claims count.

***

#### 12.5 Spending Rules (What Credits Can Be Used For)

12.5.1 **Tooling and environments.** Access to sandboxes, replication harnesses, secure environments, controlled rooms (where eligible), rate-limit lifts, and quota-based compute usage—always gated by PoC/ILA where required.\
12.5.2 **Convening access.** Limited-seat labs/clinics, evidence rooms, and specialized sessions where capacity is constrained—never as a “VIP lane,” only as resource metering with fairness rules.\
12.5.3 **Publication services.** Access to packaging support, safety screening capacity, documentation hygiene checks, and translation integrity review.\
12.5.4 **Training and Academy.** Courses, mentorship hours, lab environments, and cohort clinics (where capacity must be metered).\
12.5.5 **Domain-specific resource queues.** Where permitted, credits may meter queue access (e.g., faster *time-to-start* for review support), but never purchase “approval,” outcomes, badge issuance, or favorable reviewer assignment.\
12.5.6 **Prohibited spend.** Any spend for governance power, seats, votes, vetoes, speaker selection, dispute outcomes, badge issuance, release authority, or influence—strictly forbidden and sanctionable.

***

#### 12.6 Allocation and Issuance Mechanisms (How Credits Enter Circulation)

12.6.1 **Earned issuance.** Primary mechanism: credits are earned through verified participation and evidence work recorded on-platform.\
12.6.2 **Grant/Scholarship issuance.** Need-based and public-interest allocations (students, low-resource geographies, accessibility needs, public-sector ethics-safe pathways), with documentation minimization and COI-screened review.\
12.6.3 **Sponsor-supported issuance.** Permitted only under strict firewall rules: sponsors may fund scholarship pools or capacity pools; sponsors cannot direct recipients, cannot buy agenda/roles, and cannot influence decisions. Concentration caps and disclosures apply.\
12.6.4 **Emergency-mode issuance.** Time-boxed issuance during integrity/safety incident mode to support measurement and after-action evidence capture; requires after-action records and expiry-by-default.\
12.6.5 **Expiry-by-default and anti-hoarding.** Credits may expire by default to prevent hoarding, capture, and queue domination. Exceptions require record-valid justification and must not create influence.

***

#### 12.7 Accounting, Ledgers, and Record-Validity Requirements

12.7.1 **Platform-record primacy.** Balances, issuance, spends, holds, revocations, and expiries are valid only by platform record.\
12.7.2 **Audit logs and traceability.** Credit events must be traceable to record-valid activity logs, role markers, and artifact pointers, with handling-class appropriate distribution logs when relevant.\
12.7.3 **Corrections and supersession.** Credit events are correctionable by record: no silent edits; adjustments must be reason-coded, dated, and linked to the triggering evidence.\
12.7.4 **Negative balances and pending states.** The system may use pending states for disputes, fraud flags, or safety holds; negative balances may be allowed only as bounded “pending clawback” states with due process and expiry.\
12.7.5 **Portability across Labs/Guilds.** Credit portability is permitted within GCRI Platforms only under equivalent-or-stronger handling and anti-gaming constraints; cross-entity portability outside GCRI is prohibited unless explicitly designated and safety-reviewed.

***

#### 12.8 Controls Against Capture, Influence, and Pay-to-Play

12.8.1 **Sponsor concentration limits.** Sponsor-funded issuance is capped; concentration indicators are monitored; mitigation actions include diversification, rotation, restrictions, and public-safe disclosures.\
12.8.2 **Subscription firewall.** Subscription payments and add-on purchases must be separated from credit issuance logic; payment cannot generate credits that buy privilege.\
12.8.3 **Anti-bulk allocation and “VIP” prohibition.** Bulk allocations that create dominance are prohibited; any exception requires Stewardship review, reason codes, expiry-by-default, and fairness tests.\
12.8.4 **Reviewer rotation and anti-self-review.** Credits cannot purchase reviewer choice; review assignments are rotation-based with COI screens and calibration. Self-review is prohibited; reciprocal-review rings trigger fraud controls.\
12.8.5 **Competition/procurement linkage.** Credit misuse to steer vendors, coordinate markets, or influence procurement triggers immediate stop-the-line measures and sanctions.

***

#### 12.9 Compute and Tooling Governance (NUCs Specific)

12.9.1 **Eligible compute environments.** NUCs apply to approved environments segmented by handling class: public-safe sandboxes, controlled sandboxes, restricted sandboxes (need-to-know).\
12.9.2 **Security posture.** Zero-trust access, MFA, audit logs, quotas, anomaly detection, and kill switches are mandatory; restricted environments require stronger controls and time-boxed access.\
12.9.3 **Data sovereignty constraints.** Compute-to-data is the default for sensitive datasets; sovereign data zones apply where designated; no PII by default; lawful basis must be documented when exceptions exist.\
12.9.4 **Abuse prevention and sanctions.** Prohibited activities include model extraction attempts, scraping, exploit development, surveillance tooling, and targeting cue generation. Violations trigger holds, revocations, clawbacks, and sanctions.\
12.9.5 **Availability and non-guarantees.** Compute is provided on a best-efforts basis; throttling, safety holds, and incident-mode restrictions may override entitlements without liability.

***

#### 12.10 Equity, Accessibility, and Inclusion Mechanisms

12.10.1 **Sliding-scale issuance.** Credits may be issued via sliding-scale rules to support low-resource participation without creating privilege inequality in governance.\
12.10.2 **Public-sector ethics constraints.** Credits for public officials must respect gift rules and non-inducement posture; disclosures and acceptance pathways must be ethics-safe and documented.\
12.10.3 **Low-bandwidth and offline pathways.** Where feasible, credits may be earned via asynchronous review, offline-friendly artifacts, and low-bandwidth participation modes—recorded once synchronized.\
12.10.4 **Multilingual support credits.** Credits may be allocated for translation integrity and multilingual moderation, including meaning-preservation checks and correction parity across languages.\
12.10.5 **Accessibility accommodations.** Accessibility needs (assistive tools, interpretation, adaptive formats) are first-class issuance/spend use cases with minimization of sensitive personal disclosures.

***

#### 12.11 Member States, Status Impacts, and Credit Effects

12.11.1 **Status coupling.** Membership states (Active/Limited/Restricted/Suspended/etc.) affect credit earning and spending privileges, especially for Controlled/Restricted lanes.\
12.11.2 **Lapse/suspension/removal effects.** Non-payment lapses may reduce add-on entitlements without confiscating baseline membership; integrity or safety suspensions may freeze spends and place holds pending due process.\
12.11.3 **Alumni/read-only states.** Alumni may retain limited read-only access and residual credit balances only where permitted; credits do not preserve authority after role expiry.\
12.11.4 **Role-marker expiry effects.** Role-marker expiry automatically downgrades credit-linked privileges; credits cannot “keep” a role.\
12.11.5 **Reinstatement mechanics.** Reinstatement requires re-attestation, PoC refresh where applicable, and integrity review for cases involving safety or fraud.

***

#### 12.12 Disputes, Remedies, and Due Process (Credits)

12.12.1 **Dispute types.** Earn denial, clawback disputes, spend denial, fraud flags, allocation disputes, expiry disputes, and sponsor-funded pool disputes.\
12.12.2 **Evidence standards and minimum explanations.** Decisions must be reason-coded with minimum evidence basis; opaque or purely automated punitive outcomes are prohibited.\
12.12.3 **Appeals lane and independent review.** Appeals are time-boxed; independent review triggers apply to high-impact disputes, handled under appropriate handling class.\
12.12.4 **Restitution and corrections.** Where errors are found, corrections are issued by record; reinstatements may be partial and include anti-gaming safeguards.\
12.12.5 **Public-safe transparency reporting.** Systemic issues (fraud rates, concentration, dispute volumes) are reported in aggregate, privacy-preserving form.

***

#### 12.13 Sanctions, Clawbacks, and Fraud Controls

12.13.1 **Fraud definitions.** Sybil behavior, wash contribution, plagiarized artifacts, collusion rings, fabricated reviews, falsified logs, and sponsor-directed allocations.\
12.13.2 **Automated flags + human review.** Automated detection may flag anomalies, but punitive actions require human review, reason codes, and recorded outcomes.\
12.13.3 **Clawback mechanics.** Clawbacks are reason-coded, proportional (partial vs full), and propagate to dependent privileges and trust surfaces where necessary, with contestation lanes.\
12.13.4 **Repeat-offender escalation.** Repeat abuse triggers escalating restrictions up to removal; re-entry conditions may include supervision, PoC resets, and probationary periods.\
12.13.5 **Coordination with conduct/handling enforcement.** Credit fraud and abuse integrates with conduct and handling enforcement lanes; sanctions must be consistent and record-valid.

***

#### 12.14 Transparency, Reporting, and iVRS Integration

12.14.1 **Credit health metrics.** Issuance, burn, hoarding indicators, concentration ratios, queue fairness measures, and equity distribution indicators.\
12.14.2 **Integrity metrics.** Fraud rates, clawbacks, dispute volumes, resolution times, and false-positive rates for automated flags.\
12.14.3 **Service metrics.** Compute availability, throttling events, incident-mode holds, average time-to-start for capacity-gated services.\
12.14.4 **Public-safe vs controlled split.** Public-safe reporting is aggregated and identity-minimized; controlled audit packs are available only under role-gated access with logs.\
12.14.5 **No marketing substitution.** Reporting must include uncertainty and limits; credits cannot be marketed as “rewards,” “returns,” or “member value capture.”

***

#### 12.15 Legal, Tax, and Regulatory Hygiene (Nonprofit-Compatible)

12.15.1 **Non-financial utility characterization.** Member notices must include explicit non-financial characterization and prohibition on conversion, trading, or redemption.\
12.15.2 **Tax/benefit considerations.** Scholarship and sponsor-supported credits must be handled with jurisdiction-aware tax and benefit hygiene; privacy-minimized documentation and clear donor/service characterizations apply.\
12.15.3 **Consumer protection and fairness.** Rules must be clear, appealable, and consistently enforced; price/credit changes require notice and non-retroactive fairness unless fraud is involved.\
12.15.4 **Export controls and sanctions.** Compute/tooling credits are subject to lawful constraints; restricted jurisdictions may have reduced availability or denial, reason-coded and appealable where permissible.\
12.15.5 **No financial promotion.** Any investment framing, promises of value, or secondary market facilitation is prohibited and sanctionable.

***

#### 12.16 Change Control, Versioning, and Supersession (Credits Policy)

12.16.1 **Governance authority.** Credit rules change only by record-valid acts under designated bodies, consistent with safeguard-critical constraints.\
12.16.2 **Safeguard-critical constraints.** Non-transferability by default, no vote-buying, no influence purchase, and no cash-out are non-derogable; amendments cannot weaken these safeguards.\
12.16.3 **Notice, contestation, and migration.** Material changes require notice periods, contestation windows where designated, and migration plans (including grace windows and non-punitive transitions).\
12.16.4 **Backward compatibility and effective dates.** Effective dates must be explicit; backward compatibility is preferred; if breaking changes occur, they must be justified, time-boxed, and corrected by supersession, not silent edits.\
12.16.5 **Emergency patches.** Emergency changes are permitted only for safety/integrity incidents, must include expiry, after-action reporting, and ratification requirements, and must never create pay-to-play effects.


---

# 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/xii.-economics.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.