Certified Execution Records

Overview

A Certified Execution Record (CER) is a portable, tamper-evident record of an execution. CERs can represent AI completions, deterministic system operations, or any execution you want to certify.

A CER binds execution metadata to a certificateHash. The bundle structure is deterministic: given the same inputs, the same hash is produced. Attestation adds a signed receipt under meta.attestation, but the CER itself is the base record.

What a CER Contains

• Inputs: hashed (SHA-256) representation of the execution input. Raw content is not stored in the CER.
• Outputs: hashed representation of the execution output.
• Parameters: model identifier, execution configuration.
• Context (signals): optional structured metadata recorded alongside the execution. See Context Signals and Execution Context and Signals for the builder API.
• Metadata: application-defined fields like appId and projectId.
• certificateHash: SHA-256 hash derived from the canonical bundle. This is the unique identifier and what the node signs.

CER Anatomy

A fully certified CER contains these fields:

Top-level fields

• bundleType: identifies the record type (e.g. cer.ai.execution.v1). Determines what verification checks apply.
• version: protocol version (currently "0.1").
• createdAt: when the CER was created (ISO 8601).
• certificateHash: SHA-256 hash derived from the canonical bundle.

Snapshot (execution metadata)

• model: the model or system that produced the execution.
• inputHash: SHA-256 hash of the input/prompt. The raw input is not stored in the CER.
• outputHash: SHA-256 hash of the output/completion.
• metadata: application-defined fields like appId and projectId.

Attestation (meta.attestation)

Attestation data is stored under meta.attestation in the CER bundle:

• receipt: the canonical payload signed by the attestation node. Contains certificateHash, timestamp, nodeId, and kid.
• signature: raw Ed25519 signature over the receipt payload.
• kid: the signing key identifier, matching a key published at the node's well-known endpoint.

Full Example

{
  "bundleType": "cer.ai.execution.v1",
  "version": "0.1",
  "createdAt": "2026-03-06T12:00:00.000Z",
  "snapshot": {
    "model": "gpt-4",
    "inputHash": "sha256:a1b2c3d4e5f6...",
    "outputHash": "sha256:f6e5d4c3b2a1...",
    "metadata": {
      "appId": "my-app",
      "projectId": "proj_abc123"
    }
  },
  "certificateHash": "sha256:9e8d7c6b5a4f...",
  "meta": {
    "attestation": {
      "receipt": {
        "certificateHash": "sha256:9e8d7c6b5a4f...",
        "timestamp": "2026-03-06T12:00:00.001Z",
        "nodeId": "nexart-node-primary",
        "kid": "key_01HXYZ..."
      },
      "signature": "<raw Ed25519 signature bytes>",
      "kid": "key_01HXYZ..."
    }
  }
}

Create vs Certify

There are two API endpoints for creating CERs, and the difference matters:

• POST /v1/cer/ai/create generates a CER bundle with a certificateHash but does not attest it. The meta.attestation field is absent. Use this if you need the bundle for external handling or deferred attestation.
• POST /v1/cer/ai/certify creates the CER and attests it in one request. Returns the certificateHash, receipt, signature, and a verificationUrl. This is the recommended path for most integrations.

Bundle Types

The bundleType field describes the record type and attestation condition:

• cer.ai.execution.v1: an AI execution record. Fully verifiable when attested. This is the default when you use the certify endpoint.
• signed-redacted-reseal: a redacted export that has been resealed and signed again for safe sharing while preserving verifiability.
• hash-only-timestamp: the receipt signs only the certificateHash. Used when full snapshot attestation is not possible.
• legacy: historical records that may lack full attestation data.

Certificate Hash

The certificateHash is a SHA-256 hash derived from a strict whitelist projection of the bundle, canonicalized per the profile bound to protocolVersion (1.2.0 → nexart-v1, default; 1.3.0 → jcs-v1 / RFC 8785, opt-in). It uniquely identifies the record and is what the attestation node signs. Any modification to a covered field produces a different hash.

What is hashed

The certificateHash is computed ONLY over the following fields:

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

What is NOT hashed

The following fields are explicitly excluded from the certificate hash payload:

• certificateHash
• meta
• declaration
• verificationEnvelope
• verificationEnvelopeSignature
• receipt
• any unknown fields not in the whitelist

Rules for verifiers:

