Glossary

System

A generative specification that defines behavior, not output. A system describes how visual output should be produced given a set of inputs, parameters, and rules.

Systems are declarative: they specify what should happen, not what has happened. The same system, executed under the same conditions, should produce consistent results according to its declared determinism level.

In NexArt, the system is the primary creative artifact. Outputs are derived; systems are authored.

Canonical Unit

The protocol-level representation of a NexArt system. A canonical unit is a structured object that encodes everything the protocol requires to identify, validate, and reproduce a system.

Canonical units include metadata such as mode, protocol version, creation context, and declared determinism. They reference external inputs where applicable and declare whether full reproducibility is guaranteed or best-effort.

The canonical unit is the fundamental exchange format. All compliant implementations must be able to read, write, or validate canonical units according to their role.

Output

A rendered artifact derived from executing a system. Outputs are the visual (or audiovisual) results of running a system through a renderer.

Outputs may be images, videos, or real-time visual streams. They are products of systems, not protocol objects themselves. The protocol concerns itself with systems; outputs are implementation details.

Storing or distributing outputs is outside the protocol's scope. What matters to the protocol is that outputs can be regenerated from systems under specified conditions.

Deterministic System

A system that guarantees identical output given identical inputs, under specified conditions. A deterministic system, when executed by conforming renderers with the same inputs, will always produce the same result.

Determinism in NexArt is conditional. It depends on renderer conformance, specified rendering rules, and the stability of external references. A system's determinism declaration is a contract, not an automatic property.

HARD enforced modes: Shapes, Noise, SoundArt, and Code Mode are fully deterministic and rendered exclusively via the NexArt Code Mode runtime under Protocol v1.2.0. No arbitrary rendering logic is permitted.

Best-Effort System

A system that aims for reproducibility but cannot guarantee identical output in all environments. Best-effort systems are honest about the limits of their reproducibility.

Factors such as floating-point precision, hardware differences, audio analysis variations, or unpinned dependencies may cause outputs to differ slightly across executions or renderers.

Best-effort is not a failure state. Many valuable systems, particularly those involving real-time audio, procedural fluids, or user-provided code are inherently best-effort. The protocol values honesty over false guarantees.

Renderer

An implementation that executes a NexArt system and produces visual output. A renderer reads a canonical unit, interprets its mode-specific parameters, and generates the corresponding output.

Multiple renderers may exist for the same mode. The protocol does not mandate a single rendering engine. However, for deterministic systems, renderers must conform to specified rendering rules to produce consistent results.

Renderers may be embedded in applications, run as standalone tools, or operate as services. The protocol is agnostic to renderer architecture.

Implementation

Any software that reads, writes, validates, or renders NexArt systems. Implementations include renderers, editors, validators, archivers, and tools that interact with canonical units.

An implementation does not need to support all modes or all protocol features. Partial implementations, such as a read-only parser or a validator for a single mode, are valid and encouraged.

The protocol specifies what implementations must do to be conforming in their declared scope. It does not require any single implementation to do everything.

Protocol Version

The version of the NexArt specification a system conforms to. Every canonical unit declares its protocol version, allowing implementations to interpret it correctly.

Protocol versions are immutable once released. A system authored under v0.1 remains a v0.1 system. Future protocol versions may add features or modes but must maintain backward compatibility with existing systems.

Versioning ensures that systems remain interpretable over time. Deprecation, when necessary, will be explicit, documented, and gradual.

External Reference

A pointer to data required by a system but stored outside the canonical unit. External references include audio files, text sources, or other assets that a system depends on for execution.

External references introduce reproducibility dependencies. A system that references external audio can only be fully reproduced if that audio remains accessible and unchanged.

The protocol encourages content-addressable references (such as hashes) where possible, and requires systems to declare their external dependencies explicitly.

Mode

A creation primitive that defines how systems are authored. Each mode: SoundArt, Code Mode, Shapes, Fluids, Noise provides a distinct set of inputs, parameters, and behaviors.

Modes are not plugins or extensions. They are first-class protocol primitives, each with defined semantics and determinism characteristics. HARD enforced modes (Shapes, Noise, SoundArt, Code Mode) execute through the shared NexArt Code Mode runtime under Protocol v1.2.0.

All modes produce canonical units that conform to the protocol structure, but each mode's internal parameters and rendering requirements differ according to its nature.

SoundArt

A protocol-enforced mode for audio-reactive deterministic systems. SoundArt is now fully protocol-enforced, rendered exclusively via the NexArt Code Mode runtime.

Audio input is normalized into a frozen SoundSnapshot and injected into the runtime as read-only parameters. All outputs are deterministic, seeded, and verifiable under the NexArt protocol. There are no Canvas2D or legacy rendering paths.

Identical audio input and seed always produce identical visual output.

CER / Certified Execution Record

A structured, tamper-evident record that captures the inputs, parameters, outputs, and metadata of an execution. CERs are sealed with a cryptographic hash (the certificateHash) that binds all protected fields.

CERs are the fundamental unit of the AI Execution Integrity surface. They can be verified independently and optionally attested by an attestation node. A CER does not guarantee output correctness. It guarantees record integrity.

