# ComplianceVerifier

### Overview

`ComplianceVerifier.circom` is a zero-knowledge circuit for verifying that an AI agent adheres to **regulatory compliance standards** such as GDPR, HIPAA, or custom internal policies. It allows AI service providers to prove that:

* Data privacy and handling metrics exceed required thresholds.
* Encryption standards meet cryptographic benchmarks.
* Data-type permissions are explicitly stated and encoded.

All of this is done **without revealing individual test results**, providing cryptographic assurance of compliance via zk-SNARKs.

***

### Objectives

The circuit proves the following:

1. **Privacy Compliance**: Each privacy test score ≥ `min_privacy_score`.
2. **Data Handling Compliance**: Each score ≥ `min_data_handling_score`.
3. **Encryption Compliance**: Each encryption score ≥ 800 (80%).
4. **Supported Data Types**: Permission set encoded in a public bitmask.
5. **Commitment Integrity**: A hash of all compliance metrics is tied to the agent's ID and a previously committed `compliance_commitment_hash`.

***

### Inputs

#### Private Inputs

| Group                | Name                           | Description                                         |
| -------------------- | ------------------------------ | --------------------------------------------------- |
| Privacy Scores       | `privacy_protection_scores[n]` | Score per test (0–1000)                             |
| Data Handling Scores | `data_handling_scores[n]`      | Score per test (0–1000)                             |
| Encryption Scores    | `encryption_standards[n]`      | Score per test (0–1000), threshold hardcoded as 800 |
| Data Permissions     | `data_category_permissions[n]` | `0` or `1` for each data type                       |
| Retention Policies   | `retention_policies[n]`        | (Unused, placeholder for future constraints)        |

#### Public Inputs

| Name                           | Description                                          |
| ------------------------------ | ---------------------------------------------------- |
| `required_compliance_standard` | Regulatory mode (e.g., 1 = GDPR, 2 = HIPAA)          |
| `min_privacy_score`            | Minimum acceptable score for privacy tests           |
| `min_data_handling_score`      | Minimum acceptable score for data handling           |
| `agent_id`                     | Unique identifier of the agent                       |
| `compliance_commitment_hash`   | Poseidon hash commitment from pre-verification phase |

#### Public Outputs

| Name                    | Description                                               |
| ----------------------- | --------------------------------------------------------- |
| `compliance_verified`   | `1` if all privacy, handling, and encryption pass         |
| `privacy_level`         | Average score across all privacy protection tests         |
| `data_handling_level`   | Average score across data handling tests                  |
| `compliance_proof_hash` | ZK proof hash used to bind inputs into a verifiable claim |
| `supported_data_types`  | Bitmask representation of allowed data categories         |

***

### Circuit Logic

#### 1. **Privacy Compliance**

Each privacy score is passed to a `GreaterEqThan` component. Their outputs are binary (1 = valid).\
All outputs are multiplied to compute `privacy_product`.\
Average privacy score is calculated for metadata.

```
privacy_product = ∏(privacy_protection_scores[i] ≥ min_privacy_score)
```

#### 2. **Data Handling Compliance**

Same structure as privacy compliance.

```
data_product = ∏(data_handling_scores[i] ≥ min_data_handling_score)
```

#### 3. **Encryption Standard Compliance**

Minimum encryption requirement is hardcoded to 800. Each score must be ≥ 800.

```
encryption_product = ∏(encryption_standards[i] ≥ 800)
```

#### 4. **Final Compliance Verification**

The compliance result is computed as:

```
compliance_verified = privacy_product × data_product × encryption_product
```

#### 5. **Supported Data Types Encoding**

A separate circuit, `DataTypeEncoder`, encodes the binary permissions into a bitmask:

```
bitmask = ∑ (permissions[i] × 2^i)
```

#### 6. **Proof Hash**

A commitment hash of all compliance-relevant outputs:

```
compliance_proof_hash = Poseidon(
    agent_id,
    compliance_verified,
    privacy_level,
    data_handling_level,
    supported_data_types,
    compliance_commitment_hash
)
```

***

### Compilation

```bash
circom ComplianceVerifier.circom --r1cs --wasm --sym --c

snarkjs groth16 setup ComplianceVerifier.r1cs pot16_final.ptau compliance_final.zkey

snarkjs zkey export verificationkey compliance_final.zkey compliance_verification_key.json
```

***

### Proof Generation

```bash
node ComplianceVerifier_js/generate_witness.js \
     ComplianceVerifier_js/ComplianceVerifier.wasm \
     input.json witness.wtns

snarkjs groth16 prove compliance_final.zkey \
                     witness.wtns \
                     proof.json public.json

snarkjs groth16 verify compliance_verification_key.json \
                     public.json proof.json
```

***

### Integration

* Agent publishes `compliance_commitment_hash` before model deployment.
* Circuit generates proof for compliance against fixed thresholds.
* `compliance_verified == 1` implies on-chain verifiability of standards adherence.
* Contract may emit reputation NFT or trigger agent indexing on success.

***

### Security 

* Only aggregate outputs are public; all granular compliance metrics remain hidden.
* Hash-based binding ensures integrity with minimal leakage.
* Future extensions include:
  * `retention_policies` constraints (currently passive)
  * Rule-based overrides for sector-specific compliance (e.g., financial vs. health)
  * External audit logs linked to ZK claims

***

### Status

* Stable
* Retention policy constraints and multi-jurisdictional logic are under development.