AI CER Verification Layers

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:

{
  "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:

{
  "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:

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.