> 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-schema.md). # CAC Schema ## Clause-Attested Compute in the Nexus Sovereignty Framework: Verifiable Execution Receipts, Runtime Attestation, Input-Output Provenance, Governance Scope, Hash Graphs, and Audit-Bound Compute Evidence ### What Is Clause-Attested Compute? Clause-Attested Compute (CAC) is the primary proof-bearing artifact produced when a Smart Clause executes inside an NSF-compatible verifiable compute environment. It is the execution receipt of the Nexus Sovereignty Framework. It records which clause ran, which version and hash governed execution, which inputs were bound, which parameters were resolved, which credentials were checked, which simulation outputs were used, which trigger activated the clause, which runtime executed it, which attestation evidence supports the execution, which output was produced, which governance scope applied, and which audit record preserves the trace. A CAC is not merely a log entry. A log may say that something happened. A CAC proves, under a defined proof scope, that a specific governed computation occurred. It binds clause identity, input provenance, runtime measurement, output status, jurisdiction, credential state, simulation references, and attestation into a single verifiable record. It is the artifact that allows another actor, system, auditor, public-safe reviewer, credential issuer, national node, regional consortium, Project SPV evidence room, AI agent runtime, or controlled reviewer to inspect execution without relying on unsupported claims. CAC is the machine-verifiable equivalent of “a governed clause was executed under these conditions.” It should not be reduced to “policy acted” without qualification, because the word “acted” can imply legal effect, public authority, enforcement, finance approval, insurance underwriting, contract execution, or regulatory determination. A safer formulation is: **CAC records that a policy-bound computational clause executed and produced a proof-scoped output.** This distinction is essential. A CAC can support credential issuance, public-safe review, audit replay, simulation comparison, AI agent governance, evidence routing, Project SPV diligence, finance-readiness evidence, insurance-readiness evidence, disaster readiness support, and lawful handoff to authorized actors. It does not by itself create legal authority, official warning status, regulated financial action, insurance coverage, procurement approval, compliance certification, or treaty determination. The core doctrine is: **A CAC is a verifiable execution receipt. It proves that a defined clause package executed under defined inputs, runtime, credentials, simulation state, governance scope, and proof conditions. It does not by itself prove that the output has legal, financial, regulatory, public authority, or professional effect beyond its declared authority class.** ### Why CACs Are the Execution Unit of Verifiable Governance The NSF architecture requires an artifact that can travel across institutions, jurisdictions, agents, registries, evidence rooms, audit systems, and public-safe interfaces without losing execution meaning. A Smart Clause may execute inside a national Sovereign Data Zone. Its output may need to be reviewed by a regional consortium. A credential issuer may need to verify it. A Project SPV evidence room may need to include it in a readiness package. A public-safe dashboard may need a redacted summary. An AI agent may need to know whether it can rely on it. An auditor may need to replay it years later. Without a CAC, these actors would rely on screenshots, logs, APIs, database entries, platform claims, or institutional assertions. Those are not enough. A CAC provides a standardized, proof-scoped, machine-verifiable execution object. It allows the system to say: This clause hash ran. These inputs were bound. These credentials were checked. These parameter values applied. This simulation output was used. This runtime measurement executed the workload. This enclave or proof system attested execution. This jurisdictional scope applied. This output was produced. This audit record preserves the trace. This is what CACs add to governance: not merely computation, but computation with memory, provenance, and accountability. ### CAC Schema Overview Every CAC should conform to a registered CAC schema. The schema defines required fields, optional fields, serialization profile, proof type, disclosure level, replay class, and compatibility rules. A simplified CAC may look like the seed example, but a mature NSF CAC should be claims-safe, namespace-safe, privacy-aware, and proof-scoped. A representative CAC structure may include: ```json { "schema": { "id": "CACSchema@2.1", "profile": "tee-gov", "serialization": "JSON-LD" }, "execution": { "execution_id": "cac-0x81ab4d", "timestamp": "2025-04-30T16:21:43Z", "replay_class": "proof-replay", "authority_class": "evidence-support" }, "clause": { "clause_id": "FoodRef::Food::ToxinThresholdEvidenceClause@1.2.3", "clause_hash": "0x...", "clause_version": "1.2.3", "clause_status_at_execution": "ACTIVE", "fork_lineage": { "parent_clause_id": "FoodRef::Food::ToxinThresholdEvidenceClause@1.2.0", "parent_clause_hash": "0x...", "fork_status": "national-reference-profile" } }, "trigger": { "type": "sensor", "source": "EO::CopernicusReferenced::Sentinel5P", "event_id": "evt-0xdeadbeef", "event_timestamp": "2025-04-30T16:20:10Z", "source_status": "ACTIVE", "proof": "0x..." }, "inputs": { "sensor_data": [], "credentials": [], "simulation_results": [], "parameters": [], "registry_snapshot": {} }, "outputs": { "status": "REVIEW_REQUIRED", "meaning": "toxin-threshold-evidence-requires-review", "non_meaning": "not-certification-not-export-approval-not-regulatory-determination", "actions_requested": [ { "type": "route_to_review", "target": "FoodSafetyEvidenceReview" } ] }, "attestation": { "attestation_type": "TEE", "runtime_hash": "0xcafe...", "enclave_quote_hash": "0xabc...", "node_did": "did:nsf:tee-node:42", "node_credential": "TEEExecutorVC@1.0", "signature": "0xDEADBEEF", "attestation_timestamp": "2025-04-30T16:21:44Z" }, "governance_scope": { "jurisdiction": "KEN", "governance_body": "KEN::FoodSafetyEvidenceGovernance", "registry_scope": "national-reference", "public_safe_class": "restricted-summary", "sdz": "KEN::FoodSafetySDZ" }, "hash_graph": { "input_root_hash": "0x123abc", "output_hash": "0x456def", "attestation_hash": "0x789aaa", "simulation_root_hash": "0x222bbb", "credential_root_hash": "0x333ccc", "full_cac_hash": "0x789fed" }, "audit": { "audit_record_id": "audit-0x...", "storage_class": "restricted", "public_anchor": "optional-commitment-only" } } ``` This schema does three things. First, it records execution. Second, it preserves proof scope. Third, it prevents overclaim by including output meaning and non-meaning fields. A CAC must never leave downstream systems guessing whether an output is evidence support, official action, public-safe summary, credential status, finance-readiness evidence, insurance-readiness evidence, or controlled-room record. ### Clause Identity Fields The clause identity section is the foundation of the CAC. It identifies the exact Smart Clause that executed. It should include Clause ID, Clause Hash, version, namespace, domain, authority class, status at execution, dependency graph hash, registry snapshot, fork lineage, and deprecation or suspension status. The Clause ID is human-readable and registry-resolvable. The Clause Hash is cryptographic and canonical. Both are required. A CAC that records only a clause name is insufficient. A CAC that records only a hash without governance metadata is difficult to interpret. The clause status at execution matters. If the clause was active at execution time but later deprecated, the CAC remains historically meaningful. If the clause was suspended at execution time, the CAC may be invalid or disputed. If the clause was active-limited, the CAC must show whether execution fell within allowed scope. If the clause was simulation-only, the CAC should not be used for production credential actions. Fork lineage matters because many clauses will have national, regional, community, enterprise, or experimental forks. A CAC must show which fork ran. This prevents a global reference clause, national implementation fork, Project SPV implementation fork, and public authority-adopted fork from being confused. Clause identity fields answer the question: **which governed rule package produced this output?** ### Input Substructure The input section of a CAC must preserve enough provenance to verify execution while respecting privacy, confidentiality, and public-safe constraints. Inputs may be public, restricted, sovereign-sensitive, community-controlled, personal, confidential, market-sensitive, or controlled-room-only. The CAC should not expose raw sensitive data where commitments, hashes, proofs, or controlled references are sufficient. Sensor data inputs should include source, source credential or source mapping, device or dataset ID, timestamp, jurisdiction, geospatial scope, schema version, quality flags, units, input hash, signature status, and provenance reference. For earth observation data, this may include mission reference, product ID, acquisition time, processing level, tile ID, spatial resolution, cloud or quality flags, and archive commitment. For IoT data, this may include device ID, calibration status, firmware status where relevant, location, measurement time, and operator credential. Credential inputs should include subject identifier or pseudonymous commitment, issuer, schema, credential hash, status at execution, revocation status, recognition status, expiration, issuer status, presentation proof, and jurisdictional scope. Raw credential payloads should not be disclosed unless necessary and permitted. Simulation inputs should include model ID, model version, simulation bundle ID, run ID, scenario ID, run timestamp, input commitments, output commitments, confidence, uncertainty labels, reviewer signatures where applicable, model status, and simulation proof reference. Parameter inputs should include parameter ID, parameter hash, resolved value, unit, source, jurisdiction, validity period, resolution function, resolution timestamp, and override status if used. External calls or RPC inputs should be handled carefully. If a clause depends on a smart contract, oracle, registry, API, or external system, the CAC should record the call source, response hash, timestamp, proof, and authority class. External calls should be declared input bindings, not hidden runtime behavior. Every input should include schema version hash and validation result. If an input failed validation but execution continued in degraded mode, the CAC must show that. If input data was restricted and only a hash is included, the replay class must reflect proof replay or controlled replay. The input substructure answers: **what evidence did the clause use, and under what proof limits?** ### Attestation Metadata The attestation section records how execution integrity was proven. It may include TEE attestation, ZK proof, multi-party attestation, controlled-room attestation, or hybrid proof. For TEE-backed CACs, attestation metadata should include runtime measurement, enclave or confidential VM quote, platform type, hardware attestation chain reference, node DID, node credential, runtime build hash, workload hash, clause hash, dependency graph hash, security version, attestation timestamp, verifier status, and signature. For ZK-backed CACs, attestation metadata should include proof system, circuit ID, proving key commitment, verification key, public inputs, proof commitment, prover identity where applicable, proof timestamp, and verification result. For hybrid CACs, the attestation section may include both TEE quote and ZK proof, or TEE plus multi-signer review, or controlled-room review plus hash commitments. The proof profile should state what each proof component establishes. The seed says runtime build hash is “governance-certified.” Safer language is **governance-approved**, **registry-recognized**, or **conformance-tested**, unless NSF creates a formal certification regime. A runtime hash shows that a registered runtime build executed. It does not legally certify the runtime. Attestation metadata should also support replay protection. It should include nonce, execution ID, timestamp, and input commitment binding. This prevents an attacker from reusing old attestation evidence for new outputs. The attestation section answers: **what compute environment produced this output, and what proof supports that claim?** ### Governance and Jurisdictional Scoping Every CAC must include governance and jurisdictional scope. Execution meaning depends on where, for whom, under what authority class, and inside which governance context the clause ran. The jurisdiction tag may use ISO 3166 codes, subnational codes, treaty-area identifiers, SDZ identifiers, community territory identifiers, regional corridor identifiers, public authority scope, enterprise scope, or controlled-room scope. The jurisdiction tag should not be treated as a legal conclusion by itself. It records the execution context used by the clause. The governance scope should identify the relevant governance body, registry, node, review process, or authority context. In the seed, this is called DAO scope. The mature NSF framing should use **governance scope**, **review body**, **registry authority**, **national node**, **regional consortium**, **community steward body**, **enterprise evidence governance**, or **governance quorum**. DAO tooling may support a workflow, but the CAC should not imply token-based authority unless that is actually part of the governance design. Fork lineage should identify whether the clause was canonical reference, national fork, regional fork, community safeguard fork, enterprise implementation fork, public authority-adopted fork, simulation-only fork, or restricted fork. Credential issuer compatibility metadata should show whether credential effects are recognized only locally, regionally, globally, conditionally, or not at all. A CAC that supports a credential action in one jurisdiction may not be valid for another. The seed says CACs enable localized enforcement and treaty-anchored action triggers. Safer language is **localized execution support**, **jurisdictional evidence routing**, **treaty-aligned evidence triggers**, or **lawful handoff support**. Enforcement and treaty action require competent authority. Governance scoping answers: **under whose scope and jurisdiction did this execution occur, and what does that scope permit?** ### Output Structure and Output Semantics The output section must be carefully designed because CAC outputs may be consumed by humans, machines, registries, AI agents, dashboards, credential issuers, Project SPV evidence rooms, and enterprise systems. Outputs must be structured and boundary-labeled. A CAC output should include status, result code, output values, confidence or uncertainty where relevant, output meaning, output non-meaning, requested actions, blocked actions, public-safe class, credential effects, contract hook status, review routing, and safe-mode state. The seed example uses: ```json "outputs": { "status": "VIOLATION", "action": "Revoke:FoodExportVC" } ``` This should be reframed to avoid legal and regulatory overclaim. “Violation” implies legal breach. “Revoke:FoodExportVC” may imply automatic revocation of a trade or export credential. Safer outputs include: ```json "outputs": { "status": "THRESHOLD_EXCEEDED", "meaning": "evidence threshold exceeded under declared clause and inputs", "non_meaning": "not legal violation, not export approval, not regulatory determination", "actions_requested": [ { "type": "credential_status_review", "credential": "FoodExportEvidenceVC", "scope": "affected-batch", "review_required": true } ] } ``` If a clause is authorized to suspend a technical evidence credential, the output should state scope and review path. Automatic revocation should be limited to credentials whose schema and governance rules permit such action. CAC outputs may include statuses such as PASS, FAIL, TRIGGER, REVIEW\_REQUIRED, INSUFFICIENT\_EVIDENCE, BLOCKED, SUSPENDED, SAFE\_MODE, DISPUTED, THRESHOLD\_EXCEEDED, PUBLIC\_SAFE, NOT\_PUBLIC\_SAFE, or ERROR. These statuses should be defined by schema. “FAIL” should mean clause condition failed under proof scope, not legal violation. Output semantics are critical for downstream safety. A CAC must tell users what the output means and what it does not mean. ### Hash Graph Structure NSF uses hash graphs to preserve CAC integrity and link related proof components. A hash graph allows verification of inputs, outputs, attestation, simulation state, credential state, parameter state, clause identity, and audit records without exposing all payloads. A CAC hash graph may include input root hash, sensor root hash, credential root hash, simulation root hash, parameter root hash, registry snapshot hash, clause package hash, dependency graph hash, runtime hash, attestation hash, output hash, action hash, audit event hash, and full CAC hash. These can be organized in Merkle-style structures for efficient verification. Hash graphs support several functions. They prove CAC integrity. They chain executions across workflows. They allow partial disclosure of sensitive components. They allow public anchoring of commitments without exposing data. They allow ZK or enclave validators to verify inclusion. They allow forensic replay to locate the exact evidence package. They allow dependency analysis when an input, credential, parameter, or model is later corrected. Hash graphs should be included in the Audit Layer. Relevant nodes may be discoverable through the Registry Layer depending on access rights. Public anchors may store only root commitments. Restricted payloads should remain inside SDZs, controlled rooms, community registries, or enterprise evidence rooms. A hash graph proves structural integrity. It does not prove that every underlying input is true or authoritative. That meaning depends on source validation and governance. ### Serialization and Signing CACs should support serialization formats that are both machine-verifiable and interoperable. JSON-LD is useful where DID, Verifiable Credential, RDF, and linked-data compatibility are important. CBOR or CBOR-LD may be useful for compact binary encoding, edge execution, constrained devices, and certain proof systems. Deterministic canonicalization is essential. If the same CAC content serializes differently, signatures and hashes become unreliable. CACs may be encrypted for recipients. Encryption should be based on data classification, recipient authorization, public-safe class, and jurisdiction. A public CAC may expose metadata and commitments. A restricted CAC may be encrypted to credentialed reviewers. A sovereign CAC may remain inside a national SDZ with external proof commitment. A community-sensitive CAC may reveal only limited public metadata. A Project SPV CAC may remain in a controlled evidence room. Signing should support multiple signer types. A TEE-backed CAC may be signed by enclave or node keys. A ZK-backed CAC may include prover and verifier commitments. A user-run agent or copilot may sign the invocation context, but that does not substitute for runtime attestation. A governance body may co-sign public CACs, but such co-signature should state what it means, such as publication approval, review acknowledgment, or registry acceptance. Signature algorithms may include Ed25519, ECDSA, BLS for aggregated signatures, and post-quantum algorithms as they mature. Signatures should identify algorithm, key, signer DID or equivalent identity, signer credential, timestamp, key status, and signature scope. Multi-signature governance may be used for high-risk CAC publication or validation. But a multi-signature does not automatically make the output legally authoritative. It records role-bound approval or verification. Serialization and signing turn CACs into portable evidence objects. ### CAC Versioning and Schema Evolution CAC schemas must be versioned because proof requirements, execution environments, privacy expectations, governance metadata, and interoperability standards will evolve. Schema evolution must be controlled, backward-compatible where possible, and audit-linked. Examples may include: `CACSchema@1.0` for baseline TEE-backed execution receipts. `CACSchema@2.1-zk` for zero-knowledge compatible variants. `CACSchema@3.0-gov` for expanded governance scope, override history, dispute records, and safe-mode metadata. `CACSchema@4.0-edge` for offline and edge execution profiles. `CACSchema@5.0-publicsafe` for public-safe reporting outputs. Each schema version should define required fields, optional fields, canonicalization, serialization, proof profile, encryption model, disclosure classes, replay class, and compatibility constraints. Schema versions should be registered in the Registry Layer with changelogs and diff tooling. Governance validators may enforce allowed schema versions. A high-risk clause may require `CACSchema@3.0-gov` or higher. A ZK clause may require `CACSchema@2.1-zk`. A public-safe output may require a schema that includes boundary labels and correction fields. When schemas change, historical CACs remain valid under their original schema. They should not be rewritten. Cross-version validation tools should interpret older CACs and identify limitations. Schema evolution must not break audit memory. ### CAC Integration with the Data Layer CACs bind to the Data Layer through input hashes, provenance references, data classification, SDZ context, transformation records, and public-safe output rules. The CAC does not need to contain raw data. It must contain enough reference and proof structure to verify what data was used. For sensitive data, the CAC may include commitments, controlled-room pointers, encrypted references, or ZK proof references. For public data, it may include source URLs, dataset identifiers, and hashes. For sovereign data, it may include national registry references. For community data, it may include community steward commitments and public-safe restrictions. For Project SPV evidence, it may include controlled evidence room references. The Data Layer uses CACs to maintain input-output lineage. If an input dataset is corrected, the system can identify affected CACs. If a data provider is suspended, dependent CACs may be flagged. If a public-safe rule changes, outputs derived from affected inputs can be reviewed. CACs make data use accountable. ### CAC Integration with the Credential Layer CACs integrate with the Credential Layer in two ways. First, credentials can be inputs to clause execution. Second, CACs can support credential actions. As inputs, CACs record credential schema, subject, issuer, status, revocation state, recognition, and timestamp. This allows replay and dispute review. As outputs, CACs may support credential issuance, suspension, revocation request, recognition, renewal, or status review. The CAC should identify whether the credential action was executed, requested, blocked, or routed to review. It should state authority class. For high-consequence credentials, the CAC should not imply automatic legal or professional credential effect unless the credential issuer and applicable governance allow it. Credential issuers can verify CACs before issuing credentials. A wallet can display that a credential was issued based on CAC evidence. A verifier can inspect which clause supported the credential. If the clause is later corrected, affected credentials can be identified. CACs make credentials evidence-bound rather than assertion-bound. ### CAC Integration with the Simulation Layer CACs should link to simulation packages, embedded simulation runs, dynamic thresholds, scenario outputs, model status, uncertainty labels, and simulation reviewer signatures where applicable. If a clause used an embedded simulation, the CAC should include model ID, model version, simulation bundle, run ID, input commitments, output commitments, confidence, uncertainty, runtime proof, and simulation status. If the clause relied on a pre-activation simulation package, the CAC should reference the package that supported activation. Simulation-linked CACs allow model audit. If a model is later quarantined, dependent CACs can be identified. If observed outcomes diverge from forecast, CACs provide execution history. If a dynamic threshold is challenged, the CAC shows which model produced it. CACs make simulation use traceable. ### CAC Integration with the Registry and Audit Layers The Registry Layer stores or indexes CAC schema versions, clause identities, node credentials, parameter records, credential schemas, model statuses, public-safe rules, and governance scope. CACs refer to these registry records. The Registry Layer may also index CACs by clause, jurisdiction, domain, status, fork, credential impact, simulation dependency, or public-safe class. The Audit Layer preserves CACs as execution memory. It stores full CACs or access-controlled references. It records execution events, failure states, safe-mode transitions, replay attempts, dispute records, corrections, public anchors, and lifecycle effects. A CAC should always have an audit anchor. If a CAC is public-safe, a public commitment may be anchored externally. If restricted, the Audit Layer may store only metadata and commitments while payload remains encrypted or controlled. The Registry tells systems what the CAC refers to. The Audit Layer preserves what happened. ### CAC Integration with the Communication Layer CACs can be transmitted as messages, attached to events, referenced in notifications, or used as proof payloads. The Communication Layer should ensure CAC messages preserve identity, proof, classification, recipient authorization, jurisdiction, public-safe status, and correction path. A Reactive Clause may emit a CAC when a trigger validates. A credential issuer may receive a CAC as issuance evidence. A public-safe dashboard may receive a public summary CAC. A national node may receive a CAC from a regional simulation. An enterprise evidence room may receive a CAC from a TEE execution. An AI agent may receive a CAC to verify a tool-use decision. CACs should support selective disclosure. Not every recipient needs every field. A public user may see output status and boundary label. A regulator or competent authority may see more under lawful access. A Project SPV reviewer may see controlled evidence references. A community steward may see safeguard-relevant fields. A ZK verifier may see proof statements only. Communication of CACs must be governed. ### CAC Integration with Safe-Mode Logic CACs should record failure and safe-mode states. If execution failed, the CAC or associated failure notice should include failure class, reason, safe-mode action, escalation route, freeze status, credential impact, contract-trigger evidence status, public-safe status, and recovery requirements. A failure CAC may show that execution was attempted but blocked due to invalid attestation. Another may show that input mismatch caused review required. Another may show that simulation output was below confidence threshold. Another may show that public-safe publication was blocked. Safe-mode CACs are important because they prove that the system did not continue silently. They also provide evidence for recovery, correction, and governance review. Failure is part of execution memory. CACs must preserve it. ### CACs for AI Agents and Autonomous Systems AI agents and autonomous systems can use CACs as proof objects. Before an AI agent relies on a clause output, it should verify the CAC. Before it invokes a tool, it may need a CAC showing tool-use authorization. Before it publishes a public-safe summary, it may need a CAC showing public-safe clearance. Before it accesses a controlled evidence room, it may need a CAC confirming credential and policy checks. Agent-generated actions should also produce CACs where governance requires it. For example, an agentic workflow that routes a risk signal, classifies a document, or requests simulation should leave CAC or audit records. These records prevent AI decisions from becoming untraceable. Autonomous systems can use CACs to verify edge decisions, offline execution, drone geofencing, AI-RAN policy gates, industrial system safety rules, or robotic mission constraints. CACs make machine behavior inspectable. ### CACs for Project SPVs, Finance-Readiness, and Insurance-Readiness CACs are especially useful in Project SPV evidence rooms and risk-to-capital workflows because they allow sensitive evidence to be verified without uncontrolled disclosure. A CAC can show that a clause checked asset telemetry, maintenance evidence, climate simulation, safeguard status, or monitoring compliance under a controlled runtime. It can support diligence by authorized actors. Finance-readiness CACs can show evidence completeness, scenario linkage, data provenance, and review routing. They must not be framed as finance approval, creditworthiness, investment advice, guarantee, rating, or solicitation. Insurance-readiness CACs can show exposure evidence, hazard model linkage, parametric trigger evidence, monitoring status, basis risk evidence, or data completeness. They must not be framed as underwriting, claim approval, coverage, pricing, or insurability. CACs support evidence readiness. Licensed or authorized actors make regulated decisions. ### CACs Across GNC, RNC, and NNC Architecture CACs operate across the Nexus multiscale architecture. At the national level, National Nexus Consortiums may generate CACs inside national SDZs for domestic clauses, public authority support, national credentials, public health, disaster risk, infrastructure, climate, and Project SPV evidence. National CACs preserve domestic jurisdiction and data control. At the regional level, Regional Nexus Consortiums may receive, compare, or aggregate CACs for cross-border hazards, regional simulations, corridor systems, mutual recognition, and shared risk reporting. Regional CAC use must respect national disclosure constraints. At the global level, the Global Nexus Consortium may define CAC schemas, proof profiles, interoperability standards, public-good reference tooling, and cross-registry verification. It should not centralize all CAC payloads. At the community level, community governance bodies may produce or verify CACs for protected knowledge, public-safe mapping, local risk signals, and safeguard compliance. Community CACs must preserve local control. At the enterprise layer, National Consortium Companies, Project SPVs, providers, operators, insurers, investors, and contractors may generate CACs for lawful delivery and controlled evidence workflows. Enterprise CACs remain scoped and do not imply public-good endorsement, procurement approval, finance approval, or insurance underwriting. This distributed CAC architecture allows verifiable execution without centralizing authority or raw data. ### CAC Privacy, Disclosure, and Public-Safe Profiles CACs can contain sensitive metadata. Even hashes, timestamps, locations, clause names, or failure states can reveal information. Therefore, CACs must include disclosure profiles. A public CAC may be suitable for public reference clauses, public-safe summaries, open tests, or public dashboards. A restricted CAC may require credentialed access. A sovereign CAC may remain in national infrastructure. A community CAC may be controlled by community governance. An enterprise CAC may remain in an evidence room. A ZK CAC may expose proof statements without payload. A sealed CAC may require TEE or controlled-room access. Disclosure profiles should define which fields are public, credential-gated, encrypted, sovereign-controlled, community-controlled, enterprise-controlled, or audit-only. Redaction must be structured, not ad hoc. Public-safe profiles should include boundary labels, uncertainty labels, official-source distinction, correction path, and prohibited claims. A public CAC output should not expose sensitive inputs or overstate meaning. CAC privacy is part of trust. ### CAC Replay and Verification CACs should be replayable or verifiable under their declared replay class. Verification may include checking signatures, clause hash, registry status at execution, input commitments, credential status, parameter records, simulation run, runtime attestation, output hash, and full CAC hash. Exact replay is possible where raw inputs and deterministic runtime are available. Proof replay is possible where commitments and proofs are sufficient. Controlled replay is possible in restricted environments. Statistical replay applies to stochastic simulations. Methodological replay applies where exact execution cannot be reproduced but method, evidence, and attestations can be reviewed. Replay tools should report whether the CAC verifies, fails, or requires restricted access. A failed replay should produce a dispute or audit event. CAC verification is the practical mechanism behind execution trust. ### CAC Boundary Statement Clause-Attested Compute supports verifiable execution receipts, input-output provenance, runtime attestation, simulation linkage, credential-state recording, trigger traceability, governance scoping, hash-graph integrity, replay, auditability, public-safe review, AI agent governance, Project SPV evidence, finance-readiness evidence, and insurance-readiness evidence. It does not by itself create legal authority, public authority action, regulatory approval, certification, procurement approval, finance approval, investment advice, insurance underwriting, claims determination, official public warnings, treaty compliance, legal liability determination, or proof of absolute data truth. A CAC proves a bounded execution claim under a defined proof profile. The institutional meaning of the output depends on clause authority class, source authority, jurisdiction, governance review, credential scope, data quality, simulation validity, public-safe rules, and applicable law. A CAC is not a legal judgment. A CAC is not certification. A CAC is not finance approval. A CAC is not underwriting. A CAC is not an official public warning. A CAC is not proof that the input data was true beyond declared validation. A CAC is not proof that a model was correct beyond declared simulation status. This boundary must be embedded in CAC schema, verification tools, registry pages, audit dashboards, public-safe outputs, and documentation. ### CACs as Verifiable Execution Receipts A CAC is more than a log. It is the execution receipt of verifiable governance. It captures the fact that a Smart Clause ran under declared conditions and produced a proof-scoped output. It binds policy logic to compute, data, credentials, simulations, triggers, jurisdiction, governance, and audit memory. With CACs, NSF replaces weak assertions with inspectable execution evidence. Not “we think this rule was followed.” Not “the system says it passed.” Not “the dashboard produced a result.” But: This clause version ran. This hash identifies it. These inputs were used. These credentials were checked. These parameters applied. This simulation was linked. This trigger activated it. This runtime executed it. This attestation supports it. This output was produced. This proof scope limits it. This jurisdiction governed it. This audit record preserves it. This correction path remains open. That is the role of Clause-Attested Compute in the Nexus Sovereignty Framework. CACs turn execution into a verifiable institutional artifact: portable enough for machines, structured enough for auditors, bounded enough for lawyers, useful enough for operators, privacy-aware enough for sovereign systems, and disciplined enough for public-good 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/iv.-verifiable-execution/cac-schema.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.