# IV. Architecture

### Part 4 — Open Membership Architecture

#### 4.1 Open-to-All Membership Principle (Voluntary-by-Default)

4.1.1 **Open commons posture.** GCRI Guild membership is an open commons. No person may be excluded on the basis of employer brand, status, ideology, geography, or sector affiliation. Any restriction must be justified by lawful constraints, handling class, safety risk, integrity risk, or PoC gating for controlled lanes, and must be recorded with reason codes.\
4.1.2 **Voluntary participation baseline.** Membership is voluntary-by-default: no duty exists to contribute, attend, review, publish, disclose identity, accept roles, or remain active. Voluntary participation is preserved even when a member holds optional roles, subject only to role timeboxes and handover duties recorded at acceptance.\
4.1.3 **Lawful participation condition.** Participation is conditioned on compliance with applicable law, including sanctions regimes, export controls, and local legal constraints. Where law conflicts with platform rules, the default posture is abstention from the conflicting activity and escalation via recorded dispute lanes.\
4.1.4 **Safety and integrity condition.** Access and participation are conditioned on adherence to handling requirements, conduct standards, anti-abuse controls, anti-harassment rules, and publication safety gates. Safety holds may override access and publication entitlements.\
4.1.5 **Non-executing perimeter condition.** Membership may not be used to imply operational command, enforcement authority, regulatory delegation, procurement steering, vendor endorsement, or deal-room activity. Any attempt to operationalize the Guild ecosystem beyond the non-executing perimeter constitutes a perimeter breach.\
4.1.6 **Member states overview.** Membership state is recorded and may include: **Observer, Active, Limited, Restricted, Suspended, Removed, Alumni, Read-Only**. Each state has a defined entitlement posture, access constraints, and visibility rules, and must be changeable only by Record-Valid act with notice and reason codes.\
4.1.7 **Member-in-Good-Standing gate.** “Member-in-Good-Standing” (MGS) is defined by record as a compliance and integrity posture (handling compliance, conduct posture, non-misrepresentation, and required attestations) and is not purchasable. Payment tiers may enable add-on services but may not override integrity gates, role eligibility, or safety vetoes.\
4.1.8 **Accessibility-by-design baseline.** Membership must be operable in low-bandwidth and multilingual contexts with inclusive formats, asynchronous participation options, and accessible artifact standards; accessibility accommodations are treated as a core platform requirement, not a courtesy.

***

#### 4.2 Join Pathways and Onboarding Flow

4.2.1 **Join channels.** Joining may occur through: (i) platform self-enrollment; (ii) invitation pathways for specific optional roles or controlled lanes; and (iii) scholarship onboarding where applicable. All join channels converge into the same baseline rights and obligations; invitations do not create authority.\
4.2.2 **Onboarding steps.** The canonical onboarding flow is: **account creation → mandatory attestations → handling orientation → PoC0 completion → Home Lab election (if required) → baseline access activation**. Each step is recorded, time-stamped, and version-pinned.\
4.2.3 **Home Lab election and switching rules.** Members elect a Home Lab as a routing anchor. Switching is permitted by record with effective dates and may be subject to cooldowns to prevent manipulation of review pools, governance eligibility, and seat completion logic.\
4.2.4 **Optional roaming enablement.** Members may subscribe to additional Lab workspaces, notifications, and watch lists. Roaming does not confer authority; controlled/restricted participation remains PoC- and handling-gated.\
4.2.5 **Onboarding disclosures.** Every member must acknowledge binding disclosures: non-agency, non-employment, non-endorsement, strict non-executing perimeter, handling obligations, competition/procurement neutrality, and reliance bounds for outputs.\
4.2.6 **Platform terms acknowledgement.** Acceptance of platform terms and security/handling rules must be Record-Valid, version-pinned, and subject to supersession notice. Off-platform “terms by email” are non-authoritative.\
4.2.7 **Initial access defaults.** New members start at least privilege: public-safe artifacts, open learning resources, and open issue queues where applicable. Controlled lanes remain inaccessible until competence and handling thresholds are met.\
4.2.8 **Progressive activation.** Elevated privileges activate progressively through PoC and ILA gates, and where necessary through verified identity steps. Progression is earned by recorded work and compliance, not by payment or status.\
4.2.9 **Youth/vulnerable person onboarding (if permitted).** If youth or vulnerable persons are permitted in defined contexts, onboarding requires heightened safeguards, restricted default visibility, guardian consent where required, and strict content boundaries; where safeguards cannot be satisfied, participation is prohibited.\
4.2.10 **Off-platform onboarding prohibition.** There is no “informal membership.” Only the platform record confers membership state, privileges, role markers, and standing; claims of membership absent record are treated as misrepresentation.

