> 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-dependency-trees-and-lifecycle-hooks.md). # VC Dependency Trees and Lifecycle Hooks ## VC Dependency Trees and Lifecycle Hooks in the Nexus Sovereignty Framework: Credential Preconditions, Cascading Status Logic, Event-Driven Trust, Dependency-Aware Revocation, ZK-Compatible Lifecycle Proofs, and Institutional Credential Memory ### Why VC Dependency Management Is Critical Verifiable Credentials in the Nexus Sovereignty Framework are not isolated trust objects. They often depend on other credentials, clause executions, simulation runs, issuer status, jurisdictional recognition, public-safe approvals, training records, machine attestations, model status, and governance events. A disaster response credential may depend on a training credential, a jurisdictional role credential, an emergency activation credential, a simulation run credential, and a public-safe communication credential. A TEEExecutorVC may depend on a node registration credential, runtime attestation credential, hardware profile credential, and revocation status root. A SimulationRunVC may depend on an active SimulationModelVC, DatasetLineageVC, SimulationRunnerVC, and SimulationValidatorVC. A ProjectReadinessEvidenceVC may depend on asset operator credentials, climate scenario review credentials, safeguard evidence credentials, controlled evidence room credentials, finance-readiness evidence credentials, and insurance-readiness evidence credentials. An AI-AgentToolUseVC may depend on AgentIdentityVC, ModelStatusVC, MemoryPolicyVC, DataAccessVC, HumanSupervisorVC, and PublicSafeDraftingVC. If these dependencies are not represented explicitly, credential systems become brittle. A downstream credential may remain active after its parent credential is revoked. A simulation run may remain usable after the model is quarantined. A public-safe review credential may remain active after training expires. A Project SPV evidence bundle may remain valid after the evidence room access credential is suspended. An AI agent may retain tool access after the model version changes. A disaster response credential may be accepted even though the underlying simulation is stale. A credential issuer may continue issuing credentials after its issuer credential is revoked. A cross-jurisdictional credential may be used after recognition is withdrawn. NSF solves this through **VC Dependency Trees** and **Lifecycle Hooks**. A dependency tree makes credential validity conditional on the status of upstream credentials, clauses, simulations, CACs, registries, and governance events. Lifecycle hooks define what happens when a credential is issued, used, renewed, escalated, suspended, revoked, superseded, expired, disputed, or when one of its dependencies fails. Together, they turn credentials from static documents into living institutional objects. The core doctrine is: **A credential is valid for material execution only when its own status and all required dependencies are valid within the declared scope, time, jurisdiction, clause binding, and governance context. Credential lifecycle events must be signed, auditable, dependency-aware, and correctionable.** ### Dependency Management Is Not Centralized Enforcement Dependency management should not be understood as a central authority controlling every credential. NSF dependency logic is distributed, registry-linked, and governance-scoped. A national credential registry may define domestic dependencies. A regional consortium may define cross-border recognition dependencies. A community steward body may define protected knowledge dependencies. An enterprise evidence room may define Project SPV evidence dependencies. A global reference function may define interoperability schemas and dependency formats. The dependency graph provides a machine-readable trust structure. It does not create authority by itself. Authority still comes from issuers, credentials, clause bindings, jurisdiction, institutional mandates, contracts, community rules, and applicable law. Dependency management makes those authority relationships visible and enforceable by runtimes, credential oracles, registries, and audit systems. This distinction protects NSF from over-centralization. Dependency management allows trust to propagate and fail predictably without creating a single global credential controller. ### VC Dependency Trees: Concept and Structure A VC Dependency Tree is a directed acyclic graph, or DAG, in which each node represents a credential or credential-like trust object, and each edge represents a “depends on” relationship. The validity of a root credential depends on the validity of one or more upstream credentials, proofs, CACs, simulations, or registry states. A simplified disaster credential dependency tree may look like: ``` DisasterResponseEvidenceVC -> TrainingCredentialVC -> JurisdictionalRoleVC -> SimulationRunVC -> SimulationModelVC -> DatasetLineageVC -> SimulationRunnerVC -> PublicSafeReviewerVC ``` This means that the DisasterResponseEvidenceVC should be accepted only if the holder completed required training, the jurisdictional role remains active, the simulation run is valid, the model used in the simulation is credentialed and active, the dataset lineage is acceptable, the simulation runner was authorized, and public-safe review requirements are satisfied where public outputs are involved. A dependency tree may be shallow or deep. Some operational credentials may depend only on identity and training. High-risk credentials may depend on many layers. The system should avoid unnecessary depth because deep chains increase failure risk and verification cost. But the chain must be deep enough to represent real authority. The DAG requirement prevents circular dependencies. A credential should not depend on itself, directly or indirectly. Circular dependency creates unverifiable trust. The Credential Registry should detect and reject circular graphs. Dependency trees make credential authority inspectable. ### Encoding Dependencies in Credential Metadata Dependencies should be encoded directly in credential metadata or referenced through registry-linked dependency profiles. A credential may list specific credential IDs, credential types, issuer requirements, clause hashes, CACs, simulation outputs, parameter records, status roots, or policy profiles. A simple dependency declaration may look like: ```json { "id": "DisasterResponseEvidenceVC#0x772e", "depends_on": [ { "type": "specific_vc", "vc_id": "TrainingCredentialVC#0x994c", "required": true }, { "type": "specific_vc", "vc_id": "SimulationRunVC#0x73af", "required": true } ] } ``` A more expressive dependency declaration may include credential type, issuer, jurisdiction, clause binding, status requirement, freshness window, and fallback rule: ```json { "dependency_profile": "DisasterResponseEvidenceDependencyProfile@1.0", "depends_on": [ { "dependency_id": "training", "credential_type": "TrainingCredentialVC", "issuer_set": "RecognizedDisasterTrainingIssuers@2025-Q2", "status_required": "ACTIVE", "jurisdiction": "matched-to-root", "required": true }, { "dependency_id": "simulation_run", "credential_type": "SimulationRunVC", "model_status_required": "ACTIVE", "freshness": "PT6H", "clause_binding": "FloodRiskSimulationEvidenceClause@3.*", "required": true }, { "dependency_id": "public_safe_review", "credential_type": "PublicSafeReviewerVC", "required_if": "output_class == public-facing", "status_required": "ACTIVE" } ] } ``` Dependencies can reference: Specific credential IDs. Credential types. Issuer sets. Credential bundles. Clause hashes. CAC IDs or CAC hashes. Simulation runs. Simulation model credentials. Dataset lineage records. Parameter records. Status roots. Jurisdictional recognition records. Community approval records. Enterprise evidence room records. Credential Oracles and clause runtimes resolve these dependencies at execution time. The Audit Layer records what was checked and which dependency state was used. Dependency metadata should be canonicalized and hash-linked so that dependency requirements cannot be silently changed after issuance. ### Types of Dependencies NSF should distinguish dependency types because not all dependencies behave the same way. A **required dependency** must be valid for the root credential to be valid. If it fails, the root credential fails or suspends. An **optional dependency** enhances trust or enables additional actions, but its failure does not invalidate the root credential entirely. A **conditional dependency** is required only when a condition is met, such as public-facing output, cross-border use, emergency escalation, AI tool access, or finance-readiness evidence routing. A **jurisdictional dependency** requires recognition or authorization in a specific jurisdiction. A credential may be active generally but not valid in the invoking jurisdiction. A **temporal dependency** requires that an upstream credential or simulation be valid within a defined time window. A **simulation dependency** requires that a model, run, dataset, or scenario credential remain active and fresh. A **CAC dependency** requires that a supporting CAC be valid, non-disputed, non-replayed, and within scope. A **issuer dependency** requires that the issuer’s own CredentialIssuerVC or meta-credential remain active. A **delegation dependency** requires that a parent delegation credential remain active for a child credential to be used. A **public-safe dependency** requires review, disclosure clearance, or public-safe credential before public output. A **community dependency** requires community steward approval, protected knowledge review, or local governance credential. A **enterprise dependency** requires an active evidence room, contract role, Project SPV record, or operator credential. A **machine dependency** requires active node attestation, runtime profile, or machine credential. A **negative dependency** blocks use if a specified condition exists, such as credential under dispute, model quarantined, public-safe restriction active, conflict-of-interest credential present, or jurisdictional prohibition. Each dependency should define failure effect: block, suspend, restrict, route to review, issue warning, mark historical-only, require renewal, or trigger safe mode. Dependency typing prevents a single upstream change from causing either too much or too little downstream effect. ### Lifecycle Hooks: Definition and Function Lifecycle Hooks are programmable events inside the credential lifecycle. They define what happens when a credential changes state or is used. They make credential systems event-driven and correctionable. A lifecycle hook may fire on issuance, presentation, use in a clause, renewal, expiry, dependency failure, revocation, suspension, restoration, escalation, delegation, fork compatibility change, issuer status change, simulation update, public-safe violation, dispute filing, rollup inclusion, or audit challenge. Lifecycle hooks can trigger registry updates, audit events, credential oracle checks, Smart Clause execution, notification, bundle status update, public-safe review, safe-mode activation, renewal workflow, dependency revalidation, or governance review. A lifecycle hook is not uncontrolled automation. It must be schema-bound, issuer-authorized, registry-recorded, and audit-linked. High-consequence effects should route to review unless automatic action is clearly authorized by the credential schema and governance policy. Lifecycle hooks make credentials responsive to change. ### Example Lifecycle Hook Configuration A basic lifecycle hook configuration may look like: ```json { "lifecycle_hooks": { "on_issue": ["log_to_registry", "create_audit_event"], "on_use": ["update_usage_counter", "create_disclosure_receipt"], "on_expiry": ["mark_expired", "notify_holder"], "on_dependency_fail": ["flag_for_review", "suspend_if_high_risk"] } } ``` A more mature configuration should include scope, authority, and boundaries: ```json { "lifecycle_hooks": { "on_issue": { "actions": ["log_to_registry", "link_supporting_cac", "emit_credential_issued_event"], "audit_required": true }, "on_use": { "actions": ["verify_dependency_tree", "record_usage_receipt"], "privacy_profile": "metadata-only", "rate_limit_policy": "CredentialUseRateLimit@1.0" }, "on_expiry": { "actions": ["mark_expired", "notify_holder", "notify_dependent_bundle_oracles"], "effect": "future-use-blocked" }, "on_dependency_fail": { "actions": ["mark_under_review", "notify_issuer", "emit_dependency_failure_notice"], "automatic_revocation": false, "safe_mode": "block-high-consequence-actions" }, "on_revocation": { "actions": ["propagate_to_dependents", "create_revocation_audit_record"], "historical_status": "preserved" }, "on_restoration": { "actions": ["verify_reinstatement_conditions", "emit_status_restored_event"], "requires_supporting_cac": true } } } ``` Lifecycle hooks may call Smart Clauses, Credential Oracles, registry functions, notification systems, and governance workflows. DAO workflows may be used where applicable, but the mature framing should include governance bodies, national nodes, community stewards, credential issuers, enterprise evidence authorities, and registry maintainers. Hooks are the event ports of the credential lifecycle. ### Issuance Hooks An issuance hook fires when a credential is created. It should record issuer DID, subject DID or commitment, credential type, schema, clause binding, supporting CAC, dependency tree hash, validity window, revocation method, and audit record. For high-consequence credentials, issuance should not occur unless required dependencies are already valid. A DisasterResponseEvidenceVC should not issue unless training and jurisdictional role credentials are active. A SimulationRunVC should not issue unless the SimulationModelVC and SimulationRunnerVC are active. A ProjectReadinessEvidenceVC should not issue unless required evidence credentials and CACs exist. An AI-AgentToolUseVC should not issue unless model status and tool policy credentials are active. Issuance hooks ensure credentials are born with traceable provenance. ### Use Hooks A use hook fires when a credential is presented or relied upon by a clause, runtime, agent, verifier, or registry. It can verify dependency state, create a disclosure receipt, update usage counters, check replay constraints, and log audit metadata. Use hooks are essential for detecting overuse, misuse, expired use, cross-jurisdictional misuse, AI agent overreach, and one-time-use violations. They also allow privacy-preserving usage logging. The audit record may store proof hash, credential type, clause ID, timestamp, jurisdiction, and outcome without storing full credential content. Use hooks make credential use visible without overexposure. ### Renewal and Expiry Hooks A renewal hook defines how a credential may be extended. Renewal may require a new CAC, training completion, re-attestation, model validation, public-safe review, issuer approval, or evidence refresh. A credential should not auto-renew merely because it exists. It must satisfy renewal rules. An expiry hook defines what happens when the validity window closes. It may mark the credential expired, notify the holder, notify dependent credentials, block future use, preserve historical validity, or trigger renewal workflow. Expiry should not be treated as misconduct. It is a normal lifecycle event. For simulation-dependent credentials, expiry may occur when the forecast window closes. For AI agent credentials, expiry may occur at session end. For Project SPV evidence credentials, expiry may occur at reporting period close or evidence freshness failure. For machine credentials, expiry may occur after attestation window closes. Renewal and expiry hooks protect against stale authority. ### Dependency Failure Hooks A dependency failure hook fires when an upstream dependency changes status or fails validation. If a ForecastModelVC is revoked, SimulationRunVCs depending on it may become under review. If a TrainingCredentialVC expires, operational credentials depending on it may suspend. If a CredentialIssuerVC is revoked, credentials issued by that issuer may require review. If a public-safe credential is suspended, publication workflows may be blocked. If a Project SPV evidence room credential is revoked, dependent readiness credentials may become restricted. If an AI ModelStatusVC is quarantined, agent tool credentials may suspend. The failure effect should be defined by policy. It may block execution, suspend credential, mark under review, restrict use, require renewal, notify governance, or preserve historical-only status. A dependency failure should not automatically erase dependent credentials. It should update reliance status and trigger review where appropriate. ### Cascading Revocation and Audit Propagation Cascading revocation is the process by which a status change in one credential affects dependent credentials. It is necessary but must be carefully bounded. If a SimulationModelVC is revoked, the system may identify all SimulationRunVCs that used it, all DisasterResponseEvidenceVCs that depended on those runs, all public-safe outputs informed by them, and all CAC Rollups containing related CACs. The system should not blindly declare every downstream credential invalid. It should apply dependency rules: block future use, mark under review, suspend high-consequence actions, require resimulation, or preserve historical status. A cascade event may look like: ```json { "event_type": "DependencyFailureNotice", "source_vc": "ForecastModelVC#0x33aa", "source_status": "SUSPENDED", "affected": { "SimulationRunVC": 11, "DisasterResponseEvidenceVC": 38, "PublicSafeOutputCredential": 4 }, "default_effect": "UNDER_REVIEW", "high_consequence_effect": "BLOCK_FUTURE_USE", "audit_record": "audit-0x..." } ``` All cascade events should be signed, logged in the Audit Layer, and queryable. Credential Oracles should emit dependency failure notices. Issuers and affected holders should be notified where policy permits. Reissuance or restoration pathways may be offered if clause-bound conditions can be satisfied. Cascading revocation makes trust correction scalable. ### Reissuance, Restoration, and Supersession Dependency failure should not always end in revocation. NSF should support reissuance, restoration, and supersession. **Reissuance** creates a new credential after required conditions are met. For example, a SimulationRunVC may be reissued after rerun with an updated model. **Restoration** returns a suspended credential to active status after review, correction, or new evidence. **Supersession** replaces an old credential with a new version while preserving historical linkage. This is useful when schemas change, clauses are forked, models are updated, or Project SPV evidence packages are refreshed. These events should link to supporting CACs and audit records. They should not erase the prior state. Correctionability requires pathways back to valid status. ### Visualizing and Querying Dependency Graphs Credential dependency graphs should be visible to authorized users through the Credential Registry and Audit Layer. Visualization helps auditors, issuers, AI agents, national nodes, community stewards, enterprise reviewers, and governance bodies understand how trust flows. A graph UI may show root credential, dependencies, status, issuer, validity window, jurisdiction, clause binding, CAC references, revocation state, and failure effects. It may display active paths, broken paths, optional paths, high-risk dependencies, and pending reviews. The system should support queries such as: `Find all active DisasterResponseEvidenceVCs dependent on SimulationRunVCs older than 90 days.` `Show all credentials dependent on ForecastModelVC#0x33aa.` `List credential bundles with unresolved dependencies in jurisdiction = KEN.` `Find all AI-AgentToolUseVCs dependent on ModelStatusVC = QUARANTINED.` `Show all ProjectReadinessEvidenceVCs dependent on expired AssetOperatorEvidenceVCs.` `Find circular or invalid dependency declarations in new credential schemas.` `List credentials whose issuer credential expires within 30 days.` Diagnostics should include dependency depth, number of affected policies, recency of validation, unresolved nodes, circularity, expired dependencies, missing issuers, high-risk concentration, and stale simulation dependencies. Dependency graph observability allows governance to manage systemic trust risk. ### Lifecycle Event Signing and ZK Compatibility All lifecycle and dependency events should be cryptographically signed. A dependency failure notice, revocation propagation event, renewal event, restoration event, escalation event, or usage event should identify signer DID, signing key, credential authority, timestamp, affected credentials, supporting evidence, and audit record. Lifecycle events should also support ZK compatibility. A holder may need to prove that a credential had no revoked dependencies without revealing the entire dependency tree. A ZK proof may state: the root credential is active; all required dependencies are active; no dependency is revoked under the status roots; validity windows are satisfied; jurisdiction matches; and clause binding is compatible. For sensitive contexts, delayed disclosure may be necessary. A public verifier may see only that dependency conditions are satisfied. A controlled reviewer may inspect the full graph. A community steward may control protected dependencies. A Project SPV evidence room may keep commercial dependencies confidential while proving completeness. Credential Oracles can generate these ZK-compatible dependency attestations and include proof hashes in CACs. This allows dependency management to preserve privacy. ### Dependency Management for AI Agents AI agent authority is highly dependency-driven. An agent may be allowed to act only if its model status is active, its operator credential is active, its tool-use credential is active, its memory policy credential is current, its data access credential matches the task, its human supervisor credential is active, and its public-safe output credential applies. If any dependency fails, the agent should lose or restrict authority. If the model is quarantined, tool-use credentials suspend. If the human supervisor credential expires, high-consequence actions route to review. If data access is restricted, the agent may operate only on public or synthetic data. If public-safe review is missing, public output is blocked. Agent runtimes should query dependency trees before tool calls and clause dispatch. They should not rely on cached authority without status checks. Dependency management prevents agent permissions from becoming invisible permanent power. ### Dependency Management for Project SPVs, Finance-Readiness, and Insurance-Readiness Project SPV evidence credentials are complex dependency objects. A ProjectReadinessEvidenceVC may depend on asset operator credentials, data provider credentials, maintenance evidence, climate scenario review, safeguard review, public-safe summary review, controlled evidence room access, and registry status. A FinanceReadinessEvidenceVC may depend on evidence completeness, risk documentation, governance review, and controlled-room CACs. An InsuranceReadinessEvidenceVC may depend on exposure evidence, monitoring data, hazard model status, basis-risk review, and sensor provider credentials. If any dependency fails, the credential should not be interpreted as current. It may become under review, partially valid, historical-only, restricted, or expired. This does not mean finance denial or underwriting denial. It means evidence status changed. Dependency management allows capital-relevant evidence to remain current, auditable, and legally boundary-safe. ### Dependency Management Across GNC, RNC, and NNC Architecture At the national level, National Nexus Consortiums may define domestic dependency rules for national credentials, SDZ access, public-safe roles, disaster credentials, public health credentials, AI agents, Project SPV evidence, and national credential issuers. At the regional level, Regional Nexus Consortiums may define dependency trees for cross-border recognition, shared hazards, regional simulations, corridor systems, and mutual recognition workflows. Regional dependency graphs should preserve national raw data control. At the global level, the Global Nexus Consortium may define dependency graph schemas, lifecycle hook formats, interoperability tests, status vocabulary, and public-good reference profiles. It should not centrally control all credential dependencies. At the community level, community and Indigenous governance bodies may define dependencies for protected knowledge, public-safe mapping, community data access, and grievance workflows. At the enterprise layer, National Consortium Companies, Project SPVs, providers, operators, insurers, investors, contractors, and evidence rooms may define enterprise dependency graphs for lawful implementation and controlled evidence workflows. This federated dependency architecture lets trust remain local where authority is local, while still being interoperable. ### VC Dependency and Lifecycle Boundary Statement VC Dependency Trees and Lifecycle Hooks support credential preconditions, dependency validation, cascading status updates, renewal, expiry, escalation, revocation propagation, audit diagnostics, ZK dependency proofs, AI agent control, Project SPV evidence workflows, finance-readiness evidence, insurance-readiness evidence, and machine-verifiable credential governance. They do not by themselves create legal authority, public authority action, regulatory approval, certification, procurement approval, finance approval, investment advice, insurance underwriting, claims determination, official public warning status, treaty enforcement, legal liability, or universal recognition. A dependency graph proves declared trust relationships and status conditions under a schema. Its institutional meaning depends on issuer authority, credential schema, clause binding, jurisdiction, applicable law, contracts, community rules, governance review, and competent adoption. A dependency tree is not legal hierarchy. A lifecycle hook is not public authority. A cascade notice is not legal finding. A finance-readiness dependency is not finance approval. An insurance-readiness dependency is not underwriting. A simulation dependency is not prediction certainty. An automated suspension is not proof of misconduct. This boundary must appear in dependency schemas, lifecycle hook definitions, credential registries, verifier tools, AI agent policies, audit dashboards, and public documentation. ### Dependency Management as Institutional Logic In NSF, credential issuance is no longer a one-off event. A credential becomes part of a living trust graph. It has preconditions, dependencies, lifecycle hooks, status roots, clause bindings, audit obligations, expiration rules, escalation paths, revocation propagation, and correction pathways. This makes trust modular. It makes authority conditional. It makes revocation scalable. It makes AI permissions bounded. It makes simulation dependency visible. It makes Project SPV evidence current. It makes finance-readiness and insurance-readiness evidence auditable without becoming regulated approval. It makes cross-jurisdictional recognition precise. It makes institutional memory queryable. VC Dependency Trees and Lifecycle Hooks allow NSF to operate like an event-driven trust operating system without requiring centralized enforcement. They let credentials react to live governance state while preserving issuer authority, jurisdictional boundaries, privacy, and correctionability. That is the role of VC dependency management in the Nexus Sovereignty Framework: to transform credentials from isolated signed claims into programmable, dependency-aware, auditable components of institutional trust. --- # 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-dependency-trees-and-lifecycle-hooks.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.