# X. Accounts

### Part 10 — Integrated Learning Accounts (ILAs)

*(Competence Infrastructure for Membership; Voluntary-by-Default; No Silent Edits)*

#### 10.1 Purpose, Scope, and Non-Executing Boundary

10.1.1 **ILAs as competence infrastructure.** Integrated Learning Accounts (ILAs) are the membership-layer competence infrastructure that enables safe participation at scale in evidence-grade work. ILAs record learning progress and competence evidence to support role-marker issuance, access gating, and reviewer rotation pools; ILAs are not licensure, not employment qualification, and not professional authorization.\
10.1.2 **What ILAs do and do not do.** ILAs provide competence indicators and recorded evidence of learning and performance tasks; ILAs do not certify regulatory compliance, do not authorize operational action, do not confer professional credentials outside the platform, and do not create any agency, fiduciary, or duty-of-care relationship.\
10.1.3 **Voluntary participation baseline.** Enrollment in ILAs is optional. Members have no obligation to enroll, complete tracks, disclose identity, or pursue any competence ladder. Non-participation in ILAs may limit eligibility for certain optional privileges, but never removes baseline membership.\
10.1.4 **Relationship to PoC, CRS, iVRS, badges, roles, and access lanes.** ILAs interoperate with Proof of Competence (PoC) ladders, Contribution Recognition System (CRS) footprints, Integrated Value Reporting System (iVRS) indicators, scoped badges, role markers, and least-privilege access lanes. ILAs are the member-facing competence record; PoC is the privilege gate; CRS records contributions; iVRS reports aggregate system health; badges and role markers are expiry-bound trust surfaces.\
10.1.5 **Reliance bounds for ILA outputs.** ILA outputs are competence indicators only. Any display or export must include limitations, expiry/renewal status, correction pathway, and explicit non-equivalence to licensure, certification, audit opinion, or regulatory acceptance.

***

#### 10.2 ILA Architecture and Components (What an ILA Contains)

10.2.1 **ILA record structure.** Each ILA contains a record-valid profile (identity mode selection), enrolled tracks, evidence objects, assessment outcomes, renewal clocks, access permissions, and change history. The platform record is the authoritative ILA source; off-platform copies have no standing.\
10.2.2 **Track catalog.** ILAs include (i) core tracks required for elevated privileges, (ii) domain tracks mapped to Labs/Guilds, and (iii) integrity tracks for handling, neutrality, COI, and protected participation. Track definitions are versioned and governed by record.\
10.2.3 **Evidence objects.** Evidence objects include assessments, practical tasks, authored artifacts, peer reviews, drill participation logs, attestations, and instructor/mentor sign-offs where permitted. Evidence objects are content-addressed, versioned, and handling-classed.\
10.2.4 **Competence assertions vs competence evidence.** The platform separates self-asserted claims (statements) from competence evidence (recorded proof). Assertions never substitute for evidence. Privileges may only be granted based on evidence objects, not assertions.\
10.2.5 **Handling class inheritance.** Every ILA component inherits or is assigned a handling class. Public-facing views must default to minimized summaries; controlled/restricted evidence remains subject to distribution logs and “no-forward” rules where designated.\
10.2.6 **Identity-minimized ILA mode.** ILAs support role-marker and pseudonymous modes by default. Verified identity linkage is optional except where required for restricted roles, abuse prevention, or lawful constraints. Identity is not competence; competence is not identity.\
10.2.7 **Interoperability fields.** ILAs include portable metadata fields that support roaming and eligibility checks (track IDs, completion states, expiry dates, PoC level indicators) without leaking sensitive detail, restricted content, or personal data by default.

***

#### 10.3 ILA Enrollment, Consent, and Privacy Controls

10.3.1 **Opt-in enrollment by platform record.** Enrollment requires affirmative consent recorded on-platform. Consent includes acknowledgement of reliance bounds, privacy posture, handling inheritance, and non-equivalence disclaimers.\
10.3.2 **Pseudonymous enrollment options.** Members may enroll using pseudonyms and role markers where lawful. Default settings minimize public exposure of learning status and restrict third-party visibility.\
10.3.3 **Verified identity triggers.** Verified identity may be required for (i) restricted-room roles, (ii) integrity-critical functions (e.g., safety reviewer), (iii) fraud prevention or sybil resistance, or (iv) lawful obligations. Such requirements are reason-coded and recorded with expiry and minimization.\
10.3.4 **Consent granularity.** Members control what ILA elements are visible to whom. Default is least disclosure: public-safe summaries only, with controlled evidence limited to need-to-know roles and logged access.\
10.3.5 **Data minimization and retention.** ILAs operate on “no PII by default” posture. Retention is limited to what is necessary for integrity, auditability, and privilege gating. Sensitive items are minimized, de-identified where feasible, and protected by access controls.\
10.3.6 **Export/delete requests within integrity limits.** Members may request exports, deletion, or de-identification subject to record-integrity constraints and lawful retention requirements. Where deletion is not feasible, access restriction and de-identification pathways apply, recorded with reason codes.\
10.3.7 **Youth and vulnerable-person safeguards.** If youth/vulnerable participation is permitted, enrollment requires enhanced safeguards, consent mechanisms, content constraints, and strict visibility defaults; otherwise such enrollment is prohibited.