***

#### 4.3 Identity Options and Participation Modes

4.3.1 **Identity model overview.** The system supports three participation modes: **pseudonymous**, **semi-verified**, and **verified**. The choice is a safety and privacy control, not a status symbol.\
4.3.2 **Pseudonymous participation default.** Pseudonymous participation is permitted by default. Role markers indicate authority scope; they do not reveal identity. Public rosters are avoided unless explicitly elected and recorded under attribution rules.\
4.3.3 **Verified identity optionality.** Verified identity is optional unless required by lawful obligations, safety posture, controlled-room access rules, anti-fraud controls, or defined stewardship roles where identity assurance is necessary to protect integrity.\
4.3.4 **Identity requirement triggers.** Identity verification may be required for: (i) restricted handling lanes; (ii) safety reviewer or identity-cell roles; (iii) sanction/export-control screening where applicable; (iv) incident integrity investigations; and (v) any role that can materially affect access control or publication safety.\
4.3.5 **Separation of identity and contribution record.** Identity data is minimized and segregated. Contributions remain attributable to role markers and pseudonymous identifiers by default; identity linkage is limited to need-to-know cases and must be access-logged.\
4.3.6 **Public attribution controls.** Named attribution is opt-in, scoped, and expiry-bound. Attribution elections must specify: scope (artifact/event), handling class, duration, withdrawal rights, and misquote response pathway.\
4.3.7 **Anti-doxxing and retaliation protections.** Default non-attribution is a safety posture. The platform must provide safe contact routing, restrict harvesting of member metadata, and support protected participation pathways for high-risk members.\
4.3.8 **Identity assurance levels.** Where identity is verified, assurance levels may be expressed as DID/VC tiers with defined evidence standards, renewal clocks, and revocation pathways; identity assurance does not imply competence or authority beyond recorded role markers.\
4.3.9 **Cross-jurisdiction identity constraints.** Identity workflows must respect local law, export controls, and sensitive jurisdiction constraints. Where identity verification creates safety risk, protected participation options must be prioritized unless lawful obligations require otherwise.\
4.3.10 **Identity dispute and correction lane.** Impersonation, mislinking, credential compromise, and identity disputes must be handled through a recorded correction lane with containment measures, role resets, audit trails, and where permissible member notice.

***

#### 4.4 Identity Minimization Cell and Unmasking Controls

