Trust Model: What NexArt Verification Proves
What NexArt cryptographic verification, Node attestation and optional time evidence establish, and the limits around truth, completeness, identity and public visibility.
NexArt is verifiable execution infrastructure: it creates cryptographically verifiable evidence of what an integration submitted. This page states, for each layer, exactly what that evidence proves and where the guarantee ends. It applies across record families; where a rule depends on the family, schema or version, the page says so.
1. Integrity and canonical hashing
Every sealed record carries a SHA-256 certificateHash. The hash covers the protected projection defined by the applicable record family, schema and version. Fields outside that projection are not covered. Verification recomputes the projection from the record and compares it with the declared hash.
The producer creates the hash. On attestation, the Node recomputes the protected projection to check the producer-supplied hash; it does not create, replace or alter a valid producer hash, and it fails closed on a mismatch.
Canonicalization is bound to the record's declared profile, not universal:
- AI CERs on protocol
1.2.0use the NexArtnexart-v1canonicalization profile. - Records explicitly using
jcs-v1use RFC 8785 (JCS). - Governed Execution records (
cer.governed.execution.v1) use the canonicalization defined by their own SDK and profile contract; see Governed Execution schema.
An unknown protocol version or profile fails verification.
- The protected submitted content has not changed since it was sealed.
- That the content is true, correct or complete. A hash proves integrity of what was submitted, nothing more. The same execution does not necessarily produce the same hash: timestamps, identifiers and other protected fields vary between runs.
2. Node attestation and signature authenticity
The attestation Node is a cryptographic attestor of the submitted record. It is not a witness to the underlying real-world execution. It signs a defined receipt (and, where applicable, a verification envelope) with an Ed25519 key identified by kid. Verifiers MUST check the signatures themselves rather than trusting an ok flag or an HTTP 2xx status.
A Node operated by NexArt is operationally separate from the producer integration. That separation limits what a producer can forge on its own, but the Node's signature and timestamp are still assertions made by that Node.
- A particular signing key signed the defined receipt or envelope.
- The signature matches the protected signed payload.
- The signed receipt binds the record identity to a Node-issued timestamp.
- The signed material has not been altered without invalidating verification.
- Execution truth, semantic correctness or policy correctness.
- Producer honesty or completeness of capture.
- Independent user identity. Producer-declared fields such as executionRole, instruction, identity and policyEvaluation are attributable to the producer, not independently proven.
- Independent proof of wall-clock time.
- Public publication or public discoverability.
3. Time evidence, timestamps and key lifecycle
Timestamps
attestedAt/ receipt timestamp. A Node-issued, signed timestamp. It is not independent proof that the record existed at that wall-clock time.- RFC 3161. Optional third-party time evidence. Where a valid external RFC 3161 timestamp is attached and independently verified, it provides time evidence from a party other than the Node.
Not every record is guaranteed to carry an RFC 3161 timestamp. The presence of an RFC 3161 object is not enough: its signature, trust chain and message imprint MUST verify. Absence or failure of the optional external timestamp MUST be reported separately from record-integrity and Node-signature checks.
Keys and rotation
Receipts identify their signing key by kid. The active key can be rotated. Verifiers resolve kid against the Node key metadata published at node.nexart.io/.well-known/nexart-node.json, which exposes per-key lifecycle fields including kid, status, revoked, notBefore, validFrom and validTo. Unknown, unavailable, revoked or policy-disallowed keys MUST NOT be silently accepted. For operational guidance see Key Management.
- Which key, by kid, signed a receipt, and whether that key is present in the Node's published metadata with the stated lifecycle fields.
- Where a valid RFC 3161 timestamp is attached and verified: that the timestamped digest existed no later than the time asserted by that timestamp authority.
- That a record existed at its Node-issued timestamp, on that timestamp alone.
- That a signature predates a key compromise.
- Anything about a record if the key's private material was compromised without detection.
4. Workflow scope, structural consistency and completeness of capture
NexArt seals what the integration submits at runtime. Records and Project Bundles declare their scope (steps, included inputs, parameters and outputs, protocol version), and that declaration is part of the protected content. Declared references are checked according to the applicable contract: for example, Project Bundles require every parent reference to resolve to a recorded step.
Verification cannot determine whether the integration omitted actions it never recorded. Completeness of capture requires a producer-side capture policy, an expected manifest or another enforceable completeness contract.
- The submitted evidence is intact, and structurally consistent and referentially closed under the declared contract.
- That the integration submitted every relevant input, output or step, or that the evidence covers every real-world action, unless the integration commits to an enforceable manifest of expected steps.
Publication and storage
The following are separate operations, and none implies the next: local sealing, local verification, Node attestation, Node persistence, authenticated visibility changes, public lookup and public verification. Attestation does not automatically publish a record, and public verification is not guaranteed after attestation. Whether the Node stores data depends on the endpoint, record family, submitted representation, retention policy and visibility configuration; persistence is not public discoverability.
Summary
NexArt is the execution-evidence layer. It establishes the integrity of what was recorded, the authenticity of Node signatures, Node-asserted and optionally third-party time evidence, and the structural consistency of submitted workflows. Assessing whether that evidence is sufficient for a given governance conclusion is a separate, higher layer.