# XIV. Action

### Part 14 — Platform Governance and Collective Action Mechanics 

*(Records-First; Non-Executing; Voluntary-by-Default; Audit-Ready; Correctionable)*

#### 14.1 Purpose, Scope, and Platform-Governance Doctrine

14.1.1 **Records-first operating system.** Platform governance is a records-first operating system for evidence work: it creates traceable acts, auditable decisions, correctionable outputs, and bounded reliance artifacts. It is not designed or operated as a social network, publicity channel, or influence marketplace.\
14.1.2 **Voluntary-by-default participation.** Participation is voluntary by default. Members may observe, contribute, or serve in roles only by opt-in. No implied duty to vote, attend, publish, review, or disclose identity.\
14.1.3 **Non-executing perimeter enforcement.** Platform mechanics enforce the non-executing perimeter: no operational command, dispatch, enforcement, procurement steering, underwriting, custody, settlement, placement, or deal-making functions may be embedded in workflows, rooms, roles, or incentives.\
14.1.4 **System relationships.** This Part operationalizes the governance wiring (Part 2), competence and privilege-gating (Parts 10–12), and integrity surfaces (Parts 15–18), ensuring that governance actions are record-valid, contestable, and safety-bounded.

***

#### 14.2 Record-Validity and Act Types (What the Platform Recognizes)

14.2.1 **Record-Valid act definition.** A record-valid act is an event recognized by the Platform as governing for privileges, states, releases, and enforcement. Each act has minimum required fields: (a) act type; (b) scope; (c) effective date/time; (d) issuer/role marker; (e) approvals/signatures (where required); (f) handling election; (g) reliance bounds; (h) expiry or review clock; (i) reason codes (for adverse acts); (j) pointers to supporting artifacts; (k) distribution log pointer when required.\
14.2.2 **Canonical act taxonomy.** The Platform recognizes a canonical set of acts, including membership state acts, role issuance/revocation acts, workspace creation/archival acts, convening notice/minutes acts, release and deprecation acts, dispute and appeal acts, sanctions and remedies acts, cell and CERT formation/dissolution acts, and schema/rule change acts.\
14.2.3 **Designated acts and anchoring rules.** Certain acts may be designated as higher-integrity acts requiring additional approvals, multi-person controls, or anchoring mechanisms (where applicable), without changing the non-executing perimeter.\
14.2.4 **Distribution logging by act type.** Where an act changes access, releases controlled content, or imposes a hold/sanction, distribution logs are mandatory, capturing recipients, scope, expiry, revocation capability, and correction notification duties.\
14.2.5 **Expiry-by-default.** Privileges, holds, and sensitive designations expire by default unless renewed by record. Deprecation is explicit; non-renewal reverts permissions to least privilege.\
14.2.6 **No silent edits.** Acts are immutable once issued; amendments occur only through supersession acts with diffs, reason codes, effective dates, and redistribution reconciliation where needed.

***

#### 14.3 Workspace Architecture (Guilds, Labs, Clinics, Cells, and Federations)

14.3.1 **Workspace types.** Workspace types include: Guild hubs; Lab rooms; project rooms; clinic rooms; controlled rooms; restricted rooms; hearing rooms; and incident-mode rooms. Each type has default templates for docketing, safe-meeting scripts, handling elections, and artifact requirements.\
14.3.2 **Primary home + roaming model.** The Platform implements a “primary home + roaming” participation model: each member elects a primary home for routing and seat completion while retaining roaming rights subject to handling and privilege gates.\
14.3.3 **Federation workspaces.** Cross-Guild federations are permitted for coupling domains (e.g., WEFH, cyber–AI coupling, supply-chain coupling), with a lead-of-record designation, co-tagging limits, and contestation lanes to prevent shadow governance and double counting.\
14.3.4 **Namespace controls.** Official labels, reserved names, and anti-impersonation controls apply. Only record-valid workspaces may use protected names (e.g., “GCRI,” “Official,” “Council,” “CERT”).\
14.3.5 **Scope statements embedded.** Every workspace contains embedded metadata: scope, exclusions, intended audiences, default handling, dual-use notes, and reliance bounds.\
14.3.6 **Workspace lifecycle.** Create → operate → archive → retain/minimize. Archival preserves record integrity, prevents silent deletion, and applies handling-aware retention/minimization.