4.4.1 **Limited identity cell purpose and scope.** A small identity minimization cell exists solely to: (i) administer identity assurance where required; (ii) investigate fraud, harassment, leaks, or sanctions triggers; and (iii) support lawful unmasking when necessary. It may not be used for publicity, influence, or governance capture.\
4.4.2 **Two-person rule and access logging.** Any access to identity mapping requires a two-person rule and is access-logged with reason codes. Single-person access is prohibited except in narrowly defined emergency containment scenarios recorded and reviewed post hoc.\
4.4.3 **Unmasking criteria.** Unmasking is permitted only when lawfully necessary for: safety incidents, credible fraud, sanctions/export-control enforcement, harassment/doxxing threats, severe handling breaches, or integrity investigations where pseudonymous resolution is insufficient.\
4.4.4 **Unmasking workflow.** The workflow is: **request → justification → conflict screening → approval → record entry → limited disclosure → expiry → minimization**. Unmasking is time-boxed and limited to the minimum necessary recipients.\
4.4.5 **Unmasking notices and exceptions.** Notice to the affected member is provided when permissible and safe. Notice may be withheld where it would compromise safety, lawful investigations, or protected participation; withholding requires recorded reason codes.\
4.4.6 **Identity store separation.** Identity mappings are technically segregated, encrypted, and protected with strong key custody controls. Identity store access is independent from content access to reduce insider risk and correlation attacks.\
4.4.7 **Identity cell eligibility.** Identity cell roles require heightened PoC thresholds, COI screening, term limits, rotation, and enhanced handling training. Members of the identity cell are prohibited from using identity access for influence, recruiting, or reputation building.\
4.4.8 **Identity breach response.** Identity breaches trigger immediate containment, credential resets, role-marker freezes where necessary, forensic record creation, and mandatory after-action reporting under controlled handling.\
4.4.9 **Retention and deletion.** Identity data is minimized and retained only as long as necessary for the lawful and integrity purposes of membership. Where deletion is constrained by record integrity, de-identification and access restriction are used.\
4.4.10 **No informal identity sharing.** Off-platform rosters, ad hoc identity mapping, informal “who is who” lists, and identity trading are prohibited; violations constitute severe handling and integrity breaches.

***

#### 4.5 Member Attestations and Baseline Commitments (Binding)

4.5.1 **Handling and distribution compliance.** Members attest to comply with handling elections, distribution constraints, watermarking and “no-forward” rules where applicable, and to respect controlled/restricted lane requirements.\
4.5.2 **Non-misrepresentation.** Members attest they will not claim to represent a “GCRI node,” “chapter,” “office,” “official delegation,” or authority absent record-valid activation; they will not imply endorsement or certification by GCRI.\
4.5.3 **Non-executing perimeter.** Members attest that membership will not be used for dispatch, command, enforcement, regulatory determinations, procurement steering, or deal-room activity.\
4.5.4 **Neutrality and political safety.** Members attest to non-partisan conduct within the ecosystem, election-safe communications, and disciplined attribution; political mobilization using the platform is prohibited.\
4.5.5 **Competition/antitrust and procurement neutrality.** Members attest to competition hygiene and procurement neutrality: no collusive coordination, bid steering, vendor favoritism, or procurement influence through Guild activities.\
4.5.6 **COI disclosure baseline.** Members attest to disclose conflicts where required, especially for reviewer, steward, program committee, or safety gate roles; recusals are mandatory where conflicts are material.\
4.5.7 **IP and contribution rights.** Members attest they have the right to grant the required inbound license for contributions they submit and will not submit materials that violate third-party rights or contaminate restricted material into open releases.\
4.5.8 **Security and account hygiene.** Members attest to maintain account security (MFA where provided), protect credentials, use secure devices to access controlled lanes, and report suspected compromise promptly.\
4.5.9 **Protected participation and anti-retaliation.** Members attest to support protected participation norms, refrain from retaliation, and respect reporting channels and confidentiality constraints.\
4.5.10 **Jurisdiction activation compliance.** Members attest they will not convene, brand, or represent local presence absent jurisdiction activation and mandate evidence; this includes branded events, local programs, and CERT mobilizations.\
4.5.11 **Attestation updates and renewals.** Attestations may be renewed on a defined cadence or when safeguard-critical terms change. Refusal to renew may result in access limitation or state change by record, with due process rights.

***

#### 4.6 Access Model and Least-Privilege Architecture

