# Certified Execution Records URL: https://docs.nexart.io/docs/concepts/cer A Certified Execution Record seals an execution snapshot into a hash bound bundle, giving anyone the ability to verify integrity and attestation without. Mental model - Logs describe. CERs prove. - The certificateHash is the canonical identity. - Mutate the bundle and you break the proof. ## 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. Logs vs CERs Logs describe events. CERs prove execution integrity. A CER binds execution inputs, outputs, parameters, and context into a single tamper-evident artifact with a deterministic hash. 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 Certified CER with Signed Receipt ``` { "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": "", "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 Identity object inside snapshot ``` { "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. Optional Identity binding is optional. Records without an `identity` object remain fully valid and verifiable under the same protocol rules. ## 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. Verification confirms integrity and applicable trust material. It does not establish that the AI output was correct, fair, lawful, or complete. The completeness and truthfulness of the recorded execution data depend on the integration and capture boundary. ## 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.