***

#### 14.4 Proposals and Backlog Governance (From Idea to Work Item)

14.4.1 **Proposal types.** Proposal types include: method proposals; dataset documentation proposals; benchmark proposals; Proof Pack/AEP pattern proposals; safety notes; tooling change proposals; schema/rule change proposals.\
14.4.2 **Intake rules.** Proposals require minimum fields: problem statement; intended public value; limitations and uncertainty; handling election; COI tags; dependencies; proposed reviewers; and any dual-use/market sensitivity flags.\
14.4.3 **Triage lanes.** Triage lanes may include: automated screening (format/fields); steward screening (fit and duplication); safety screening (dual-use/targeting/rights harm); council screening (domain governance fit); and escalation lanes (cross-council or Stewardship).\
14.4.4 **Prioritization principles.** Prioritization is based on public value, safety posture, reproducibility/replayability, adoption fit, and capacity constraints—never sponsor preference or payment level.\
14.4.5 **Acceptance thresholds.** Backlog acceptance uses impact-class thresholds (lightweight where low-risk; higher thresholds for safety-critical, market-sensitive, or rights-impacting work).\
14.4.6 **Anti-gaming controls.** Duplicate detection, sybil resistance, rate limits, and contribution integrity checks apply; repeated manipulation triggers holds and clawbacks by record.

***

#### 14.5 Decision Records and Voting Mechanics (Lightweight but Auditable)

14.5.1 **Decision record template.** Every decision produces a record: decision; rationale; alternatives considered; limitations; expiry/review clock; correction path; dissent capture; handling election; and distribution requirements.\
14.5.2 **Voting vs consent vs delegated review.** Voting is used sparingly for designated governance matters; consent-based decisions are default for operational routing; delegated review is used for technical judgments where PoC-qualified reviewers are required.\
14.5.3 **Quorum/threshold and anti-capture.** Quorum and thresholds are risk-weighted and include anti-capture constraints (influence caps, rotation, helix balance checks, and independence requirements).\
14.5.4 **Abstention protections.** Abstention and non-participation are protected choices; no penalties attach unless a member has opted into a role with explicit duties and SLAs.\
14.5.5 **Minority reports preserved.** Material dissent must be preserved as a first-class artifact; suppression is prohibited; dissent may be public-safe or controlled depending on handling.\
14.5.6 **Ballot integrity.** Ballots are auditable with identity minimization, anti-sybil proportionality, and audit logs. Public attribution is opt-in and expiry-bound.

***

#### 14.6 Collective Action Modes (Sprints, Clinics, Drills, Campaigns)

14.6.1 **Replication sprints.** Time-boxed efforts to test replayability, reproduce results, and improve benchmark integrity; outputs are replication logs and method deltas.\
14.6.2 **Clinics.** Methods, verification, and publication clinics produce structured artifacts (checklists, review notes, packaging deltas) and competence evidence for ILAs/PoC where elected.\
14.6.3 **Drills.** Drills validate governance primitives: record drills, watermark drills, correction drills, safe-meeting drills, and access-revocation drills.\
14.6.4 **Campaign integration.** Campaigns are time-boxed, non-partisan, non-executing activation drives that produce evidence artifacts and public-safe summaries; they do not direct operations or procure solutions.\
14.6.5 **Entry/exit rules.** Opt-in only; exit without penalty except survival obligations for handling and corrections.\
14.6.6 **Reporting outputs.** Public-safe summary defaults; controlled appendices minimized; distribution logs mandatory for controlled outputs.

***