4.6.1 **Default access tiers.** Access is segmented into **Public-Safe**, **Controlled**, and **Restricted** lanes. Public-safe is the baseline; controlled and restricted require competence and handling thresholds.\
4.6.2 **Role-marker based access.** Access is conferred through scoped, time-boxed role markers recorded on the platform; role markers are revocable and non-transferable.\
4.6.3 **PoC-gated privileges.** Publishing rights, review authority, safety reviewer authority, and controlled-room entry require PoC thresholds appropriate to lane sensitivity and safety posture.\
4.6.4 **ILA-gated access.** Certain lanes require completion of learning modules (ILAs) to reduce accidental harm and improve handling compliance; training is a prerequisite, not a guarantee of access.\
4.6.5 **Handling-class workspace separation.** Workspaces are segmented by handling class with distinct controls, watermarking defaults where needed, and restricted export/copy policies consistent with lane risk.\
4.6.6 **Distribution logs.** Controlled/restricted artifacts and convenings require distribution logs, expiry controls, and revocation tracking; distribution logging is a validity requirement for those lanes.\
4.6.7 **No-forward and copy controls.** “No-forward” rules apply by policy and may be reinforced by tooling. Attempts to bypass controls are treated as handling breaches.\
4.6.8 **Access request workflow.** Access requests require justification, approvals appropriate to lane risk, audit trail recording, and expiry dates; blanket access is discouraged by design.\
4.6.9 **Access revocation workflow.** Revocation may be triggered by incidents, handling breaches, misrepresentation, safety holds, or lawful compliance needs. Emergency holds may apply with mandatory expiry and post-hoc review.\
4.6.10 **Access portability rules.** Portability across Labs preserves least privilege and never causes handling regression; a member’s standing may be portable, but lane access must still satisfy local PoC and safety gates.

***

#### 4.7 Eligibility Exclusions and Safety-Based Denial Criteria

4.7.1 **Sanctions/export control exclusions.** Participation may be denied or limited to comply with sanctions and export controls; denial must be recorded with lawful basis references at an appropriate handling level.\
4.7.2 **Harassment/threats/doxxing/coercion.** Credible harassment, threats, doxxing, coercion, or stalking triggers restriction or removal pathways consistent with due process and safety-first protections.\
4.7.3 **Misrepresentation and impersonation.** Impersonation and false authority claims are grounds for denial, restriction, or removal; urgent takedown and clarification actions may be taken where harm risk is high.\
4.7.4 **Repeated handling violations/leak indicators.** Repeated handling breaches, leak indicators, or unsafe dissemination patterns trigger access reduction and potential suspension pending investigation.\
4.7.5 **Dual-use abuse and weaponized disinformation.** Use of the ecosystem to enable harm, targeting, manipulation, or weaponized disinformation triggers denial or removal pathways with appropriate incident handling.\
4.7.6 **Fraud/sybil/gaming.** Fraud, sybil behavior, and gaming of credits or review systems are grounds for denial, clawbacks, restriction, and removal.\
4.7.7 **Role-specific COI refusals.** A member may be refused a specific role due to conflict of interest without being removed from membership; refusals must be recorded with reason codes.\
4.7.8 **Reason codes and evidence standards.** Denial actions must meet minimum evidence standards, use documented reason codes, and be recorded with handling appropriate to sensitivity and protected participation.\
4.7.9 **Due process and appeal lane.** All denials and exclusions must link to the dispute and appeal lane, including time windows, evidence access rules, and correction procedures.\
4.7.10 **Re-entry and rehabilitation.** Where appropriate and safe, re-entry conditions may be defined by record: training, time-based cooling-off, role restrictions, monitoring, and probationary states.

***

#### 4.8 Accessibility, Inclusion, and Safe Participation Patterns

