> 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/v.-verifiable-credentials/vc-types-operational-legal-simulation-credentialal.md). # VC Types: Operational, Legal, Simulation, Credentialal ## Typed Verifiable Credentials in the Nexus Sovereignty Framework: Operational Authority, Legal Standing, Simulation Trust, Meta-Credential Governance, Lifecycle Control, and Credential-Aware Execution ### Why Verifiable Credential Typing Matters Verifiable Credentials are not interchangeable labels. In the Nexus Sovereignty Framework, a credential may authorize a human actor to perform an operational task, identify a node as eligible to execute clauses, recognize an institution as a credential issuer, bind a model to a simulation review record, grant an AI agent limited tool access, establish a public-safe review role, support a Project SPV evidence workflow, or record that a governance body has standing inside a defined jurisdictional or institutional context. Each of these functions carries different risks. They require different schemas, issuers, revocation rules, recognition boundaries, proof requirements, audit obligations, and lifecycle controls. If all credentials are treated as one generic credential class, the system becomes unsafe. A disaster operator credential could be misread as legal authority. A simulation reviewer credential could be mistaken for model certification. A Project SPV evidence credential could be misread as finance approval. A public-safe reviewer credential could be mistaken for public authority. A machine credential could be trusted after its attestation profile expires. A meta-credential issuer could issue roles outside its scope. A credential valid in one country could be accepted in another without recognition. An AI agent could use a credential intended for read-only access to trigger execution. These are not theoretical errors. They are exactly the kinds of authority-collapse failures that occur when identity, role, proof, and jurisdiction are not typed. The NSF Protocol therefore requires typed Verifiable Credentials. A typed VC is a credential whose purpose, authority class, issuer requirements, subject class, permitted actions, jurisdiction, lifecycle, revocation logic, recognition conditions, audit obligations, and proof dependencies are explicit. Typed credentials allow Smart Clauses to make precise authorization decisions. They allow CACs to record which authority was checked. They allow auditors to trace credential impact. They allow AI agents to reason about access without overreach. They allow national, regional, community, and enterprise systems to interoperate without pretending that all credentials mean the same thing. The core doctrine is: **No credential should authorize an NSF action unless its type, schema, issuer, subject, scope, validity, revocation status, jurisdiction, and permitted use are machine-readable, registry-resolved, and audit-verifiable at execution time.** ### Verifiable Credentials as Bounded Authority Objects A Verifiable Credential in NSF is not merely an identity token. It is a bounded authority object. It states that an issuer makes a claim about a subject under a schema, within a scope, for a period, with a revocation method, under a governance context, and with defined uses. The credential may be held by a human, organization, machine, AI agent, TEE node, simulation model, credential issuer, public-safe reviewer, Project SPV evidence room, registry maintainer, or governance body. A VC’s authority is never universal. It is bounded by schema, issuer, recognition, jurisdiction, purpose, and time. A credential may authorize field evidence submission but not public communication. It may authorize clause execution but not clause publication. It may authorize a machine to sign CACs for disaster clauses but not health clauses. It may authorize a model reviewer to approve simulation bundles but not issue credentials. It may authorize an enterprise evidence room to produce Project SPV CACs but not imply public-good endorsement, procurement approval, finance approval, or insurance underwriting. Typed VCs make these boundaries explicit. ### VC Type Overview NSF should define a controlled taxonomy of credential types. Four major categories are foundational: Operational Credentials, Legal or Standing Credentials, Simulation Credentials, and Credential Governance Credentials (meta-credentials). In practice, NSF may also define Node Credentials, Public-Safe Credentials, Community Stewardship Credentials, AI Agent Credentials, Project SPV Evidence Credentials, Registry Credentials, and Emergency Credentials as subtypes or cross-cutting profiles. The four primary categories should be understood as follows. **Operational Credentials** authorize action within bounded workflows. They are used for execution, access, routing, review, field operations, data submission, node operation, AI tool use, public-safe workflow participation, and Project SPV evidence handling. **Legal or Standing Credentials** record institutional standing, lawful role, jurisdictional recognition, treaty-aligned participation, contractual role, or authorized representation. They should be claims-safe and should not be used to imply legal status unless issued by a competent authority or authorized issuer. **Simulation Credentials** identify and govern models, model maintainers, simulation runners, validation reviewers, simulation bundles, model outputs, and forecast evidence used by Smart Clauses. **Credential Governance Credentials**, also called meta-credentials, govern the credentialing system itself. They identify authorized issuers, schema maintainers, revocation registries, validator sets, key rotation authorities, verifier sets, and dispute bodies. Each category has different issuance rules. Each must be registry-indexed. Each must be revocable or at least status-manageable. Each must be linked to audit records. Each must be understood by Smart Clause logic. ### Operational Credentials Operational Credentials are the most common credential type in NSF. They authorize bounded, task-level actions. They may allow a human to submit field evidence, a machine to sign sensor observations, a TEE node to execute a clause, a scheduler to dispatch jobs, an AI agent to use a tool, a public-safe reviewer to approve a redacted output, a Project SPV reviewer to access controlled evidence, or a regional node to participate in a rollup. Operational VCs are checked during clause execution, CAC signing, input submission, simulation submission, public-safe routing, credential issuance workflows, and orchestration. They should be short-lived where risk is high. They should include jurisdiction, role, permitted actions, prohibited actions, issuer, valid period, revocation method, and audit requirements. A safe operational credential schema may look like: ```json { "id": "DisasterReliefOperatorVC#0x7ad1", "type": ["VerifiableCredential", "OperationalCredential", "DisasterReliefOperatorVC"], "issuer": "did:nsf:org:HumanitarianEvidenceCredentialIssuer", "subject": "did:nsf:human:0x83e1", "valid_from": "2025-01-01", "expires": "2025-06-01", "jurisdiction": "PHL", "roles": ["FieldEvidenceSubmitter", "EarlyWarningSubscriber"], "allowed_actions": [ "submit-field-attestation", "receive-restricted-risk-briefing", "request-evidence-clause-execution" ], "prohibited_actions": [ "issue-official-public-warning", "approve-relief-disbursement", "execute-financial-transfer" ], "revocation_registry": "CredentialStatusRegistry::PHL::DisasterOps@1.0", "audit_policy": "material-actions-must-reference-CAC" } ``` The seed uses WFP as issuer. Unless WFP has formally issued the credential, examples should avoid using WFP directly. A credential may be `WFPReferenced` or `HumanitarianEvidenceCredentialIssuer` where the system maps to humanitarian workflows without implying official WFP issuance. Operational credentials may be linked to CAC execution history. A credential can be issued based on training CACs, renewed based on competence CACs, suspended after misuse CACs, or restricted after jurisdictional review. This makes operations auditable. Operational Credentials grant action within scope. They do not grant public authority. ### Operational Credential Subtypes NSF should support operational subtypes because different actions require different safeguards. A **FieldOperatorVC** authorizes a person to submit field observations or mobile attestations. A **SensorProviderVC** authorizes a device or provider to submit sensor data. A **TEEExecutorVC** authorizes a machine node to execute Smart Clauses under a defined runtime profile. A **SchedulerOperatorVC** authorizes orchestration services to dispatch jobs. A **RollupCoordinatorVC** authorizes rollup generation within scope. A **PublicSafeReviewerVC** authorizes review of public-facing outputs under public-safe policy. A **AI-AgentToolUseVC** authorizes an AI agent to use specific tools under policy. A **EvidenceRoomAccessVC** authorizes controlled access to Project SPV or institutional evidence. A **EmergencyResponseWorkflowVC** authorizes time-limited participation in emergency evidence routing, not official emergency command unless issued by competent authority. Each subtype should define allowed actions, risk class, data class, valid period, issuer requirements, and revocation logic. Typed subcategories prevent operational credentials from becoming overly broad. ### Legal and Standing Credentials Legal or Standing Credentials bind a DID to an institutional, jurisdictional, treaty-aligned, contractual, or governance role. They may record that an organization is a party to a framework, that a representative may sign on behalf of an institution, that a Project SPV has a lawful entity record, that a public authority interface is recognized, that a national node has domestic standing, that a community steward body has local governance standing, or that an enterprise actor has a contractual role. These credentials must be handled with extreme claims discipline. NSF should not issue credentials that claim treaty participation, regulatory compliance, public authority status, export approval, tax compliance, or legal certification unless the issuer is competent and authorized to make that claim. Most NSF Legal or Standing Credentials should be framed as **standing records**, **role records**, **representation credentials**, **treaty-aligned evidence participation records**, **contractual role credentials**, or **jurisdictional mapping credentials**, not legal determinations. A safe legal or standing credential may look like: ```json { "id": "InstitutionalStandingVC#0x3ed1", "type": ["VerifiableCredential", "StandingCredential"], "issuer": "did:nsf:org:NationalNexusRegistry", "subject": "did:nsf:org:0x9991", "standing_type": "national-node-participant", "legal_basis_reference": "registry-record-or-authorizing-instrument", "jurisdiction": "FRA", "scope": "climate-risk-evidence-coordination", "authority_class": "evidence-coordination", "non_meaning": [ "not-regulatory-approval", "not-public-authority-delegation", "not-treaty-compliance-determination" ], "dispute_policy": "NationalRegistryDisputePolicy@2.0" } ``` The seed uses `TreatySignatoryVC` issued by `UNFCCC`. Unless official issuance exists, this should not be used as a generic example. A safer alternative is: ```json { "id": "ParisAgreementReferenceParticipationRecordVC#0x3ed1", "issuer": "did:nsf:org:ClimateEvidenceRegistry", "subject": "did:nsf:org:0x9991", "framework_reference": "ParisAgreement", "role": "evidence-reporting-participant", "binding_clause": "UNFCCCRef::EmissionTargetsEvidenceProfile@2.1.3", "jurisdiction": "FRA", "dispute_policy": "ClimateEvidenceRegistryDisputePolicy@2.0", "non_meaning": [ "not-UNFCCC-issued", "not-treaty-compliance-determination", "not-legal-enforcement" ] } ``` Legal or Standing Credentials may be harder to revoke than operational credentials because they may represent institutional status, legal relationships, or dispute-sensitive claims. They should support suspension, dispute, supersession, correction, and revocation according to issuer authority and applicable law. These credentials grant standing within scope. They do not automatically grant execution authority. ### Simulation Credentials Simulation Credentials govern the modeling and forecasting stack. They identify which models, simulation bundles, simulation runners, datasets, reviewers, validation records, and outputs are trusted for specific clause contexts. Simulation VCs are essential because embedded simulations influence clause behavior. A clause that relies on a flood model, crop forecast, public health forecast, emissions model, climate scenario, AI risk evaluator, financial stress model, or digital twin must know whether the model is active, validated for scope, reviewed, versioned, and linked to a registered simulation bundle. Simulation Credentials may include several subtypes. A **ForecastModelVC** identifies a model and its allowed use scope. A **SimulationBundleVC** identifies a packaged model, parameters, datasets, runtime, and validation record. A **SimulationRunnerVC** authorizes a node or service to run simulations. A **SimulationValidatorVC** authorizes a reviewer or review body to validate model outputs. A **SimulationRunProofVC** records that a specific run occurred under defined conditions. A **ModelStatusVC** records whether a model is active, restricted, deprecated, quarantined, or retired. A **DatasetLineageVC** records data provenance for simulation inputs. A simulation credential may include model ID, model version, domain, jurisdictional scope, intended use, prohibited use, input schema, output schema, validation record, uncertainty method, dataset lineage, runtime profile, reviewer signatures, CAC references, ZK proof or TEE attestation, and drift monitoring requirements. A mature simulation credential may look like: ```json { "id": "ForecastModelVC#0x551a", "type": ["VerifiableCredential", "SimulationCredential", "ForecastModelVC"], "issuer": "did:nsf:org:SimulationRegistry", "subject": "did:nsf:artifact:FloodRiskSim-3-2", "model_id": "FloodRiskSim@3.2", "domain": "flood-risk", "jurisdiction_scope": ["regional-corridor", "specified-basins"], "status": "ACTIVE_LIMITED", "intended_use": ["evidence-support", "dynamic-threshold-support"], "prohibited_use": [ "official-public-warning-by-itself", "insurance-underwriting-by-itself", "legal-liability-determination" ], "input_schema_hash": "0x...", "output_schema_hash": "0x...", "dataset_lineage": ["DatasetLineageVC#0x..."], "validation_record": "SimulationValidationRecord#0x...", "uncertainty_policy": "UncertaintyProfile@1.0", "expires": "2025-12-31" } ``` Simulation Credentials do not “certify” model truth. They record model identity, review state, scope, and permitted use. The seed says Simulation VCs “certify forecasting models.” Safer language is **validate**, **recognize**, **status-label**, or **register for use under scope**, unless a formal certification scheme exists. Simulation Credentials make model trust machine-readable. ### Credential Governance Credentials (Meta-Credentials) Credential Governance Credentials, or meta-credentials, govern the trustworthiness of the credentialing system itself. They answer questions such as: who may issue a given credential type; which schema is active; which registry is authoritative for status; which key may sign issuer actions; which verifier set is recognized; which dispute body may review; which revocation registry is valid; which schema version supersedes another; which credential issuer is suspended; which public-safe reviewer is authorized. Without meta-credentials, decentralized credential networks fragment quickly. Anyone can create a credential that looks official. Issuers can overreach. Revocation registries can fork. Key rotations can be disputed. Schema versions can conflict. AI agents can accept credentials from unrecognized issuers. Cross-jurisdictional verification becomes unsafe. A meta-credential may look like: ```json { "id": "CredentialIssuerVC#0x991f", "type": ["VerifiableCredential", "CredentialGovernanceCredential", "CredentialIssuerVC"], "issuer": "did:nsf:org:CredentialGovernanceRegistry", "subject": "did:nsf:org:0x7a9c", "authorized_credential_types": [ "DisasterReliefOperatorVC", "ForecastModelVC" ], "jurisdiction_scope": ["KEN", "UGA", "TZA"], "authority_class": "issuer-recognition", "audit_interval": "P90D", "revocable_by": "did:nsf:org:CredentialGovernanceRegistry", "status_registry": "CredentialStatusRegistry::RegionalDisasterOps@1.0", "non_meaning": [ "not-public-authority-status", "not-professional-license", "not-regulatory-certification" ] } ``` The seed uses `GCRI-CentralDAO` and `UNDRR-GovDAO`. A safer approach is to use named registry or governance bodies without implying UNDRR governance unless authorized. For Nexus drafting, GCRI may be referenced as a public-good evidence steward, but the credential governance function should be role-separated and claims-safe. Meta-credentials can authorize root key rotation, schema publication, revocation registry operation, validator set membership, simulation auditor status, credential issuer recognition, public-safe reviewer recognition, and dispute panel membership. These credentials are the trust fabric of the credential layer. ### Additional NSF Credential Types Beyond the four major classes, NSF should support additional typed credentials. **Node Credentials** authorize machines, TEEs, secure runtimes, schedulers, rollup builders, attestation verifiers, and registries. These credentials must be bound to attestation, runtime profile, jurisdiction, workload scope, and revocation. **Public-Safe Credentials** authorize actors or systems to review, approve, publish, redact, translate, or correct public-facing outputs. They should include public-safe training, jurisdiction, domain, and prohibited claim rules. **Community Stewardship Credentials** authorize community or Indigenous data stewards, protected knowledge reviewers, local public-safe reviewers, grievance facilitators, and community registry maintainers. These must respect collective governance and disclosure rules. **Project SPV Evidence Credentials** authorize evidence submission, controlled-room access, asset telemetry validation, safeguard review, climate simulation review, and readiness evidence handling for lawful project workflows. **AI Agent Credentials** authorize agent identity, tool use, data access, memory scope, model status, public-safe drafting, simulation calling, and controlled evidence interaction. **Emergency Credentials** grant time-limited roles during emergencies. They should be strictly scoped, audited, expiring, and subject to after-action review. **Registry Credentials** authorize registry publication, schema update, parameter publication, clause status change, fork recognition, and revocation list signing. These types can be implemented as top-level categories or profiles under Operational, Standing, Simulation, or Credential Governance credentials. ### VC Schema Compatibility and Signatures All NSF VCs should conform to W3C Verifiable Credential data model principles where appropriate, use DID-based subject and issuer fields, include schema references, define credential type, include valid period, support status checking, and be cryptographically signed. JSON-LD is useful for linked-data interoperability. CBOR or compact encodings may be useful for edge and ZK contexts. The canonicalization method must be specified. VCs may include CAC reference, simulation output hash, clause binding ID, parameter record, proof profile, revocation registry pointer, rollup inclusion proof, audit record, or public-safe policy reference. Signatures should be algorithm-agile. Ed25519 may be used for efficient signatures. ECDSA may be used in certain interoperability contexts. BLS12-381 may support aggregate or threshold verification. Post-quantum algorithms should be considered as standards mature. The credential must identify algorithm, key ID, issuer DID, signature scope, timestamp, and proof purpose. The seed says VCs may be signed with DAO or enclave key. Mature NSF language should distinguish issuer signatures from runtime signatures. A credential should be signed by an authorized issuer DID. A CAC may be signed by an enclave or node DID. A credential can reference an enclave-signed CAC as evidence, but the enclave does not automatically become the credential issuer unless the schema authorizes machine issuance. This prevents runtime keys from becoming issuer authority by accident. ### Validity, Revocation, and Overlap Handling Every NSF VC must specify validity and status. At minimum, it should include `valid_from`, `expires`, credential status method, revocation authority, suspension authority, reissuance policy, and dispute policy. Some credentials may also include renewal requirements, training requirements, CAC triggers, audit intervals, key rotation conditions, and emergency expiration. Revocation should be precise. Credential states may include active, expired, suspended, revoked, under review, disputed, restricted, superseded, not recognized, inactive, or provisional. Revoked should not be used when under review is more appropriate. Suspension may be temporary. Restriction may narrow scope. Supersession may replace an old schema. NSF may use sparse Merkle proofs, status lists, accumulators, CRLs, registry status endpoints, or ZK status proofs. The status mechanism should match privacy and scale requirements. Overlapping credentials require precedence rules. A human may hold both FieldOperatorVC and PublicSafeReviewerVC. An organization may hold an issuer credential in one domain and a reviewer credential in another. A machine may hold TEEExecutorVC and RollupCoordinatorVC. Conflicts must be resolved by policy: more specific scope may override general scope; emergency credentials may override ordinary roles only within time and jurisdiction; revoked credentials override active claims; restricted credentials narrow actions; jurisdictional rules may override regional recognition. Smart Clauses should not simply check whether any credential exists. They should check the required credential type, issuer, scope, status, and precedence. Credential lifecycle logic makes zero-trust authorization possible. ### VC Lifecycle Hooks Typed VCs should support lifecycle hooks. These are predefined events and clause connections that update credential state. An issuance hook links credential issuance to a CAC, governance decision, issuer review, or manual authority record. A renewal hook defines what evidence is required for renewal, such as training CAC, simulation review, node re-attestation, or audit completion. A suspension hook defines what events can trigger temporary restriction, such as invalid CAC, key compromise, public-safe violation, node failure, credential misuse, or dispute filing. A revocation hook defines who may revoke, under what evidence, and through which process. A restoration hook defines what correction, training, revalidation, or governance review is required to restore status. A supersession hook defines how schema upgrades or role changes affect old credentials. A dispute hook defines how challenges are filed, reviewed, and resolved. Lifecycle hooks should be registered with credential schemas and tested. They prevent credentials from becoming static and stale. ### Registry and Audit Layer Integration All NSF credentials should be registered or resolvable through the Credential Registry, subject to privacy policy. The registry may store full credentials, encrypted credentials, status records, commitments, indexes, or pointers depending on classification. Credentials should be indexed by type, issuer, subject DID or commitment, jurisdiction, valid period, status, schema, clause, CAC reference, simulation link, role, authority class, and audit record. Sensitive indexes should be protected. The Audit Layer links credential activity to CACs, clause executions, governance decisions, revocation records, key rotations, disputes, public-safe outputs, and rollups. Credential actions should leave records: issued, presented, verified, used in clause, suspended, revoked, restored, renewed, disputed, superseded. Queries might include: `Show all active DisasterReliefOperatorVCs in jurisdiction = COL issued by recognized humanitarian evidence issuers.` `List all ForecastModelVCs active for flood-risk clauses in 2025-Q2.` `Find all credentials affected by CACs from node did:nsf:tee-node:27 after its suspension.` `Show all ProjectReadinessEvidenceVCs linked to ProjectSPV-42, excluding disputed CACs.` The seed’s query names `RedCross-LatAm`; such examples should be used only if the entity is actually participating. Otherwise, use neutral identifiers like `RegionalHumanitarianCredentialIssuer`. Registry and audit integration makes credentials discoverable, verifiable, and correctable. ### Cross-Jurisdictional Credential Recognition Typed VCs support cross-jurisdictional interoperability, but not automatic universal recognition. A credential issued in one jurisdiction may be accepted in another only if recognition rules allow it. Recognition may be full, partial, advisory, conditional, time-limited, emergency-only, evidence-only, public-safe-only, or not recognized. Recognition metadata should include recognizing authority or registry, credential type, issuer, subject class, jurisdiction, purpose, conditions, expiration, revocation propagation, and dispute path. For example, a DisasterOperatorVC issued in one country may allow participation in a regional evidence review but not field deployment in another country. A SimulationValidatorVC may be recognized for model review but not credential issuance. A Project SPV reviewer credential may be recognized only inside one evidence room. An AI agent credential may be recognized only by a specific orchestration layer. Typed credentials make these recognition distinctions machine-readable. ### Typed VCs for AI Agents and Machines AI agents and machines require typed credentials because they can act rapidly and at scale. A generic machine credential is not enough. An AI-AgentToolUseVC should define agent DID, model version, operator, allowed tools, prohibited tools, data classes, memory policy, human review conditions, public-safe restrictions, valid period, and revocation triggers. An AI agent may need different credentials for document retrieval, simulation calling, clause execution request, public-safe drafting, or controlled evidence access. A TEEExecutorVC should define node DID, runtime profile, attestation method, jurisdiction, workload classes, allowed clause domains, data classes, key usage, and revocation triggers. A SensorProviderVC should define device or provider DID, measurement class, calibration status, location scope, timestamp policy, signature method, and data quality rules. Machine credentials must be short-lived or frequently revalidated where risk is high. They should be linked to attestation and audit records. Typed machine VCs make automated infrastructure governable. ### Typed VCs for Project SPVs and Capital-Relevant Evidence Project SPV workflows require typed credentials for evidence without regulated overclaim. A ProjectSPVEvidenceRoomVC may authorize a controlled environment to host evidence. An AssetOperatorEvidenceVC may identify an operator’s role in providing telemetry. A ClimateScenarioReviewerVC may identify a reviewer for climate stress evidence. A SafeguardEvidenceReviewerVC may authorize safeguard evidence review. A FinanceReadinessEvidenceVC may record evidence completeness. An InsuranceReadinessEvidenceVC may record exposure and monitoring evidence readiness. Each must carry boundary language. FinanceReadinessEvidenceVC must not mean finance approval, investment advice, credit rating, or guarantee. InsuranceReadinessEvidenceVC must not mean underwriting, coverage, claim determination, pricing, or insurability. Typed VCs let Project SPV ecosystems share evidence without collapsing into regulated decisions. ### VC Boundary Statement Typed Verifiable Credentials support operational authorization, standing records, simulation trust, issuer governance, node identity, AI agent control, public-safe review, community stewardship, Project SPV evidence, finance-readiness evidence, insurance-readiness evidence, cross-jurisdictional recognition checks, and auditability. They do not by themselves create public authority, professional licensing, regulatory approval, certification, procurement approval, finance approval, investment advice, insurance underwriting, claims determination, official public warning status, treaty compliance, legal liability, or universal recognition. A VC is a signed claim under a schema by an issuer about a subject. Its authority depends on issuer authority, schema governance, jurisdiction, recognition rules, credential status, CAC evidence, applicable law, contracts, community rules, and institutional adoption. An Operational VC is not public authority. A Legal or Standing VC is not legal determination unless issued by a competent authority. A Simulation VC is not proof of model truth. A Credential Governance VC is not universal issuer authority. A FinanceReadinessEvidenceVC is not finance approval. An InsuranceReadinessEvidenceVC is not underwriting. A cross-jurisdictional VC is not automatically recognized everywhere. This boundary must appear in credential schemas, registry records, wallets, verifier tools, Smart Clause authorization logic, audit dashboards, agent policies, and public documentation. ### Typed VCs as the Nervous System of NSF Trust Typed Verifiable Credentials are the nervous system of NSF trust because they allow the framework to distinguish who can do what, where, when, under which authority, with which evidence, and subject to which revocation path. Operational VCs grant bounded action. Standing VCs record bounded institutional role. Simulation VCs establish model and run trust under scope. Credential Governance VCs protect the credentialing infrastructure itself. Node VCs make machines accountable. Public-Safe VCs protect communication. Community VCs protect local authority and knowledge. AI Agent VCs bound automation. Project SPV VCs make evidence workflows reviewable. Registry and Audit integration make all of them traceable. Together, typed credentials allow human, machine, and institutional agents to operate safely, execute predictably, audit trust lines, and scale governance across jurisdictions without reducing authority to a signature, a platform account, or a generic badge. That is the role of VC typing in the Nexus Sovereignty Framework: to transform credentials from static claims into precise, bounded, revocable, interoperable, and CAC-linked instruments of verifiable 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/v.-verifiable-credentials/vc-types-operational-legal-simulation-credentialal.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.