#### 14.7 Formation Mechanics for CCells and CERTs (Create, Scope, Dissolve)

14.7.1 **CCell formation records.** Each CCell requires a formation act: scope, deliverables, timebox, lead steward, PoC gates, handling election, archive plan, and dissolution default.\
14.7.2 **CERT formation records.** CERT formation requires a higher-integrity act: scope (measurement support only), liaison routing, handling election, expiry, and after-action obligations.\
14.7.3 **Dissolve-by-default.** Cells and CERTs dissolve by default at expiry unless renewed; archival is mandatory and record-valid.\
14.7.4 **No shadow governance.** Cells cannot override Councils or Stewardship lanes; escalations route to the designated governance interface only.\
14.7.5 **After-action obligations.** CERTs and high-impact CCells must produce after-action artifacts, including what changed/what holds/what was withheld and correction routing.\
14.7.6 **Jurisdiction activation gate.** Any activity that would constitute local presence is prohibited absent activation + mandate evidence.

***

#### 14.8 Release Governance (Draft → Candidate → Published → Deprecated)

14.8.1 **Release states and gates.** Releases move through defined states with readiness checklists, PoC-qualified reviews, safety screening, and record-valid sign-offs.\
14.8.2 **Required release artifacts.** Releases require limitation statements, uncertainty disclosure, reliance bounds, expiry clocks, and correction/supersession readiness.\
14.8.3 **Reviewer rotation and independence.** Rotation pools and independence checks reduce capture and self-review; escalations required for sensitive domains.\
14.8.4 **Safety screening and dual-use routing.** Safety routing may require abstraction, redaction, delayed release, partitioning into public-safe vs controlled appendices, or temporary holds with expiry.\
14.8.5 **Public-safe summaries default.** Sensitive domains must default to public-safe summaries with controlled appendices minimized and access-logged.\
14.8.6 **Deprecation and linkage.** Deprecation and supersession must be explicit; correction records link to all downstream references and distribution logs.

***

#### 14.9 Contestation and Appeals Workflows (Built-In Safety Feature)

14.9.1 **Contestation triggers.** Quality disputes, safety concerns, COI concerns, misrepresentation, handling breaches, and rights harms trigger contestation lanes.\
14.9.2 **Contestation lanes.** Guild lane → Council lane → cross-council lane → Stewardship lane, with routing rules by sensitivity and impact.\
14.9.3 **Temporary holds with expiry.** Stop-the-line holds are permitted, must be reason-coded, expire by default, and include reopen conditions.\
14.9.4 **Evidence requirements.** Decisions require minimum evidence basis; anonymous reporting is supported where lawful; retaliatory contestation is sanctionable.\
14.9.5 **Appeal windows and rationale.** Appeals have defined windows and outcomes; public-safe rationale is published where possible without doxxing or sensitivity leakage.\
14.9.6 **Anti-retaliation.** Challengers and minority reporters receive protected participation safeguards; retaliation triggers sanctions and role revocations.

***

#### 14.10 Corrections, Supersession, and Version Discipline

14.10.1 **Correction clocks.** Correction clocks are severity-based: rapid errata for minor defects, formal supersession for substantive errors, and immediate safety advisories where harm risk exists.\
14.10.2 **Errata vs deprecation vs supersession.** Errata corrects without changing meaning; deprecation signals non-reliance; supersession replaces with a new version and diff.\
14.10.3 **Immutable pointers; mutable commentary.** Immutable release pointers preserve integrity; commentary layers may evolve by record where allowed, without altering the release artifact.\
14.10.4 **Known-issues registers.** Known issues, safety advisories, and limitations are maintained as first-class records to prevent quiet erosion of trust.\
14.10.5 **Redistribution reconciliation.** Prior recipients must be notified of corrections; distribution logs are updated with correction delivery evidence.\
14.10.6 **Misquote/misuse response.** Misquote clarifications, misuse notices, and takedown requests follow a defined workflow with record defense and public-safe explanations.

