CAC Schema

The Canonical Structure of Clause-Attested Compute Outputs for Proof-Backed Governance

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:

{
  "clause_id": "WFP::Food::[email protected]",
  "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::[email protected]"
  },
  "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:

• [email protected]

• [email protected] (ZK-compatible variant)

• [email protected]+ (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."