4.8.1 **Accessibility accommodations.** Reasonable accommodations for disability, language, time zones, and low-bandwidth access must be available, including asynchronous review patterns and accessible artifact formats.\
4.8.2 **Multilingual support and translation integrity.** Multilingual participation is supported; translation must preserve meaning, uncertainty, and limitations. Controlled/restricted content must not be translated into unsafe channels.\
4.8.3 **Low-resource participation design.** Participation pathways must support offline-friendly artifacts, low-compute workflows, and asynchronous contribution lanes; elite hardware is not a membership prerequisite.\
4.8.4 **Safeguarding and moderation.** Anti-harassment, anti-discrimination, and moderation rules are enforced with protected reporting and graduated interventions.\
4.8.5 **High-risk participant safety.** Journalists, whistleblowers, public officials, and others at elevated personal risk must have protected participation options and default non-attribution.\
4.8.6 **Protected participation mechanisms.** Anonymous reporting, role-marker attribution, minimal public rosters, and safe contact routing are supported as safety primitives.\
4.8.7 **Anti-discrimination baseline.** Discrimination on protected attributes is prohibited. Enforcement prioritizes victim safety and protected participation.\
4.8.8 **Public sector official constraints.** Participation must respect gift rules, ethics constraints, and attribution safety; membership must never be used to imply official endorsement.\
4.8.9 **Critical infrastructure operator constraints.** Targeting-cue safety and disclosure routing apply; operator participation must not create facility vulnerability disclosures or operational instructions.\
4.8.10 **Youth/vulnerable persons safeguards.** Where permitted, additional constraints apply, including prohibition of certain interactions, enhanced privacy defaults, and restricted visibility.

***

#### 4.9 Jurisdictional Constraints and Cross-Border Compliance

4.9.1 **Local law compliance baseline.** Members must comply with local laws on privacy, security, speech, IP, labor, and public safety; where compliance cannot be satisfied, the member must abstain from the activity and may remain in other lawful lanes.\
4.9.2 **Sensitive jurisdiction limitations.** Access may be limited based on risk where sensitive jurisdictions create safety, lawful, or export-control complications; limitations must be recorded with appropriate handling.\
4.9.3 **Export controls and controlled technologies.** Controlled technical detail may be restricted and routed through controlled lanes; publication of restricted technical detail is prohibited where it creates export-control or harm risk.\
4.9.4 **Sanctions screening posture.** Where screening is required, access denial mechanics must be lawful, minimal, and recorded with reason codes, with appeals where permissible.\
4.9.5 **Cross-border data movement constraints.** The default posture avoids unnecessary cross-border data movement; compute-to-data patterns and sovereign data zone constraints are used to preserve sovereignty and lawful basis.\
4.9.6 **Government participation constraints.** Mandate safety, attribution controls, and conflict handling apply; participation does not imply government endorsement or confer any official authority.\
4.9.7 **Jurisdiction activation gate.** Local operations, branded convenings, and mirror instances are prohibited absent activation and mandate evidence; this gate is enforceable through misrepresentation and access control mechanisms.\
4.9.8 **Cross-jurisdiction dispute venue.** Membership disputes follow the venue and escalation lane specified in the front matter; venue selection does not alter local law compliance obligations.\
4.9.9 **Recordkeeping and audit invariants.** Minimal recordkeeping and audit invariants apply across jurisdictions: record-validity, reason codes for restrictions, and correction/supersession discipline.\
4.9.10 **Local law conflicts with platform rules.** Where local law conflicts with platform rules, the default posture is abstention and escalation; no member may use “local necessity” to bypass safety or handling minima.

***

#### 4.10 Data Protection Baseline and Privacy Engineering

4.10.1 **No PII by default.** The system is designed to operate without PII by default through minimization, pseudonym support, and separation of identity from contribution records.\
4.10.2 **Data classification alignment.** Data classification aligns to handling classes: Public-Safe, Controlled, Restricted, with required controls, access constraints, and distribution rules per class.\
4.10.3 **Consent and lawful basis tracking.** Where personal data is processed, lawful basis and consent (where applicable) must be tracked in records appropriate to sensitivity and minimization requirements.\
4.10.4 **Retention and minimization logic.** Data is retained only for stated purposes and for the minimum time required, with purpose limitation enforced through technical and governance controls.\
4.10.5 **Deletion and de-identification.** Deletion requests are honored where possible. Where record integrity prevents deletion, de-identification, restricted access, and minimization alternatives are used.\
4.10.6 **Security controls.** Access logs, encryption, key management, least privilege, and incident response are mandatory; governance-critical logs are integrity-protected and tamper-evident.\
4.10.7 **Third-party processors posture.** Where third parties process data, contractual safeguards must enforce minimization, isolation, security, incident notification clocks, audit rights where appropriate, and portability/exit.\
4.10.8 **Privacy incident response.** Privacy incidents trigger triage, containment, notification where required, forensic record creation, and correction/supersession entries for affected artifacts or trust surfaces.\
4.10.9 **Data subject rights handling.** Requests for access, correction, deletion, and restriction are handled within defined timelines and constraints, balancing legal requirements with record integrity obligations.\
4.10.10 **Cross-border privacy posture.** Sovereign data zones, compute-to-data, and federated access are used to minimize cross-border risk while preserving interoperability and auditability.