***

#### 10.4 ILA Tracks and Competence Domains (What Members Can Learn)

10.4.1 **Core integrity track.** Covers handling discipline, neutrality, political safety, competition/procurement hygiene, COI literacy, protected participation, and reporting channels; this track underpins eligibility for any elevated roles.\
10.4.2 **Evidence methods track.** Covers reproducibility, provenance, documentation hygiene, method cards, dataset cards, evaluation discipline, and uncertainty disclosure.\
10.4.3 **Verification track.** Covers replayability validation, replication runs, validation protocols, reviewer discipline, and adversarial review methods consistent with safety constraints.\
10.4.4 **Publication track.** Covers safe summaries, dual-use screening basics, staged release patterns, dissent preservation formats, and corrections/supersession discipline.\
10.4.5 **Data governance track.** Covers sovereign data zones, compute-to-data, lawful basis patterns, minimization, retention logic, and cross-border constraints.\
10.4.6 **Systems risk track.** Covers coupling, cascade analysis, scenario framing, correlated loss reasoning, confidence/limits communication, and measurement safety.\
10.4.7 **Domain tracks mapped to Guilds.** Domain tracks are defined by Guilds/Labs (e.g., Energy, Water, Cyber/Outage, Health) and include domain-specific constraints, safety gates, and artifact types; these tracks never relax global safeguards.\
10.4.8 **Executive track.** Covers evidence-room conduct, dissent protocols, drill participation hygiene, MNPI and market sensitivity constraints, crisis communications integrity, and attribution discipline.\
10.4.9 **Stewardship track.** Covers stop-the-line mechanics, incident triage, sanctions ladder literacy, appeals discipline, record-validity rules, and identity minimization cell constraints.\
10.4.10 **Trainer/mentor track.** Covers teaching competence, safeguarding, non-coercion, assessment integrity, accessibility accommodations, and neutrality (no stealth marketing).

***

#### 10.5 Assessment and Evidence Standards (How Competence Is Demonstrated)

10.5.1 **Evidence-first assessment philosophy.** Competence is demonstrated through performance and traceable outputs, not by résumé, institution, or credentials. Assessments prioritize reproducible work and integrity behaviors.\
10.5.2 **Assessment types.** Assessments may include knowledge checks, practical tasks, artifact review exercises, replication runs, drill participation, moderation simulations, and safety screening exercises appropriate to the track.\
10.5.3 **Standard rubrics and thresholds.** Rubrics, pass thresholds, and scoring criteria are record-valid, auditable, and versioned. Changes require supersession with diffs and effective dates; no silent threshold shifts are permitted.\
10.5.4 **Anti-cheat and integrity measures.** Integrity measures may include randomized item pools, reviewer rotation, anomaly checks, and optional proctoring for high-sensitivity roles, always with minimization and lawful-basis posture.\
10.5.5 **Third-party evidence acceptance.** External training or credentials may be accepted only as bounded signals and never as automatic privilege grants; where accepted, verification requirements, mapping limits, and expiry rules apply.\
10.5.6 **Accessibility accommodations.** Assessments must support reasonable accommodations (language, disability, bandwidth constraints) without diluting integrity; accommodations are documented in a privacy-preserving manner.\
10.5.7 **Appeals and reassessment.** Members may appeal assessment outcomes through due process lanes; reassessment and remediation pathways exist, with recorded reason codes, reviewer rotation, and protected participation guarantees.

***

#### 10.6 ILA Lifecycle Management (Create → Maintain → Renew → Retire)