certificateHash

The certificate hash is derived from the canonical certificate-bound content and identifies one exact Certified Execution Record. It is computed as a SHA-256 over the protected fields of a CER (bundleType, version, createdAt, and snapshot). A successful certificate-hash check confirms that the certificate-bound fields have not changed.

Use certificate hash when sharing or directly verifying a specific CER. Meta and attestation fields (receipt, signature, kid) are excluded from hash computation so attestation can be added without invalidating integrity.

Execution ID

Execution ID is an application-level identifier used to locate or group records. It is not necessarily the cryptographic identity of a CER.

Execution ID helps locate records. Certificate hash identifies the exact Certified Execution Record. Prefer certificate hash for any claim about a specific artifact.

Project Hash

The Project Hash is derived from the canonical Project Bundle and identifies one exact Project Bundle.

Use Project Hash when sharing or directly verifying a specific Project Bundle.

Attestation Node

A NexArt-operated service that validates the integrity of a submitted CER bundle and issues an Ed25519-signed receipt over the certificateHash. A successful signature check confirms that the displayed attestation-node key signed the record.

The attestation node does not re-run models, validate provider execution, or guarantee output correctness. It verifies that the bundle is internally consistent and signs the certificateHash.

External Timestamp

Optional third-party time evidence anchored to a signed record. When present, a successful external timestamp check provides independent time evidence for the signed record.

Not every CER carries an external timestamp, and timestamp presence alone does not prove validity. Timestamp evidence complements, but does not replace, the certificate-hash and signature checks.

Signed Receipt

An Ed25519-signed attestation issued by an attestation node. A signed receipt binds the certificateHash to a timestamp and the node's public key, enabling offline verification without contacting the node.

Signed receipts replace legacy attestation stamps which required contacting the node for verification.

bundleType

A string identifier that declares the format and semantics of a CER. The current AI execution bundle type is cer.ai.execution.v1.

The bundleType is a protected field included in hash computation. It allows verification tools to interpret the record correctly and apply the appropriate validation rules.

Declaration

Advisory metadata attached to a CER that describes the protected field set and stability scheme. Declarations are informational. They are excluded from the certificateHash and do not affect verification.

Declarations allow integrators to communicate intent (e.g., which fields are considered protected) without altering the cryptographic seal.

toolCalls

Optional evidence records within a CER snapshot that capture external tool invocations made during an AI execution (e.g., function calls, API lookups, retrieval results). When present, toolCalls are included in the snapshot and therefore covered by the certificateHash.

toolCalls provide auditability for agentic workflows where the model invokes external capabilities as part of its execution.

Context Signals

Structured metadata fields within a Certified Execution Record that capture the execution environment of an AI operation: permissions, memory state, tool availability, session context, and runtime conditions.

When present, context signals are sealed into the certificateHash and become part of the tamper-evident record. See the dedicated context signals page for full details.

Certified Decision

An AI-generated output that is bound to its full execution context within a Certified Execution Record: the inputs that triggered it, the model and parameters that produced it, the tools that were called, and the context signals that surrounded it.

A certified decision is sealed with a cryptographic hash that makes any modification detectable. It transforms AI outputs from claims into verifiable evidence. See certified decisions for the complete explanation.

Agent Execution

Autonomous AI workflows where an agent makes decisions, invokes tools, manages memory, and triggers downstream actions across multiple steps. Execution integrity for agents means producing tamper-evident, independently verifiable evidence at every decision point.

Agent execution integrity is critical for multi-step autonomous workflows where each decision influences the next. See agent execution for the full explanation.

Evidence Layer

The role NexArt plays in an AI stack. A dedicated layer that turns AI executions into tamper-evident, independently verifiable audit records.

Distinct from the model layer (generation), the application layer (business logic), the orchestration layer (chaining and routing), the observability layer (real-time monitoring), and the governance layer (policy and rules). The evidence layer's role is to make execution defensible after the fact.

Tamper-Evident

A property of a record such that any modification is cryptographically detectable by a third party. In NexArt, tamper-evidence is achieved by sealing the protected fields of a Certified Execution Record with a SHA-256 certificateHash and signing the bundle with an Ed25519 key from the NexArt attestation node.

On terminology. Regulatory and industry sources sometimes use the phrase tamper-proof as a colloquial synonym. The accurate term is tamper-evident: no software system can prevent an operator from deleting or overwriting a file; the achievable property is that such modification is detectable. The EU AI Act, ISO/IEC 42001, NIST AI RMF, and SOC 2 all converge on this operational meaning even when the specific word is not used in the text.

See the answer page What is tamper-evident AI execution? for how the property is implemented and verified.

Vendor-Independent Verification

A property of NexArt records: they can be verified by any party using only the published public keys and a documented hash procedure, with no API call to NexArt and no trust in NexArt's infrastructure.

This is why NexArt does not require its own SOC 2 or ISO certifications: the vendor is not part of the auditor's trust boundary.

Framework Consolidation

The property that one integration with NexArt produces a single evidence stream that maps to control requirements across SOC 2, ISO/IEC 42001, NIST AI RMF, and the EU AI Act, rather than requiring a separate tool per framework.