***

#### 4.11 Member Privacy Controls and Visibility Settings

4.11.1 **Attribution settings.** Members choose attribution settings: none, role-marker, or named; any named attribution is scoped and expiry-bound by record.\
4.11.2 **Presence controls.** Members control directory visibility, search visibility, and event listing visibility, subject to safety overrides and role-based requirements where lawful/necessary.\
4.11.3 **Contact and messaging controls.** Safe contact routing, anti-spam controls, and harassment protections apply; members may restrict contact channels while maintaining participation.\
4.11.4 **Artifact association controls.** Artifacts may link to role markers by default; linking to named identity is opt-in and constrained by handling class and safety posture.\
4.11.5 **Safety overrides.** Where doxxing risk, harassment, or lawful necessity exists, privacy settings may be overridden by recorded safety actions with expiry and appeal lanes.\
4.11.6 **Transparency vs safety balancing.** Transparency is satisfied through record-validity, role markers, and artifact provenance; identity exposure is minimized unless necessary.\
4.11.7 **Audit of privacy setting changes.** Changes to privacy settings are recorded to provide integrity against coercion, impersonation, and stealth manipulation; audit access is limited and logged.\
4.11.8 **Privacy complaints lane.** Members may submit privacy complaints through protected channels; complaints are triaged with clocks and remedies consistent with protected participation.\
4.11.9 **Portability when switching Home Lab.** Privacy settings remain portable across Home Lab switching unless the member elects changes or role requirements impose additional constraints.\
4.11.10 **Defaults by handling class and role.** Default privacy settings are conservative, especially for controlled/restricted lanes and high-risk roles; any increase in public visibility requires explicit opt-in by record.

***

#### 4.12 Reputation Without Doxxing (Trust Surfaces)

4.12.1 **Role markers and scoped badges.** Trust is expressed through role markers and scoped, expiry-bound badges that are revocable by record; badges must never use “certified/approved” language.\
4.12.2 **Contribution footprints without identity exposure.** CRS footprints may be displayed under pseudonyms or role markers; identity exposure is optional and controlled by attribution settings.\
4.12.3 **Review credits and rotation signals.** Eligibility for reviewer rotation pools may be displayed as a capability signal without employer prominence or identity exposure; separation-of-duties remains enforced.\
4.12.4 **Quality ladders and maturity indicators.** Evidence maturity indicators signal readiness states (draft/reviewed/safety-screened/released/superseded) without implying certification or compliance determination.\
4.12.5 **Public-safe member registry displays.** Public displays are limited to safe fields and must include limitations and reliance bounds; controlled identity information is never published by default.\
4.12.6 **Anti-hype constraints.** iVRS and public trust surfaces are not marketing. Overstatement, omission of limitations, and performance inflation are integrity breaches.\
4.12.7 **Anti-impersonation protections.** Impersonation detection, dispute lanes, and takedown pathways are maintained; confirmed impersonation triggers immediate restriction and correction records.\
4.12.8 **Correction status as trust signal.** Supersession and correction status are surfaced to users; use of superseded artifacts without acknowledging status is treated as misuse.\
4.12.9 **Neutrality disclosures.** Sponsor influence indicators and neutrality disclosures may be surfaced in public-safe form to preserve trust under scrutiny without exposing sensitive details.\
4.12.10 **Removal/expiry effects.** Removal, suspension, or badge expiry triggers automatic de-listing or status change on trust surfaces by record; historical artifacts retain correction and provenance metadata.

