# CAC Schema

#### **4.2.1 What is a CAC?**

**Clause-Attested Compute (CAC)** is the **primary cryptographic artifact** produced by the NSF Execution Layer when a Smart Clause is run in a TEE or verifiable compute environment.

Each CAC:

* Encapsulates the execution result of a clause
* Proves the inputs, outputs, and runtime conditions
* Links to simulation outputs, credential states, and trigger metadata
* Includes signed attestation from the enclave and/or ZK circuit
* Is immutably recorded in the **Audit Layer**, and optionally anchored to public ledgers

CACs are the **machine-verifiable equivalent of “policy acted”**.

***

#### **4.2.2 CAC Schema Overview**

Every CAC contains the following **top-level fields**:

```json
{
  "clause_id": "WFP::Food::ToxinThreshold@1.2.3",
  "execution_id": "cac-0x81ab4d...",
  "timestamp": "2025-04-30T16:21:43Z",
  "trigger": {
    "type": "sensor",
    "source": "EO::Copernicus::Sentinel5",
    "event_id": "evt-0xdeadbeef"
  },
  "inputs": {
    "sensor_data": {...},
    "credentials": [...],
    "simulation_results": {...}
  },
  "outputs": {
    "status": "VIOLATION",
    "action": "Revoke:FoodExportVC"
  },
  "attestation": {
    "runtime_hash": "0xcafe...",
    "enclave_quote": "SGXQuote:0xabc...",
    "signer": "did:nsf:TEEExecutor#node42",
    "signature": "0xDEADBEEF...",
    "public_keys": [...],
    "attestation_type": "TEE"
  },
  "governance_scope": {
    "jurisdiction": "KEN",
    "dao": "WFP-RegionalDAO",
    "clause_fork": "WFP::Food::ToxinThreshold@1.2.3-KE"
  },
  "hash_graph": {
    "input_hash": "0x123abc...",
    "output_hash": "0x456def...",
    "full_cac_hash": "0x789fed..."
  }
}
```

Each field supports **cryptographic audit, governance enforcement, and multi-party verification**.

***

#### **4.2.3 Input Substructure**

The `inputs` section is itself a structured schema:

* `sensor_data`: timestamped, attested, signed IOT/EO values
* `credentials`: subject, issuer, revocation status, VC hash
* `simulation_results`: versioned model ID, run parameters, forecast outputs
* Optional: `external_calls` from smart contracts or RPC inputs

Each field includes:

* Provenance link
* Credential validator ID
* Schema version hash
* Data timestamp and jurisdiction

***

#### **4.2.4 Attestation Metadata**

The `attestation` section includes:

* **Enclave identity hash**
* **Remote attestation quote** (SGX, SEV, TrustZone, Enarx)
* **Signature over full clause + input hash**
* **Signer DID** (authorized TEE executor)
* **Runtime build hash** (governance-certified)
* Optional: **zero-knowledge proof commitment** (if ZK backend used)

This ensures **execution integrity**, **environment isolation**, and **replay protection**.

***

#### **4.2.5 Governance and Jurisdictional Scoping**

Each CAC includes:

* Jurisdiction tag (ISO 3166 or custom treaty scope)
* DAO scope (governance entity validating this execution)
* Fork lineage (if this clause is a derivative of a canonical global clause)
* Credential issuer compatibility metadata

This enables:

* Localized enforcement
* Cross-DAO audit
* Governance rollback
* Treaty-anchored action triggers

***

#### **4.2.6 Hash Graph Structure**

NSF uses **hash graphs** to:

* Prove CAC integrity
* Chain executions
* Anchor inputs, outputs, attestations, and simulation states

| Hash            | Description                            |
| --------------- | -------------------------------------- |
| `input_hash`    | Combined SHA256 of all input fields    |
| `output_hash`   | Combined hash of clause output state   |
| `enclave_hash`  | Runtime + code + governance scope hash |
| `full_cac_hash` | Final Merkle root of all CAC elements  |

Hash graphs are:

* Included in the Audit Layer
* Discoverable in the Registry Layer
* Verifiable by ZK or enclave validators
* Anchorable to public blockchains

***

#### **4.2.7 Serialization and Signing**

CACs are serialized using:

* **JSON-LD or CBOR** (for DID compatibility and ZK serialization)
* Encrypted (optional) using recipient public key
* Signed using:
  * Enclave key (if TEE)
  * Prover key (if ZK)
  * Agent key (if user-run copilot)
  * DAO signer (optional co-sign for public CACs)

Signatures use:

* Ed25519
* ECDSA
* BLS (if aggregated validators)
* Optional: multi-sig DAO key sets

***

#### **4.2.8 CAC Versioning and Schema Evolution**

CAC schema is versioned:

* `CACSchema@1.0`
* `CACSchema@2.1-zk` (ZK-compatible variant)
* `CACSchema@3.0-gov+` (includes governance metadata and override history)

DAO validators may enforce:

* Allowed schema versions
* Input/output typing checks
* Compatibility constraints per clause
* Simulation package linkage per version

All schema versions are registered in the Registry Layer with full changelogs and diff tooling.

***

#### **4.2.9 Integration with Other NSF Layers**

CACs are **linked across the protocol stack**:

| Layer                | Role                                                           |
| -------------------- | -------------------------------------------------------------- |
| **Audit Layer**      | Records CACs immutably and supports search/filter/replay       |
| **Credential Layer** | Triggers issuance or revocation of VCs based on clause results |
| **Governance Layer** | Used in DAO votes, overrides, or dispute arbitration           |
| **Simulation Layer** | Binds forecast inputs to clause execution                      |
| **Interop Layer**    | Aligns CAC outputs with ISO/WHO/ICAO etc. regulatory semantics |
| **Registry Layer**   | Logs clause, fork, and schema IDs referenced in CAC            |

CACs become the **common substrate of trust** across agents, institutions, and jurisdictions.

***

#### **4.2.10 CACs as Verifiable Execution Receipts**

A CAC is more than a log. It is:

* A **receipt of action**
* A **proof of governance logic applied**
* A **cross-domain trust anchor**
* A **replayable, inspectable trace**
* A **governance transaction unit**

With CACs, NSF replaces:

> "We think this rule was followed"\
> with\
> "We can prove this rule was executed, here is the full trace."


---

# Agent Instructions: 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:

```
GET https://docs.therisk.global/organization/standardization/nexus-sovereignty/iv.-verifiable-execution/cac-schema.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.