# AI CER Verification Layers

URL: https://docs.nexart.io/docs/ai-cer-verification-layers

How AI CER verification layers stack up: bundle integrity, node signature, receipt consistency and envelope checks, and what each layer actually proves.

Mental model
- Integrity ≠ Stamp ≠ Envelope.
- Each layer has one job and fails for one reason.
- Public/redacted records cannot satisfy Layer 3.

## Overview

NexArt AI CER bundles support up to three independent verification layers. Each layer protects a distinct part of the record, and each can be validated independently.

- Bundle Integrity - protects execution evidence and context
- Signed Attestation Receipt - protects attestation receipt fields
- Verification Envelope - protects the authoritative displayed verification surface

Not all layers are present on every artifact. Historical records may include only the first two layers. Newer uploaded AI CER bundles may include all three.

## Layer 1: Integrity (certificateHash)

The `certificateHash` is computed as a SHA-256 digest over a strict whitelist projection of the CER bundle, canonicalized per the profile selected by `protocolVersion` (1.2.0 → nexart-v1, default; 1.3.0 → jcs-v1 / RFC 8785, opt-in).

Hashed fields (whitelist):

- `bundleType`
- `version`
- `createdAt`
- `snapshot`
- `context` (only if present)
- `contextSummary` (only if present)
- `policyEvaluation` (only if present)

NOT hashed: `certificateHash`, `meta`, `declaration`, `verificationEnvelope`, `verificationEnvelopeSignature`, `receipt`, and any unknown fields.

Canonicalization is protocol-bound. Verifiers MUST apply the whitelist projection to the bundle exactly as received and use the canonicalization profile corresponding to the bundle's `protocolVersion`. No reconstruction. No field stripping.

What it protects: execution snapshot, context signals (when included in `context`), and bundle metadata fields covered by the whitelist.

## Layer 2: Signed Attestation Receipt

When a CER is attested by the attestation node, the node returns a signed receipt stored at `meta.attestation` in the bundle.

### Receipt Fields

- `meta.attestation.receipt` - the receipt payload containing `certificateHash`, `timestamp`, `nodeId`, and `kid`
- `meta.attestation.signature` - raw Ed25519 signature bytes over the deterministically serialized receipt payload
- `meta.attestation.kid` - key identifier; resolves via the node's published metadata at `node.nexart.io/.well-known/nexart-node.json`

What it protects: attestation receipt fields (certificateHash binding, timestamp, node identity, signature validity).

## Layer 3: Verification Envelope

Uploaded and newer AI CER bundles may include a verification envelope that protects the authoritative displayed verification surface.

### Envelope Fields

In the official package format, verification envelope fields are at the package level:

- `verificationEnvelope` - metadata describing the v2 verification envelope
- `verificationEnvelopeSignature` - signature over the v2 signable payload

For legacy/raw bundle artifacts, these fields may appear inside `meta` as a compatibility fallback.

### Package-Path Signable Payload (v2)

For the official package format, verifiers reconstruct the v2 signable payload as:

v2 Signable Payload Construction

```
{
  "attestation": package.verificationEnvelope.attestation,
  "bundle": package.cer,
  "envelopeType": package.verificationEnvelope.envelopeType
}
```

- Attestation projection — exactly 5 fields: `attestationId`, `attestedAt`, `kid`, `nodeRuntimeHash`, `protocolVersion`.
- Bundle projection (whitelist): `bundleType`, `version`, `createdAt`, `snapshot`, `context` (if present), `contextSummary` (if present).
- `certificateHash` is NOT part of the signed payload.
- `meta` is NOT signed by the envelope.
- `receipt` is NOT signed by the envelope.
- The full package object is NOT the signed payload.
- `verificationEnvelope` itself is NOT the signed payload.
- For the package path, `cer` is used as-is. Any mutation after signing will cause this check to fail.

What it protects: full bundle integrity under the node's signature, beyond the certificateHash. Envelope failure indicates the signed bundle projection has been altered. It MUST NOT be reported as integrity (Layer 1) failure.

## Field-Level Reference

The following fields may be present on an uploaded AI CER bundle:

AI CER Bundle with All Three Verification Layers

```
{
  "bundleType": "cer.ai.execution.v1",
  "version": "0.1",
  "createdAt": "2026-03-17T10:00:00.000Z",
  "snapshot": {
    "model": "gpt-4",
    "inputHash": "sha256:a1b2c3...",
    "outputHash": "sha256:d4e5f6...",
    "metadata": { "appId": "my-app" }
  },
  "context": {
    "signals": [
      { "type": "policy.check", "source": "compliance-engine", "payload": { "result": "pass" } }
    ]
  },
  "certificateHash": "sha256:9e8d7c...",
  "meta": {
    "attestation": {
      "receipt": {
        "certificateHash": "sha256:9e8d7c...",
        "timestamp": "2026-03-17T10:00:01.000Z",
        "nodeId": "nexart-node-primary",
        "kid": "key_01HXYZ..."
      },
      "signature": "<Ed25519 signature bytes>",
      "kid": "key_01HXYZ..."
    },
    "verificationEnvelope": { "...signed verification surface..." },
    "verificationEnvelopeSignature": "MEUCIQD..."
  }
}
```

## Tamper Behavior

Each verification layer independently detects specific types of modification:

| Modification | Layer Affected | Result |
| --- | --- | --- |
| Change snapshot.model | Bundle Integrity | FAIL |
| Change context.signals | Bundle Integrity | FAIL |
| Change meta.attestation.receipt or signature | Signed Attestation Receipt | FAIL |
| Change meta.verificationEnvelope or its signature | Verification Envelope | FAIL |

## Backward Compatibility

- Historical artifacts may not include `meta.verificationEnvelope`. These records are verified using Bundle Integrity and Signed Attestation Receipt only. They remain valid.
- Historical public artifacts may not hash-cover `context`. Older bundles that predate context signal support do not include `context` in the `certificateHash` computation.
- The verifier applies compatibility fallback for older artifacts. The verification logic detects the bundle version and applies the appropriate checks.
- Newer uploaded bundles with a verification envelope have stronger protection. The additional layer provides tamper detection over the displayed verification surface.

## Relationship to Other Documentation

- For the official package format and bundle immutability rules, see AI CER Package Format.
- For the CER data model and bundle structure, see the CER Protocol specification.
- For verification checks and statuses, see Verification.
- For the attestation node contract, see Attestation Node.
- For context signals, see Context Signals.