Verification Model · Unified Specification
Can you prove what your AI system actually did?
NexArt produces tamper-evident execution records that anyone can verify independently, with no NexArt account, no NexArt runtime, and no requirement to trust the prover.
Execution → Evidence → Verification
The verification pipeline
1 · The Problem
Logs are not proof.
As AI systems move into production, organisations need to answer a simple but critical question: can you prove what actually happened? Most existing approaches cannot.
Logs / Reconstruction
Self-attested narrative
- Produced by the same system whose behaviour is being questioned.
- Re-running produces a new execution, not the original one.
- No independent way to detect tampering or omission.
Evidence / CER
Sealed cryptographic record
- Canonicalised and hashed at capture time.
- Tamper-evident, any change breaks the hash.
- Independently verifiable using standard cryptography.
2 · What is a CER
Certified Execution Record
A CER captures the execution as a deterministic, hash-locked document. If any byte of the record changes after sealing, the hash no longer matches.
Inputs
Prompts, parameters, context, and signals supplied to the system.
Outputs
Model responses, tool calls, and any artefacts produced.
Metadata
Versions, timestamps, policy evaluation, and execution context.
Sealing
3 · The Verification Model
Two independent checks, one classification
Verification is built from cryptographic primitives, not policies. Integrity and authenticity are separate checks. A classification layer summarises the outcome, it does not replace the proof.
A. Integrity
Independent
Has the record changed since it was sealed?
- 1. Canonicalise the CER
- 2. Recompute SHA-256
- 3. Compare with
certificateHash
Fully deterministic. Requires only SHA-256.
B. Authenticity
Attribution
Who sealed it?
- Ed25519 signature over a canonical payload
- Verified against the node's published public key
- Independent from the integrity check
Authenticity binds a CER to a known signing key, it does not, by itself, prove integrity.
C. Classification
| Status | Meaning |
|---|---|
| VERIFIED | Strict cryptographic validity under current rules. |
| LEGACY_VERIFIED | Valid under legacy rules (older protocol or canonicalisation). |
| UNVERIFIABLE | Cannot be reproduced, missing fields or unknown protocol. |
| FAILED | Cryptographic failure, hash or signature mismatch. |
Classification is not the proof. It summarises the proof.
4 · Independent Verification
You don't have to trust NexArt.
A third party can verify a CER end-to-end using only the bundle, the node's public key, and standard cryptographic libraries.
CER
The portable JSON record.
Public key
Published at /.well-known/nexart-node.json.
SHA-256 + Ed25519
Any standards-compliant library.
No NexArt account. No NexArt runtime. No NexArt code required.
5 · Canonicalisation
Two protocols, both deterministic
Canonicalisation is what makes a record reproducible across implementations. NexArt supports both a deterministic in-house format and a public standard.
Protocol 1.2.0 · default
nexart-v1
Deterministic in-house canonicalisation. Stable across SDK and node, fully specified for independent reimplementation.
Protocol 1.3.0 · opt-in
RFC 8785 (JCS)
JSON Canonicalization Scheme, an IETF standard. Verification can be performed using any third-party JCS implementation.
Protocol 1.3.0 enables verification using a public standard. The choice of canonicalisation is recorded in the bundle and pinned per record.
6 · Timestamp Model
Node ordering, plus an independent RFC 3161 anchor
- Node-issued timestamp bound to
certificateHash. - Provides an ordering guarantee within the node's signing chain.
- Independent anchor of when the record existed, via an RFC 3161 timestamp from DigiCert's public timestamp authority, applied by default.
Format-stable
The RFC 3161 timestamp travels with the Certified Execution Record without changing its format. A dedicated contracted TSA is available for enterprise customers when required.
7 · Trust Boundaries
What verification proves, and what it does not
Proves
- Integrity, the record has not been altered since sealing.
- Authenticity, the record was sealed by the holder of a known signing key.
Does not prove
- Correctness of the executed program (verification proves integrity of what ran, not that it was right).
- Completeness, that every relevant execution was submitted.
- Public log inclusion, no third-party transparency log.
Completeness is an integration-level responsibility. Independent time of existence is anchored by an RFC 3161 timestamp issued via DigiCert's public timestamp authority, applied to every record by default.
8 · Why This Matters
Use cases
Dispute resolution
Settle disagreements with sealed evidence, not narrative.
Auditability
Reproducible records for internal and external review.
Enterprise trust
Counterparties verify directly, not via the prover.
Verifiable workflows
Agents and pipelines emit evidence by default.
9 · Closing
Verification does not depend on NexArt itself.
A proof that requires trusting the prover is not a proof.