10.6.1 **ILA creation by record.** Creation includes baseline state, effective date, identity mode election, initial track enrollment, and consent acknowledgements recorded as a record-valid act.\
10.6.2 **Renewal clocks.** ILAs have renewal clocks driven by time-based expiry and change-based triggers (material policy changes, handling updates, major rubric revisions). Renewal logic is transparent and recorded.\
10.6.3 **Lapse handling.** Lapse triggers privilege downgrades (not membership termination) after grace windows. Reactivation requires re-attestation and, where relevant, refreshed assessments for elevated roles.\
10.6.4 **Track retirement and migration.** Tracks may be deprecated and superseded; migrations must include mapping notes, equivalence limits, and transition deadlines, with no silent edits to historical records.\
10.6.5 **Member exit effects.** On exit, ILA records are minimized and access-limited, subject to integrity retention and lawful constraints; survival obligations apply for controlled evidence previously accessed.\
10.6.6 **Incident-triggered refresh.** After material incidents (handling breach, integrity breach, safety incident), affected roles/tracks may require mandatory refresh or temporary holds, reason-coded and time-boxed.

***

#### 10.7 Governance of ILAs (Who Sets Rules; How Changes Occur)

10.7.1 **Authority and precedence.** ILA governance follows instrument precedence: this Constitution and higher-order safeguards control, followed by platform terms and handling code; stricter rules govern.\
10.7.2 **Rulemaking bodies.** The Stewardship Committee governs system invariants (integrity, handling, no silent edits, neutrality). Domain Councils govern domain track content within invariants. Trustees intervene where systemic risk, legal risk, or capture risk arises.\
10.7.3 **Schema change control.** ILA schemas are governance-critical. Schema changes require recorded proposals, migration plans, contestation windows where designated, and rollback plans for integrity issues.\
10.7.4 **No silent edits rule.** No ILA records, rubrics, thresholds, or track definitions may be silently edited. Updates occur only through supersession with diffs, effective dates, and correction notes.\
10.7.5 **Transparency minima.** Members receive public-safe notices for material changes (new requirements, renewal clocks, visibility settings defaults). Sensitive implementation details remain controlled where necessary for security.\
10.7.6 **Independent review triggers.** Independent review is triggered by signals of capture, systematic bias, repeated failures, or disputes exceeding thresholds; findings are recorded with public-safe summaries.

***

#### 10.8 Portability, Recognition, and Boundary Rules (Interoperability Without Leakage)

10.8.1 **Portability purpose.** Portability supports roaming and cross-Guild eligibility while preserving handling and privacy. ILAs enable members to demonstrate competence without exposing sensitive evidence by default.\
10.8.2 **Equivalent-or-stronger handling rule.** Any export or portability must maintain equivalent-or-stronger handling; no downgrade of protected materials is permitted through export.\
10.8.3 **External recognition restrictions.** ILAs are not licensure and not compliance certification; external parties may not represent ILAs as regulatory acceptance, professional certification, or authorization.\
10.8.4 **Mapping to external frameworks.** Informative mappings to external frameworks may be published as non-binding references; they must include non-equivalence disclaimers and reliance bounds.\
10.8.5 **Cross-entity portability boundaries.** ILA portability is limited to membership-layer purposes and does not convey execution-stack authority or privileges in any for-profit/regulated delivery stack.\
10.8.6 **Revocation propagation.** Revocations and invalidations propagate by record to all dependent trust surfaces (role markers, badges, restricted-room eligibility).\
10.8.7 **Sensitive jurisdiction restrictions.** Export controls, sanctions, and national security constraints may limit portability; denial decisions are reason-coded with due process.

***

#### 10.9 Access and Privilege Coupling (How ILAs Gate Platform Privileges)

10.9.1 **Privilege tiers and prerequisites.** Privileges are tiered (read, contribute, review, publish, steward) with explicit ILA prerequisites and PoC thresholds; absence of prerequisites blocks only the specific privilege, not baseline membership.\
10.9.2 **Controlled/restricted eligibility.** Eligibility for controlled and restricted rooms requires handling competence evidence, distribution log literacy, need-to-know justification, and time-boxed approvals.\
10.9.3 **Role marker issuance requirements.** Role markers reference specific ILA evidence objects and PoC levels; every issuance includes scope, expiry, and revocation triggers recorded by record.\
10.9.4 **Least-privilege elevation.** Elevation is time-boxed and purpose-scoped; privilege creep detection is required; renewals require re-validation where applicable.\
10.9.5 **Downgrades on lapse or misconduct.** Lapse or misconduct triggers automatic downgrades by record; severe breaches may trigger emergency holds subject to after-action review.\
10.9.6 **Safety holds override access.** Stop-the-line holds may suspend privileges regardless of ILA status when imminent harm risk exists; holds are reason-coded, time-boxed, and appealable.

***

#### 10.10 Quality Assurance and Bias Controls (Fairness Under Scrutiny)

