Verification Semantics

How to read verification results correctly: identity, reseal behavior, signals scope, and common pitfalls.

This page resolves the ambiguities builders most often hit when integrating NexArt verification. Read it once before shipping.

certificateHash Is the Source of Truth

certificateHash is the canonical identity of any Certified Execution Record. Always store and resolve artifacts by certificateHash.

Public verification URL: https://verify.nexart.io/c/{certificateHash}
SDK lookup, deduplication, audit trails: keyed on certificateHash
For Project Bundles: projectHash plays the same role at the bundle level

executionId is not a unique artifact identifier

executionId is a convenience identifier returned by the certify API. It MUST NOT be used as the primary key for storage, deduplication, or public verification URLs. Use certificateHash.

Resealed Artifacts Have a New Hash

The public verifier MAY return a redacted reseal instead of the original CER. A reseal exists so that artifacts containing sensitive metadata can still be publicly verified after redaction.

A reseal is a new bundle:

bundleType: signed-redacted-reseal
NEW certificateHash: covers the resealed (redacted) content
Provenance pointer: references the ORIGINAL certificateHash (reference only, not validated)
Fresh node signature: covers the resealed content

Reseal provenance shape (illustrative)

{
  "bundleType": "signed-redacted-reseal",
  "certificateHash": "sha256:<NEW resealed hash>",
  "provenance": {
    "originalCertificateHash": "sha256:<ORIGINAL hash>",
    "reason": "public-redaction",
    "resealedAt": "2026-04-19T10:12:00.000Z"
  },
  "snapshot": { "...redacted snapshot...": true },
  "meta": {
    "attestation": {
      "receipt": { "certificateHash": "sha256:<NEW resealed hash>" },
      "signature": "...",
      "kid": "key_..."
    }
  }
}

Rules to apply when you receive a reseal:

The resealed certificateHash is what the verifier validates.
The original certificateHash is reference-only in public context. Do not validate against it.
Both hashes can legitimately coexist. They describe the same execution at different visibility levels.
If your application stores the original hash, also store the resealed hash returned by the verifier; treat them as a pair.

Context Signals: Inside vs Outside Hash Scope

Context signals MAY be transported either inside or outside the certificateHash scope:

Inside the hash. Signals are part of the canonical bundle. Any change invalidates the hash. This is the strongest binding.
Outside the hash. Signals are transported as supplemental metadata. They are recorded and visible, but their absence or modification does NOT invalidate certificateHash.

The verification report distinguishes the two. Signals outside the hash scope are reported as supplemental, not as a failure. Do not treat "signals outside hash scope" as a verification failure.

Verification Result Classes

Status	Meaning	Action
VERIFIED	All applicable checks PASS. No supplemental notes.	Trust the artifact.
VERIFIED (supplemental)	Core integrity PASS. Supplemental context present but outside hash scope (e.g. unbound signals).	Trust the artifact. Note that supplemental fields are not cryptographically bound.
FAILED	One or more applicable checks FAIL.	Do not trust. Inspect the per-pillar report.
NOT_FOUND	Artifact not registered on the node.	Register on the node, then re-resolve.

See Verification Reports for the full per-pillar semantics.

Common Pitfalls

Using executionId instead of certificateHash for lookup. The execution id is API convenience metadata; only certificateHash is the canonical identity.
Sending undefined values inside metadata or signals. Some runtimes drop undefined keys before serialization, others coerce them. Either omit the key or use null to keep canonical JSON deterministic.
Assuming all signals are hash-bound. They MAY be supplemental. Treat the verifier's "supplemental" status as a normal result.
Confusing the original certificateHash with the public resealed hash. Validate against whichever hash the verifier returns. Store both as a pair.
Treating local verifyProjectBundle() as proof of public verifiability. It only proves integrity. See End-to-End Verification.

End-to-End Verification: the full pipeline.
How Verification Works: per-pillar checks.
Attestation Node: reseal behavior at the node level.