***

#### 4.13 Onboarding Standard and Competence Readiness Gates

4.13.1 **PoC0 mandatory orientation.** PoC0 is mandatory before any contribution beyond observation; it covers handling basics, perimeter, neutrality, safe publication, and reliance bounds.\
4.13.2 **Baseline handling training.** Public-safe handling training is required for baseline participation; controlled/restricted lane training is mandatory before access is granted.\
4.13.3 **Controlled lane readiness path.** Controlled lane readiness requires specified PoC thresholds and ILA modules, including distribution log discipline, redaction/abstraction basics, and incident disclosure routing.\
4.13.4 **Restricted lane readiness path.** Restricted readiness requires advanced PoC, enhanced handling competencies, and may require verified identity and role-specific COI screening where lawful/necessary.\
4.13.5 **Role readiness ladders.** Reviewer, steward, program committee, and safety reviewer roles require defined readiness ladders, separation-of-duties constraints, and time-boxed role markers.\
4.13.6 **Renewal clocks.** PoC refresh, handling refresh, and account hygiene refresh occur on defined cycles; expiry may reduce access until refreshed, without compelling participation.\
4.13.7 **Role transitions.** Transitions between roles require recorded handovers, revocation of prior privileges where necessary, and confirmation of updated scope and handling requirements.\
4.13.8 **Convenings and clinics onboarding.** Convening participation may require safe-meeting orientation, recording/photography rules acknowledgement, and handling election for the room.\
4.13.9 **Cells and CERT onboarding.** Joining Cells or CERTs requires acceptance of formation records, scope/timebox, dissolution-by-default, deliverable integrity rules, and disclosure routing constraints.\
4.13.10 **Training non-entitlement disclaimer.** Completion of training does not guarantee access, roles, publication approval, or service levels; safety gates and integrity holds may still deny progression.

***

#### 4.14 Notices, Records, and Non-Silent Change Discipline (Part 4 Linkage)

4.14.1 **Authoritative notices.** Notices affecting membership, identity, privacy, or access are authoritative only when issued by platform record; email or chat summaries are non-authoritative unless linked to the record.\
4.14.2 **Version pinning.** Member acceptance is pinned to a governing version; supersession records define effective dates and transition rules, including safety-critical immediate changes where necessary.\
4.14.3 **Change notifications and review windows.** Changes to identity/privacy/access rules require member-facing summaries, a review window where feasible, and a contestation lane; emergency changes must still be recorded with expiry and post-hoc review.\
4.14.4 **Emergency holds impacting access.** Emergency holds are permitted for safety and integrity incidents; they must be time-boxed, recorded with reason codes, and reviewed with an appeal pathway.\
4.14.5 **Critical change acknowledgement.** Where safeguard-critical changes occur, member re-attestation or acknowledgement may be required to maintain MGS or controlled lane access; refusal effects must be recorded and proportionate.\
4.14.6 **Retention and audit of access decisions.** Access grant/denial/revocation decisions are retained with audit trails and reason codes consistent with minimization and protected participation.\
4.14.7 **Member-facing summaries vs controlled details.** Member-facing summaries must be public-safe and limitation-forward; sensitive identity or incident details remain controlled with distribution logs.\
4.14.8 **Dispute linkage.** Disputes on access, identity, privacy settings, or onboarding decisions route to the due process and remedy lanes with defined clocks and evidence access rules.\
4.14.9 **Survival of obligations.** Handling, confidentiality, non-misrepresentation, and record-integrity obligations survive state changes and exit where required by the instrument and platform rules.\
4.14.10 **Integrity of logs and evidence.** Tampering with logs, bypassing access controls, or manipulating records is treated as a severe integrity breach subject to immediate containment holds, clawbacks, and sanctions by record.


---

# 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/iv.-architecture.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.