Certified Execution Record (CER) Protocol

The NexArt protocol defines a standardized structure for Certified Execution Records (CERs) and the rules for verifying and evolving those records.

CERs allow AI executions and deterministic computations to produce portable, verifiable execution artifacts.

A CER contains:

• Execution snapshot
• Deterministic certificate hash
• Optional node attestation
• Verification metadata

These artifacts can be verified by any NexArt-compatible verifier.

Protocol Scope

The CER protocol defines the structure and verification semantics for execution records produced by NexArt-compatible systems.

The protocol currently supports multiple execution surfaces, including:

• AI execution certification
• Deterministic rendering (Code Mode)

Each surface defines its own namespace. Examples:

cer.ai.execution.v1
cer.codemode.render.v1

The protocol governs:

• CER bundle structure
• Verification semantics
• Schema versioning
• Compatibility rules
• Deprecation policies

Canonical CER Structure

A CER bundle is a structured JSON object.

{
  "bundleType": "cer.ai.execution.v1",
  "version": "0.1",
  "createdAt": "2026-03-08T20:30:00Z",
  "certificateHash": "sha256:...",
  "snapshot": {
    "type": "ai.execution.v1",
    "executionId": "demo-001",
    "provider": "openai",
    "model": "gpt-4o-mini",
    "inputHash": "sha256:...",
    "outputHash": "sha256:..."
  },
  "meta": {
    "attestation": {
      "receipt": {
        "certificateHash": "sha256:...",
        "timestamp": "2026-03-08T20:30:00Z",
        "nodeId": "nexart-node-primary",
        "kid": "k1"
      },
      "signature": "BASE64_SIGNATURE"
    }
  }
}

A CER bundle contains three logical layers:

Snapshot

Execution data describing the inputs and outputs of a run.

Certificate Hash

A deterministic hash of the canonicalized bundle.

Attestation

An optional node receipt and signature confirming observation of the execution.

Canonical Hash Computation

The certificateHash is computed by hashing the canonicalized CER bundle.

Canonicalization ensures that equivalent bundles produce identical hashes regardless of JSON formatting.

The canonicalization process:

• Removes non-deterministic fields
• Sorts object keys deterministically
• Serializes the bundle using canonical JSON encoding

The hash algorithm used by the protocol is:

SHA-256

The resulting certificate hash is formatted as:

sha256:<hex digest>

Hash comparison must be performed on the normalized hexadecimal digest without whitespace or case differences.

All NexArt-compatible verifiers must compute the certificate hash using this canonicalization process.

Hash Scope

The certificate hash is computed from the canonicalized CER bundle excluding attestation metadata.

Fields under the following paths are excluded from the hash computation:

meta.attestation
meta.attestation.receipt
meta.attestation.signature

These fields are excluded because they are produced after the certificate hash is computed.

This ensures the bundle hash remains stable before and after node attestation.

Verification Semantics

Verification confirms that a CER bundle is internally consistent and optionally attested by a NexArt node.

Verification consists of three checks:

Bundle Integrity

The certificate hash must match the canonicalized bundle contents.

Node Signature

If a node attestation exists, the signature must validate against the node's public keys.

Receipt Consistency

The receipt certificateHash must match the bundle certificateHash.

Node attestation is optional. A CER bundle without attestation can still be verified for bundle integrity, but cannot prove that a NexArt node observed the execution.

Verification Result Schema

All NexArt-compatible verifiers should produce a standardized verification result.

{
  "status": "VERIFIED",
  "checks": {
    "bundleIntegrity": "PASS",
    "nodeSignature": "PASS",
    "receiptConsistency": "PASS"
  },
  "reasonCodes": [],
  "certificateHash": "sha256:...",
  "bundleType": "cer.ai.execution.v1",
  "verifiedAt": "2026-03-08T20:40:00Z",
  "verifier": "nexart-verifier/1.0.0"
}

Each check value must be one of:

PASS
FAIL
SKIPPED

• PASS: check succeeded
• FAIL: check failed
• SKIPPED: check not applicable (e.g. no attestation present)

Example verification result without attestation:

{
  "checks": {
    "bundleIntegrity": "PASS",
    "nodeSignature": "SKIPPED",
    "receiptConsistency": "SKIPPED"
  }
}

This structure allows verification results to be consumed consistently across:

• CLI verification
• Public verifier
• Dashboard verification reports
• Exported audit packages

Verification Status Values

The status field indicates the overall verification outcome.

Allowed values:

VERIFIED
FAILED
NOT_FOUND

• VERIFIED. All verification checks passed.
• FAILED. One or more verification checks failed.
• NOT_FOUND. The requested execution record was not located.

Reason Codes

Reason codes provide machine-readable explanations for verification failures.

Current codes include:

BUNDLE_HASH_MISMATCH
NODE_SIGNATURE_INVALID
NODE_SIGNATURE_MISSING
RECEIPT_HASH_MISMATCH
SCHEMA_VERSION_UNSUPPORTED
RECORD_NOT_FOUND
BUNDLE_CORRUPTED

Reason codes must remain stable across protocol versions. Human-readable messages may change, but reason codes must remain consistent.

Schema Versioning

CER bundles include a namespace and schema version. Example:

cer.ai.execution.v1

The namespace (cer.ai.execution, cer.codemode.render) identifies the execution surface and ensures schema evolution can occur independently across surfaces.

Minor schema updates may introduce new optional fields without breaking compatibility.

Example: v1.0 → v1.1

Breaking changes require a new namespace version.

Example: cer.ai.execution.v2

Compatibility Rules

CER readers must support forward compatibility. Readers should:

• Ignore unknown optional fields
• Preserve unknown metadata
• Support verification of earlier revisions within the same major version

These rules allow the protocol to evolve without breaking existing integrations.

Deprecation Policy

Fields may be deprecated but must remain readable for a minimum period. Standard policy:

• Deprecated fields remain readable for at least 12 months.
• Deprecated fields must be documented in the protocol specification.
• Removal of deprecated fields requires a new major version.

Conformance Requirements

A NexArt-compliant verifier must:

1. Compute the canonical bundle hash
2. Validate node attestation signatures
3. Confirm receipt consistency
4. Produce a standardized verification result

Systems implementing these steps can be considered CER-compatible verifiers.

Alignment with AIEF

The CER protocol aligns with the AI Execution Integrity Framework (AIEF).

This alignment allows CERs to serve as verifiable execution artifacts within AIEF-compliant systems.

Record Management Layer

Lifecycle management, archival behavior, and record actions (hide, delete, revoke, export) are defined separately in the CER Record Management documentation.

These concepts operate at the storage, visibility, and governance layer and do not modify the CER bundle, certificateHash, or verification semantics.

Protocol Surfaces

The CER protocol is implemented across several NexArt system surfaces.

These surfaces share the same schema and verification semantics.

Current protocol implementations include:

• NexArt Node: produces CER bundles and node attestations
• NexArt CLI: local creation and verification of CER bundles
• NexArt Verifier: public verification interface
• NexArt Dashboard: storage, export, and audit reports
• NexArt SDKs: developer libraries for generating and verifying CERs

All implementations must follow the verification semantics defined in this specification.