FAQ

Q: What is NexArt?

NexArt produces Certified Execution Records (CERs), portable, tamper-evident records of AI or deterministic system executions. CERs capture what happened, when, and provide cryptographic proof that the record has not been altered. Multiple CERs can be grouped into a Project Bundle for multi-step workflows.

Q: When is a single CER enough?

A single CER is enough for one LLM call you want to certify, one automated decision, one n8n step output, or any execution that stands alone as a verifiable artifact.

Q: When should I use a Project Bundle?

Use a Project Bundle for multi-step agent workflows where step ordering and integrity matter, multi-agent systems where multiple actors contribute to a single outcome, or pipelines where the audit unit is the whole workflow. Each step still produces its own CER; the bundle adds a projectHash covering all step certificateHash values.

Q: What is the difference between certificateHash and executionId?

certificateHash is the SHA-256 fingerprint of the canonical CER bundle and is the canonical identity used for lookup, sharing, and verification. executionId is a builder-supplied label and must not be used as the primary identity model.

Q: Why can public resealed artifacts have a different hash?

For privacy, the public verifier may serve a redacted reseal. The reseal removes sensitive fields and is re-signed by the node, so it has a new certificateHash covering the redacted contents. Provenance fields point back to the original hash. The original record is unchanged.

Q: What can NexArt verify?

Three checks: Bundle Integrity, Node Signature, and Receipt Consistency. Each check returns PASS, FAIL, or SKIPPED. Verification statuses are VERIFIED, FAILED, or NOT_FOUND.

Q: What is the difference between signed receipts and hash-only timestamps?

A signed receipt supports full attestation of the CER bundle and can verify as VERIFIED. A hash-only timestamp signs only the certificateHash; it proves the hash existed at a specific time but does not attest the snapshot contents.

Common questions from builders integrating NexArt.

What is NexArt?

NexArt produces Certified Execution Records (CERs), portable, tamper-evident records of AI or deterministic system executions. CERs capture what happened, when, and provide cryptographic proof that the record has not been altered. Multiple CERs can be grouped into a Project Bundle for multi-step workflows.

Do I need Project Bundles for every use case?

No. Project Bundles are an additional capability, not a replacement for single CER flows. If you certify one execution at a time, a single CER is enough. Use a Project Bundle only when you have multiple steps or agents that should be verified as a single unit.

When is a single CER enough?

One LLM call you want to certify
One automated decision (approve/deny, classify, route)
One n8n step output you want to attest
Any execution that stands alone as a verifiable artifact

When should I use a Project Bundle?

Multi-step agent workflows where step ordering and integrity matter
Multi-agent systems where multiple actors contribute to a single outcome
Pipelines where the audit unit is the whole workflow, not the individual step

Each step still produces its own CER. The Project Bundle adds a projectHash that covers all step certificateHash values.

What is the difference between certificateHash and executionId?

certificateHash is the SHA-256 fingerprint of the canonical CER bundle. It is the canonical identity of the record and must be used for lookup, sharing, and verification.

executionId is a builder-supplied label. It is not a unique artifact identifier and must not be used as the primary identity model.

Why does something verify locally but not appear on verify.nexart.io?

Local SDK verification only checks the bundle you hold. Public verification requires the record to be known to the node:

Single CER: the CER must have been attested by the node. Use the certify endpoint, or send a create-only bundle for attestation.
Project Bundle: the bundle must be registered on the node. Local verification of an unregistered bundle will pass, but the public verifier will return NOT_FOUND.

See End-to-End Verification for the registration flow.

Why can public resealed artifacts have a different hash?

For privacy, the public verifier may serve a redacted reseal. The reseal removes sensitive fields and is re-signed by the node. Because the content changed, the reseal has a new certificateHash covering the redacted contents. Provenance fields point back to the original hash.

This is intentional. The original record is unchanged. The reseal is a separate artifact suitable for public sharing. See Verification Semantics for details.

What can NexArt verify?

