> 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/membership-tiered-credentials-and-domain-trust-anchors.md). # Membership: Tiered Credentials and Domain Trust Anchors ## Tiered Membership and Credentialed Governance Roles in the Nexus Sovereignty Framework: Domain Trust Anchors, Role-Bound Authority, Tiered Access, Federated Equivalence, and Machine-Verifiable Participation ### Why Tiered Membership Matters in Nexus Governance Tiered membership matters because not every participant in a governance environment should have the same access, authority, voting weight, disclosure rights, execution privileges, or review responsibilities. The Nexus Sovereignty Framework operates across high-consequence domains: climate risk, public health, disaster response, critical infrastructure, AI governance, finance-readiness evidence, insurance-readiness evidence, Project SPV evidence, community data governance, simulation-backed forecasting, and cross-jurisdictional credential recognition. In these domains, flat membership is unsafe. It can create credential inflation, confuse expertise with observation, expose sensitive records, allow unqualified actors to influence technical decisions, and make governance vulnerable to capture. A field observer, simulation validator, public-safe reviewer, national registry steward, community data steward, credential issuer, enterprise evidence-room reviewer, node operator, AI governance reviewer, and appeals reviewer may all participate in Nexus governance, but their roles are different. Some actors may observe. Some may submit evidence. Some may validate models. Some may vote on credential schemas. Some may approve clause activation. Some may review public disclosure. Some may participate in appeals. Some may only operate inside one jurisdiction. Some may hold temporary emergency roles. Some may have authority in one domain but not another. Tiered membership gives Nexus a structured way to manage these differences. Each participant’s authority is defined by credential provenance, membership tier, role type, jurisdiction, domain, clause family, governance function, delegation path, expiry, revocation status, and audit obligations. A participant is not trusted because they are “in the DAO” or “in the network.” They are trusted only for the actions their active credentials, tier, and scope allow. This is especially important because Nexus is DAO-compatible but not DAO-dependent. Tiered membership must work across on-chain DAOs, off-chain institutional councils, sovereign registries, regional consortia, community stewardship bodies, enterprise evidence rooms, multisignature governance groups, and hybrid workflows. The tier system should be portable across these environments without forcing every implementation to adopt a tokenized DAO model. The core doctrine is: **Nexus membership is not a flat permission flag. It is a credentialed, tiered, domain-scoped, jurisdiction-aware, revocable, and audit-linked governance status that determines what an actor may see, sign, vote on, validate, execute, challenge, or escalate.** ### Membership Tiers Are Authority Classes, Not Status Badges Tiered membership should not become symbolic hierarchy. It is not a prestige ladder. It is an authority classification system. A higher tier does not mean universal power. A Tier One simulation validator may have high authority for model review but no authority to approve credential issuers. A Tier Two disaster operator may have operational evidence authority but no authority to publish public-safe alerts. A Tier Three public witness may have observation and challenge rights but no execution authority. A community steward may have decisive authority over community-governed data even if they are not ranked above technical validators in another domain. Tiers must therefore be domain-specific and scope-specific. A member’s tier should always be interpreted alongside credential type, domain, jurisdiction, governance function, clause family, data class, public-safe role, and recognition record. Without that context, tiers become misleading. The right design is not “Tier One is always above Tier Two.” The right design is “this tier has these rights in this domain under these conditions.” ### Credential Tier Overview Nexus should define tier profiles as reusable patterns, while allowing each governance function, jurisdiction, community, registry, or enterprise workflow to define its own exact tier rules. A **Foundational or Observer Tier** may allow public observation, public-safe consultation, issue flagging, limited evidence submission, or participation in open review. This tier can support civil society visibility, academic observation, citizen witness roles, community feedback, or non-sensitive public consultation. It should not grant execution authority or access to restricted evidence by default. A **Contributor or Operator Tier** may authorize bounded operational participation. Actors at this tier may submit evidence, operate field workflows, participate in credentialed working groups, contribute to simulations, request clause execution, participate in readiness evidence workflows, or access restricted but non-critical data where authorized. This tier is often time-limited and jurisdiction-scoped. A **Validator or Expert Tier** may authorize model validation, credential review, clause review, public-safe review, node eligibility review, controlled evidence review, or domain-specific technical sign-off. This tier requires stronger credential provenance, conflict screening, training, professional or institutional standing where relevant, and audit obligations. A **Steward or Issuer Tier** may authorize credential issuance, registry maintenance, governance function administration, revocation authority, recognition record management, or quorum participation for high-consequence decisions. This tier requires the strongest controls because it can affect other credentials and downstream trust. A **Appeals or Correction Tier** may authorize dispute review, restoration recommendations, dependency cascade review, contested revocation review, and correction records. This tier requires independence, conflict screening, due process rules, and strict auditability. A **Community Stewardship Tier** may operate separately from technical tiers. Community or Indigenous data governance authority should not be subordinated to technical credential tiers. Where community-governed data, protected knowledge, local consent, or grievance-linked evidence is involved, community stewardship credentials may create mandatory gates regardless of other participant tiers. A **Emergency Temporary Tier** may grant time-limited elevated authority during a crisis. It should be bound to a trigger, jurisdiction, clause hash, expiration, allowed actions, prohibited actions, and after-action review. A **Enterprise Evidence Tier** may apply inside Project SPV, operator, provider, insurer, investor, contractor, or controlled evidence-room workflows. It authorizes evidence handling, not finance approval, underwriting, procurement approval, or public authority status. The exact names can vary by deployment, but the system must keep the semantics machine-readable. Tiers should never be defined only in prose. ### Domain Trust Anchors A Domain Trust Anchor is a recognized issuer, registry, governance body, national node, regional consortium, community steward body, standards steward, enterprise evidence authority, or public authority where authorized, that can issue, recognize, suspend, revoke, or validate tier credentials within a defined domain. Trust Anchors are necessary because tier credentials are only meaningful if their source is known, scoped, and accountable. A Domain Trust Anchor may be responsible for disaster response credentials, simulation credentials, public health credentials, climate evidence credentials, credential issuer credentials, node operator credentials, public-safe reviewer credentials, community data stewardship credentials, Project SPV evidence credentials, finance-readiness evidence credentials, or insurance-readiness evidence credentials. A mature Trust Anchor record may look like: ```json { "trust_anchor": { "id": "did:nsf:org:RegionalDisasterEvidenceRegistry", "domains": [ "DisasterEvidence", "EarlyWarningEvidence", "PublicSafeRiskCommunication" ], "recognized_by": [ "RegionalRecognitionRecord#0x91ab", "NationalCredentialRegistry#KEN" ], "authorized_tiers": [ "OperatorTier", "ValidatorTier", "PublicSafeReviewerTier" ], "valid_until": "2030-12-31", "revocation_registry": "CredentialStatusRegistry::RegionalDisasterEvidence@1.0", "audit_endpoint": "audit-registry-0x..." } } ``` The seed uses `UNDRR-DAO` and “UN Treaty System.” Unless there is a formal, authorized relationship, final documentation should not imply that UNDRR, a UN treaty system, or any multilateral body has issued or recognized Nexus credentials. Safer language is “disaster-risk evidence registry,” “treaty-aligned evidence profile,” or “competent multilateral body where formally authorized.” Every Trust Anchor should maintain credential issuance logs, revocation registries, public or restricted audit records, issuer credentials, key rotation records, conflict policies, and recognition metadata. A Trust Anchor can be on-chain, off-chain, hybrid, sovereign, community-controlled, or enterprise-controlled. What matters is that its authority is scoped and verifiable. ### Membership Verification at Execution Tiered membership must be enforced at execution time. It is not enough to list members in a governance document. TEEs, CAC generators, simulation oracles, Credential Oracles, clause runtimes, AI agents, registries, and dashboards must verify whether a participant’s tier credential is active and applicable to the requested action. Execution environments should verify that the credential corresponds to a registered tier, that the issuer is a recognized Trust Anchor for that domain, that the credential is active and not revoked, that the credential has not expired, that its jurisdiction matches the clause or workflow, that its domain matches the requested action, that any delegation remains valid, that dependency credentials are satisfied, and that the action is within allowed scope. A clause authorization pattern may look like: ```scl if signer.hasVC("SimulationAuditorVC") and signer.tier in ["ValidatorTier", "StewardTier"] and VC.issuer in trustAnchors("SimulationGovernance") and VC.status == "ACTIVE" and VC.jurisdiction.matches(clause.jurisdiction) { allow "simulation-review-evidence-support" } ``` For public-safe and legal boundary reasons, the action should be precise. The clause should not say “execute treaty enforcement” or “approve relief.” It should say “route evidence,” “support review,” “validate simulation status,” “approve clause activation within Nexus,” “generate CAC,” “publish public-safe summary,” or “request competent actor review,” depending on the workflow. Membership verification converts tiers from labels into enforceable authorization controls. ### Tiered Privileges and Boundaries Each tier should define privileges and boundaries. Privileges may include view access, evidence submission, proposal creation, vote eligibility, model review, credential issuance, credential revocation, public-safe approval, appeal participation, node operation, registry maintenance, controlled evidence access, AI tool governance, or Project SPV evidence review. Boundaries define what the tier cannot do. A Contributor or Operator Tier may submit evidence, but not approve public outputs. A Validator Tier may validate a model for evidence use, but not guarantee prediction truth. A Steward Tier may recognize credential issuers, but not create public authority or professional licensing. An Appeals Tier may correct protocol records, but not replace courts or regulators. A Project Evidence Tier may manage readiness evidence, but not approve financing or underwrite insurance. A Public Witness Tier may observe or challenge, but not access restricted data unless separately authorized. Tier privileges should be encoded in policy, not inferred. A tier profile may include: ```json { "tier_profile": { "tier": "ValidatorTier", "domain": "SimulationGovernance", "allowed_actions": [ "review-model-status", "sign-simulation-validation-record", "participate-in-simulation-quorum" ], "prohibited_actions": [ "issue-official-public-warning", "approve-finance", "underwrite-insurance", "grant-public-authority" ], "requires_conflict_screening": true, "requires_audit_logging": true } } ``` The best governance systems make non-authority as explicit as authority. ### Upgrading and Downgrading Tiers Tier movement must be governed. If participants can self-upgrade, tiers lose meaning. If tier upgrades are permanent, capture risk increases. If downgrades are arbitrary, governance becomes unfair. Nexus should treat tier movement as a credential lifecycle process with evidence, review, expiry, appeal, and audit. Upgrades may depend on training, experience, prior participation, peer review, institutional nomination, community endorsement, simulation performance, audit history, conflict review, contribution records, or successful completion of clause-bound tasks. For example, a simulation reviewer may move from Contributor Tier to Validator Tier only after holding an active training credential, completing supervised reviews, and receiving sign-off from credentialed validators. A field operator may receive temporary emergency elevation after a verified hazard trigger. A public-safe reviewer may upgrade only after completing public-safe training and review exercises. A Project Evidence reviewer may gain controlled-room access only after confidentiality, conflict, and evidence-governance checks. Downgrades may occur after expiry, inactivity, misuse, unresolved conflict, credential revocation, dependency failure, issuer suspension, failed re-credentialing, or appeals outcome. Downgrades should distinguish restriction, suspension, under review, expired, revoked, and historical-only status. Not every downgrade implies misconduct. Credential Oracles should track tier lineage, issuer authority, lifecycle events, upgrade CACs, downgrade records, appeal status, and restoration pathways. Tier history should remain audit-visible, but sensitive details should be disclosed only under policy. Tier movement is governance evolution, not social ranking. ### Credential Bundling Across Tiers Credential bundles may include multiple tiers. This is often necessary because real workflows require different authority layers. A flood response workflow may need a Tier One simulation validator, Tier Two disaster operators, Tier Three public witnesses, and a public-safe reviewer. A Project SPV evidence workflow may need a controlled evidence-room steward, asset operator, climate reviewer, safeguard reviewer, and public-safe reviewer. An AI governance workflow may need AI safety reviewers, model-risk reviewers, tool owners, and human supervisors. A credential bundle may look like: ```json { "bundle_id": "EmergencyFloodEvidenceBundle#0x44a1", "components": [ { "vc": "ForecastModelVC#0x11", "tier": "ValidatorTier", "required": true }, { "vc": "DisasterOperatorVC#0x22", "tier": "OperatorTier", "required_count": 2 }, { "vc": "PublicWitnessVC#0x33", "tier": "ObserverTier", "required_if": "public-consultation-required" } ], "clause_binding": "FloodEvidenceRoutingClause@2.1" } ``` Each clause should validate which tiers are required for each logic path. A simulation trigger may require at least one validator-tier simulation credential and two operator-tier confirmations. A public-facing output may require public-safe reviewer tier plus affected-jurisdiction participation. A community data workflow may require community steward tier regardless of technical tiers. Credential bundling allows tiered participation without flattening roles. ### Membership Oracles Membership Oracles verify tier status and role eligibility. They are specialized Credential Oracles that answer whether a participant is authorized for a governance function, proposal, clause, simulation, credential workflow, or evidence environment. A Membership Oracle should check tier credential validity, issuer status, Trust Anchor recognition, role match, jurisdiction, domain, clause family, delegation status, delegation expiry, revocation status, dependency tree, conflict status, and voting eligibility. A response may look like: ```json { "tier": "OperatorTier", "tier_level": 2, "authorized_for": [ "FloodReliefEvidenceRouting@2.1", "SimulationTriggerReview@1.3" ], "issuer": "did:nsf:org:RegionalDisasterEvidenceRegistry", "scope": { "jurisdiction": "EGY", "domain": "DisasterEvidence" }, "status": "ACTIVE", "limitations": [ "not-official-public-warning", "not-relief-approval", "not-financial-transfer-authorization" ], "proof_hash": "0x..." } ``` The oracle should return proof-scoped answers. It should not expose full credential details unless policy requires disclosure. It should support ZK eligibility proofs where participation privacy is necessary. Membership Oracles make tiered governance executable. ### Tier Mapping Across Federated Governance Domains In cross-jurisdictional and multilateral environments, different registries may use different tier systems. A regional disaster registry may have Operator, Validator, and Steward tiers. A national public health registry may use Reviewer, Authority, and Auditor roles. A community stewardship body may use Steward, Witness, and Consent roles. An enterprise evidence room may use Reviewer, Controller, and Observer roles. Nexus should support tier equivalence mapping, but equivalence must be explicit, signed, scoped, and limited. Tier Two in one domain should not automatically equal Tier Two in another. Mapping must specify the purpose, credential type, recognizing party, recognized issuer, domain, jurisdiction, valid period, and non-meaning boundaries. A safe tier mapping record may look like: ```json { "tier_mapping_record": "TierEquivalence#0x77aa", "from_registry": "did:nsf:org:AfricanRegionalDisasterEvidenceRegistry", "to_registry": "did:nsf:org:PublicHealthEvidenceRegistry", "credential_type": "FieldEvidenceOperatorVC", "tier_equivalents": { "OperatorTier": { "maps_to": "ContributorTier", "recognized_for": [ "field-evidence-submission" ], "not_recognized_for": [ "health-data-access", "official-public-health-notice" ] } }, "valid_until": "2026-01-01", "dispute_policy": "CrossRegistryTierMappingReview@1.0", "signature": "0x..." } ``` The seed’s example maps African Union and WHO DAO tiers. Unless formally authorized, final examples should not imply AU or WHO governance participation. Use neutral registry names unless the relationship is real. Tier mapping is interoperability, not authority transfer. ### Tiered Membership Across On-Chain, Off-Chain, and Hybrid Environments In on-chain environments, membership tiers may be represented through soulbound credentials, verifiable credentials, attestations, registry contracts, ZK membership proofs, multisig signer sets, or non-transferable governance tokens. Care must be taken that token ownership does not become public-good authority. Credentials should be non-transferable, revocable, and scoped. In off-chain environments, tiers may be represented through institutional appointment records, registry entries, signed credentials, professional review status, community steward records, or enterprise evidence-room access records. These can still be machine-verifiable through DIDs, VCs, credential registries, status roots, and audit records. In hybrid environments, an off-chain body may issue a VC, publish a status commitment, anchor a tier root on-chain, and allow smart contracts or clause runtimes to verify membership without exposing private records. Nexus should support all three. The membership model must be portable. The proof layer should adapt to the operating environment. ### Anti-Capture Controls for Tiered Membership Tiered membership can itself become a capture vector if high tiers are controlled by a small group, dominant jurisdiction, vendor, funder, or technical insider. Nexus must design tier governance with anti-capture controls. Controls should include tier expiry, periodic re-credentialing, independent review, conflict-of-interest declarations, recusal rules, maximum institutional concentration, jurisdictional diversity, community veto or consent gates where appropriate, appeal rights, public-safe challenge rights, rotation of validators, role decay after inactivity, audit sampling, and transparent tier lineage. High-tier credentials should not be permanent. Issuer credentials should be reviewable. Emergency elevated tiers should auto-expire. Delegated tiers should be time-limited. Public-good governance tiers should not be purchasable. Contribution, competence, mandate, community standing, or institutional role may support tiering, but capital should not control public-good authority. Tiered governance must prevent both chaos and oligarchy. ### Tiered Membership for AI Agents AI agents should also have tiered membership profiles where they participate in governance or execution. An AI agent may hold an AgentObserverTier for monitoring public records, an AgentAssistantTier for preparing evidence summaries, an AgentToolUseTier for bounded tool execution, or an AgentRestrictedExecutionTier for supervised clause operations. High-risk agent actions should require human supervisor credentials and active model-status credentials. AI tiers should be short-lived, task-scoped, model-version-bound, tool-specific, and revocable. A model quarantine should downgrade or suspend dependent agent tiers. An agent should not vote in governance or execute high-consequence actions unless a narrowly defined machine role is explicitly authorized, and even then only within strict controls. Tiered membership prevents AI systems from accumulating broad invisible authority. ### Tiered Membership for Project SPVs, Finance-Readiness, and Insurance-Readiness Project SPV and capital-relevant evidence workflows need tiered access. Some participants may observe public-safe summaries. Some may submit asset evidence. Some may review climate scenarios. Some may validate safeguard evidence. Some may access controlled financial or operational records. Some may produce readiness evidence credentials. These are different authority levels. A Project Evidence Operator Tier may submit telemetry or documentation. A Project Evidence Reviewer Tier may inspect controlled evidence. A Scenario Reviewer Tier may review climate or hazard simulations. A Public-Safe Reviewer Tier may approve public summaries. A Registry Steward Tier may update evidence status records. Finance-readiness and insurance-readiness tiers must include strong non-meaning boundaries. A person authorized to review finance-readiness evidence is not thereby authorized to approve financing, provide investment advice, rate credit, place securities, or guarantee capital. A person authorized to review insurance-readiness evidence is not thereby authorized to underwrite, bind coverage, price risk, determine claims, or certify insurability. Tiered access makes evidence review possible without turning Nexus into a regulated execution stack. ### Tiered Membership Across GNC, RNC, and NNC Architecture At the national level, National Nexus Consortiums may define national membership tiers for domestic governance, public-safe review, disaster evidence, public health evidence, AI agent governance, Project SPV evidence, credential issuance, and node operation. National tiers preserve jurisdiction-specific authority. At the regional level, Regional Nexus Consortiums may define regional tier mappings for shared hazards, corridor systems, regional simulations, cross-border evidence, and mutual recognition. Regional tiers should not override national or community restrictions. At the global level, the Global Nexus Consortium may define reference tier schemas, interoperability vocabulary, conformance tests, public-good boundary language, and cross-registry mapping profiles. It should not centrally assign all membership tiers. At the community level, community and Indigenous governance bodies may define tiers for stewardship, protected knowledge review, public-safe map review, local data access, and grievance participation. These tiers may be decisive for community-governed data. At the enterprise layer, National Consortium Companies, Project SPVs, providers, operators, insurers, investors, contractors, and evidence rooms may define enterprise evidence tiers for lawful implementation workflows. Tiered membership is therefore federated. It supports common verification while preserving local authority. ### Boundary Statement for Tiered Membership Tiered membership supports granular access control, role-based voting, clause authorization, simulation validation, credential issuer governance, public-safe review, community stewardship, Project SPV evidence workflows, finance-readiness evidence, insurance-readiness evidence, AI agent governance, cross-jurisdictional recognition, and machine-verifiable governance participation. It does not by itself 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, sovereign consent, community consent, legal liability, or universal recognition. A membership tier is a protocol role and access classification under a declared scope. Its legal or institutional effect depends on issuer authority, credential schema, recognition record, jurisdiction, applicable law, contracts, community rules, and competent institutional adoption. A higher tier is not universal authority. A Trust Anchor is not a regulator unless lawfully authorized. A tier credential is not professional licensing. A simulation tier is not prediction truth. A disaster response tier is not official emergency command. A project evidence tier is not finance approval. An insurance-readiness tier is not underwriting. A community data tier cannot override community governance. This boundary should appear in tier schemas, membership credentials, Trust Anchor records, verifier tools, governance dashboards, AI agent policies, CAC records, and public documentation. ### Tiered Membership as a Pillar of Machine-Verifiable Governance Tiered membership gives Nexus the ability to coordinate many actors without treating them as equal for every purpose. It allows governance to be inclusive without being uncontrolled, expert-led without being technocratic, decentralized without being token-captured, and institutionally credible without being centralized. It turns credentials into domain-aware institutional identities. It makes access granular. It makes authority scoped. It makes escalation traceable. It makes revocation meaningful. It makes delegation safe. It makes cross-jurisdictional mapping possible. It makes AI participation bounded. It makes Project SPV evidence governance practical. It makes public-good governance resistant to capture. The result is a governance system where every participant can be verified for the exact role they are allowed to perform, in the exact domain where they are recognized, under the exact conditions where their authority applies. That is the role of tiered membership in the Nexus Sovereignty Framework: to embed role quality, credential provenance, jurisdictional accountability, and revocable authority directly into the clause and execution architecture of risk governance. --- # 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/membership-tiered-credentials-and-domain-trust-anchors.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.