# Compute Layer

#### **2.2.1 The Execution Problem in Policy Systems**

In traditional policy systems, enforcement is:

* **Interpretive** (dependent on bureaucratic discretion)
* **Deferred** (audits post-factum, often years later)
* **Disjointed** (separate systems for compliance, law, and automation)
* **Opaque** (no transparent link from rule to execution to outcome)

As AI agents, autonomous systems, and automated governance increase, this model becomes untenable.

What’s required is **verifiable execution infrastructure** that:

* Is **deterministic** and tamper-proof
* **Captures proof of execution** in machine-verifiable formats
* **Binds execution to human-authored policy logic**
* Runs **autonomously**, yet transparently, across jurisdictions

The NSF Compute Layer is engineered to address exactly this challenge.

***

#### **2.2.2 Role of the Compute Layer**

The NSF Compute Layer serves three core functions:

1. **Orchestrate the deterministic execution of Smart Clauses**
2. **Securely isolate logic within trusted compute environments (TEEs, ZK environments, or secure enclaves)**
3. **Generate Clause-Attested Compute (CAC)**—the canonical record that proves what logic ran, under what inputs, and with what outputs

This transforms governance from a declaration into **a verifiable act**.

***

#### **2.2.3 Trusted Execution Environments (TEEs)**

NSF supports secure computation in:

| TEE Type               | Description                                                               |
| ---------------------- | ------------------------------------------------------------------------- |
| **Intel SGX**          | Widely available enclave for mission-critical, confidential logic.        |
| **AMD SEV**            | Secure VM isolation for virtualized deployments.                          |
| **ARM TrustZone**      | Lightweight edge-compatible enclaves (IoT, mobile).                       |
| **Enarx / WASM**       | Portable, open-source enclave-compatible with multi-vendor architectures. |
| **Custom NSF Runners** | Simulation-only or enclave-simulated environments for air-gapped systems. |

The TEE ensures:

* **Code integrity**: Clause logic cannot be altered at runtime.
* **Data confidentiality**: Inputs are shielded, outputs are signed.
* **Proof generation**: Each clause execution yields a cryptographically verifiable artifact (the CAC).

***

#### **2.2.4 Clause Execution Workflow**

1. **Clause Call**: An agent, system, or contract requests a clause execution.
2. **Data Binding**: Inputs are pulled from the NSF Data Layer and verified against schema.
3. **Environment Provisioning**: A compatible enclave is selected or instantiated.
4. **Execution**: Clause runs under strict deterministic conditions.
5. **Output Generation**:
   * Result (e.g., PASS/FAIL/TRIGGER)
   * Execution context
   * Signed CAC
6. **Storage and Propagation**: CAC is published to the Audit Layer, linked to the originating clause and credential outcome.

***

#### **2.2.5 Clause-Attested Compute (CAC): Core Structure**

The **CAC** is the formal record of clause execution. It includes:

| Field                  | Description                                                  |
| ---------------------- | ------------------------------------------------------------ |
| **ClauseHash**         | Unique identifier of clause logic                            |
| **InputsHash**         | Digest of structured data inputs                             |
| **ExecutionTimestamp** | UTC timestamp from enclave clock                             |
| **TEEProof**           | Signed attestation from TEE environment                      |
| **JurisdictionTag**    | Legal scope of execution                                     |
| **Outcome**            | Result (PASS, FAIL, TRIGGER, ESCALATE)                       |
| **CredentialEffects**  | Issuance, revocation, or validation linked to clause outcome |
| **AuditHooks**         | Links to trace logs, simulations, or external validators     |

These records are non-repudiable, independently auditable, and can be stored immutably.

***

#### **2.2.6 CAC Verification Across Systems**

CACs serve as **cross-system evidence**, enabling:

* **Credential issuance** only if clause PASSed
* **Regulatory validation** of AI agents or autonomous vehicles
* **Disaster funding disbursement** tied to clause-governed thresholds
* **Intergovernmental audit** of treaty compliance (e.g., emissions, border control)

Any node, jurisdiction, or multilateral agency can verify a CAC without needing access to the runtime or raw inputs—**only the clause hash, the signed proof, and the CAC object**.

***

#### **2.2.7 ZK Execution and Proofs of Simulation**

In sensitive environments, NSF enables:

* **ZK Execution**: Running clause logic inside a zero-knowledge circuit (e.g., zkSNARKs, STARKs)
* **Proof of Simulation**: Where complex multi-run simulations are summarized as a ZK proof bundle

This allows:

* Refugee processing clauses to run without exposing identities
* Emissions credit validators to confirm inputs without revealing business secrets
* Parametric insurance payouts to validate across sensor thresholds without disclosing full datasets

NSF’s Compute Layer supports **ZK-enabled clause types**, and **CAC + ZKP bundles** are treated as standard artifacts within governance workflows.

***

#### **2.2.8 Execution Orchestration and Compute Market Integration**

NSF supports dynamic compute orchestration:

* Local nodes (e.g., sovereign TEEs)
* Distributed compute networks (e.g., Bacalhau, Filecoin Saturn)
* Institutional testbeds (e.g., WHO simulation grids, WFP disaster zones)
* Resource providers in NSF-registered compute pools (e.g., GPU/CPU job matchers)

NSF defines a **Compute Attestor Role**—responsible for confirming execution environment integrity, latency thresholds, and clause compatibility.

This opens the door to **market-based compute provisioning with governance-level verifiability**.

***

#### **2.2.9 Execution Policies and Governance Hooks**

Each clause has attached **execution policies**, including:

* Required enclave types
* Approved jurisdictions for processing
* Minimum governance version compatibility
* Fallback logic if enclave fails (e.g., human override, alert, rollback)
* Simulation preconditions before callable by agent classes

DAOs control execution parameters, update runners, and rotate TEE keys on quorum vote.

This ensures that compute is **not just secure—but institutionally governed**.

***

#### **2.2.10 The Compute Layer as the Rule Engine of the Trust Layer**

The Compute Layer of NSF is **not generalized compute**.

It is **governance-bound compute**:

* Every execution is traceable
* Every result is auditable
* Every effect is credential-linked
* Every clause is governed
* Every machine is accountable to human-authored policy logic

With the Compute Layer, NSF transforms governance into something **you can execute, inspect, trust, and enforce at global scale.**


---

# 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/ii.-architecture/compute-layer.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.