> For the complete documentation index, see [llms.txt](https://docs.therisk.global/organization/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.therisk.global/organization/standardization/nexus-sovereignty/vi.-governance-engine/dao-typologies.md). # DAO Typologies ## Governance Function Typologies in the Nexus Sovereignty Framework: DAO-Compatible, Off-Chain, On-Chain, Hybrid, Institutional, and Machine-Verifiable Governance Structures ### Governance Functions for DAO-Compatible, Institution-Ready Digital Governance The Nexus Sovereignty Framework requires governance that is programmable, verifiable, modular, and interoperable across radically different institutional environments. Some implementations may use on-chain DAO tooling, smart-contract proposal systems, multisignature approvals, tokenless governance protocols, decentralized identity, public ledgers, attestations, and cryptographic voting. Others will operate through off-chain institutions: national registries, regional consortium boards, public-interest councils, standards committees, community steward bodies, professional review panels, enterprise evidence rooms, Project SPV governance functions, public authorities where authorized, or legally incorporated entities. Many serious deployments will be hybrid, combining off-chain authority with on-chain commitments, institutional quorum with cryptographic signatures, human review with machine-verifiable records, private evidence rooms with public proof receipts, and registry-controlled governance with programmable policy execution. For this reason, Nexus should not be framed as a DAO-only governance architecture. It must be **DAO-compatible**, **DAO-like where useful**, and **institutionally executable off-chain**. The mature design is not that “Nexus is governed by DAOs.” The mature design is that Nexus defines typed, scoped, verifiable governance functions that can be implemented through DAOs, councils, committees, registries, validator quorums, multisignature groups, sovereign nodes, community stewardship processes, enterprise governance controls, or hybrid on-chain and off-chain workflows. This distinction is critical for real-world adoption. DAO tooling can be powerful for transparent proposals, vote records, treasury-independent coordination, distributed participation, threshold signatures, public commitments, cryptographic audit trails, and programmable governance events. But DAO tooling is not automatically legally valid, jurisdictionally recognized, representative, privacy-preserving, accountable, or appropriate for high-consequence public-interest decisions. Token voting can create capture risk. Fully public on-chain transparency can expose sensitive data. Automated votes can mishandle law, public safety, Indigenous data, regulated finance, health information, emergency management, cross-border authority, or institutional accountability. Off-chain institutions, by contrast, may hold legal standing, public mandate, professional accountability, community legitimacy, fiduciary duties, contractual enforceability, or statutory authority, but they often lack machine-verifiable records, interoperable proof structures, and execution-ready policy logic. Nexus bridges this gap by defining governance functions that can operate in either environment while preserving verifiability, auditability, role separation, and legal boundaries. The operating doctrine is simple: **Nexus governance must be DAO-compatible, but not DAO-dependent. Governance authority comes from role, credential, mandate, jurisdiction, recognition, evidence, quorum, record, and correction path, not from the mere fact that a workflow uses DAO tooling.** ### From DAO Typologies to Governance Function Typologies The earlier labels, ClauseDAO, SimDAO, CredentialDAO, and AppealsDAO, capture useful functional separation, but the architecture should be upgraded from “DAO typology” to **governance function typology**. This change makes the framework more institutionally credible, technically flexible, legally safer, and deployable across public-good, sovereign, community, enterprise, and Web3 environments. A governance function is a scoped decision capability inside the Nexus Sovereignty Framework. It defines who can decide, what they can decide, what evidence they must consider, what credential authority they need, what quorum applies, what records must be produced, what privacy rules apply, what execution effects are allowed, what appeal path exists, and how the decision is anchored to clauses, credentials, simulations, CACs, registries, and audit records. The implementation can vary. In a public blockchain environment, the same function may be implemented as a DAO module, multisig contract, proposal contract, tokenless voting system, optimistic governance mechanism, or ZK-governed approval flow. In an institutional environment, it may be implemented as a registry committee, council workflow, standards panel, legal review process, national node governance cell, or secure evidence-room approval pathway. In a hybrid environment, an off-chain council may deliberate privately, publish a signed decision record, anchor a hash on-chain, and make the decision machine-verifiable for clause execution. This is the correct abstraction layer for Nexus. It allows the framework to interoperate with DAOs without being captured by DAO ideology. It allows sovereign, public-sector, nonprofit, enterprise, community, and multilateral actors to use the same protocol grammar without adopting the same governance form. ### Core Governance Function Types The Nexus Sovereignty Framework should define a set of specialized governance functions, each with a distinct authority boundary and technical role. The **Clause Governance Function** manages Smart Clause lifecycle. It reviews clause definitions, validates clause metadata, approves activation states, manages versioning and forks, deprecates or suspends unsafe clauses, defines public-safe output boundaries, and anchors clause hashes in registries. It is the function responsible for the machine-readable policy logic layer. The **Simulation Governance Function** manages models, simulation runs, uncertainty thresholds, forecast validity, dataset lineage, model status credentials, and simulation-triggered clause behavior. It determines whether a model or run may be used as evidence support for specific clause families, jurisdictions, or risk domains. The **Credential Governance Function** manages credential schemas, issuer recognition, revocation infrastructure, credential bundles, dependency profiles, selective disclosure rules, ZK proof profiles, credential oracles, and lifecycle hooks. It protects the trust fabric of identity and authorization. The **Appeals and Correction Governance Function** manages disputes, contested revocations, dependency failures, recognition conflicts, model challenges, clause freezes, public-safe disputes, and restoration pathways. It provides correctionability, not judicial authority unless separately constituted under law. The **Registry Governance Function** manages namespace discipline, registry status, object resolution, schema publication, record correction, index integrity, and registry interoperability. The **Public-Safe Governance Function** manages disclosure boundaries, redaction rules, public-facing summaries, risk communication constraints, sensitive-output review, and public-safe claims discipline. The **Node and Runtime Governance Function** manages node eligibility, TEE profiles, runtime attestation requirements, scheduler participation, secure multitenancy rules, node suspension, and execution integrity profiles. The **Community Stewardship Governance Function** manages community-controlled credentials, Indigenous and local data governance, protected knowledge disclosure, grievance-linked evidence, and community-specific public-safe review. The **Project Evidence Governance Function** manages Project SPV evidence rooms, asset telemetry credentials, safeguard evidence, climate scenario evidence, readiness evidence bundles, finance-readiness evidence, insurance-readiness evidence, and controlled disclosure for lawful implementation workflows. These functions can be implemented as DAOs, councils, committees, registries, panels, validator quorums, national nodes, community steward bodies, enterprise controls, or hybrid mechanisms. The function defines the scope. The implementation defines the operational form. ### Clause Governance Function The Clause Governance Function governs the lifecycle of Smart Clauses. It reviews clause syntax, clause metadata, source references, jurisdictional scope, credential requirements, input schemas, output schemas, public-safe constraints, simulation dependencies, safe-mode logic, and CAC requirements. It determines whether a clause is draft, simulation-only, advisory, active-limited, production-active, restricted, suspended, deprecated, superseded, revoked, or archived. This function is essential because Smart Clauses are not ordinary software snippets. They encode governance logic that may affect credentials, evidence routing, public-safe outputs, AI agent permissions, Project SPV evidence, finance-readiness evidence, insurance-readiness evidence, and cross-jurisdictional workflows. A clause must therefore be versioned, registry-resolved, tested, simulated where necessary, and linked to its authority class before it can be used in execution. The Clause Governance Function does not make law. It makes selected governance logic machine-readable, testable, auditable, and executable within defined boundaries. A clause may reference law, policy, treaty language, standards, safeguards, program rules, or institutional procedures, but the clause itself is not public authority unless a competent authority or lawful instrument gives it that effect. A mature Clause Governance Function should produce signed decision records for clause activation, modification, suspension, deprecation, fork recognition, compatibility updates, public-safe restrictions, and emergency safe-mode transitions. Each decision should link to the clause ID, clause hash, version tree, governance scope, quorum record, credentials of approving actors, dissent notes, simulation evidence, public-safe review, and audit record. In on-chain environments, this may be implemented as a smart-contract proposal and activation system with hash anchoring. In off-chain environments, it may be implemented as a registry-controlled review workflow with signed governance records. In hybrid environments, the institutional decision may remain off-chain while the clause hash, decision receipt, and status commitment are anchored on-chain or in a public audit registry. ### Simulation Governance Function The Simulation Governance Function governs the predictive and scenario-based intelligence layer of Nexus. It manages model registration, model status, simulation validation, dataset lineage, uncertainty profiles, scenario classes, forecast windows, model drift, run freshness, and simulation-triggered clause behavior. This function is essential because simulation outputs can influence high-consequence workflows. A flood model may activate emergency evidence routing. A public health model may trigger restricted review. A climate scenario may support Project SPV evidence. An AI risk model may restrict agent tool use. A hazard model may support insurance-readiness evidence. If models are not governed, stale or unvalidated simulations can become hidden authority. The Simulation Governance Function should classify models and runs by domain, jurisdiction, intended use, uncertainty method, validation state, data lineage, and expiry window. It may mark a model active, active-limited, restricted, under review, deprecated, superseded, or quarantined. It may define which simulation outputs can support which clause families and under what proof requirements. It should not be described as an absolute foresight authority. It does not guarantee prediction truth. It does not issue official warnings. It does not determine legal liability. It does not certify financeability or insurability. It governs the status of simulation evidence for declared Nexus workflows. A mature Simulation Governance Function should bind every decision to model IDs, model hashes, SimulationModelVCs, SimulationRunVCs, dataset lineage credentials, validation records, uncertainty profiles, clause dependencies, CACs, and audit logs. In privacy-sensitive contexts, it should support selective disclosure and ZK proofs so that model status can be verified without revealing protected data. ### Credential Governance Function The Credential Governance Function governs the identity, authorization, and trust layer of Nexus. It defines credential schemas, recognizes credential issuers, manages credential registries, controls revocation infrastructure, approves dependency trees, defines lifecycle hooks, governs credential bundles, approves selective disclosure profiles, manages ZK proof circuits, and supervises credential oracles. This function is essential because credentials are the permission layer of machine-verifiable governance. If credential governance is weak, unauthorized actors can issue trusted roles, stale credentials can keep working, revoked nodes can sign CACs, AI agents can retain tool access, public-safe reviewers can over-disclose, and Project SPV evidence credentials can be misinterpreted as finance approval or insurance underwriting. The Credential Governance Function should approve schemas for operational credentials, simulation credentials, credential governance credentials, public-safe credentials, machine credentials, node credentials, AI agent credentials, community stewardship credentials, Project SPV evidence credentials, finance-readiness evidence credentials, and insurance-readiness evidence credentials. It should define issuer requirements, revocation methods, status roots, credential bundle rules, cross-jurisdiction recognition metadata, and disclosure controls. It must preserve strong boundary language. Recognition of a credential issuer for Nexus use is not professional licensing, public authority delegation, regulatory approval, certification, procurement approval, finance approval, insurance underwriting, or legal compliance determination. It is protocol recognition within declared scope. In on-chain contexts, this function may use registry contracts, status roots, threshold signatures, and ZK-compatible revocation systems. In off-chain contexts, it may operate through institutional credential registries and signed status records. In hybrid contexts, credential decisions can remain institutionally governed while status commitments and proof roots are anchored for verification. ### Appeals and Correction Governance Function The Appeals and Correction Governance Function provides a structured path for disputes, errors, contested status changes, and cross-domain conflicts. It is the correction layer of Nexus governance. This function may review revoked credentials, suspended clauses, model quarantines, dependency cascade failures, issuer suspensions, cross-jurisdiction recognition conflicts, node exclusions, public-safe disputes, AI agent credential blocks, Project SPV evidence disputes, finance-readiness evidence status issues, and insurance-readiness evidence status issues. It may recommend restoration, restriction, reissuance, supersession, continued suspension, additional review, or escalation to competent authority. This function is not a court by default. It does not replace judicial process, regulatory appeal, treaty body review, public authority decision-making, professional discipline, contract remedies, or community governance unless lawfully constituted for that purpose. Its role is to correct protocol records, resolve internal governance conflicts, preserve auditability, and prevent automated systems from becoming unchallengeable. A mature Appeals and Correction Governance Function should operate under conflict-of-interest rules, evidence standards, credentialed quorum, privacy controls, due-process expectations, dissent records, and audit trails. Every decision should link to the disputed clause, credential, CAC, simulation, registry record, rollup, or recognition agreement. In DAO-compatible systems, appeals may use proposal workflows, evidence packets, timelocks, and multisignature correction. In institutional systems, appeals may use review panels, registry correction processes, and signed decisions. In hybrid systems, off-chain decisions can produce on-chain or registry-anchored correction receipts. ### Registry Governance Function The Registry Governance Function protects the integrity of names, schemas, status records, object resolution, and registry visibility. Nexus depends on registries to resolve clauses, credentials, CACs, simulations, nodes, proof profiles, recognition records, governance bodies, and dependency graphs. If registries are not governed, the system cannot know which object is authoritative, active, superseded, revoked, or disputed. This function manages namespace discipline, versioning, status transitions, schema publication, object indexing, registry corrections, registry forks, visibility controls, and interoperability mappings. It ensures that registered objects can be found, verified, updated, corrected, and retired without ambiguity. Registry governance does not make every registered object valid outside Nexus. A registry record means the object exists, resolves, and has a declared status within a defined registry. It does not mean legal approval, certification, public authority endorsement, finance approval, insurance underwriting, or universal recognition. The Registry Governance Function is especially important for SEO and public discovery in public-safe documentation. Public registry pages should use clear canonical names, stable metadata, structured descriptions, claim boundaries, and clean canonical links where published. Machine-readable registry metadata should support search, AI discovery, evidence lookup, and audit navigation without creating misleading claims. ### Public-Safe Governance Function The Public-Safe Governance Function governs how Nexus outputs are communicated to public, semi-public, institutional, community, and restricted audiences. It manages redaction, disclosure classification, public-safe summaries, sensitive-output review, official-warning boundaries, non-meaning language, community-protected data, and communications safety. This function is essential because machine-verifiable governance can produce outputs that appear authoritative. A risk score may be misread as an official warning. A readiness credential may be misread as finance approval. An insurance-readiness record may be misread as underwriting. A public health signal may be misread as an official public notice. A Project SPV evidence status may be misread as investment endorsement. A simulation result may be misread as prediction certainty. The Public-Safe Governance Function ensures that outputs carry correct labels, context, limitations, and audience controls. It governs what can be published, what must remain restricted, what requires community review, what requires competent authority, what should be summarized, and what should never be disclosed publicly. This function can be implemented through public-safe councils, red-team review cells, communication review panels, community steward approval, institutional sign-off, AI output gates, or DAO-compatible public disclosure workflows. ### Node and Runtime Governance Function The Node and Runtime Governance Function governs execution infrastructure. It manages node eligibility, TEE profiles, confidential compute requirements, scheduler participation, attestation rules, runtime measurement policies, secure multitenancy, node suspension, rollup eligibility, and machine credential status. This function is essential because Nexus execution depends on infrastructure that must be trusted only through proof. A node should not execute high-consequence clauses merely because it is available. It must hold active machine credentials, match jurisdictional requirements, produce valid attestations, satisfy runtime profiles, and remain within scheduling policy. The Node and Runtime Governance Function should define which nodes can execute which clause classes, which jurisdictions they may serve, which data classifications they may handle, which attestation types are accepted, which failover rules apply, and what happens after compromise or failure. It does not certify cloud providers, approve cybersecurity compliance, or guarantee safe outcomes. It governs node eligibility for declared Nexus execution profiles. ### Community Stewardship Governance Function The Community Stewardship Governance Function governs community-controlled credentials, local data access, protected knowledge, Indigenous data governance, public-safe map review, local grievance-linked evidence, and community-defined disclosure conditions. This function is essential because many risks and resilience workflows involve local knowledge, community vulnerability, land, culture, ecology, livelihoods, traditional knowledge, and protected data. Such information cannot be governed only through national, regional, enterprise, or technical logic. Community authority and consent structures must be represented in the protocol. Community stewardship governance may define who can access community-governed data, what can be disclosed, what must remain protected, what requires collective review, what public-safe language applies, and how disputes are handled. It may use off-chain community processes, local councils, consent records, steward credentials, controlled disclosure, or hybrid proof mechanisms. This function prevents interoperability from becoming extraction. It ensures that verifiability does not override community rights. ### Project Evidence Governance Function The Project Evidence Governance Function governs controlled evidence workflows for Project SPVs, infrastructure programs, resilience investments, asset-level monitoring, safeguard evidence, climate scenarios, operational telemetry, readiness records, and capital-relevant evidence. This function supports finance-readiness evidence and insurance-readiness evidence while preserving strict boundaries. It can coordinate evidence completeness, data provider credentials, controlled evidence room access, climate model review, safeguard review, asset operator status, monitoring evidence, and public-safe summaries. It can produce proof receipts, readiness evidence credentials, CAC-linked audit trails, and controlled disclosure packages. It must not approve finance, provide investment advice, issue credit ratings, underwrite insurance, bind coverage, determine claims, guarantee insurability, approve procurement, or imply public authority endorsement. It organizes evidence for authorized reviewers and lawful actors. Execution, financing, underwriting, procurement, and claims decisions remain with competent licensed or authorized parties. This function is essential for bridging public-good evidence infrastructure with lawful enterprise implementation without violating the One Rail - Two Stacks doctrine. ### Implementation Modes: On-Chain, Off-Chain, Hybrid, and Institutional Every governance function should declare its implementation mode. An **on-chain mode** uses smart contracts, public ledgers, DAO tooling, multisignature approvals, timelocks, on-chain registries, tokenless votes, ZK verifiers, or public commitments. This mode is useful where transparency, programmability, and decentralized verification are needed, but it must avoid exposing sensitive data or reducing authority to token ownership. An **off-chain institutional mode** uses councils, committees, registries, legal entities, public authorities where authorized, standards bodies, community processes, enterprise governance offices, and secure evidence rooms. This mode is useful where legal accountability, privacy, professional review, public mandate, or community legitimacy matters. A **hybrid mode** combines off-chain decision authority with on-chain or public proof anchoring. For example, a council reviews a clause off-chain, signs a decision packet, stores sensitive evidence in a controlled room, publishes a hash to a registry, anchors the status root on-chain, and makes the result verifiable by Smart Clauses. A **sovereign node mode** operates within a national or jurisdictional infrastructure environment, such as an SDZ, national registry, or public-sector evidence environment. It emphasizes domestic control, lawful access, auditability, and cross-border proof without raw data export. A **community-controlled mode** operates through community governance rules, local steward credentials, protected disclosure conditions, and community review processes. An **enterprise evidence mode** operates within lawful enterprise, Project SPV, or regulated-sector environments, with controlled access, contractual authority, and strict public-good boundary separation. NSF should be compatible with all of these modes. The same governance function schema should be portable across them. ### Governance Records and Proof Anchoring Every material governance function decision should generate a signed governance record. The record should state what was decided, by whom, under which authority, with which credentials, under which quorum, based on which evidence, affecting which clause, credential, simulation, registry, node, project, or public-safe output, and with what appeal path. A governance record should include the governance function type, object reference, decision type, jurisdiction, authority class, quorum record, signer DIDs, credential proofs, evidence references, CAC references, clause hashes, registry status, privacy profile, dissent notes, limitations, and non-meaning fields. Where appropriate, the record may be anchored in a registry, CAC Rollup, sovereign audit archive, public ledger, enterprise evidence room, community record system, or off-chain audit repository. The anchor should be a commitment, not a sensitive payload. This produces tamper-evident, attributable, proof-scoped traceability. It does not automatically create legal non-repudiation unless the applicable legal framework provides that effect. ### Cross-Function Coordination Typed governance functions must coordinate through signed events, shared registries, dependency graphs, and audit records. A Clause Governance Function may request simulation review. A Simulation Governance Function may notify model quarantine. A Credential Governance Function may update a credential schema. A Public-Safe Governance Function may block publication. A Node Governance Function may suspend a runtime. An Appeals and Correction Function may restore a disputed credential. A Project Evidence Governance Function may update readiness evidence status. Cross-function events should be standardized. They should include source function, target function, object reference, decision request, clause hash, credential schema hash, CAC reference, jurisdiction, urgency, privacy profile, requested action, response deadline, proof profile, and signature. This creates a governance mesh rather than a governance hierarchy. Each function retains its domain while interoperating through verifiable state. ### Governance Lifecycle Management Governance functions themselves require lifecycle controls. A governance function may be proposed, activated, limited, suspended, forked, merged, superseded, deprecated, revoked, archived, or placed under appeal. Its members, signers, quorum rules, credentials, conflict policies, privacy profile, jurisdiction, and authority class must be registered and reviewable. A governance function metadata record should include governance function ID, type, implementation mode, jurisdiction, operator or steward, authority class, credential requirements, quorum model, scope, registry reference, appeal path, audit obligations, public-safe limitations, and revocation authority. Lifecycle management prevents governance functions from becoming permanent unchecked authorities. It also supports jurisdictional adaptation. A national implementation may fork a global reference governance profile. A regional consortium may create a cross-border version. A community steward body may define protected disclosure rules. An enterprise evidence room may define project-specific evidence governance. Forking, merging, and supersession should preserve lineage so that audit remains possible. ### Quorum and Participation Design Governance quorum must match decision risk. Low-risk technical updates may require a small credentialed maintainer quorum. High-consequence clause activation may require domain, legal, technical, public-safe, and jurisdictional review. Simulation model approval may require scientific, data, uncertainty, and model-risk expertise. Credential issuer recognition may require identity, security, privacy, and governance review. Appeals may require independence, recusal, and documented evidence review. Token-weighted voting should not control high-consequence public-good governance. Where DAO tooling is used, the preferred model is credentialed, role-bound, conflict-screened, record-based governance. Participation should be based on verified role, contribution, mandate, expertise, jurisdiction, community standing, or institutional authority, not purchased governance power. Quorum models may include threshold signatures, multisig, credentialed majority, sector-balanced quorum, double-lock jurisdictional approval, community consent gates, conflict-free quorum, timelocks, emergency quorum, and staged activation. Quadratic voting, delegated voting, optimistic governance, and conviction voting may be useful in some low-risk or community contexts, but should be carefully bounded. Good governance design is not only about decentralization. It is about legitimacy, competence, accountability, and correction. ### AI Agents in Governance Functions AI agents may support governance functions, but they must not become the source of governance legitimacy. AI can help draft clauses, compare versions, detect schema inconsistencies, summarize evidence, run simulation diagnostics, identify dependency failures, prepare appeal packets, monitor public-safe risks, and support registry maintenance. But material decisions should remain credentialed, reviewable, signed, and attributable to human or institutional governance actors unless a narrowly scoped technical automation is explicitly authorized. AI agents participating in governance workflows should hold active AgentIdentityVCs, ModelStatusVCs, ToolUseVCs, DataAccessVCs, MemoryPolicyVCs, and PublicSafeDraftingVCs. Their outputs should be labeled as machine-generated support. Their use should be logged. Their authority should expire. Their tool access should be credential-oracle checked. AI can accelerate governance. It must not own governance. ### SEO and Public Discovery Architecture for Governance Functions Public-facing Nexus documentation should describe these governance functions using clear, searchable, institutionally credible terms. The strongest SEO language should connect Nexus governance to real applied domains: verifiable governance, DAO-compatible governance, digital public infrastructure governance, zero-trust governance, verifiable credentials, decentralized identity, smart clauses, policy-as-code, simulation governance, AI governance, public-safe AI, credential governance, cross-jurisdictional interoperability, sovereign data infrastructure, confidential compute governance, and audit-ready institutional trust. Headings and metadata should avoid narrow DAO-only language when the broader architecture is stronger. “DAO-Compatible Governance Functions” is more accurate and discoverable than “DAO Typologies.” “Clause Governance Function” is more institutionally portable than “ClauseDAO.” “Simulation Governance Function” speaks to AI governance, model risk, and digital twin applications. “Credential Governance Function” speaks to decentralized identity, verifiable credentials, and zero-trust authorization. “Appeals and Correction Governance Function” speaks to trust, dispute resolution, institutional accountability, and correctionability. Public pages should include boundary-safe descriptions so search engines, AI systems, institutional readers, and partners do not misclassify Nexus as a DAO project, crypto governance system, regulator, certification authority, insurer, investment adviser, public authority, or treaty body. The SEO goal is not hype. The SEO goal is semantic precision, institutional trust, and machine-readable discoverability. ### Boundary Statement for DAO-Compatible Governance Functions DAO-compatible governance functions support scoped decision-making, clause lifecycle management, simulation governance, credential governance, appeals and correction, registry integrity, public-safe disclosure, node eligibility, community stewardship, Project SPV evidence workflows, finance-readiness evidence, insurance-readiness evidence, AI governance, cross-jurisdictional interoperability, CAC-linked records, and machine-verifiable institutional coordination. They do not by themselves create legal authority, public authority status, regulatory approval, certification, procurement approval, finance approval, investment advice, insurance underwriting, claims determination, official public warning status, treaty enforcement, professional licensing, legal liability, sovereign consent, or community consent. A governance function decision is a protocol governance record under a declared scope. Its legal or institutional effect depends on applicable law, competent authority, charter, contract, recognition record, credential schema, jurisdiction, community rules, and institutional adoption. A DAO-compatible workflow is not automatically a DAO. A DAO vote is not public authority. A governance function does not make law. A simulation governance decision does not guarantee prediction truth. A credential governance decision does not create universal credential validity. An appeals function is not a court unless lawfully constituted as such. A project evidence governance decision is not finance approval. An insurance-readiness governance decision is not underwriting. This boundary should appear in governance metadata, registry entries, public documentation, credential schemas, CAC records, verifier tools, AI agent policies, and public-safe dashboards. ### Governance Function Typologies as the Institutional Fabric of Nexus The Nexus Sovereignty Framework becomes credible when governance is both machine-verifiable and institutionally disciplined. DAO compatibility gives the system programmable governance options for Web3 and decentralized environments. Off-chain institutional compatibility gives it legal, public-sector, community, nonprofit, enterprise, and multilateral usability. Hybrid design allows both worlds to interoperate without forcing one model onto all domains. Typed Governance Functions are the institutional fabric of this architecture. They define who governs clauses, who governs simulations, who governs credentials, who manages appeals, who controls registries, who reviews public-safe outputs, who manages nodes, who protects community knowledge, and who governs project evidence. They create specialized authority without centralizing the whole system. They allow modular governance without fragmentation. They enable automation without losing accountability. They support decentralization without token capture. They support institutional adoption without sacrificing verifiability. This is the mature architecture Nexus needs: DAO-compatible, off-chain ready, on-chain verifiable, hybrid by design, jurisdiction-aware, credential-bound, CAC-linked, privacy-preserving, public-safe, and correction-ready. Nexus does not need to be governed only by DAOs to be decentralized. It needs governance functions that can operate wherever legitimate authority exists, and make that authority verifiable wherever machines must act. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.therisk.global/organization/standardization/nexus-sovereignty/vi.-governance-engine/dao-typologies.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.