• No reconstruction of the payload
• No normalization beyond the canonicalization profile bound to the bundle's protocolVersion (nexart-v1 for 1.2.0, jcs-v1 / RFC 8785 for 1.3.0)
• No field stripping or addition
• The whitelist projection MUST be applied to the bundle exactly as received

Identity Binding (PII-Safe)

A CER MAY include an optional identity object inside the execution snapshot. When present, it is part of the protected payload, included in the whitelist projection, and covered by the certificateHash. Any modification to identity fields invalidates the record. Available in @nexart/ai-execution v0.23.0 and later.

Structure

{
  "snapshot": {
    "model": "gpt-4",
    "inputHash": "sha256:...",
    "outputHash": "sha256:...",
    "identity": {
      "provider": "https://accounts.google.com",
      "sub": "user_1234567890",
      "verified": true,
      "emailHash": "sha256:...",
      "assertionHash": "sha256:..."
    }
  }
}

Fields

• provider: identity provider URL or identifier (e.g. https://accounts.google.com, Okta issuer).
• sub: stable subject identifier issued by the IdP.
• verified: boolean indicating that the application verified the identity assertion before sealing the CER.
• emailHash: SHA-256 hash of the user's email address. Optional, PII-safe.
• assertionHash: SHA-256 hash of the original identity assertion (e.g. the raw JWT). Allows later re-verification against an out-of-band copy of the assertion.

PII Handling

Raw personal data (email address, name, profile attributes) is NOT stored in the CER by default. Only hashed or derived identifiers are included in the identity object. This allows an identity to be cryptographically bound to an execution without exposing sensitive data in the sealed record or in any public verification view.

Trust Boundary

Identity fields are claims captured at execution time, not independently verifiable assertions. Only hashes are stored in the CER (emailHash, assertionHash). NexArt does NOT verify identity providers and does NOT validate IdP assertions. Identity verification (token validation, signature checks, audience and expiry checks) happens in the application layer before the CER is sealed. NexArt seals the provided identity object as tamper-evident evidence of what the application asserted at execution time. The verified flag reflects the application's claim, not an independent NexArt check. Identity verification is evolving toward externally verifiable assertions in a future protocol version.

Verification Impact

• identity is part of the canonical snapshot.
• It is included in the certificateHash computation under the existing whitelist projection.
• It is independently verifiable using the standard verification flow (SHA-256 over the canonicalized whitelist, Ed25519 over the receipt). No additional dependencies or IdP calls are required.

Tamper Detection

Because identity is covered by certificateHash, modifying any field (for example changing identity.sub or identity.emailHash) recomputes to a different hash and produces a verification failure. There is no partial validation: the record either matches the sealed bytes or fails.

Export Paths

• Full export: the complete CER with all snapshot data intact.
• Redacted export: sensitive fields removed, then resealed and signed so verification still works.
• Legacy export: older records with limited verification coverage.

Tamper Evidence

The certificateHash makes tampering immediately evident. Any modification to the CER produces a different hash. Verification tools recompute the hash and compare it to detect changes.

Replayability

Because a CER captures all relevant execution parameters and context, it can support replay where applicable. The deterministic hash computation means the same inputs always produce the same certificateHash, enabling independent verification without re-executing.

Verification

Any CER can be verified independently. No trust in NexArt infrastructure is required. Verification checks:

• Bundle Integrity: the bundle hashes are internally consistent.
• Node Signature: the receipt signature is valid against a published node key. SKIPPED if no attestation.
• Receipt Consistency: the receipt's certificateHash matches the CER bundle. SKIPPED if no attestation.

The node provides attestation and discovery. It is not required to verify integrity. Integrity is proven by the hashes alone.

Verification statuses: VERIFIED, FAILED, or NOT_FOUND. Each check returns PASS, FAIL, or SKIPPED.

Verify using the SDK (verifyCer() or verifyCerAsync()) or at verify.nexart.io.

See How Verification Works, Certificate Hash vs Project Hash, and the CER Protocol for full details.

What NexArt Guarantees (and Does Not)

Guaranteed: integrity of the recorded execution (tamper-evidence via certificateHash), independent verification without trusting NexArt infrastructure.

Not guaranteed: correctness of the execution result, completeness of recorded steps. NexArt proves what happened. It does not evaluate whether the result was correct or whether all steps were recorded.

Multi-Step Workflows

For workflows with multiple steps, CERs can be collected into a Project Bundle with its own projectHash covering the entire sequence. Use agent-kit for simplified workflow orchestration.