***

#### 14.11 Access Control, Identity Minimization, and Auditability

14.11.1 **RBAC tied to PoC and handling.** Access uses role-based controls coupled to PoC, ILA status, and handling class; least privilege and time-boxed elevation are default.\
14.11.2 **Pseudonym support.** Pseudonym participation is supported; identity is segregated and minimized; role markers remain the primary trust surface.\
14.11.3 **Two-person unmasking.** Unmasking occurs only where lawful/necessary, under two-person rule, access logging, reason codes, and expiry.\
14.11.4 **Audit logs.** The Platform maintains auditable logs for access events, edits, approvals, holds, releases, and distribution actions, with retention aligned to handling.\
14.11.5 **Credential lifecycle.** Credential issuance, rotation, revocation, and emergency locks are governed by record-valid acts and incident protocols.\
14.11.6 **Compromise and recovery.** Compromise response includes containment, role resets, lockouts, forensic records, and correction notices where impacted artifacts exist.

***

#### 14.12 Competition / Procurement / Market Neutrality Controls in Platform Design

14.12.1 **Prohibited topics and coordination.** Price coordination, bid discussions, market allocation, client restrictions, and procurement steering are prohibited in platform rooms.\
14.12.2 **Safe-meeting scripts embedded.** Room templates embed safe-meeting opening scripts, interrupt protocols, and escalation routing.\
14.12.3 **Controlled minutes and redaction.** Minutes are minimal by default; sensitive content is reason-coded and redacted where required by handling rules.\
14.12.4 **Vendor neutrality enforcement.** No endorsement language; no shortlists; no implied procurement outcomes; misrepresentation triggers takedown and sanctions.\
14.12.5 **Market sensitivity flags.** Market-sensitive content triggers delayed-release and partitioning into public-safe summaries and controlled appendices.\
14.12.6 **Neutrality breach escalation.** Breaches trigger stop-the-line controls, incident handling, role suspension, and public clarification where required.

***

#### 14.13 Safety and Safeguarding Mechanics (Do-No-Harm Embedded)

14.13.1 **Anti-harassment/doxxing tools.** The Platform supports prevention, detection, and enforcement, integrated with role revocation and membership state changes by record.\
14.13.2 **Protected reporting.** Confidential and anonymous reporting channels are available where lawful, with protected participation safeguards and routing to integrity roles.\
14.13.3 **Youth/vulnerable constraints.** Where enabled, enhanced safeguarding applies; certain rooms and roles may be prohibited to protect participants.\
14.13.4 **Crisis narrative safety.** Non-amplification posture, uncertainty disclosure, and safe-summary defaults are mandatory during incidents.\
14.13.5 **Targeting-cue suppression.** Defaults suppress facility targeting cues; operator-safe abstraction is the baseline for critical infrastructure.\
14.13.6 **Privacy-preserving harm detection.** Pattern-of-harm detection is designed to preserve privacy while enabling enforcement, using minimized signals and human review.

***

#### 14.14 Data Governance in the Platform (No PII by Default)

14.14.1 **Minimization and retention.** No PII by default; handling-aware retention schedules; purpose limitation enforced in templates and intake forms.\
14.14.2 **Controlled datasets and restricted rooms.** Controlled datasets require lawful basis, expiry, access logs, distribution logs, and compute-to-data constraints where applicable.\
14.14.3 **Provenance/lineage.** Provenance and lineage requirements align to GRIx: source traceability, schema conformity, dataset/model cards, and versioning.\
14.14.4 **Export/sanctions gating.** Export controls and sanctions restrictions are implemented in access control and distribution routing.\
14.14.5 **Deletion and de-identification.** Deletion is constrained by record integrity; alternatives include de-identification, access restriction, and minimized linking.\
14.14.6 **Third-party ingestion.** Third-party content must respect copyright and licenses; permissions are recorded; prohibited scraping and unlawful ingestion are blocked.

