# II. Pillars ### 2.1 Architecture Summary 2.1.1 **Nexus Platforms are built as a governed “knowledge-and-standards operating environment,” not a document site.** Every component is designed to convert community activity into **structured objects**, move those objects through **record-valid state machines**, package them into **immutable releases**, and preserve long-term integrity through **handling segregation** and **correctionability**. 2.1.2 **The platform is intentionally “capability-heavy and authority-light.”** Nexus provides primitives (objects, registers, workflows, indices, lanes, gates, logs, templates, automation, challenges), while the community supplies decisions (priorities, nominations, peer review, replication, releases, maintenance) inside enforceable constraints. 2.1.3 **Nexus outcomes depend on five invariants:**\ (1) object model discipline (governed types, mandatory metadata),\ (2) validity-by-record (workflow states confer standing),\ (3) handling-by-design (Public-Safe/Controlled/Restricted segregation),\ (4) correctionability as a trust primitive (no silent edits; supersession discipline), and\ (5) non-executing perimeter (no operational command, no regulated execution, no procurement steering, no implied authority). *** ### 2.2 Pillar A — Standards OS (Governed Object Model) 2.2.1 **Governed objects replace “pages” and “attachments” as the unit of work.** Nexus stores standards work as canonical object types with explicit semantics, required metadata, and lifecycle rules, enabling machine-indexing, safe reuse, and deterministic “what is current” answers across the ecosystem. 2.2.2 **Canonical object types:**\ a. **Standard** — normative specification with machine-readable schema pointers, conformance expectations, and versioned release lineage.\ b. **Framework** — non-normative control/governance structure with applicability guidance, mappings, and adoption notes (explicitly not a standard).\ c. **Profile / Implementation Guide** — sector/jurisdiction/use-case overlays that constrain or extend without forking core semantics; includes rationale and incompatibility notes.\ d. **Artifact** — reusable unit (template, checklist, method card, runbook, dataset card, model card, threat card, control card, assurance note) designed for adoption and replication.\ e. **Conformance Suite** — test vectors, harness notes, negative/adversarial cases, expected outcomes, and reporting requirements for proving conformance.\ f. **Release Bundle** — immutable, versioned package of standards + profiles + artifacts + conformance references + known-issues list; includes “current pointer” updates.\ g. **Correction / Supersession** — structured change record (diff, rationale, impact, migration guidance, timelines) that updates standing without rewriting history.\ h. **Working Group Charter** — scope, exclusions, decision rule, handling default, cadence, expiry/renewal terms, and dispute path as a record-valid object.\ i. **Role Marker** — time-boxed, scoped privileges (reviewer, maintainer, steward, session lead) with duties, recusal triggers, and revocation pathway.\ j. **Call for Work** — structured intake primitive for Quests/Bounties/Builds/Hackathons with acceptance criteria and packaging requirements.\ k. **Public-Good Extract** — safe derivative output: public-safe summary + method card + limitations + optional anonymized/aggregated dataset extract when lawful. 2.2.3 **Mandatory metadata is a first-class interface, not “nice to have.”** For every Standard/Artifact/Release, Nexus requires: scope + exclusions; handling election; reliance bounds (intended use, non-intended use, limitations, uncertainty); expiry/review date; correction/dispute path; provenance + rights attestation; and COI flag with linked disclosure when applicable. 2.2.4 **Immutability discipline is enforced by design, not policy.** Released objects are immutable; changes occur only through corrections/supersessions with diffs and migration notes, ensuring that downstream adopters can audit evolution, reproduce prior states, and safely manage upgrades. 2.2.5 **“Current pointer” is the operational truth surface.** Each Standard and Framework maintains a machine-resolvable “current release” pointer, backed by registers that show lineage (what superseded what, what is contested, what is expired), preventing stale adoption and enabling reliable institutional referencing. *** ### 2.3 Pillar B — Records-First Governance Engine (Validity-by-Record) 2.3.1 **Governance actions are executed as record-valid acts.** Nexus turns every standing-creating action into a structured record that drives a state machine and updates the relevant registers—so legitimacy is deterministic, auditable, and portable across jurisdictions and institutions. 2.3.2 **Record-valid acts (governance substrate):**\ a. Membership onboarding, COI declaration, handling election, and visibility settings.\ b. WG charter creation, renewal, amendment, retirement, and merger/split actions.\ c. Role nomination, acceptance, resignation, term renewal, recusal, and revocation.\ d. Release request and bundle declaration (what objects are included; which versions; which conformance references).\ e. Correction, dispute, appeal, and remedy requests with time-boxed response clocks.\ f. Dataset/artifact submission with rights and minimization attestations and sensitivity flags.\ g. Conformance result submission with environment metadata, vectors used, pass/fail results, known limitations, and signer identity markers (as permitted). 2.3.3 **State machines replace informal process.** Core workflows follow explicit states (submit → triage → review → accept/reject → publish/register → renew/expire → supersede/withdraw), reducing governance drift, preventing “shadow decisions,” and enabling auditability without centralized bureaucracy. 2.3.4 **Publication blockers are systematic “release gates.”** If required fields are missing, if handling obligations are unmet, or if conformance evidence is required and absent, Nexus blocks publication and surfaces actionable remediation steps—so governance quality is enforced at the point where risk becomes externalized. 2.3.5 **Dispute and appeals are treated as operational integrity, not social conflict.** Disputes create structured records with grounds, evidence, requested remedy, and clocks; resolutions must result in published outcomes (errata, supersession, withdrawal, limitation updates) so consumers can adapt quickly and safely. *** ### 2.4 Pillar C — Handling, Safety, and Reliance Controls (Safety-by-Design) 2.4.1 **Handling classes are structural, not labels.** Nexus enforces three handling classes with segregated indices, access gates, retention/expiry requirements, distribution logging (for gated lanes), and staged release obligations to prevent accidental leakage and reduce harm risk. 2.4.2 **Handling classes (operational definitions):**\ a. **Public-Safe** — default publishable content; broad indexing; designed for unrestricted reuse with reliance bounds.\ b. **Controlled** — gated access based on eligibility; distribution logs; expiry required; intended for sensitive but shareable collaboration.\ c. **Restricted** — tightly gated access; distribution logs; staged release mandatory; intended for high-sensitivity domains where detail could enable harm (market-moving, infrastructure targeting, dual-use, regulated contexts). 2.4.3 **Staged release is mandatory when detail increases harm risk.** Nexus requires a public-safe top-line release (summary + method card + limitations) before any controlled/restricted appendices can be distributed, ensuring the ecosystem remains regenerative without exposing sensitive detail. 2.4.4 **Reliance bounds are binding packaging requirements.** Every release must specify intended use, non-intended use, limitations, uncertainty, validity window, dependencies, and correction path—so consumers can assess fitness-for-purpose and avoid unsafe extrapolation. 2.4.5 **“Non-operational framing” is enforced by posture and templates.** Nexus content is structured toward standards, controls, schemas, and testability; requests for operational direction are redirected to governance-safe artifacts, and sensitive domains enforce “pattern-level” guidance rather than tactical instruction. *** ### 2.5 Pillar D — Intelligence Layer (Indexing → Retrieval → Recycling, Non-Authoritative) 2.5.1 **Nexus Intelligence is a transformation and retrieval engine, not a decision engine.** It accelerates expert work by indexing governed objects, enabling handling-aware retrieval, and converting drafts into structured artifacts—while remaining subordinate to record-valid governance for standing and publication. 2.5.2 **Handling-separated knowledge indices are non-negotiable.** The platform maintains distinct indices aligned to handling class (Public-Safe, Controlled, Restricted), ensuring that retrieval and synthesis cannot cross boundaries and that access policy can be enforced without ambiguity. 2.5.3 **Index admission is gated by governance completeness.** Only objects that satisfy required metadata and handling eligibility are admitted into indices; incomplete drafts remain in draft lanes until they can be safely indexed and reused. 2.5.4 **Retrieval is context-aware and permission-aware.** Domain assistants can use page context plus authorized retrieval from the relevant index, enabling expert-grade answers and synthesis without leaking restricted detail or producing blended outputs across handling classes. 2.5.5 **Recycling turns deliberation into reusable infrastructure.** Nexus Intelligence converts working notes and drafts into public-safe summaries, method cards, artifact candidates, mapping tables, metadata normalization, and release-candidate bundles—reducing duplication and making expert work compounding. 2.5.6 **AI-agnostic provider routing is treated as a platform control plane.** The intelligence layer can route workloads (chat, embeddings, media generation, speech) based on handling class, jurisdiction policy, cost envelope, latency, and availability, preserving portability and avoiding vendor lock-in. 2.5.7 **Non-authority guarantees are explicit and enforceable.** Assistants cannot approve, certify, or create standing; generated outputs carry limitations and source footprint references to the underlying governed objects; and only releases issued via record-valid acts are treated as authoritative within Nexus. *** ### 2.6 Pillar E — Community Graph (Guilds, Working Groups, Cells, Clinics) 2.6.1 **Community structure is designed to be self-organizing at scale.** Nexus provides domain homes (Guilds), chartered production units (WGs), verification capacity (review pools), reproducibility capacity (replication cells), and time-boxed working environments (clinics/sessions), enabling IEEE/IETF-like operations with modern automation. 2.6.2 **Guilds are persistent operating environments.** They host backlogs, roadmaps, knowledge libraries, member directories, and domain assistants, allowing experts to continuously ship standards-grade outputs rather than relying on annual cycles. 2.6.3 **Working Groups are legitimate only by charter-as-record.** WGs must define scope/exclusions, decision rule, handling default, and expiry/renewal posture; outputs created outside the WG record-valid pipeline remain drafts without standing. 2.6.4 **Review pools and replication cells are formal capacity systems.** Reviewer eligibility is gated by evidence (verification credits, clean conduct history, role markers); replication cells produce conformance and reproducibility evidence that strengthens releases and reduces ambiguity. 2.6.5 **Clinics/sessions are production accelerators with governance discipline.** They are time-boxed environments that generate draft artifacts; nothing becomes official until it passes through record-valid acts and release gating, preventing “meeting outcomes” from being misconstrued as standards. *** ### 2.7 Pillar F — Credits, Reputation, and Eligibility (Progression Without Gamification Failure) 2.7.1 **Credits are an integrity mechanism, not a social score.** Nexus uses structured credits to recognize contribution, verification, and responsible dissemination while preventing popularity dynamics from driving authority or access. 2.7.2 **Credit classes (portfolio-grade signals):**\ a. **Participation credits** — earned through recorded submissions, attendance, quest completion, and sustained contribution.\ b. **Verification credits** — earned through accepted reviews, replication runs, conformance executions, and correction validations.\ c. **Engagement credits** — earned through translations, explainers, education assets, and community-safe dissemination that expands adoption and literacy. 2.7.3 **Anti-gaming controls are mandatory.** Credits accrue only on accepted record-valid outcomes, are capped and uniqueness-gated, and are revocable via misconduct findings or misrepresentation—ensuring credits represent professional evidence rather than activity volume. 2.7.4 **Eligibility gates create earned access and trusted capacity.** Credits plus role markers unlock reviewer status, controlled/restricted lane eligibility, maintainer nomination, and release management privileges—keeping sensitive lanes safe and ensuring higher privileges are tied to demonstrated integrity work. *** ### 2.8 Pillar G — Challenges Engine (Quests, Bounties, Builds, Hackathons) 2.8.1 **Challenges are structured intake mechanisms that produce governed outputs.** Nexus turns “calls for work” into formal objects with acceptance criteria, required handling, packaging rules, review lanes, and release expectations, enabling sponsor demand to translate into standards-grade deliverables. 2.8.2 **Challenge types (distinct operational purposes):**\ a. **Quests** — guided learning-plus-output missions that generate artifacts and help onboard experts into Nexus object discipline.\ b. **Bounties** — sponsor-defined deliverables with explicit acceptance criteria, review requirements, and release packaging expectations.\ c. **Builds** — multi-week collaborative sprints designed to produce release candidates and conformance evidence, not demos.\ d. **Hackathons** — timeboxed build-test-publish cycles where outputs must pass metadata gates and safety posture to be accepted. 2.8.3 **Common acceptance spine:** scope → handling → reliance bounds → provenance → review → conformance (when applicable) → release bundle → public-good extract (where safe). This makes outcomes comparable across domains and prevents “one-off” work from becoming ecosystem debt. 2.8.4 **Challenge outputs become durable ecosystem assets.** When accepted, outputs enter registers, are indexed, and become reusable building blocks for future releases; when rejected, the record persists with reasons, reducing repetition of failure modes and improving future submissions. *** ### 2.9 Pillar H — Registers and Truth Surfaces (Deterministic “What Is Current?”) 2.9.1 **Registers are the platform’s canonical truth layer.** They provide deterministic visibility into what is current, what is superseded, what is contested, what is expired, and what conformance evidence exists—so experts and institutions can make adoption decisions quickly and defensibly. 2.9.2 **Core registers:** Standards Register; Framework Register; Guild/WG Register; Role Marker Register; Release Register; Correction/Supersession Register; Dispute/Appeal Register; Conformance Register; Public-Good Extract Library; and Expert Directory (competence map). 2.9.3 **Handling-aware presentation is enforced at the register level.** Public registers expose public-safe entries; controlled/restricted registers apply access gates and distribution logging, ensuring that sensitivity controls apply consistently across discovery, retrieval, and export. *** ### 2.10 Pillar I — Portability and Provider-Neutral Operations (Cloud + AI Agnostic by Design) 2.10.1 **Cloud portability is treated as a product property.** Nexus is designed so that objects, registers, workflows, and indices remain portable across providers and regions, supporting multi-region deployment, migration, and partner-specific residency requirements without rewriting the operating model. 2.10.2 **AI-provider neutrality is treated as an architectural control plane.** Workloads (generation, embeddings/indexing, media, speech, moderation) can be routed by policy and swapped over time, enabling resilience, cost governance, jurisdictional compliance, and continuity as providers evolve. 2.10.3 **Separation of “core primitives” from “optional extensions” preserves future-proofing.** The core remains: object model, records engine, handling segregation, correctionability, registers, indices, and challenge primitives; partners can attach additional analytics, modeling, repositories, or identity systems without breaking ecosystem invariants. --- # 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/platforms/ii.-pillars.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.