nexart.iodocs

    AI Execution CER

    The smallest unit of proof in NexArt: a tamper-evident record of one AI execution step.

    Overview

    An AI Execution CER is a single, tamper-evident record of one AI execution. Its bundle type is cer.ai.execution.v1. It is the smallest unit of proof in the NexArt protocol. Multi-step workflows compose AI Execution CERs into a Project Bundle.

    certificateHash is the canonical identity
    Always look up an AI Execution CER by certificateHash. executionId is a convenience identifier returned by the certify API. It is NOT a unique artifact identifier and MUST NOT be used as the primary key for storage, deduplication, or public verification URLs.

    What an AI Execution CER Proves

    • Integrity. The recorded execution metadata has not been modified since it was certified.
    • Witness (when attested). The NexArt attestation node observed the artifact at a specific point in time.

    It does not prove that the model output was correct, that the execution was reproducible by re-calling the model, or that all related steps were recorded. NexArt proves what was recorded, not the quality of the result. See the Trust Model.

    What Is Included in certificateHash

    certificateHash is SHA-256 over the canonical CER bundle. The following fields are covered:

    • bundleType, version, createdAt
    • snapshot.model
    • snapshot.inputHash, snapshot.outputHash
    • snapshot.metadata (when present)
    • context.signals when included in the canonical bundle (see below)

    Any change to any covered field produces a different certificateHash.

    What Is NOT Included in certificateHash

    • Raw input and output. Only the SHA-256 hashes are stored. The original prompt and completion text are never written into the CER.
    • Optional context attached after hashing. context.signals MAY be transported outside the hash scope when supplied as supplemental metadata rather than as part of the canonical bundle. In that case, signals do not invalidate core integrity if absent or modified. See Verification Semantics.
    • Node attestation. meta.attestation is added by the attestation node AFTER the hash is computed. The receipt itself binds the existing certificateHash; it does not change it.
    • Verification envelope. meta.verificationEnvelope and its signature are added under meta and do not affect certificateHash.

    Determinism vs Verifiability

    These two terms are often confused. They are not the same.

    • Determinism means: given the same canonical bundle bytes, the same certificateHash is produced. This is a property of the hashing function and the canonical JSON serialization.
    • Verifiability means: anyone can recompute certificateHash from the bundle and validate the node receipt against the node's published key, without trusting NexArt. This is a property of the protocol.

    NexArt does not replay the model. The protocol proves the record's integrity and witness, not the model's behavior.

    Minimal Correct Flow

    Create and certify a single AI Execution CER
    import { certifyDecision } from "@nexart/ai-execution";

const cer = await certifyDecision({
  model: "gpt-4o-mini",
  input: { messages: [{ role: "user", content: "Approve invoice #42?" }] },
  output: { decision: "approve", reason: "policy_passed" },
  metadata: { appId: "ap-bot", projectId: "proj_demo" },
});

// canonical identifier - use this for storage, dedup, and public URLs
const id = cer.certificateHash;

// public verification URL
const url = `https://verify.nexart.io/c/${encodeURIComponent(id)}`;

    Required vs Optional Fields

    • Required: model, input, output. The SDK hashes input and output internally; only the hashes are stored.
    • Optional: metadata (appId, projectId), signals (see Context Signals).

    Avoid passing undefined values inside metadata or signals. Undefined values can break canonical JSON serialization on some runtimes. Either omit the key entirely or use null.

    Next