10.10.1 **Bias detection and mitigation.** Bias is monitored across language, geography, disability, and resource constraints. Where bias is detected, remediation includes rubric revision, alternate pathways, and accessibility improvements.\
10.10.2 **Reviewer rotation and calibration.** Assessment reviewers are rotated and calibrated to reduce favoritism, capture, and inconsistency; calibration artifacts are recorded and auditable.\
10.10.3 **Multi-helix oversight.** Track content and assessment design are reviewed through multi-helix participation to reduce blind spots and prevent dominance by any single sector.\
10.10.4 **Low-bandwidth and inclusive pathways.** ILAs support asynchronous, offline-friendly, and low-bandwidth pathways with equivalent integrity requirements; accommodations are documented without doxxing.\
10.10.5 **Appeals and remediation.** Complaints and appeals are protected participation events; retaliation is prohibited; remedies include reassessment, rubric clarification, and independent review where triggered.

***

#### 10.11 Security, Handling, and Data Protection for ILAs

10.11.1 **Handling elections for evidence objects.** Each evidence object is handling-classed; defaults are conservative; controlled/restricted evidence requires additional access controls and logs.\
10.11.2 **Distribution logging.** Where controlled evidence is shared, distribution logs are mandatory, including expiry and revocation tracking.\
10.11.3 **Watermarking and leak response.** Sensitive training materials and restricted assessments may be watermarked; leak drills, incident triage, and sanctions pathways apply.\
10.11.4 **Account security requirements.** MFA, secure recovery, anomaly detection, and access logging are required for ILA-related privileges; higher sensitivity roles may require stronger controls.\
10.11.5 **Retention and audit trails.** Retention is minimized but sufficient for integrity and dispute resolution; audit trails record access to controlled ILA components.\
10.11.6 **Incident response for compromise.** Compromise triggers containment, credential resets, access suspension where needed, correction records, and member notifications where lawful/appropriate.

***

#### 10.12 Operational Delivery Model (How ILAs Run at Scale)

10.12.1 **Self-serve vs cohort learning.** ILAs support self-serve modules for baseline tracks and cohort clinics for high-sensitivity roles requiring supervised practice, calibration, or moderated drills.\
10.12.2 **Mentorship and office hours.** Mentorship is opt-in, safeguarded, and non-coercive; mentors operate under handling rules and COI disclosure requirements.\
10.12.3 **Labs and replication environments.** Certain tracks require replication environments and tool access governed by compute policies, rate limits, and anti-abuse constraints.\
10.12.4 **Translation and localization.** Localization must preserve meaning, include version control, and maintain correction parity; translations inherit handling and are subject to safety review where needed.\
10.12.5 **Cadence.** ILAs operate with monthly clinic options and quarterly refresh cycles for critical tracks, aligned to correction and release cycles where applicable.\
10.12.6 **Service availability disclaimers.** Learning availability is not guaranteed; safety holds, platform outages, and lawful constraints may restrict access without liability.

***

#### 10.13 Metrics and Reporting (iVRS Integration for Learning Health)

10.13.1 **Participation metrics.** Track enrollments, completion rates, retention, and time-to-competence are measured in aggregate, privacy-preserving form.\
10.13.2 **Integrity metrics.** Appeals rates, anomaly flags, incident rates, and reviewer calibration drift are tracked and reviewed for system health.\
10.13.3 **Equity metrics.** Accessibility uptake, geographic distribution, language coverage, and scholarship effects are monitored to detect exclusion patterns.\
10.13.4 **Outcome metrics.** Review quality, correction performance, publication hygiene, and safe-handling compliance outcomes are used as downstream competence indicators.\
10.13.5 **Transparency outputs.** Public-safe summaries are published for key indicators; controlled audit packs exist for oversight bodies with access logging and minimization.

***

#### 10.14 Legal Disclaimers and Liability Boundaries (ILA-Specific)

10.14.1 **As-is posture.** ILA materials, assessments, and learning tools are provided “as is,” without warranties, subject to platform terms and lawful limitations.\
10.14.2 **No advice.** ILAs provide competence learning only and do not provide legal, medical, operational, financial, or regulatory advice.\
10.14.3 **No employment relationship.** ILAs create no employment, agency, partnership, joint venture, or fiduciary duty; participation is voluntary and membership-layer only.\
10.14.4 **Non-endorsement and non-equivalence.** ILA completion does not imply endorsement, regulatory acceptance, certification, or compliance determination; any external reference must include disclaimers and expiry status.\
10.14.5 **Limitation of liability.** Liability is limited as permitted by law; reliance bounds govern any use; disputes route through the membership dispute lane and record-valid correction processes.


---

# 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/x.-accounts.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.