The NexArt Protocol for Verifiable AI Execution
An open execution and verification standard for deterministic and integrity-bound systems.
The NexArt Protocol is an open specification for verifiable execution. It defines how executions are captured, sealed with cryptographic hashes, and independently verified across two distinct execution surfaces under one versioned trust model.
Code Mode provides deterministic, reproducible execution where the same inputs always produce the same output. AI Execution produces tamper-evident records of AI and LLM calls. Integrity evidence that anyone can verify independently.
Both surfaces share the same protocol version, verification semantics, and trust model. The protocol defines execution guarantees, not aesthetics or application logic.
Two Execution Surfaces
The protocol defines two execution surfaces, each with distinct guarantees:
Code Mode, Deterministic Execution
Canonical outputs (PNG / MP4) produced under pinned execution semantics. The same system, same seed, same renderer always produces the same output. Seeded randomness, no external dependencies, and a fixed execution environment ensure bit-for-bit reproducibility. Used for certification, archival, and independent verification.
AI Execution, Integrity Records
Tamper-evident Certified Execution Records (CER) for AI and LLM calls. Inputs, parameters, and outputs are cryptographically bound via a SHA-256 hash. Optional node attestation provides an Ed25519-signed receipt for independent, third-party proof of integrity. This surface does not claim deterministic output. It provides integrity evidence, not replay guarantees.
| Surface | What it proves | Deterministic | Verification | Use cases |
|---|---|---|---|---|
| Code Mode | Same inputs → same output, always | Yes, bit-for-bit | Re-execute and compare hash | Certification, archival, simulations |
| AI Execution | Record integrity: inputs, outputs, context are untampered | No. Integrity, not replay | Recompute hash, check attestation signature | AI agents, workflows, compliance |
Why Verifiable Execution Matters
Non-deterministic systems may appear stable until reproducibility is required. Logs can describe what happened. They cannot prove it. Execution drift creates silent risk in:
- AI agent decision workflows
- Compliance-sensitive automation pipelines
- Financial simulations requiring deterministic replay
- Model evaluation and benchmarking systems
The NexArt Protocol addresses this by enforcing execution guarantees at the protocol layer. Not inferred after execution, but built into the execution itself.
Protocol-Level Guarantees
- Canonical execution semantics: execution rules are defined by the protocol, not the application
- Version-pinned guarantees: protocol versions lock behavior across time and environments
- Cryptographic binding: SHA-256 hashes seal protected fields into tamper-evident structures
- Independent attestation: canonical nodes verify integrity and issue Ed25519-signed receipts
- Zero-trust verification: any party can verify without trusting the originating system
Integrity ≠ correctness. A verified record confirms that protected fields have not been modified since issuance. It does not guarantee that a model produced correct, truthful, or deterministic output. Integrity is about the record; correctness is about the model.
How Verification Works
Capture
Inputs, parameters, outputs, and execution context are recorded at runtime.
Seal
Fields are canonicalized and bound with a SHA-256 hash into a tamper-evident record.
Attest
The NexArt attestation node verifies the record and issues an Ed25519-signed receipt.
Verify
Anyone recomputes the hash and checks the signature. No account required.
Protocol Architecture
NexArt separates the protocol layer from the application layer. The protocol defines execution semantics and verification rules. Applications implement the protocol to create, certify, and verify execution records.
Execution Trust Chain
Code Mode SDK
The language definition and deterministic execution primitives. Defines syntax, available functions, and execution rules. The Canonical Renderer is the reference runtime for certification-grade deterministic execution, producing verified PNG/MP4 outputs with cryptographic proofs.
Attestation Node
Independent attestation for execution records across both surfaces. Issues signed receipts that provide chain-of-custody signals without re-running models or re-executing code.
Protocol-Compliant Applications
Applications that implement the protocol correctly. Must not alter execution semantics or introduce non-canonical fallback paths for certified outputs. Third-party implementations are supported and encouraged.
Applicable Domains
AI Agents
Verifiable decision trails for autonomous tool calls and multi-step agent workflows.
Multi-Step Pipelines
Certify every stage in tool-calling and automation pipelines with independently verifiable evidence.
Regulated Workflows
Audit-supporting execution records for compliance-sensitive operations and governance mechanisms.
Financial Services
Auditable evidence for AI-driven risk scoring, fraud detection, and trading signals.
Governed Decisions
Evidence-backed governance for AI decisions that require human oversight and approval trails.
Who It Serves
Developers & Builders
Build applications that create and certify execution records. Integrate via the Code Mode SDK for deterministic rendering or the AI Execution SDK for integrity-bound records.
Auditors & Compliance
Rely on replayable execution and tamper-evident records. A verified hash confirms the record matches the certified run. Attestation receipts provide independent third-party evidence.
AI System Operators
Produce verifiable evidence for AI agent decisions, tool calls, and workflow outputs. Integrate integrity records into existing pipelines and monitoring systems.
Researchers
Publish executable systems with deterministic replay or tamper-evident AI execution records, enabling verification by independent peers.
Protocol Status
Protocol 1.2.0 uses the deterministic NexArt canonicalisation (nexart-v1). Protocol 1.3.0uses RFC 8785 (JCS) and enables verification with off-the-shelf libraries. Protocol 1.3.1 adds the confidential node-side certification flow. Records produced under earlier versions are not rewritten; producers select the version explicitly via protocolVersion.
Public verification harness for NexArt's deterministic execution and replay guarantees.
determinism.nexart.ioReference
- Certified Execution Records: The core protocol artifact
- AI Execution Integrity: Tamper-evident records for AI workflows
- How NexArt Works: Five steps from execution to proof
- Determinism & Versioning: Guarantees and constraints
- Modes: The creation primitives
- Canonical Unit: The core protocol object
- Standards Alignment: ISO 42001, SOC 2, NIST mapping
- Security Architecture: Sandboxed, auditable execution
- Glossary: Precise definitions for protocol terms
- FAQ: Common questions answered
Comparisons
- Logs vs Certified Execution Records: Why logs are not proof
- Observability vs Execution Evidence: Monitoring is not verification
- Audit Trails vs Verifiable Execution: Visibility is not proof
From the blog