> 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/clause-attested-compute.md). # Clause-Attested Compute ## Clause-Attested Compute Rollups in the Nexus Sovereignty Framework: Scalable Execution Aggregation, Merkleized CAC Batching, Cross-Jurisdictional Audit Compression, ZK Rollup Integrity, and Queryable Governance Memory ### The Scaling Challenge in Verifiable Governance The Nexus Sovereignty Framework cannot rely on one-off execution receipts alone. Clause-Attested Compute gives each Smart Clause execution a verifiable record, but as NSF expands across jurisdictions, domains, agents, simulations, registries, public-safe outputs, Project SPVs, AI systems, credential issuers, and sovereign compute environments, the volume of CACs can become enormous. A national disaster-risk system may generate thousands of CACs during a major weather event. A public health network may generate CACs from sensor signals, credential checks, privacy-preserving aggregation, and public-safe reporting. A climate and emissions evidence system may generate CACs across facilities, models, reporting periods, and jurisdictional forks. A Project SPV evidence room may generate CACs for asset telemetry, maintenance, safeguards, climate simulation, finance-readiness evidence, and insurance-readiness evidence. AI agent governance may generate CACs for tool-use checks, memory rules, data access, public-safe review, and model-status gates. At small scale, individual CACs can be inspected directly. At large scale, the system requires structured aggregation. Without aggregation, audit systems become costly, search becomes slow, public-safe disclosure becomes difficult, verification becomes repetitive, and cross-jurisdictional review becomes operationally heavy. A governance system that produces proof for every execution must also provide a way to index, compress, verify, replay, and query those proofs without forcing every verifier to download or inspect every CAC individually. This is the purpose of **Clause-Attested Compute Rollups**, or **CAC Rollups**. A CAC Rollup is a cryptographically structured bundle of individual CACs, grouped under a defined scope, ordered deterministically, committed through a Merkle or hash-graph structure, signed by an authorized rollup process, and anchored in the Audit Layer. A rollup allows many execution receipts to be treated as one verifiable artifact while preserving inclusion proofs for every underlying CAC. CAC Rollups solve the scaling problem without weakening proof. They allow NSF to compress many executions into one audit object, generate inclusion proofs for individual CACs, support batch replay, support anomaly detection, support governance review, support cross-domain query, and optionally anchor root commitments to public or sovereign ledgers. The core doctrine is: **A CAC Rollup compresses execution records without erasing execution accountability. Every individual CAC remains traceable, every inclusion remains provable, every scope remains governed, and every rollup remains auditable under defined jurisdiction, domain, and proof constraints.** ### CAC Rollups Are Not Execution Substitutes A CAC Rollup does not replace individual CACs. It aggregates them. The individual CAC remains the primary execution receipt. The rollup is the batching, indexing, compression, and verification layer that makes large-scale governance memory practical. This distinction matters. A rollup root can prove that a CAC belongs to a batch, but it does not by itself explain the full execution unless the CAC or authorized proof path is available. A rollup summary may show that 247 disaster-risk executions occurred in a jurisdiction during a time window, but the meaning of each execution still depends on the underlying clause, inputs, output, runtime, proof scope, and governance context. A CAC Rollup also does not create legal, financial, regulatory, public authority, treaty, or professional meaning by aggregation. Ten thousand evidence-support CACs do not become a regulatory determination because they were rolled up. A rollup of finance-readiness evidence does not approve finance. A rollup of insurance-readiness evidence does not underwrite coverage. A rollup of disaster triggers does not issue official public warnings. A rollup of emissions evidence does not impose penalties. Aggregation improves verifiability and auditability, not authority. A CAC Rollup is therefore a governance-memory artifact, not a governing authority by itself. ### What Is a CAC Rollup? A CAC Rollup is a structured, signed, and registry-linked bundle of CAC entries. It groups CACs under a declared scope such as domain, jurisdiction, time period, clause family, simulation model, trigger event, Project SPV, credential schema, national node, regional corridor, public-safe output class, or enterprise evidence room. A rollup may contain a small number of high-sensitivity CACs or thousands of low-risk public CACs. The seed suggests 10 to 10,000 CACs. That is a reasonable design range, but actual rollup size should depend on risk class, proof profile, storage model, query needs, confidentiality, public-safe rules, and verification cost. A high-sensitivity health rollup may contain fewer CACs and expose only ZK summaries. A public test rollup may contain many. A disaster event rollup may be time-bounded by incident phase. A Project SPV rollup may be organized by evidence package. A CAC Rollup typically includes a rollup header, scope metadata, execution metadata, deterministic ordering rule, Merkleized CAC index, aggregate signatures, attestation summary, verifier set, inclusion proof interface, privacy profile, audit anchor, registry references, and optional external anchor. A simplified rollup record may include: ```json { "rollup_id": "cacrollup-0x84712a", "schema": "CACRollupSchema@1.0", "timestamp": "2025-04-30T17:00:00Z", "scope": { "domain": "DisasterReadiness", "jurisdiction": "BRA", "time_window": "2025-04-30T16:00:00Z/2025-04-30T17:00:00Z", "authority_class": "evidence-support" }, "executions": 247, "cac_root": "0xabc123", "ordering_rule": "timestamp,execution_id,clause_hash", "enclave_set": [ "did:nsf:tee-node:1", "did:nsf:tee-node:9" ], "verifier_set": "NSFVerifierSet@2025-Q2", "aggregate_signature": "0xDEAD", "audit_anchor": "audit-0x...", "external_anchor": { "type": "public-chain-commitment", "reference": "Ethereum:block:19723455", "payload": "root-hash-only" } } ``` The rollup must show what it contains, what it does not contain, who generated it, who verified it, what proof profile applies, and what disclosure restrictions govern it. ### Rollup Schema Overview A mature CAC Rollup schema should include several top-level structures. The **rollup identity** section includes rollup ID, schema version, rollup type, creation timestamp, creator, rollup coordinator credential, verifier set, and status. The **scope** section includes domain, jurisdiction, SDZ, tenant, time window, clause families, risk class, data class, public-safe class, Project SPV scope if applicable, credential schema scope if applicable, simulation model scope if applicable, and authority class. The **CAC index** section includes deterministic ordering rule, number of CACs, CAC root hash, index root hash, inclusion proof format, and searchable metadata commitments. The **attestation summary** section includes execution backend summary, TEE node set, ZK proof references, verifier signatures, runtime profiles, and proof statuses. The **hash graph** section includes CAC root, input root summary, output root summary, credential impact root, simulation dependency root, trigger root, failure root, public-safe root, and full rollup hash. The **governance metadata** section includes governance body or registry scope, approving or publishing actor, review status, dispute status, fork compatibility, credential impact summary, public-safe restrictions, and correction path. The **storage and disclosure** section includes storage class, encryption profile, public fields, restricted fields, sovereign mirror references, community restrictions, enterprise evidence room references, and public anchor status. The **query metadata** section includes indexed fields, allowed query classes, access requirements, and aggregation limitations. The **audit and lifecycle** section includes audit anchor, registry entry, correction history, supersession status, deprecation status, and replay profile. This schema allows rollups to become structured governance assets rather than opaque compressed archives. ### Merkle Trees and Hash Commitments The technical foundation of a CAC Rollup is a deterministic hash commitment structure. Individual CACs are canonicalized, hashed, ordered, and inserted into a Merkle tree or equivalent authenticated data structure. The resulting root, the `cac_root`, commits to every CAC in the rollup. If any CAC changes, the root changes. Deterministic ordering is essential. Without a canonical ordering rule, different rollup builders could produce different roots for the same CAC set. Ordering may use timestamp, execution ID, clause hash, jurisdiction, or a defined tuple. The ordering rule must be recorded in the rollup header. Each CAC may be indexed by execution ID, Clause ID, Clause Hash, timestamp, jurisdiction, domain, trigger type, credential impact, simulation model, output status, public-safe class, and risk class. Indexes may be separate Merkle trees or committed metadata structures. Sensitive fields should be hashed or selectively disclosed. Merkle inclusion proofs allow a verifier to prove that a specific CAC belongs to a rollup without accessing every CAC. A national node can verify that its execution is included. A credential issuer can verify that a credential-supporting CAC is part of an official evidence batch. A public-safe dashboard can verify that a displayed summary derives from a rollup root. A dispute reviewer can inspect only the affected branch. Hash commitments support stateless validation. An AI agent or auditor can verify a CAC inclusion proof against the rollup root, then verify the rollup root against the Audit Layer or public anchor. It does not need to load the entire rollup. For restricted rollups, the root may be public while contents remain encrypted or controlled. This supports transparency without disclosure. ### Hash Graphs Beyond Simple Merkle Trees A simple Merkle tree proves membership. NSF often needs more than membership. It needs relationship tracing across clauses, credentials, simulations, triggers, jurisdictions, tenants, and failure states. For this reason, CAC Rollups may use richer hash graphs. A rollup hash graph can include multiple committed roots: The CAC root commits to individual CAC records. The clause root commits to all clause hashes represented in the rollup. The input root commits to input commitments. The credential root commits to credential states and impacts. The simulation root commits to simulation packages and run IDs. The trigger root commits to triggering events. The output root commits to output statuses and actions requested. The failure root commits to failures and safe-mode states. The jurisdiction root commits to jurisdictional and SDZ scope. The tenant root commits to tenant metadata. The public-safe root commits to public-safe classes and disclosure rules. This multi-root structure enables targeted verification. A reviewer may verify all CACs linked to a specific simulation model. A public-safe reviewer may inspect only public output classes. A credential issuer may inspect credential-affecting CACs. A national node may verify jurisdictional inclusion. Hash graphs make rollups useful for governance analysis, not only cryptographic compression. ### Rollup Generation Protocol A CAC Rollup should be generated through a governed protocol. The rollup builder cannot simply bundle records arbitrarily. It must validate individual CACs, apply scope rules, canonicalize order, generate commitments, sign the rollup, publish audit records, and update registry indexes. The protocol begins with CAC collection. CACs may be collected from TEE nodes, ZK execution systems, national nodes, regional nodes, edge devices after synchronization, enterprise evidence rooms, public-safe workflows, or credential systems. Each CAC must be individually validated before inclusion. Invalid, disputed, incomplete, or unverifiable CACs should be excluded, quarantined, or included only under a failure or disputed status root. The rollup builder then verifies scope. It checks that each CAC belongs to the declared domain, time window, jurisdiction, tenant, clause family, simulation model, or other rollup scope. A CAC outside scope should not be included. Next, the builder canonicalizes CAC representations and orders them deterministically. It generates Merkle trees or hash graphs, computes roots, prepares indexes, and produces inclusion proof metadata. The builder signs the rollup. Depending on risk, the signature may come from a rollup coordinator, TEE aggregation node, ZK rollup builder, national node, regional registry, controlled-room reviewer, or verifier quorum. High-risk rollups may require threshold signatures. The rollup is written to the Audit Layer. Registry indexes are updated. Optional public or sovereign anchors are written. Subscribers are notified through the Communication Layer. A rollup lifecycle event should be emitted: RollupCreated, RollupVerified, RollupAnchored, RollupDisputed, RollupCorrected, RollupSuperseded, or RollupArchived. This protocol ensures that a rollup is not just compressed data. It is governed aggregation. ### Rollup Coordinators and Builders CAC Rollups may be generated by different authorized builders depending on scope. A national rollup coordinator may aggregate CACs within a national SDZ or national registry. A regional coordinator may aggregate cross-border CACs for a regional corridor or hazard. A global reference coordinator may aggregate public reference tests or standards-mapping executions. A Project SPV evidence room may aggregate enterprise CACs for a reporting period. A public-safe coordinator may aggregate public dashboard outputs. A ZK rollup builder may aggregate privacy-preserving CAC commitments. A TEE aggregation node may generate rollups from enclave-executed workloads. The seed refers to DAO-elected or node-affinitized agents. The mature framing should be role-bound: rollup coordinators, registry stewards, national nodes, regional coordinators, community stewards, enterprise evidence room operators, or governance-approved builders. DAO tooling may support selection or governance, but the authority should be credentialed and scoped. Rollup builders should hold credentials such as `CACRollupCoordinatorVC`, `NationalRollupPublisherVC`, `RegionalRollupPublisherVC`, `ZKRollupBuilderVC`, `ProjectSPVEvidenceRollupVC`, or `PublicSafeRollupPublisherVC`. The credential should specify scope, allowed domains, jurisdiction, proof profiles, data classes, and publication rights. A rollup built by an unauthorized actor may still be a technical bundle, but it should not be treated as a valid NSF governance rollup. ### Cross-Domain Rollups CAC Rollups can be scoped across domains when governance requires systemic analysis. A disaster event may generate CACs across flood risk, food security, logistics, public health, public-safe reporting, emergency coordination, finance-readiness evidence, insurance-readiness evidence, and community safeguards. A climate transition program may generate CACs across emissions, energy, finance, labor, biodiversity, and infrastructure. An AI incident may generate CACs across model governance, data access, cybersecurity, public-safe outputs, and credential status. A cross-domain rollup should include domain scope metadata and relationship indexes. It should show which clauses belong to which domain, which triggers linked them, which simulations contributed, which credentials were affected, and which public-safe outputs were produced. Cross-domain rollups are valuable because real risks do not respect sector boundaries. But they are also sensitive because they may combine data classes and jurisdictions. Disclosure profiles must be strict. Public summaries may expose only aggregate results. Restricted reviewers may access more. Cross-domain rollups support systemic governance analysis without forcing raw data centralization. ### Cross-Jurisdiction Rollups Cross-jurisdiction rollups aggregate CACs across multiple jurisdictions, national nodes, regional corridors, treaty-aligned contexts, or shared risk systems. They can support regional disaster review, river-basin coordination, cross-border disease surveillance, migration risk, supply-chain continuity, emissions comparison, food systems monitoring, or shared infrastructure. Each cross-jurisdiction rollup must include jurisdictional constraint declarations. These specify what each jurisdiction allowed to be included, what fields are public, what fields are restricted, whether raw CACs remain in national mirrors, whether only commitments are shared, and which recognition rules apply. A cross-jurisdiction rollup should not override national data sovereignty. It should aggregate commitments and permitted metadata where raw data cannot move. Inclusion proofs can show that national CACs were part of the rollup without disclosing protected payloads. Fork compatibility is especially important. A flood readiness CAC from one national fork may not be directly comparable to another. The rollup should include fork compatibility indexes and semantic mapping notes. Cross-jurisdiction rollups enable regional visibility while preserving sovereign control. ### Simulation-Centered Rollups A rollup may group every CAC derived from one simulation model, simulation bundle, scenario package, or digital twin. This is useful for model governance. If a flood risk model produces dynamic thresholds across many clauses, a simulation-centered rollup can aggregate all CACs that used that model during a period. If the model is later corrected or quarantined, the rollup helps identify affected executions. If observed outcomes diverge from forecasts, reviewers can compare model-linked CACs. If a model update changes outputs, rollups can support before-and-after analysis. Simulation-centered rollups should include model ID, model version, simulation bundle, run IDs, scenario classes, uncertainty labels, domains, jurisdictions, output summaries, and affected clauses. Sensitive model inputs may remain protected. These rollups are key to epistemic accountability. They make model dependency visible at scale. ### Trigger-Aligned Rollups Reactive governance benefits from trigger-aligned rollups. A major hazard, public health event, cyber incident, emissions reporting period, AI incident, or supply-chain disruption can trigger many clauses. A trigger-aligned rollup groups all CACs generated by a shared event or trigger family. For example, a flood event may generate CACs for sensor validation, simulation update, readiness review, public-safe communication, credential activation, logistics support, Project SPV infrastructure review, and finance-readiness evidence. A trigger-aligned rollup lets reviewers reconstruct the full event response. Trigger-aligned rollups should include trigger ID, trigger source, event time, trigger validation records, affected jurisdictions, clause families, output statuses, failures, safe-mode events, and public-safe outputs. They should also include correction status if a trigger was later disputed. These rollups turn events into auditable governance episodes. ### Rollup Compression and Query Models CAC Rollups reduce storage and verification burden, but compression must not erase meaning. A rollup may reduce storage through canonicalization, deduplication, commitment structures, encrypted payload separation, metadata indexing, and root anchoring. The seed suggests one to three orders of magnitude storage reduction. This may be achievable in some contexts, but should be treated as an engineering target rather than a universal guarantee. Compression depends on CAC size, input payload references, proof type, encryption, indexing, and disclosure model. Rollups should support indexed search over CAC fields. Queries may filter by Clause ID, domain, jurisdiction, time range, risk class, output status, credential impact, simulation model, trigger ID, tenant, failure class, public-safe status, fork, or node. A query may look like: ```json { "query": "clause_id LIKE 'UNFCCCRef::%'", "time_range": "2025-Q1", "jurisdiction": "IND", "risk_class": ">3", "output_status": "REVIEW_REQUIRED" } ``` The seed example uses “emissions violations.” Safer language is “emissions threshold exceedances,” “emissions evidence flags,” or “emissions review-required outputs,” unless a competent authority has made a violation determination. Rollup-based search should respect access controls. A public user may query public summaries. A national node may query domestic CACs. A regional consortium may query cross-border commitments. A Project SPV reviewer may query controlled evidence. A public-safe reviewer may query disclosure status. Sensitive fields require credentials. Queryability is one of the primary benefits of rollups. It turns proof archives into governance intelligence. ### Batch Replay and Rollup Audits Rollups support batch replay. Instead of replaying one CAC, a reviewer can replay or verify an entire rollup, a subset of CACs, or all CACs matching a query. This is useful for governance challenges, simulation comparison, model drift review, public-safe correction, credential impact analysis, and incident review. Batch replay may be exact, proof-based, controlled, statistical, or methodological depending on underlying CAC replay classes. A rollup should state which replay classes are represented. A rollup containing restricted health CACs may support proof replay for public reviewers and controlled replay for authorized health reviewers. A simulation rollup may support statistical replay. Rollup audits can answer questions such as: Which CACs used a deprecated model? Which outputs were generated under an emergency override? Which credentials were affected by a disputed clause fork? Which public-safe outputs lacked correction propagation? Which Project SPV evidence CACs depended on a stale parameter? Which national nodes produced CACs under the same regional trigger? Which clauses repeatedly failed under one runtime profile? Batch replay makes governance review scalable. ### ZK-Enabled Rollup Integrity Privacy-critical domains require rollups that can be verified without revealing underlying CAC content. ZK-enabled CAC Rollups allow membership, consistency, aggregation, and summary claims to be proven while keeping details confidential. A ZK rollup may prove that all included CACs satisfy a schema, belong to a time window, were signed by authorized nodes, and have outputs within a declared summary class, without revealing individual records. It may prove that a count exceeds a threshold, that no CAC failed a public-safe condition, that credential revocation checks were performed, or that all included executions used an active clause version. A ZK rollup record may include: ```json { "rollup_id": "cacrollup-0x...", "proof_profile": "ZK-CACRollup@1.0", "zk_proof": "stark@0x934f...", "circuit_commitment": "0xAAFF...", "verifier_key": "did:nsf:zk-registry:2025-Q2", "public_claims": { "included_cac_count": 247, "jurisdiction": "restricted-commitment", "schema_valid": true } } ``` ZK rollups are useful for health, finance-readiness, insurance-readiness, community data, critical infrastructure, protected humanitarian contexts, and confidential enterprise evidence. But proof scope must be clear. A ZK rollup proves only its circuit statements. It does not prove that input data was true, that models were correct, that legal compliance occurred, that finance is approved, or that insurance coverage exists. ZK rollups allow transparency of structure without exposure of content. ### Aggregate Signatures and Verifier Sets A rollup should include aggregate signatures. The signature may come from one authorized coordinator, a threshold set of validators, multiple enclave nodes, national nodes, regional verifiers, or controlled-room reviewers depending on risk. BLS signatures or other aggregation methods may compress multiple signatures. Multi-signature sets may show that three of five validators approved rollup publication. A TEE enclave set may show that the rollup was generated by approved aggregation nodes. A ZK verifier set may show that proof verification succeeded. Verifier sets must be credentialed and scoped. A verifier set for public test rollups is not the same as a verifier set for national health rollups or Project SPV controlled evidence. The rollup should state who verified what. Did they verify inclusion? Schema validity? TEE attestations? Public-safe status? Governance scope? Simulation linkage? The signature scope must be explicit. An aggregate signature increases trust in rollup integrity. It does not automatically approve the underlying policy outputs. ### Governance and Anchoring CAC Rollups are governance assets. They may be referenced in governance proposals, audit reviews, dispute processes, public-safe reports, simulation retraining decisions, credential issuer reviews, and Project SPV evidence packages. A governance body may use a rollup to evaluate policy outcomes. For example, a disaster review body may examine all CACs from a flood event. A simulation governance body may analyze model-linked CACs. A credential issuer may review rollups of credential status actions. A public-safe body may review outputs flagged for correction. A Project SPV may present controlled rollups to authorized diligence reviewers. Rollup records may produce review credentials or attestations such as `RollupAuditVC`, but the name should be used carefully. A safer term may be `RollupReviewRecord`, `RollupAuditReceipt`, or `RollupVerificationRecord`, unless a formal audit credential is intended. Such records should state their scope and limitations. Rollups may trigger simulation retraining if anomalies are detected. For example, repeated forecast mismatch across rollup records may trigger model review. Repeated public-safe corrections may trigger clause revision. Repeated input failures may trigger data provider review. Anchoring rollup roots to public ledgers may improve timestamping and tamper evidence. But public anchors should generally include only hash commitments and public-safe metadata. Sovereign or institutional mirrors may store full rollups under access control. Community and enterprise rollups may remain restricted. Governance anchoring makes rollups durable and reviewable, not self-authorizing. ### Rollups and Dispute Resolution Rollups are valuable in disputes because they preserve batch context. A dispute may challenge one CAC, a clause family, a parameter update, a simulation model, a trigger event, a node, a runtime, or an entire time period. Rollups allow the affected set to be identified. If a clause fork is disputed, rollups can identify all CACs generated under that fork. If a model is quarantined, simulation-centered rollups identify dependent outputs. If a TEE node is compromised, rollups identify CACs signed by that node. If a public-safe output was unsafe, rollups identify related publications. If a parameter value was wrong, rollups identify all executions that used it. A disputed rollup should not be deleted. It should be marked disputed, corrected, superseded, or partially invalidated according to governance review. Historical records remain preserved. Inclusion proofs remain meaningful, but current reliance may change. Dispute-aware rollups are essential for correctionability at scale. ### Rollups for Public Memory and Public-Safe Transparency Some rollups can support public memory. A public-safe disaster rollup may show that a set of evidence-support executions occurred during an event, without disclosing sensitive data. A climate evidence rollup may publish aggregate threshold-exceedance counts. A public test rollup may show conformance testing results. A registry rollup may show clause activation events. Public rollups must include public-safe labels. They must distinguish evidence support from official public action. They must avoid revealing sensitive inputs, protected locations, personal data, security vulnerabilities, market-sensitive Project SPV information, or community-protected knowledge. Public memory is powerful only when disciplined. A rollup can show that the system observed and processed signals. It should not imply official warnings, regulatory findings, finance approval, insurance underwriting, or legal conclusions without competent authority. ### Rollups Across GNC, RNC, and NNC Architecture CAC Rollups operate across the Nexus multiscale architecture. At the national level, National Nexus Consortiums may generate national CAC Rollups inside national SDZs. These rollups can cover domestic disaster risk, public health, infrastructure, climate, credentials, Project SPV evidence, public-safe outputs, and national registry events. National rollups preserve domestic control and may publish only commitments externally. At the regional level, Regional Nexus Consortiums may generate rollups for shared hazards, river basins, corridors, cross-border public health, regional simulations, mutual recognition, and regional public-safe dashboards. Regional rollups may aggregate national commitments while leaving raw CACs in national mirrors. At the global level, the Global Nexus Consortium may maintain reference rollup schemas, proof profiles, public-good query standards, and interoperability tools. It may aggregate public reference CACs and standards-mapping outputs. It should not centralize all national or enterprise rollup payloads. At the community level, community governance bodies may maintain community-controlled rollups for protected knowledge, public-safe mapping, local hazard signals, and community safeguards. These rollups require special disclosure controls. At the enterprise layer, National Consortium Companies, Project SPVs, operators, providers, insurers, investors, and contractors may maintain enterprise rollups for controlled evidence workflows. These rollups support lawful delivery and review, not public-good endorsement, finance approval, or insurance underwriting. Rollups allow governance memory to scale while remaining distributed. ### Rollup Security and Failure Modes CAC Rollups introduce their own risks. A rollup builder may include invalid CACs, omit relevant CACs, misclassify scope, leak sensitive metadata, use wrong ordering, sign with compromised keys, anchor incorrect roots, expose public data improperly, or produce misleading summaries. NSF should define rollup validation and safe-mode logic. A rollup should be rejected or disputed if its root does not match contents, signatures fail, coordinator credential is invalid, scope metadata conflicts with CACs, ordering rule is violated, public-safe rules are breached, proof verification fails, or required CACs are missing. Rollup failure should generate a RollupFailureNotice or equivalent failure record. A failed rollup should not erase included CACs. The underlying CACs remain individually auditable. A corrected rollup may supersede the failed one. Rollup security requires independent validation, reproducible building, key management, access control, public-safe review, and audit monitoring. ### Rollup Boundary Statement CAC Rollups support scalable execution aggregation, Merkleized inclusion proofs, audit compression, queryable governance memory, batch replay, ZK privacy, cross-domain analysis, cross-jurisdictional evidence coordination, simulation dependency review, credential impact tracing, public-safe reporting, Project SPV evidence organization, finance-readiness evidence, and insurance-readiness evidence. They do not by themselves create legal authority, regulatory approval, certification, procurement approval, finance approval, investment advice, insurance underwriting, claims determination, official public warnings, treaty enforcement, legal liability determination, or proof that underlying data was true. A rollup proves that a set of CACs was committed, indexed, signed, and anchored under a declared scope. The meaning of the underlying outputs depends on the individual CACs, clause authority class, source data, credential scope, simulation validity, governance review, jurisdiction, public-safe rules, and applicable law. A rollup is not a legal ledger by itself. A rollup root is not regulatory approval. A rollup summary is not official public warning. A finance-readiness rollup is not finance approval. An insurance-readiness rollup is not underwriting. A ZK rollup proves only its stated circuit claims. A public anchor proves timestamped commitment, not institutional endorsement. This boundary must appear in rollup schemas, registry pages, audit dashboards, public-safe reports, query tools, and documentation. ### Rollups as the Ledger of Risk-Aware Governance CAC Rollups are the scalable memory layer of NSF execution. They allow millions of clause executions to become queryable, auditable, verifiable, and correctable without forcing every actor to inspect every receipt one by one. They compress evidence without erasing accountability. They support public memory without reckless disclosure. They support cross-border coordination without centralizing sovereign data. They support simulation governance without losing model dependency traces. They support Project SPV and capital-relevant evidence without crossing into regulated decision-making. They allow the world to ask, under proper authorization: What executed? Which clause version ran? What triggered it? Which jurisdiction governed it? Which node executed it? Which credentials were affected? Which simulations contributed? Which public-safe outputs were produced? Which failures occurred? Which proofs verify inclusion? Which records are disputed? Which patterns require review? Which models need retraining? Which clauses require correction? This is not merely a storage optimization. It is institutional-scale execution memory. CACs make individual executions verifiable. CAC Rollups make governance at scale intelligible. Together, they form the execution ledger of the Nexus Sovereignty Framework: distributed, proof-bound, jurisdiction-aware, privacy-preserving, audit-ready, and correctionable. That is the role of CAC Rollups in NSF: to make large-scale verifiable governance computationally practical without sacrificing sovereignty, public-good discipline, legal boundaries, or trust-minimized proof. --- # 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/clause-attested-compute.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.