***

#### 14.15 Operational Resilience of Governance-Critical Platform Services

14.15.1 **Governance-critical services list.** Registry, record store, roles/permissions, audit logs, corrections engine, distribution logs, dispute lanes, and safety holds are governance-critical primitives.\
14.15.2 **Backup and continuity.** Backup, continuity, and disaster recovery protect record integrity; reconciliation procedures exist for outages and partial failures.\
14.15.3 **Secure change management.** Governance schemas, templates, and release pipelines follow secure change management with approvals, diffs, rollback plans, and test gates.\
14.15.4 **Incident response.** Outage/leak incidents prioritize integrity: contain, preserve evidence, notify by handling rules, issue holds, and publish public-safe summaries as appropriate.\
14.15.5 **Monitoring and SLOs.** SLOs apply to governance primitives (record availability, log integrity, correction distribution, dispute triage), with public-safe status reporting.\
14.15.6 **After-action improvements.** Post-incident after-action artifacts drive control improvements, template updates, and rule supersessions by record.

***

#### 14.16 Transparency Outputs and Public Trust Surfaces (Non-Marketing)

14.16.1 **Public-safe summaries.** Every material output defaults to a public-safe summary: what, why, limitations, expiry, correction path—without sensitive leakage.\
14.16.2 **Controlled appendices minimized.** Controlled appendices are minimized, access-logged, retention-bounded, and partitioned from public-safe artifacts.\
14.16.3 **Registry views.** Registry exposes public-safe views of membership states, role markers, badge status, sanction summaries, and correction status—without doxxing.\
14.16.4 **Attribution controls.** Attribution is permissioned, scoped, expiry-bound; role-marker attribution is default.\
14.16.5 **Publication integrity.** Outputs include non-endorsement and bounded reliance language; promotional framing is prohibited.\
14.16.6 **Metrics integration.** iVRS health/integrity/impact signals are published in public-safe form, with uncertainty and limitations mandatory.

***

#### 14.17 Change Control for Platform Governance Rules

14.17.1 **Rule change proposals.** Rule changes require an impact statement, safety review, neutrality review, and handling posture, with explicit migration implications for roles, credits, artifacts, and in-flight work.\
14.17.2 **Notice and contestation.** Notice windows and contestation periods apply; emergency patches are time-boxed and require post-hoc ratification.\
14.17.3 **Safeguard-critical protections.** Safeguard-critical rules (handling, identity minimization, anti-pay-to-play, stop-the-line, due process) have enhanced thresholds and safety veto pathways.\
14.17.4 **Migration plans.** Migration plans are mandatory for breaking changes; backward compatibility is preferred; deprecations are explicit with timelines.\
14.17.5 **Effective dates and supersession.** Changes take effect only by record with effective dates and diff visibility; silent edits are prohibited.\
14.17.6 **Rollback and emergency patches.** Rollbacks follow record-valid procedures; emergency patches are expiry-bound and audited.

***

#### 14.18 Interpretation and Conflict Handling Within Platform Mechanics

14.18.1 **Room rules vs Constitution invariants.** Workspace rules may not override constitutional invariants; conflicts are resolved in favor of constitutional constraints by record.\
14.18.2 **Priority rules.** Handling > safety > due process > convenience.\
14.18.3 **Jurisdictional constraints.** When local law conflicts with platform rules, abstention is default, escalated by record, and safety-first.\
14.18.4 **Dispute venue.** Platform governance matters route through the designated membership/dispute lanes with reason codes, evidence basis, and appeal windows.\
14.18.5 **Severability and survivability.** Invalid or inapplicable rules do not void unrelated governance actions; survival obligations persist post-exit as designated (handling, non-misrepresentation, correction duties where applicable).\
14.18.6 **Notices by record.** Authoritative communications occur by platform record; off-platform notices are informative only and cannot change rights, states, or obligations.


---

# 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/xiv.-action.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.