Verification Statuses & Errors

Every verification outcome and node error, what most likely caused it, and what to do next.

This page is the operational counterpart to Verification Semantics. Semantics defines what results mean. This page maps them to causes and fixes.

Success

Artifact integrity is confirmed. No action required.

Outcome	Meaning	Likely cause	What to do
`VERIFIED`	All applicable checks passed. Artifact integrity is confirmed.	Normal success path.	Treat the artifact as verified.

Core integrity passes. Additional context is reported but does not invalidate verification.

Outcome	Meaning	Likely cause	What to do
`VERIFIED (supplemental)`	Core integrity passed. Supplemental context (e.g. signals outside hash scope) is present.	context.signals were transported alongside the bundle but are not bound by the certificateHash.	Safe to treat as verified. If you require signals to be hash-bound, re-issue with signals inside the canonical bundle.
`CONTEXT_NOT_PROTECTED`	Context signals were submitted but are not covered by the certificateHash.	Signals were transported as supplemental metadata, outside the canonical bundle.	Treat as supplemental. Not a failure of core integrity. See Context Signals.

Do not treat the artifact as verified. Investigate before trusting.

Code	Meaning	Likely cause	What to do
`FAILED`	One or more checks failed. Do NOT treat as verified.	Bundle was modified, signature is invalid, or recomputed hash does not match.	Re-fetch the original artifact. If the failure persists, the artifact has been tampered with or was never valid.
`CERTIFICATE_HASH_MISMATCH`	Recomputed certificateHash does not match the value in the bundle.	Non-canonical JSON: undefined values, key reordering, extra whitespace, or wrong serializer.	Re-serialize using the SDK's canonical encoder. Do not hand-build bundle JSON.
`HASH_MISMATCH`	Same as above but for projectHash on Project Bundle registration.	Steps were modified after the bundle was sealed, or non-canonical JSON.	Rebuild the bundle from the original step CERs and re-register.
`PERSISTENCE_FAILED`	Node accepted the request but could not persist it.	Transient backend issue.	Retry with backoff. Registration is idempotent on projectHash / certificateHash.
`AUTH_INVALID`	API key missing, malformed, or rejected.	Wrong key, wrong environment, or revoked key.	Confirm NEXART_API_KEY is set and matches the App in the dashboard.

The artifact cannot be found at the address used. Usually a registration or identity problem.

Outcome	Meaning	Likely cause	What to do
`NOT_FOUND`	No record of this certificateHash or projectHash on the node.	Artifact was never registered, or you are looking it up by the wrong identifier.	Confirm you are using certificateHash (not executionId). For Project Bundles, register via /v1/project-bundle/register.
`LOCAL_OK_PUBLIC_NOT_FOUND`	verifyCer / verifyProjectBundle passes locally but verify.nexart.io returns NOT_FOUND.	The artifact was never registered on the node.	For single CER: call /api/attest. For Project Bundle: call /v1/project-bundle/register.

Local verify passes, public verify says NOT_FOUND: you skipped the registration step. See Project Bundle Registration.
Recomputed hash differs from bundled hash: you are building JSON outside the SDK. Re-serialize with the canonical encoder.
Result is VERIFIED (supplemental): this is success. Signals are recorded but not hash-bound. See Context Signals.
Public hash differs from the hash you originally produced: you are looking at a redacted reseal. See Public Reseals & Redacted Verification.