> 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/iv.-verifiable-execution/cac-linking-with-verifiable-credentials-vcs-and-audit-trails.md). # CAC Linking with Verifiable Credentials (VCs) and Audit Trails ## CAC-to-Credential and Audit Linkage in the Nexus Sovereignty Framework: Evidence-Bound Credentials, Hash-Linked Provenance, Credential Lifecycle Traceability, Audit Indexing, Dispute Replay, and Verifiable Institutional Action ### Why CACs Must Link to Credentials and Audit Systems In the Nexus Sovereignty Framework, clause execution is not an isolated technical event. A Smart Clause may support credential issuance, credential renewal, credential suspension, credential revocation review, public-safe routing, simulation audit updates, Project SPV evidence status, AI agent tool authorization, disaster readiness records, finance-readiness evidence, insurance-readiness evidence, cross-jurisdictional recognition, or governance review. If these downstream effects are not explicitly linked to the Clause-Attested Compute record that produced them, the system becomes fragmented. Credentials become assertions without execution evidence. Audit logs become disconnected from institutional outcomes. Simulations become advisory traces without credential impact. Governance bodies lose the ability to verify why a credential changed. Users lose the ability to challenge or correct decisions. AI agents may treat credentials as valid without understanding the proof chain behind them. CAC-to-credential linkage solves this problem by making execution provenance a first-class part of credential state. A credential should not merely say “this person, institution, node, model, project, or agent has status X.” It should be able to show the governed execution or review record that supported that status. If a disaster response credential was issued, the credential should link to the CAC or governance record that verified eligibility. If an AI agent tool credential was suspended, the credential status should link to the CAC that recorded policy violation or unsafe state. If a Project SPV evidence credential was updated, the credential should link to the evidence clause and runtime proof. If a finance-readiness evidence profile changed, the profile should point to the underlying CACs without implying finance approval. If an insurance-readiness record changed, it should point to CACs without implying underwriting or coverage. This linkage is also essential for audit. A CAC without audit indexing is difficult to find. A credential without CAC references is difficult to trust. An audit trail without credential impact is difficult to interpret. A governance dispute without execution proof is difficult to resolve. NSF therefore treats CAC, Verifiable Credential, Registry, Audit, Governance, and Replay systems as linked components of one provenance architecture. The core doctrine is: **Every material credential state or governance status produced by Smart Clause execution should be linked to the CAC, clause hash, input commitments, runtime proof, jurisdiction, and audit record that support it. Credential authority must be evidence-bound, replayable, and correctionable.** ### CACs, Credentials, and the Difference Between Evidence and Authority A CAC-linked credential is stronger than an ordinary credential because it contains verifiable execution provenance. But it still must not overclaim. The CAC proves that a clause executed under defined conditions. The credential records a claim, status, entitlement, role, or evidence state issued by a credential issuer. The authority of the credential depends on the issuer, schema, governance scope, jurisdiction, recognition rules, and applicable law. CAC linkage strengthens provenance. It does not automatically create legal authority, licensing, certification, public approval, regulatory compliance, finance approval, insurance underwriting, procurement approval, treaty compliance, or professional status. For example, a `DroughtRiskEvidenceVC` linked to a CAC can show that soil moisture, simulation risk, and field evidence met an NSF evidence threshold. It does not mean a relief payment is approved unless an authorized program makes that decision. A `FoodSafetyEvidenceReviewVC` can show that a batch requires review under a threshold clause. It does not mean a legal violation occurred. A `ProjectReadinessEvidenceVC` can show that project evidence met a readiness profile. It does not mean the project is investable, financeable, insured, or approved. An `AIModelUseCredential` can show that a model passed specific governance checks. It does not guarantee model safety in all contexts. CAC linkage therefore supports **evidence-bound credentials**, not self-legitimating credentials. ### Linking CACs to Credential Issuance, Renewal, Suspension, and Revocation Review A Smart Clause may specify credential-related actions. These actions should be carefully typed. Instead of treating every output as direct issuance or revocation, NSF should distinguish between credential issuance, credential renewal, credential status annotation, credential suspension, credential revocation request, credential review routing, credential dispute marking, and credential revocation by issuer. A simplified clause may say: ```scl onSuccess: issue("CropReliefCredential") onFailure: revoke("AgExporterVC") ``` A mature NSF version should preserve boundary and due process: ```scl credentialEffects { on Success { requestIssue DroughtRiskEvidenceVC { subject: applicant.did evidence: currentCAC boundary: "evidence-support-not-relief-approval" issuer: AuthorizedEvidenceCredentialIssuer } } on Failure { markCredentialUnderReview AgExporterEvidenceVC { subject: exporter.did reason: "threshold-evidence-failed" evidence: currentCAC boundary: "not-legal-violation-not-export-ban" reviewRequired: true } } } ``` This preserves the causal link between clause execution and credential outcome while preventing overreach. A Smart Clause can generate the evidence required for credential action. The credential issuer remains responsible for issuance under its schema and authority. If a credential schema authorizes automatic suspension for machine safety, such as node compromise or AI agent tool misuse, the clause may suspend within that scope. Human, institutional, professional, financial, trade, or public authority credentials should generally require issuer review unless the lawful framework explicitly permits automatic action. Upon clause execution, the CAC is generated first or atomically with the credential event. The credential event references the CAC ID, CAC hash, Clause ID, Clause Hash, runtime proof, trigger metadata, jurisdiction, issuer, and credential action type. The resulting Verifiable Credential or credential status update is signed by the issuer and recorded in the Credential Layer. The Audit Layer indexes both CAC and credential event. This establishes a verifiable causal chain: clause execution produced evidence; evidence supported credential action; credential action was issued by a scoped issuer; audit records preserve the link. ### VC Schema Extension with CAC References NSF-compliant Verifiable Credentials should support evidence fields that reference CACs. This can be implemented through W3C Verifiable Credential evidence mechanisms, linked-data proofs, credential status extensions, or NSF-specific evidence profiles. A CAC-linked credential evidence section may look like: ```json { "evidence": [ { "type": "ClauseAttestedComputeEvidence", "cac_id": "cac-0xabc123", "cac_hash": "0xdeadbeef", "clause_id": "UNFCCCRef::Emissions::ThresholdEvidenceClause@1.0.0", "clause_hash": "0x...", "execution_hash": "0x...", "attestation_reference": "attestation-0xsign123", "jurisdiction": "IND", "runtime_profile": "TEE-SGX-Compatible@Node27", "authority_class": "evidence-support", "output_status": "THRESHOLD_EXCEEDED", "output_boundary": "not-regulatory-violation-not-penalty-determination", "audit_record": "audit-0x..." } ] } ``` This turns the credential into a provenance-bearing governance artifact. A verifier can inspect the CAC reference, validate the CAC hash, check clause identity, verify runtime proof, confirm jurisdictional scope, inspect output meaning, and follow the audit record. The schema should support multiple CAC references. A credential may be based on several executions: identity check, training check, simulation check, public-safe review, jurisdictional recognition, and renewal. The credential evidence field should identify whether each CAC is required, supporting, superseded, disputed, corrected, or historical. The credential should also include proof scope. For sensitive CACs, the VC may include only commitments or ZK proof references. The raw CAC may remain in a controlled room, SDZ, or enterprise evidence room. A CAC-linked VC is therefore not just an identity token. It is a verifiable governance record. ### CAC-Chained Credential Lifecycle Management Credentials have lifecycles. They are issued, renewed, expanded, restricted, suspended, restored, disputed, revoked, superseded, or expired. In NSF, these lifecycle events should be linked to CACs or governance records. The result is a credential provenance tree. For example, a `DisasterReliefOperatorVC` may be issued after a training eligibility clause produces CAC-1. It may be renewed after a continuing competence clause produces CAC-2. It may be restricted after an incident review clause produces CAC-3. It may be restored after a corrective training clause produces CAC-4. It may be revoked by the issuer after a governance review record and supporting CAC-5. Each step is linked. The credential’s lifecycle tree may include: Initial issuance CAC. Issuer signature. Training evidence CACs. Role-scope updates. Jurisdictional recognition records. Suspension CACs or review records. Dispute filings. Correction records. Revocation records. Restoration CACs. Supersession links. Expiration and renewal records. This lifecycle tree should be hash-linked. Each status change references prior status, supporting CACs, issuer action, timestamp, jurisdiction, and audit record. Historical states remain preserved. The current state is a pointer to the latest valid status. Correction does not erase history; it supersedes or annotates it. This is especially important for cross-jurisdictional credentials. If a credential was valid in one jurisdiction but not recognized in another, the lifecycle tree should show recognition scope. If a credential was suspended due to a disputed CAC, the tree should show dispute status. If a CAC was later invalidated, dependent credential states should be flagged for review. Credential lifecycle management becomes verifiable institutional memory. ### Credential Status Lists and CAC-Backed Status Updates Credential status must be machine-readable. NSF can support revocation lists, status lists, status registries, bitstring status lists, accumulator-based status, ZK status proofs, and registry-based status endpoints. Whatever method is used, status changes should be linked to CACs where the status was clause-supported. A status update should include credential ID or commitment, status type, previous status, new status, reason code, issuer signature, supporting CAC ID, supporting CAC hash, audit record, jurisdiction, effective time, and review path. Status types should be precise. “Revoked” is different from “suspended,” “expired,” “under review,” “restricted,” “disputed,” “not recognized,” “superseded,” or “inactive.” A CAC may support “under review” rather than revocation. This protects fairness and due process. For privacy-preserving credentials, status checks may use accumulators or ZK proofs. A verifier may learn that a credential is active without seeing the full lifecycle tree. Authorized reviewers may access more detail. CAC-backed status updates ensure that credential changes are not arbitrary. ### Audit Trail Design and CAC Indexing The Audit Layer must index CACs and credential events together. It should not merely store CACs in chronological order. It should allow retrieval by clause, credential, subject, issuer, jurisdiction, execution time, trigger source, simulation model, node, tenant, public-safe output, Project SPV, failure class, dispute status, and governance body. A credential query might ask: `Find all CACs affecting OperatorCredential#0x938 between 2025-01-01 and 2025-03-31.` Another might ask: `Verify credential lineage for FoodSafetyInspectorVC@1.4 for jurisdiction KEN.` Another might ask: `Show all CACs supporting ProjectReadinessEvidenceVC for ProjectSPV-42, excluding disputed CACs.` Another might ask: `List all credentials affected by SimulationModel::FloodRiskSim@3.2 after model quarantine.` These queries are essential for governance review. If a clause is corrected, affected credentials can be found. If a node is compromised, credentials relying on its CACs can be identified. If a public-safe output was wrong, credentials linked to the output can be reviewed. If a credential issuer is suspended, CAC-linked credentials can be flagged. Audit indexing should support access control. A public verifier may see limited proof. An issuer may see credential-relevant details. A national node may see domestic records. A controlled-room reviewer may see restricted evidence. A community steward may see community-governed records. A Project SPV reviewer may see enterprise evidence. A good audit system makes provenance queryable without making sensitive data public. ### Cross-Governance and Jurisdictional Traceability CAC-to-VC linkage must work across governance systems. The seed refers to cross-DAO traceability across WHO, ICAO, WFP, jurisdictions, treaty zones, and NGO zones. This should be reframed carefully. NSF can support interoperability with public authority systems, treaty-aligned frameworks, sectoral bodies, humanitarian actors, and institutional registries where authorized. It should not imply that WHO, ICAO, WFP, FATF, or other bodies are default NSF DAOs or that they have adopted NSF credentials unless that is true. The safer architecture is: CAC-to-VC links are interoperable across national nodes, regional consortia, community governance bodies, public authority interfaces where authorized, treaty-aligned evidence frameworks, humanitarian evidence systems, credential issuers, enterprise evidence rooms, and public-good registries. A credential issued in one system may be auditable by another if recognition rules allow it. The verifier can inspect proof of issuance, proof of execution logic, proof of jurisdictional scope, proof of issuer status, proof of credential schema, and proof of governance approval where applicable. Cross-jurisdictional traceability does not mean universal recognition. A credential valid in one jurisdiction may be advisory in another, not recognized in another, or require additional review. CAC linkage makes those differences visible. This is critical for mobility, supply chains, disaster coordination, public health, AI governance, professional roles, Project SPV evidence, and regional risk systems. Interoperability requires traceability. It does not erase sovereignty. ### Hash Linking, Anchoring, and Inclusion Proofs CAC-linked credentials should include hash links. If a CAC belongs to a CAC Rollup, the credential may include a rollup inclusion proof. This allows a verifier to confirm that the CAC was included in a recognized rollup without loading all CACs. A credential evidence field may include: CAC ID and CAC hash. CAC Rollup ID and root hash. Merkle inclusion proof. Audit record reference. External anchor reference. Clause lineage proof. Credential lifecycle previous status hash. Issuer signature. ZK proof or selective disclosure proof where needed. Anchoring may occur in the Audit Layer, national archive, regional registry, enterprise evidence room, community registry, or public chain. Public chains such as Ethereum-like systems, Filecoin-like systems, or Arweave-like systems may be used for commitments, but sensitive credential payloads and personal data should not be placed on public immutable ledgers. Inclusion proofs support cross-chain or cross-registry migration. A credential moving from one registry to another can carry proof of its CAC lineage. A sovereign archive can preserve CAC roots even if external systems change. A long-term verifier can validate historical credential state using archived root commitments. Hash linking provides durability and integrity. It does not by itself create legal recognition. ### CAC-Linked Dispute and Review Framework Credential disputes should trace to CACs. If a user, institution, issuer, verifier, community steward, national node, or enterprise actor challenges a credential action, the dispute process should load the associated CACs and audit records. A dispute review may verify: The clause identity and hash. The input bindings. The credential state at execution. The issuer authority. The runtime attestation. The jurisdictional scope. The simulation model and output. The trigger metadata. The output meaning. The safe-mode state. The public-safe boundary. The credential schema rule. The issuer decision. The CAC rollup inclusion proof. The dispute body or credential issuer may uphold the status, correct it, reissue the credential, restore the credential, restrict recognition, request resimulation, require additional evidence, mark CAC disputed, suspend reliance, or escalate to competent authority. The seed says a DAO votes to override, reissue, or escalate. In mature NSF language, this becomes: **the credential issuer, governance review body, national node, community steward body, enterprise evidence governance function, or authorized dispute process reviews and issues a signed decision**. DAO voting may be one possible workflow, not the authority source. Every dispute step should be logged, traceable, and auditable. Historical CACs should not be deleted. Corrections should supersede or annotate. If a credential was wrongly suspended, restoration should link to the dispute resolution record. CAC-linked disputes make correction possible. ### Credential-Aware Agents and Copilots NSF agents and user-side copilots must be credential-aware. They should not treat credentials as static badges. They should inspect credential status, CAC evidence, jurisdictional recognition, issuer status, dispute status, expiry, public-safe constraints, and audit lineage. A credential-aware agent may query CACs linked to a VC, verify CAC hashes, check rollup inclusion, replay clause execution where authorized, verify simulation model used, detect expired or disputed CAC links, fetch jurisdictional override status, check credential schema version, and determine whether a credential is recognized for a specific action. This is essential in supply chains, legal workflows, mobility governance, public health, disaster coordination, AI agent tool access, Project SPV evidence rooms, finance-readiness workflows, and insurance-readiness workflows. For example, an AI agent supporting a supply-chain review should not simply see `FoodSafetyInspectorVC` and accept it. It should verify that the credential is active, issuer is recognized, jurisdiction matches, CAC evidence is valid, no dispute is pending, and the requested action falls within scope. An agent supporting finance-readiness evidence should verify CAC-linked credentials for project reviewers, data providers, model reviewers, and evidence packages, while avoiding investment advice or finance approval claims. Credential-aware agents make trust machine-readable. ### CAC-Linked Credentials for AI Agent Governance AI agents themselves may hold credentials. An agent may have an AgentIdentityVC, ToolUseVC, ModelAccessVC, EvidenceRoomAccessVC, PublicSafeDraftingVC, or SimulationRunnerVC. These credentials should be CAC-linked. If an agent receives access to a tool, the credential should reference the CAC that checked model status, user authority, data class, tool scope, public-safe status, and runtime policy. If an agent violates policy, a CAC should support suspension or review. If an agent is upgraded or model version changes, new CACs should update credential status. This allows AI agent authority to be dynamic and auditable. It prevents agents from carrying stale permissions. It also allows human reviewers to inspect why an agent was allowed or blocked. CAC-linked agent credentials are a core safeguard for autonomous governance systems. ### CAC-Linked Credentials for Project SPVs and Capital-Relevant Evidence Project SPVs may use credentials for project status, evidence completeness, data provider authority, asset operator role, maintenance verification, climate simulation review, safeguard review, public-safe publication, and controlled-room access. Each credential should link to CAC evidence where clause execution supported the status. A ProjectReadinessEvidenceVC may link to CACs for asset registry validation, maintenance evidence, climate stress simulation, safeguard evidence, operator credential check, and public-safe summary. A FinanceReadinessEvidenceVC may link to controlled evidence CACs showing completeness and scenario review, while stating clearly that it is not finance approval, investment advice, guarantee, or rating. An InsuranceReadinessEvidenceVC may link to hazard model CACs, exposure evidence, monitoring data, and basis risk review, while stating clearly that it is not underwriting, coverage, claims determination, pricing, or insurability. CAC linkage makes Project SPV evidence more reviewable without exposing all confidential data. It also allows corrections. If an asset telemetry CAC is disputed, dependent readiness credentials can be flagged. This is how capital-relevant evidence becomes proof-bound while staying legally disciplined. ### CAC-Linked Credentials Across GNC, RNC, and NNC Architecture CAC-to-credential linkage operates across the Nexus multiscale architecture. At the national level, National Nexus Consortiums may issue or support domestic credentials linked to national CACs: national node credentials, public-safe reviewer credentials, disaster coordination credentials, Project SPV evidence credentials, national data provider credentials, AI agent credentials, and national registry credentials. National CACs preserve domestic jurisdiction and SDZ controls. At the regional level, Regional Nexus Consortiums may support regional recognition credentials, corridor evidence credentials, regional simulation reviewer credentials, regional public-safe output credentials, and mutual recognition records. Regional credentials should link to national CACs or commitments without centralizing raw data. At the global level, the Global Nexus Consortium may maintain reference credential schemas, CAC evidence profiles, interoperability mappings, proof receipt formats, and cross-registry verification tools. It should not centralize all credential payloads or override national authority. At the community level, community and Indigenous governance bodies may issue or govern credentials for local stewards, protected knowledge review, public-safe map clearance, grievance participation, and community data access. CAC links must respect community disclosure rules. At the enterprise layer, National Consortium Companies, Project SPVs, providers, operators, insurers, investors, contractors, and evidence rooms may use CAC-linked credentials for lawful implementation and controlled evidence workflows. These credentials remain scoped and do not imply public-good endorsement, public authority status, finance approval, or insurance underwriting. This architecture gives credentials provenance without flattening institutional authority. ### CAC-to-VC Privacy and Selective Disclosure Credentials often involve personal, institutional, financial, health, security, or community-sensitive information. Linking them to CACs must not expose sensitive data. CAC references should support selective disclosure. A verifier may need proof that a credential was issued based on a valid CAC, not the full CAC content. A public verifier may see the CAC hash and schema. An issuer may see full credential evidence. A national authority may access domestic records under law. A community steward may control protected knowledge fields. A Project SPV reviewer may access controlled evidence room references. A ZK verifier may see only proof that required conditions were satisfied. Privacy-preserving linkage may use hash commitments, ZK proofs, encrypted CAC references, blinded credential identifiers, accumulator-based status, selective disclosure credentials, pairwise DIDs, and controlled-room access. A CAC-linked credential should never place sensitive CAC payloads on public ledgers. Public anchors should be commitments only. Verifiable credentials must be privacy-preserving to be trustworthy. ### CAC-to-VC Boundary Statement CAC-to-credential linkage supports evidence-bound credential issuance, renewal, suspension, revocation review, status updates, lifecycle provenance, audit indexing, dispute replay, cross-jurisdictional recognition checks, agent reasoning, Project SPV evidence, finance-readiness evidence, insurance-readiness evidence, and institutional accountability. It does not by itself create public authority, professional licensing, regulatory approval, certification, procurement approval, finance approval, investment advice, insurance underwriting, claims determination, official public warnings, treaty compliance, legal liability determination, or universal credential recognition. A CAC-linked credential proves that a credential claim or status is supported by declared execution evidence under a defined proof scope. Its authority depends on issuer authority, schema governance, jurisdiction, recognition rules, applicable law, and credential purpose. A CAC reference is not legal approval. A credential evidence field is not certification. A revocation request is not professional license revocation. A finance-readiness credential is not finance approval. An insurance-readiness credential is not underwriting. A cross-jurisdictional credential is not universally recognized. A public-safe credential is not official public authority status. This boundary must be embedded in VC schemas, credential wallets, verifier tools, registries, audit dashboards, agent policies, and public documentation. ### Linked CACs as Verifiable Institutions in Action CAC-to-VC-to-Audit linkage turns governance into inspectable institutional action. It allows a system to show not only that a credential exists, but why it exists. Not only that a credential changed, but which clause, input, simulation, runtime, trigger, issuer, jurisdiction, and governance record supported the change. Not only that an audit trail exists, but how it connects to real institutional outcomes. With this linkage: Governance becomes inspectable. Credentials become evidence-bound. Policies become traceable. Credential lifecycles become replayable. Institutions become accountable. AI agents become credential-aware. Project SPV evidence becomes reviewable. Finance-readiness and insurance-readiness evidence becomes proof-supported without becoming regulated approval. Disputes become reconstructable. Corrections become possible. CACs are not ordinary logs. They are proof-bound execution records. Credentials are not merely identity tokens. They are claims whose legitimacy depends on issuer authority and evidence provenance. Audit trails are not archive clutter. They are the memory of institutional action. Together, CACs, VCs, Audit records, Registry state, Governance review, and Replay tools form the civic verification fabric of NSF. They allow institutions, agents, communities, jurisdictions, and enterprise actors to coordinate through evidence rather than assertion. That is the role of CAC-to-Credential and Audit linkage in the Nexus Sovereignty Framework: to make every material credentialed outcome traceable to the governed computation, proof, jurisdiction, and institutional record that supported it. --- # 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/iv.-verifiable-execution/cac-linking-with-verifiable-credentials-vcs-and-audit-trails.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.