Three checks: Bundle Integrity (the CER bundle hashes are internally consistent), Node Signature (the receipt signature is valid against the node's published Ed25519 key), and Receipt Consistency (the receipt references the correct certificateHash). Each check returns PASS, FAIL, or SKIPPED. Verification statuses are VERIFIED, FAILED, or NOT_FOUND, as defined by the CER Protocol.

What is the difference between signed receipts and hash-only timestamps?

A signed receipt supports full attestation of the CER bundle and can verify as VERIFIED. A hash-only timestamp signs only the certificateHash. It proves the hash existed at a specific time but does not attest the snapshot contents. Hash-only timestamps verify as VERIFIED when the applicable checks pass.

What does SKIPPED mean?

A SKIPPED check means the check is not applicable to the record. For example, a CER without attestation will have Node Signature and Receipt Consistency checks marked as SKIPPED. This does not indicate failure. The overall status can still be VERIFIED if all applicable checks pass.

Are Context Signals always part of the certificateHash?

Not always. Signals are optional. They MAY be inside the hash scope (tamper-evident as part of the certified record) or supplemental (recorded alongside the artifact but outside the hash). A signal being outside the hash scope does not invalidate core artifact integrity. See Context Signals and Verification Semantics.

What does a redacted export prove?

A redacted export contains a limited view of the original record with sensitive fields removed. A redacted reseal is signed again by the attestation node so the shared version remains verifiable. The signature covers exactly what is present in the exported record. The original full bundle is not recoverable from the redacted version.

What is a legacy record?

A legacy record is a historical record format that may lack full attestation data, a complete bundle structure, or a signed receipt. Legacy records may verify as VERIFIED or FAILED depending on available data.

Does NexArt always store the full original content?

Not always. Records may be full, redacted, hash-only, or legacy depending on the source and export path. Some records contain complete snapshot data, others contain only hashes, and redacted exports have sensitive fields removed. The record's bundleType indicates what kind of data is present.

Where do verifiers fetch node keys?

Node signing keys are published at node.nexart.io/.well-known/nexart-node.json. Verifiers use the attestorKeyId from the receipt to select the correct key for Ed25519 signature verification.

Which AI models are supported?

NexArt does not depend on a specific AI provider. Model identifiers can be recorded in CER metadata. NexArt can be used with many AI systems as long as valid execution records are produced.

Can I self-host an attestation node?

Self-hosted attestation nodes are on the roadmap but not currently available.

Where can I verify a CER?

Public verification is available at https://verify.nexart.io/c/{certificateHash}. Independent verification can also be performed locally using the CER bundle, signed receipt, and node keys from node.nexart.io/.well-known/nexart-node.json.

Why does NexArt default to protocolVersion 1.2.0 if I omit protocolVersion?

Because older clients and existing records were created before explicit 1.3.0 / JCS support. Defaulting omitted or null protocolVersion to 1.2.0 preserves backward compatibility and keeps legacy records verifiable. New integrations that require RFC 8785 JCS canonicalization should set protocolVersion: "1.3.0" explicitly at creation/sealing time. See Verification Model → protocolVersion.

How do I use RFC 8785 JCS?

Create the CER with protocolVersion: "1.3.0". Pass it into createSnapshot (or the equivalent SDK entry point such as certifyDecision) so it is part of the sealed snapshot. Do not add or change it after sealing — it controls the canonicalization profile (jcs-v1) used to compute the certificateHash. The CLI equivalent is --protocol-version 1.3.0. See the SDK reference for a code example.

What happens if I send protocolVersion "2.0.0" or another unsupported version?

The node rejects unsupported explicit protocol versions before signing. Verification also fails closed on unknown protocolVersion values. This prevents unsupported records from being accidentally attested or silently accepted by verifiers.

Why does the root node endpoint still show protocolVersion "1.2.0"?

That value represents the node's default/backward-compatible protocol version for clients that do not specify one. It does not mean 1.3.0 is unsupported. For an individual CER, check the sealed snapshot, the node receipt, and the verification envelope attestation. A 1.3.0 CER will carry protocolVersion: "1.3.0" in those signed surfaces; the node mirrors it from the sealed snapshot rather than rewriting it on the UI side. NexArt proves the integrity and authenticity of the execution record, not the correctness of the AI result.

Can I change protocolVersion after creating the CER?

No. protocolVersion sits inside the sealed snapshot and is part of the strict whitelist projection that produces the certificateHash. Changing it after sealing changes what is being verified and invalidates the record. Set it correctly at creation/sealing/certification time. See Hashes and Attestation Node.

FAQ