# NexArt Documentation — Full Text > Concatenated full text of every NexArt documentation page. > Companion to /llms.txt (which lists URLs only). > Generated at build time from the live rendered pages. Generated: 2026-04-22T12:54:18.556Z Pages: 47 --- # Getting Started URL: https://docs.nexart.io Getting StartedPick the path that matches your use case: a single execution CER, or a multi-step Project Bundle.What NexArt DoesNexArt creates Certified Execution Records (CERs), cryptographically bound records of AI or deterministic execution that can be independently verified.Every CER produces a deterministic certificateHash. That hash is the canonical identity of the record. Optional node attestation produces a signed receipt so anyone can verify the record without trusting your infrastructure.Two Integration PathsNexArt supports both single-execution certification and multi-step workflow certification. Pick the one that matches your use case. You do not need Project Bundles for every integration.Path A - Single CEROne execution, one verifiable record.Run the executionCreate a CER (@nexart/ai-execution)Optional: verify locallyOptional: attest via node and share /c/{certificateHash}Path B - Project BundleMulti-step or multi-agent workflows verified as a unit.Create a CER per stepAssemble a Project BundleRegister the bundle on the nodeVerify publicly at verify.nexart.ioInstall the SDKnpm install @nexart/ai-executionCurrent version: @nexart/ai-execution@0.15.0.Path A: Create a Single CERThe simplest integration. One execution produces one verifiable record.Single CERimport { createLangChainCer } from "@nexart/ai-execution"; const { certificateHash } = createLangChainCer({ provider: "openai", model: "gpt-4o-mini", input: { messages: [{ role: "user", content: "What is 2 + 2?" }] }, output: { text: "4" } }); console.log(certificateHash);The certificateHash is the canonical identity of the record. Verify the CER locally with the SDK, or share the public URL https://verify.nexart.io/c/{certificateHash}.Note: executionId is not a unique artifact identifier. Always look up records by certificateHash.Path B: Workflow with a Project BundleFor multi-step or multi-agent workflows, certify each step as its own CER and group them into a Project Bundle. The bundle has its own projectHash covering all step certificateHash values.Linear workflow with @nexart/agent-kitimport { startWorkflow } from "@nexart/agent-kit"; const workflow = startWorkflow({ projectTitle: "Contract review" }); const clauses = await workflow.step("Extract clauses", async () => { return await llm.call("Extract key clauses..."); }); const risks = await workflow.step("Summarize risks", async () => { return await llm.call("Summarize risks from: " + clauses); }); const bundle = workflow.finish(); // bundle.integrity.projectHash is the verifiable hashFor public verification on verify.nexart.io, the bundle must be registered on the node. See End-to-End Verification for the full registration flow.Verify the RecordVerification can be performed independently. Open https://verify.nexart.io and paste the certificateHash, or open the URL directly:https://verify.nexart.io/c/{certificateHash}Official Example ReposLangChain exampleCreate and verify CERs in LangChain chains and agent workflows.github.com/artnames/nexart-langchainn8n exampleTurn n8n workflow outcomes into Certified Execution Records.github.com/artnames/nexart-n8nNext StepsQuickstart: the shortest path through both pathsProject Bundles: how multi-step workflows are grouped and verifiedEnd-to-End Verification: node registration and public verificationLangChain and n8n: framework integrationsCLI: create and verify CERs from the command line --- # What is NexArt URL: https://docs.nexart.io/docs/what-is-nexart What is NexArtNexArt turns AI and code executions into cryptographically verifiable evidence.The problemLogs describe what happened but do not prove it.Logs can be altered, incomplete, or reconstructed after the fact.Audits rely on trusting systems, not verifying them.There is no standard way to prove that an AI or code execution produced a specific output from a specific input.What NexArt doesEvery execution becomes a Certified Execution Record (CER). CERs capture:InputsOutputsParametersMetadataOptional contextual evidence such as signalsThe record is hashed (SHA-256) to produce a certificateHash. Any change to the record breaks the hash.Single executions are identified by a certificateHash. Multi-step workflows are identified by a projectHash.Logs describe events. CERs prove execution integrity.Core componentsSDKCreates CERs and verifies them locally. See AI Execution SDK.CER (Certified Execution Record)The atomic unit of proof. One execution, one sealed record. See CERs.Project BundlesGroup multi-step workflows into a single verifiable structure with a projectHash. See Project Bundles.NodeIndependent witness and public trust surface. Provides attestation and lookup. Verification always happens independently. No trust in NexArt is required to verify a record. See Attestation Node.verify.nexart.ioPublic verification interface. Runs verification locally in the browser. See verify.nexart.io.How it worksExecute: AI or code runs via SDKRecord: CER is createdSeal: certificateHash is computedAttest (optional): node issues attestationBundle (optional): Project Bundle created, projectHash derivedVerify: using SDK or verify.nexart.ioWhat you can proveWhat ranWith what inputsWhat it producedIn what sequence (for workflows)That it has not been alteredWhere NexArt fitsAI agentsMulti-step workflowsCompliance and audit trailsDecision traceabilityEvidence-backed automationWhat NexArt is NOTNot observabilityNot loggingNot model evaluationNot correctness validationNexArt does not tell you if something is correct. It proves what happened.What NexArt guaranteesIntegrity of what was recorded (tamper-evidence via hashing)Independent verification without trusting NexArt infrastructureAttestation as an optional layer (node receipt, not required for integrity)NexArt does NOT guarantee completeness. Recording every step is the developer's responsibility.Next stepsCertified Execution RecordsProject BundlesVerificationAI Execution SDKAgent Kit --- # Getting Started URL: https://docs.nexart.io/docs/getting-started Getting StartedPick the path that matches your use case: a single execution CER, or a multi-step Project Bundle.What NexArt DoesNexArt creates Certified Execution Records (CERs), cryptographically bound records of AI or deterministic execution that can be independently verified.Every CER produces a deterministic certificateHash. That hash is the canonical identity of the record. Optional node attestation produces a signed receipt so anyone can verify the record without trusting your infrastructure.Two Integration PathsNexArt supports both single-execution certification and multi-step workflow certification. Pick the one that matches your use case. You do not need Project Bundles for every integration.Path A - Single CEROne execution, one verifiable record.Run the executionCreate a CER (@nexart/ai-execution)Optional: verify locallyOptional: attest via node and share /c/{certificateHash}Path B - Project BundleMulti-step or multi-agent workflows verified as a unit.Create a CER per stepAssemble a Project BundleRegister the bundle on the nodeVerify publicly at verify.nexart.ioInstall the SDKnpm install @nexart/ai-executionCurrent version: @nexart/ai-execution@0.15.0.Path A: Create a Single CERThe simplest integration. One execution produces one verifiable record.Single CERimport { createLangChainCer } from "@nexart/ai-execution"; const { certificateHash } = createLangChainCer({ provider: "openai", model: "gpt-4o-mini", input: { messages: [{ role: "user", content: "What is 2 + 2?" }] }, output: { text: "4" } }); console.log(certificateHash);The certificateHash is the canonical identity of the record. Verify the CER locally with the SDK, or share the public URL https://verify.nexart.io/c/{certificateHash}.Note: executionId is not a unique artifact identifier. Always look up records by certificateHash.Path B: Workflow with a Project BundleFor multi-step or multi-agent workflows, certify each step as its own CER and group them into a Project Bundle. The bundle has its own projectHash covering all step certificateHash values.Linear workflow with @nexart/agent-kitimport { startWorkflow } from "@nexart/agent-kit"; const workflow = startWorkflow({ projectTitle: "Contract review" }); const clauses = await workflow.step("Extract clauses", async () => { return await llm.call("Extract key clauses..."); }); const risks = await workflow.step("Summarize risks", async () => { return await llm.call("Summarize risks from: " + clauses); }); const bundle = workflow.finish(); // bundle.integrity.projectHash is the verifiable hashFor public verification on verify.nexart.io, the bundle must be registered on the node. See End-to-End Verification for the full registration flow.Verify the RecordVerification can be performed independently. Open https://verify.nexart.io and paste the certificateHash, or open the URL directly:https://verify.nexart.io/c/{certificateHash}Official Example ReposLangChain exampleCreate and verify CERs in LangChain chains and agent workflows.github.com/artnames/nexart-langchainn8n exampleTurn n8n workflow outcomes into Certified Execution Records.github.com/artnames/nexart-n8nNext StepsQuickstart: the shortest path through both pathsProject Bundles: how multi-step workflows are grouped and verifiedEnd-to-End Verification: node registration and public verificationLangChain and n8n: framework integrationsCLI: create and verify CERs from the command line --- # Quickstart URL: https://docs.nexart.io/docs/quickstart QuickstartTwo integration paths: single execution CER, or multi-step Project Bundle. Pick one.The fastest path from zero to a verified record. For a broader overview, see Getting Started.Choose a PathPath A - Single CER: certify one execution. The most common starting point.Path B - Project Bundle: certify a multi-step or multi-agent workflow as a single verifiable unit.Project Bundles are not required for single-execution use cases.Path A: Single CER1. Install the SDKnpm install @nexart/ai-executionCurrent version: @nexart/ai-execution@0.15.0.2. Create and Certify a CERCertify a single AI Executionimport { createLangChainCer } from "@nexart/ai-execution"; const { bundle, certificateHash } = createLangChainCer({ provider: "openai", model: "gpt-4o-mini", input: { messages: [{ role: "user", content: "Should this report be approved?" }] }, output: { decision: "approve", reason: "policy_passed" } }); console.log(certificateHash);This produces a Certified Execution Record locally and returns a deterministic certificateHash. That hash is the canonical identity of the record.3. VerifyOpen verify.nexart.io and paste the certificateHash, or open the URL directly:https://verify.nexart.io/c/{certificateHash}Local CER creation produces a valid, verifiable artifact. Public resolution on verify.nexart.io depends on node attestation or availability of the record.The verifier checks Bundle Integrity, Node Signature (if attested), and Receipt Consistency.Path B: Project Bundle (Multi-Step Workflow)1. Install agent-kitnpm install @nexart/agent-kitCurrent version: @nexart/agent-kit@0.4.0.2. Build a workflowLinear workflow producing a Project Bundleimport { startWorkflow } from "@nexart/agent-kit"; const workflow = startWorkflow({ projectTitle: "Refund decision" }); const policy = await workflow.step("Check policy", async () => { return { eligible: true, policyId: "ret-30d" }; }); const decision = await workflow.step("Final decision", async () => { return { decision: "approve_refund", policy }; }); const bundle = workflow.finish(); console.log(bundle.integrity.projectHash);3. Register on the node and verify publiclyTo make the bundle verifiable on verify.nexart.io, register it on the node. See End-to-End Verification for the registration flow and node behavior.Important: certificateHash, not executionIdAlways look up and share records by certificateHash. executionId is not a unique artifact identifier and must not be used as the primary identity for verification.Next StepsLangChain Integration: certify chain and agent executionsn8n Integration: certify workflow automation resultsProject Bundles: deeper look at multi-step verificationCLI: create and verify CERs from the command lineVerification: deep dive into verification semantics --- # Certified Execution Record (CER) Protocol URL: https://docs.nexart.io/docs/cer-protocol Certified Execution Record (CER) ProtocolGovernance, verification semantics, and schema rules for the NexArt protocol.Version: Draft v1Status: Public Specification DraftThe NexArt protocol defines a standardized structure for Certified Execution Records (CERs) and the rules for verifying and evolving those records.CERs allow AI executions and deterministic computations to produce portable, verifiable execution artifacts.A CER contains:Execution snapshotDeterministic certificate hashOptional node attestationVerification metadataThese artifacts can be verified by any NexArt-compatible verifier.Protocol ScopeThe CER protocol defines the structure and verification semantics for execution records produced by NexArt-compatible systems.The protocol currently supports multiple execution surfaces, including:AI execution certificationDeterministic rendering (Code Mode)Each surface defines its own namespace. Examples:cer.ai.execution.v1 cer.codemode.render.v1The protocol governs:CER bundle structureVerification semanticsSchema versioningCompatibility rulesDeprecation policiesCanonical CER StructureA CER bundle is a structured JSON object.Example CER Bundle{ "bundleType": "cer.ai.execution.v1", "version": "0.1", "createdAt": "2026-03-08T20:30:00Z", "certificateHash": "sha256:...", "snapshot": { "type": "ai.execution.v1", "executionId": "demo-001", "provider": "openai", "model": "gpt-4o-mini", "inputHash": "sha256:...", "outputHash": "sha256:..." }, "meta": { "attestation": { "receipt": { "certificateHash": "sha256:...", "timestamp": "2026-03-08T20:30:00Z", "nodeId": "nexart-node-primary", "kid": "k1" }, "signature": "BASE64_SIGNATURE" } } }A CER bundle contains three logical layers:SnapshotExecution data describing the inputs and outputs of a run.Certificate HashA deterministic hash of the canonicalized bundle.AttestationAn optional node receipt and signature confirming observation of the execution.Canonical Hash ComputationThe certificateHash is computed by hashing the canonicalized CER bundle.Canonicalization ensures that equivalent bundles produce identical hashes regardless of JSON formatting.The canonicalization process:Removes non-deterministic fieldsSorts object keys deterministicallySerializes the bundle using canonical JSON encodingThe hash algorithm used by the protocol is:SHA-256The resulting certificate hash is formatted as:sha256:Hash comparison must be performed on the normalized hexadecimal digest without whitespace or case differences.All NexArt-compatible verifiers must compute the certificate hash using this canonicalization process.Hash ScopeThe certificate hash is computed from the canonicalized CER bundle excluding attestation metadata.Fields under the following paths are excluded from the hash computation:meta.attestation meta.attestation.receipt meta.attestation.signatureThese fields are excluded because they are produced after the certificate hash is computed.This ensures the bundle hash remains stable before and after node attestation.Verification SemanticsVerification confirms that a CER bundle is internally consistent and optionally attested by a NexArt node.Verification consists of three checks:Bundle IntegrityThe certificate hash must match the canonicalized bundle contents.Node SignatureIf a node attestation exists, the signature must validate against the node's public keys.Receipt ConsistencyThe receipt certificateHash must match the bundle certificateHash.Node attestation is optional. A CER bundle without attestation can still be verified for bundle integrity, but cannot prove that a NexArt node observed the execution.Verification Result SchemaAll NexArt-compatible verifiers should produce a standardized verification result.Verification Result (with attestation){ "status": "VERIFIED", "checks": { "bundleIntegrity": "PASS", "nodeSignature": "PASS", "receiptConsistency": "PASS" }, "reasonCodes": [], "certificateHash": "sha256:...", "bundleType": "cer.ai.execution.v1", "verifiedAt": "2026-03-08T20:40:00Z", "verifier": "nexart-verifier/1.0.0" }Each check value must be one of:PASS FAIL SKIPPEDPASS: check succeededFAIL: check failedSKIPPED: check not applicable (e.g. no attestation present)Example verification result without attestation:Verification Result (without attestation){ "checks": { "bundleIntegrity": "PASS", "nodeSignature": "SKIPPED", "receiptConsistency": "SKIPPED" } }This structure allows verification results to be consumed consistently across:CLI verificationPublic verifierDashboard verification reportsExported audit packagesVerification Status ValuesThe status field indicates the overall verification outcome.Allowed values:VERIFIED FAILED NOT_FOUNDVERIFIED. All verification checks passed.FAILED. One or more verification checks failed.NOT_FOUND. The requested execution record was not located.Reason CodesReason codes provide machine-readable explanations for verification failures.Current codes include:BUNDLE_HASH_MISMATCH NODE_SIGNATURE_INVALID NODE_SIGNATURE_MISSING RECEIPT_HASH_MISMATCH SCHEMA_VERSION_UNSUPPORTED RECORD_NOT_FOUND BUNDLE_CORRUPTEDReason codes must remain stable across protocol versions. Human-readable messages may change, but reason codes must remain consistent.Schema VersioningCER bundles include a namespace and schema version. Example:cer.ai.execution.v1The namespace (cer.ai.execution, cer.codemode.render) identifies the execution surface and ensures schema evolution can occur independently across surfaces.Minor schema updates may introduce new optional fields without breaking compatibility.Example: v1.0 → v1.1Breaking changes require a new namespace version.Example: cer.ai.execution.v2Compatibility RulesCER readers must support forward compatibility. Readers should:Ignore unknown optional fieldsPreserve unknown metadataSupport verification of earlier revisions within the same major versionThese rules allow the protocol to evolve without breaking existing integrations.Deprecation PolicyFields may be deprecated but must remain readable for a minimum period. Standard policy:Deprecated fields remain readable for at least 12 months.Deprecated fields must be documented in the protocol specification.Removal of deprecated fields requires a new major version.Conformance RequirementsA NexArt-compliant verifier must:Compute the canonical bundle hashValidate node attestation signaturesConfirm receipt consistencyProduce a standardized verification resultSystems implementing these steps can be considered CER-compatible verifiers.Alignment with AIEFThe CER protocol aligns with the AI Execution Integrity Framework (AIEF).AIEF ConceptCER EquivalentExecution ArtifactCER SnapshotExecution FingerprintcertificateHashIntegrity ProofNode Attestation ReceiptAudit EvidenceVerification ReportThis alignment allows CERs to serve as verifiable execution artifacts within AIEF-compliant systems.Record Management LayerLifecycle management, archival behavior, and record actions (hide, delete, revoke, export) are defined separately in the CER Record Management documentation.These concepts operate at the storage, visibility, and governance layer and do not modify the CER bundle, certificateHash, or verification semantics.Protocol SurfacesThe CER protocol is implemented across several NexArt system surfaces.These surfaces share the same schema and verification semantics.Current protocol implementations include:NexArt Node: produces CER bundles and node attestationsNexArt CLI: local creation and verification of CER bundlesNexArt Verifier: public verification interfaceNexArt Dashboard: storage, export, and audit reportsNexArt SDKs: developer libraries for generating and verifying CERsAll implementations must follow the verification semantics defined in this specification. --- # CER Record Management URL: https://docs.nexart.io/docs/cer-record-management CER Record ManagementOperational lifecycle and enterprise control semantics for CER records.CER bundles are immutable protocol artifacts. Record management defines how organizations store, surface, and govern CER records over time.This page defines management-layer behavior only. It does not modify the CER protocol schema, certificateHash computation, or verification semantics.CER Lifecycle ModelThis section defines the operational lifecycle of a Certified Execution Record as a managed record inside the NexArt system.Lifecycle states describe how records are managed, stored, or presented. They do not describe how the CER bundle itself behaves cryptographically.CER bundles are immutable protocol artifacts. Lifecycle states apply to record management systems such as dashboards, storage layers, and audit workflows.Lifecycle StatesActiveThe CER is stored and available for normal operations. It can be resolved by execution ID or certificate hash and may appear in dashboard queries and exports.ExportedExported indicates that a CER has been included in one or more evidence exports. Export does not modify the CER or change its verification status. Exported is an event marker, not a storage state. A CER may be exported while remaining Active, Archived, or in any other lifecycle state.ArchivedThe CER has been moved to long-term storage for retention purposes. Archived records remain cryptographically verifiable and may still be resolved through the verification system. Archived records may be excluded from normal dashboard queries but remain accessible through audit workflows.HiddenThe CER remains stored and verifiable but is no longer publicly resolvable through public endpoints. Hidden records remain accessible to authorized organizational users and retain full verification capability.Deleted (storage-level deletion)The stored bundle may be removed from the NexArt storage layer according to retention policies. However, deletion does not invalidate the underlying cryptographic provenance of the CER. Any previously exported bundles or receipts remain independently verifiable.Lifecycle TransitionsLifecycle states may transition through operational actions:Active → ArchivedActive → HiddenArchived → Active (restore)Active → Deleted (storage-level removal)Transitions affect storage and visibility behavior, not the CER bundle contents.Audit VisibilityLifecycle states influence how records appear in operational interfaces but must not alter their verification integrity.Verification tools must evaluate CER bundles independently of lifecycle state. Audit workflows must preserve historical visibility of lifecycle actions.Interaction with Protocol ImmutabilityLifecycle management never modifies the CER bundle, certificateHash, or attestation receipt. All lifecycle operations occur at the record management layer and do not affect the cryptographic validity of the record.Record Action SemanticsThis section defines the management actions that may apply to stored CER records.These actions operate at the storage, visibility, and governance layer. They do not modify the CER bundle, certificateHash, or signed receipt.HideA hidden record remains stored and cryptographically verifiable but is no longer publicly resolvable through public verification endpoints. Hidden records remain accessible to authorized organizational users and retain full verification capability.Delete (storage-level deletion)Deletion removes the stored bundle from the NexArt-managed storage layer according to retention or governance rules. Deletion does not invalidate the underlying cryptographic provenance of the record. Previously exported bundles, receipts, and verification artifacts remain independently verifiable.Deletion is a governance-sensitive action. Organizations may restrict deletion to authorized governance review processes rather than exposing it as a normal self-service operation.RevokeRevocation does not alter or delete the original CER. Instead, revocation is a governance action indicating that the original record should no longer be treated as operationally valid for current workflows. A revocation must preserve the historical audit trace of the original CER.Revocation is a governance-sensitive action. Organizations may choose not to expose revocation as a direct user-facing action, instead handling it through governance review workflows.ExportExport creates an external evidence package or bundle copy for audit or archival use. Export does not modify the CER or change its verification status.Revocation SemanticsRevocation must not mutate the original CER. The original record remains historically valid as evidence of what was certified at the time.Revocation affects operational reliance, not historical existence or cryptographic validity. A revoked CER still proves that a specific execution was certified. It simply indicates that the record should no longer be relied upon for current operational purposes.Future protocol revisions may represent revocation as a separate linked artifact. This documentation defines revocation semantics without extending the current schema.Deletion SemanticsDeletion refers only to removal from managed storage layers. Deletion does not erase:Prior exportsIndependently held CER bundlesSigned receiptsHistorical evidence that a record once existedDeletion therefore affects availability, not cryptographic history.Public Visibility SemanticsA hidden record may no longer resolve through public verification URLs or public certificate-hash lookup. However, hiding does not change the CER itself, its certificateHash, or its signed receipt.Organizationally authorized users may still access hidden records through internal control surfaces, subject to permissions and policy.Audit Trace PreservationAll hide, revoke, delete, and export actions must preserve an audit trail at the management layer.Management actions must remain visible to authorized audit workflows even when the underlying record is hidden or removed from primary storage. Historical accountability is preserved even when operational visibility changes.Interaction with Lifecycle ModelRecord actions interact with lifecycle states defined in the CER Lifecycle Model. Hide may move a record into the Hidden state. Delete may move a record into Deleted (storage-level deletion). Export may record an Exported lifecycle event. Revoke may affect operational validity without mutating the CER or its lifecycle state.Archival Behavior ModelThis section defines what it means for a Certified Execution Record to be archived inside the NexArt system.Archival is a record-management behavior, not a change to the CER bundle itself. Archiving must not modify the CER, certificateHash, attestation receipt, or verification semantics.Storage BehaviorAn archived CER is moved from active operational storage into long-term managed storage.Archived records may be excluded from normal dashboard lists, high-frequency operational queries, or default application views.However, archival must preserve the ability to retrieve the record for audit, restore, or verification purposes according to organizational policy.Public ResolvabilityArchival does not automatically remove a record from public verification surfaces unless separate visibility rules (such as Hidden) apply.An archived record may remain publicly resolvable by execution ID or certificate hash if public visibility is still allowed by policy.If a record is both archived and hidden, public resolution may be disabled while internal audit access remains preserved.Verification PersistenceArchived records remain cryptographically verifiable. Archival does not affect:certificateHash validitySigned receipt validityIndependent verification of previously exported bundlesVerifier interpretation of the recordVerification depends on the CER artifact and receipt, not on whether the record is active or archived.Searchable MetadataArchived records may be excluded from default operational search results.However, core metadata may remain searchable for authorized users, such as:executionIdcertificateHashbundleTypecreatedAtProject and app identifiers where applicableThis allows organizations to locate archived records without restoring them to active state.Restore BehaviorArchived records may be restored to the Active state through management-layer actions.Restoration affects storage and operational visibility only. It does not modify the CER bundle, certificateHash, or signed receipt.Archived → Active is a lifecycle management transition, not a new certification event.Interaction with Protocol ImmutabilityArchival never mutates the CER bundle or its cryptographic evidence. The same CER must remain verifiable before, during, and after archival.Archival changes how the record is stored and surfaced, not what the record is.Relationship to Lifecycle and ActionsArchival is one lifecycle state within the CER Lifecycle Model. It is distinct from Hide (which affects public resolvability) and Delete (which removes the stored bundle). Archival preserves audit trace and verification continuity as defined in the Record Action Semantics.Retention Policy ModelRetention policies define how long CER records remain stored and accessible inside NexArt-managed systems.Retention policies affect storage behavior but never modify CER artifacts, certificateHash, or verification semantics.Retention ClassesOrganizations may define retention classes to categorize how long records are kept:Short-termUsed for temporary operational logs or transient execution records that do not require long-term preservation.StandardThe default retention period for most CER records. Suitable for general operational use.Long-termUsed for regulated workflows or compliance-sensitive systems where extended retention is required.PermanentRecords intended to remain stored indefinitely. Suitable for critical audit evidence or records subject to permanent regulatory requirements.Retention class definitions may vary by organization. The classes listed here are examples. Organizations may define custom classes aligned with their governance requirements.Policy ScopeRetention policies may apply at multiple levels:Organization: default retention for all recordsProject: override for a specific projectApplication: override for a specific app within a projectExecution surface: override based on bundle type (e.g. AI execution vs. Code Mode)Lower-level scopes may override higher-level defaults. For example, an organization default of 5 years may be overridden by a project-level policy of 1 year.Expiry BehaviorWhen a retention period expires, the system may take one or more of the following actions:Archive the recordDelete the stored bundleRequire manual review before deletionTrigger an export before deletionRetention expiry must not invalidate cryptographic evidence. Previously exported bundles and signed receipts remain independently verifiable regardless of whether the stored record has been removed.Legal Hold and Audit HoldRetention policies must support suspension of scheduled deletion when records are subject to:Legal investigationRegulatory reviewInternal auditWhen a record is under hold, deletion must be blocked. Archival may still occur during a hold period, but storage-level removal must be prevented until the hold is released.Interaction with Lifecycle StatesRetention policies influence lifecycle transitions such as:Active → Archived (when a retention period triggers archival)Archived → Deleted (when a retention period expires for archived records)Retention policies never mutate the CER bundle, certificateHash, or attestation receipt. They govern when lifecycle transitions occur, not what happens to the CER artifact itself.Interaction with Record ActionsRetention policies interact with record actions including hide, delete, archive, and export. For example, a policy may trigger an automatic export before a scheduled deletion.However, retention rules must not remove historical audit traces. All retention-driven actions must be logged and remain visible to authorized audit workflows.Evidence and Auditability GuaranteesCertified Execution Records are designed to function as durable execution evidence.A CER captures a verifiable record of a computation or AI execution and binds it to a deterministic certificate hash. When node attestation is present, the record also includes a signed receipt proving that the record existed at a specific point in time.Evidence GuaranteesImmutabilityCER bundles and certificate hashes cannot be modified after creation without invalidating verification. Any alteration to the bundle will produce a different hash, making tampering detectable.Independent VerificationVerification does not require access to NexArt infrastructure. Anyone with the CER bundle and the node's public keys can verify the record independently.Historical VerifiabilityRecords remain verifiable even if they are archived, hidden, or deleted from NexArt-managed storage. Verification depends on the CER artifact and receipt, not on storage state.Audit Trace PreservationManagement-layer actions (archive, hide, revoke, delete, export) must preserve an audit trail visible to authorized workflows. No management action may silently remove evidence of prior record state.Protocol StabilityVerification semantics are versioned and must remain compatible with earlier protocol versions. Records certified under an earlier version must remain verifiable under future verification implementations.Scope of EvidenceCERs provide cryptographic evidence of execution records and attestations.They do not prove that an execution result was correct, desirable, or appropriate. They prove that a specific execution artifact existed and can be verified against its certificate hash and, when present, its attestation receipt.This distinction is important for audit clarity. A CER demonstrates what was executed and certified, not whether the outcome was good.Operational and Sensitive ActionsRecord-management actions in NexArt do not all have the same governance significance. Some actions affect normal storage and operational workflows. Other actions affect visibility, trust posture, or governance and therefore require stronger controls.This classification operates only at the management layer. It does not modify the CER bundle, certificateHash, or signed receipt.Operational ActionsOperational actions are normal management actions that organize, store, or surface CER records without changing their trust meaning.Examples of operational actions include:ExportArchiveRestore from archiveOrdinary record lookupOrdinary internal searchRetention-driven archivalThese actions may affect where or how a record is surfaced, but they do not alter public trust semantics or cryptographic validity.Sensitive ActionsSensitive actions are management actions that affect public visibility, operational trust, long-term availability, or governance posture.Examples of sensitive actions include:Hide from public resolutionDelete stored bundleRevoke operational validityOverride standard retention behaviorApply or release legal/audit holdThese actions require stronger governance controls because they affect how records are relied upon, discovered, or preserved.Some organizations may choose not to expose revocation or deletion as direct user-facing actions. In such cases, these actions are handled through governance review workflows rather than normal self-service UI controls.This section defines the classification only. It does not introduce formal permissions, roles, or approval workflows.Why the Distinction MattersSeparating operational actions from sensitive actions helps organizations apply stronger controls where record visibility, trust posture, or long-term evidence preservation may be affected.This distinction also supports future work on:PermissionsApproval workflowsAudit review processesEnterprise governance controlsInteraction with Lifecycle and RetentionOperational and sensitive actions interact with lifecycle states and retention policies:Archive: generally operationalDelete: sensitiveHide: sensitiveExport: operationalRetention expiry: may trigger operational or sensitive actions depending on policyThe classification helps determine how actions should later be controlled, reviewed, and audited.Interaction with Protocol ImmutabilityNeither operational nor sensitive actions mutate the CER bundle or its cryptographic evidence.The distinction concerns governance significance, not protocol behavior. The CER bundle, certificateHash, and signed receipt remain immutable regardless of how an action is classified.Roles and Permissions ModelOrganizations using NexArt may need to control who can view, manage, export, or modify the operational state of CER records.Roles and permissions apply only to management-layer operations such as lifecycle transitions, export actions, and governance controls. Access control does not modify the CER artifact itself. Verification and cryptographic integrity remain independent of access permissions.Common Role CategoriesThe following role categories represent typical organizational governance structures for CER management. Organizations may implement custom roles aligned with their own requirements.ViewerRead-only access to CER records and verification results. Viewers can browse record metadata and view verification outcomes but cannot modify records or trigger management actions.OperatorOperational access for day-to-day record management tasks. Operators can perform routine lifecycle actions such as archiving, restoring, and exporting records.AuditorRead and export access intended for compliance and review workflows. Auditors can view records and generate evidence packs but cannot modify lifecycle state or governance controls.AdministratorFull management access including lifecycle transitions, policy configuration, and governance controls such as hide, revoke, and delete, subject to policy constraints.Permission CategoriesThe following categories define the main types of actions that may require permission controls. These permissions apply only to record management behavior.Read PermissionsView CER metadata, verification results, and record details.Export PermissionsGenerate evidence packs or export verification artifacts.Lifecycle PermissionsArchive, restore, or hide records.Sensitive PermissionsDelete records, revoke operational validity, or change retention behavior. These permissions may not be exposed through standard self-service interfaces. Organizations may require governance review processes before these actions can be executed.Policy PermissionsModify retention policies or apply legal/audit holds.Example Permission MatrixThe following table illustrates how roles may map to permission categories. This is an example governance model. Organizations may customize their permission structure.RoleReadExportArchiveHideRevokeDeletePolicyViewer✓✗✗✗✗✗✗Operator✓✓✓✓✗✗✗Auditor✓✓✗✗✗✗✗Administrator✓✓✓✓✓✓✓Interaction with Lifecycle and RetentionPermissions determine who can trigger lifecycle transitions such as:Active → ArchivedActive → HiddenArchived → Active (restore)Archived → DeletedPolicy permissions may also control who can:Define retention classesApply retention overridesPlace records under legal or audit holdInteraction with Audit WorkflowsAuditors may require controlled export permissions to generate evidence packs. Export permissions should allow authorized users to create:CER evidence packsVerification snapshotsExport manifestsAudit workflows must not require modification of CER bundles or attestation artifacts.Interaction with Protocol ImmutabilityAccess control and permissions never modify the CER bundle or its cryptographic evidence.Permissions govern operational access and management actions only. CER bundles, certificateHash values, signed receipts, and verification rules remain independent of organizational access control.Policy Control LayerOrganizations may require formal governance rules for how CER records are stored, surfaced, retained, exported, and controlled over time.The policy control layer provides a way to define those rules without modifying the CER protocol itself. Policies apply only to management-layer behavior such as lifecycle transitions, archival, export, retention, visibility, and record actions.Policies do not alter the CER artifact, certificateHash, signed receipt, or verification semantics.Policy CategoriesOrganizations may apply policies across the following governance categories:Retention PoliciesControl how long records remain stored and when they transition to archival or deletion. Retention policies interact with the Retention Policy Model defined earlier on this page.Visibility PoliciesControl whether records are publicly resolvable, hidden from external access, or restricted to internal organizational users. Visibility policies may set default visibility for new records or enforce hiding based on record class.Export PoliciesControl when evidence packs should be generated, what export scope is allowed, and whether exports are required before archival or deletion. Export policies support audit readiness by ensuring evidence is preserved before lifecycle transitions.Action PoliciesControl whether specific management actions (such as delete, hide, revoke, or restore) are allowed under normal operation. Action policies may block or constrain actions that would otherwise be permitted by role-based permissions. Organizations may use action policies to ensure that revocation and deletion are only available through governance-controlled workflows rather than as routine self-service operations.Audit PoliciesControl requirements for audit trace preservation, export logging, and evidence retention. Audit policies help organizations maintain accountability and traceability across record management operations.Sensitive Action PoliciesDefine additional controls around actions classified as governance-sensitive. These policies may require additional review, approval, or documentation before sensitive actions are executed.Policy ScopePolicies may apply at multiple organizational scopes:Organization-wide: default governance rules for all recordsProject: override for a specific projectApplication: override for a specific app within a projectExecution surface: override based on bundle typeRecord class or workflow type: override based on record classificationLower-level scopes may override higher-level defaults, consistent with the retention policy scope model.For example:Organization default: archive after 90 daysProject override: retain active for 1 yearExample Policy ExpressionsPolicies may be represented in implementation-specific ways. The governance model typically includes:Policy nameScopeTrigger conditionResulting actionExceptions or overridesThis section does not introduce a formal policy schema. These are conceptual examples of how governance rules may be expressed.Example 1Archive all AI execution CERs after 90 days and retain them for 5 years.Example 2Require evidence export before deleting records classified as long-term or permanent.Interaction with Lifecycle and Record ActionsPolicies may trigger lifecycle transitions such as:Active → ArchivedArchived → DeletedPolicies may also constrain or require management actions such as:Export before deletionHide by defaultPrevent deletion when legal hold existsPrevent revoke except by authorized governance workflowsPolicies govern how actions are applied, not what the CER artifact is.Interaction with Roles and PermissionsPolicies and permissions are related but not identical:Permissions define who is allowed to attempt an action.Policies define whether the action is allowed or required under governance rules.For example, an administrator may have permission to delete a record, but policy may still require export and hold checks before deletion is allowed.This distinction is important for enterprise governance where role-based access alone is not sufficient to enforce organizational rules.Interaction with Audit WorkflowsPolicies may require that certain records:Remain exportablePreserve audit traceTrigger evidence pack creationRemain retained for a specified periodAudit workflows must continue to operate within policy constraints while preserving independent verification. Policies support audit readiness but do not override the ability to verify CER artifacts independently.Interaction with Protocol ImmutabilityPolicies do not mutate the CER bundle, certificateHash, signed receipt, or verification result semantics.Policy controls only govern management-layer operations applied to stored records. The CER protocol remains stable and independently verifiable regardless of policy configuration. --- # Protocol Overview URL: https://docs.nexart.io/docs/protocol-overview Protocol OverviewHow NexArt produces, attests, and verifies execution records.IntroductionNexArt is a protocol for producing verifiable execution records. It allows any system to create a Certified Execution Record (CER), have it attested by a node, and allow independent verification of the result.The protocol separates three concerns:Execution. A system performs an operation and records what happened.Attestation. An independent node signs the record to prove it existed at a specific time.Verification. Anyone can check the record's integrity and the node's signature.The Execution → Attestation → Verification FlowExecution↓CER Bundle Created↓certificateHash Computed↓Attestation Node↓Signed Receipt↓VerificationExecutionAn AI or deterministic system performs an operation. The system records inputs, outputs, and relevant metadata.CER CreationA Certified Execution Record (CER) bundle is created with bundleType: "cer.ai.execution.v1". The bundle contains execution metadata and hashes of inputs and outputs. It follows a deterministic structure so that the same data always produces the same hash.certificateHashA SHA-256 hash of the CER bundle is computed. This becomes the record's fingerprint. Any modification to the bundle produces a different hash, making tampering evident.AttestationThe CER (or its certificateHash alone) is sent to an attestation node. The node timestamps the record and signs it using Ed25519. This creates a binding between the node's identity, the timestamp, and the record.Signed ReceiptThe node returns a signed receipt stored at meta.attestation in the CER bundle. The receipt contains the certificateHash, timestamp, nodeId, and kid (the signing key identifier).VerificationAnyone can verify the record by checking three things: bundle integrity, node signature, and receipt consistency. Verification can be performed locally using the SDK or through verify.nexart.io. The node is not required for verification. Integrity is proven by the hashes alone.Core ComponentsCertified Execution Record (CER)A structured record that captures execution metadata and hashes of inputs and outputs. The CER is the base unit of proof in NexArt. It is portable, self-contained, and deterministic.Attestation NodeAn independent witness that signs CERs and produces receipts. The node does not define truth or control verification. Nodes publish their public keys at node.nexart.io/.well-known/nexart-node.json using kid and activeKid fields so verifiers can independently retrieve them.Signed ReceiptA cryptographic proof returned by the node. It proves that the node witnessed the certificateHash at a specific time. The receipt does not imply the node stores or owns the execution data.VerificationVerification confirms that the CER has not been modified and that the receipt signature is valid. Verification statuses are VERIFIED, FAILED, or NOT_FOUND. Each check returns PASS, FAIL, or SKIPPED.Record TypesNexArt supports several record types depending on the attestation scope and export path:cer.ai.execution.v1. AI execution record. Fully verifiable when attested with a signed receipt.signed-redacted-reseal. A redacted version of a CER that has been re-signed by the node for safe sharing.hash-only-timestamp. Attestation of only the certificateHash. Snapshot contents are not attested.legacy. Older records from previous system versions. May lack full attestation data.Public Surfacesverify.nexart.io is the public verification portal for CERs and Project Bundles.node.nexart.io is the attestation node identity and status surface.node.nexart.io/.well-known/nexart-node.json publishes the node's signing keys for independent signature verification.Why This MattersAI systems increasingly make decisions autonomously. Organizations need to prove what happened, when, and that the record has not been altered. CERs provide a portable, cryptographic record of execution that supports:AuditingComplianceReproducibilityIndependent verificationBecause verification is independent of the original system, any third party can confirm the integrity of a record without trusting the system that produced it. --- # Certified Execution Records URL: https://docs.nexart.io/docs/concepts/cer Certified Execution RecordsCERs are the core unit of proof in NexArt. They prove execution integrity, not just log events.OverviewA Certified Execution Record (CER) is a portable, tamper-evident record of an execution. CERs can represent AI completions, deterministic system operations, or any execution you want to certify.Logs vs CERsLogs describe events. CERs prove execution integrity. A CER binds execution inputs, outputs, parameters, and context into a single tamper-evident artifact with a deterministic hash.A CER binds execution metadata to a certificateHash. The bundle structure is deterministic: given the same inputs, the same hash is produced. Attestation adds a signed receipt under meta.attestation, but the CER itself is the base record.What a CER ContainsInputs: hashed (SHA-256) representation of the execution input. Raw content is not stored in the CER.Outputs: hashed representation of the execution output.Parameters: model identifier, execution configuration.Context (signals): optional structured metadata recorded alongside the execution. See Context Signals.Metadata: application-defined fields like appId and projectId.certificateHash: SHA-256 hash derived from the canonical bundle. This is the unique identifier and what the node signs.CER AnatomyA fully certified CER contains these fields:Top-level fieldsbundleType: identifies the record type (e.g. cer.ai.execution.v1). Determines what verification checks apply.version: protocol version (currently "1.0").createdAt: when the CER was created (ISO 8601).certificateHash: SHA-256 hash derived from the canonical bundle.Snapshot (execution metadata)model: the model or system that produced the execution.inputHash: SHA-256 hash of the input/prompt. The raw input is not stored in the CER.outputHash: SHA-256 hash of the output/completion.metadata: application-defined fields like appId and projectId.Attestation (meta.attestation)Attestation data is stored under meta.attestation in the CER bundle:receipt: the canonical payload signed by the attestation node. Contains certificateHash, timestamp, nodeId, and kid.signature: raw Ed25519 signature over the receipt payload.kid: the signing key identifier, matching a key published at the node's well-known endpoint.Full ExampleCertified CER with Signed Receipt{ "bundleType": "cer.ai.execution.v1", "version": "1.0", "createdAt": "2026-03-06T12:00:00.000Z", "snapshot": { "model": "gpt-4", "inputHash": "sha256:a1b2c3d4e5f6...", "outputHash": "sha256:f6e5d4c3b2a1...", "metadata": { "appId": "my-app", "projectId": "proj_abc123" } }, "certificateHash": "sha256:9e8d7c6b5a4f...", "meta": { "attestation": { "receipt": { "certificateHash": "sha256:9e8d7c6b5a4f...", "timestamp": "2026-03-06T12:00:00.001Z", "nodeId": "nexart-node-primary", "kid": "key_01HXYZ..." }, "signature": "", "kid": "key_01HXYZ..." } } }Create vs CertifyThere are two API endpoints for creating CERs, and the difference matters:POST /v1/cer/ai/create generates a CER bundle with a certificateHash but does not attest it. The meta.attestation field is absent. Use this if you need the bundle for external handling or deferred attestation.POST /v1/cer/ai/certify creates the CER and attests it in one request. Returns the certificateHash, receipt, signature, and a verificationUrl. This is the recommended path for most integrations.Bundle TypesThe bundleType field describes the record type and attestation condition:cer.ai.execution.v1: an AI execution record. Fully verifiable when attested. This is the default when you use the certify endpoint.signed-redacted-reseal: a redacted export that has been resealed and signed again for safe sharing while preserving verifiability.hash-only-timestamp: the receipt signs only the certificateHash. Used when full snapshot attestation is not possible.legacy: historical records that may lack full attestation data.Certificate HashThe certificateHash is a SHA-256 hash derived from the canonical bundle structure. It uniquely identifies the record and is what the attestation node signs. Any modification to the CER produces a different hash, making tampering immediately evident.Export PathsFull export: the complete CER with all snapshot data intact.Redacted export: sensitive fields removed, then resealed and signed so verification still works.Legacy export: older records with limited verification coverage.Tamper EvidenceThe certificateHash makes tampering immediately evident. Any modification to the CER produces a different hash. Verification tools recompute the hash and compare it to detect changes.ReplayabilityBecause a CER captures all relevant execution parameters and context, it can support replay where applicable. The deterministic hash computation means the same inputs always produce the same certificateHash, enabling independent verification without re-executing.VerificationAny CER can be verified independently. No trust in NexArt infrastructure is required. Verification checks:Bundle Integrity: the bundle hashes are internally consistent.Node Signature: the receipt signature is valid against a published node key. SKIPPED if no attestation.Receipt Consistency: the receipt's certificateHash matches the CER bundle. SKIPPED if no attestation.The node provides attestation and discovery. It is not required to verify integrity. Integrity is proven by the hashes alone.Verification statuses: VERIFIED, FAILED, or NOT_FOUND. Each check returns PASS, FAIL, or SKIPPED.Verify using the SDK (verifyCer() or verifyCerAsync()) or at verify.nexart.io.See How Verification Works, Certificate Hash vs Project Hash, and the CER Protocol for full details.What NexArt Guarantees (and Does Not)Guaranteed: integrity of the recorded execution (tamper-evidence via certificateHash), independent verification without trusting NexArt infrastructure.Not guaranteed: correctness of the execution result, completeness of recorded steps. NexArt proves what happened. It does not evaluate whether the result was correct or whether all steps were recorded.Multi-Step WorkflowsFor workflows with multiple steps, CERs can be collected into a Project Bundle with its own projectHash covering the entire sequence. Use agent-kit for simplified workflow orchestration. --- # Project Bundles URL: https://docs.nexart.io/docs/concepts/project-bundles Project BundlesStructured collections of CERs for multi-step workflows.OverviewA Project Bundle is a structured collection of Certified Execution Records representing a multi-step workflow. Where a single CER proves one execution, a Project Bundle proves an entire sequence of executions and their relationships.Why Project Bundles ExistSingle CERs work well for isolated executions. But many real-world systems involve multiple steps:An agent that reasons, calls tools, then summarizesA pipeline that transforms data across several stagesA workflow where each step depends on a previous outputProject Bundles give these multi-step processes a single verifiable artifact with one hash.What a Project Bundle ContainsstepRegistry: ordered step metadata. Each entry contains a stepId, sequence number, stepLabel, and the step's certificateHash.embeddedBundles: the actual CERs, keyed by stepId. Each embedded bundle is a full CER with its own certificateHash.integrity: contains the projectHash and the algorithm used (sha256-canonical-json). Any change to any embedded CER, step metadata, or ordering produces a different projectHash.Project-level metadata: projectBundleId, projectTitle, timestamps (startedAt, completedAt), and optional fields like projectGoal, projectSummary, appName, and tags.Canonical StructureThis is the real stored shape of a Project Bundle artifact.Project Bundle (cer.project.bundle.v1){ "bundleType": "cer.project.bundle.v1", "projectBundleId": "pb_a1b2c3d4", "projectTitle": "Contract review pipeline", "protocolVersion": "1.2.0", "version": "0.1", "startedAt": "2026-04-01T10:00:00.000Z", "completedAt": "2026-04-01T10:02:30.000Z", "totalSteps": 2, "stepRegistry": [ { "stepId": "step_1", "sequence": 0, "stepLabel": "Extract clauses", "certificateHash": "sha256:1111..." }, { "stepId": "step_2", "sequence": 1, "stepLabel": "Summarize risks", "certificateHash": "sha256:2222..." } ], "embeddedBundles": { "step_1": { "bundleType": "cer.ai.execution.v1", "certificateHash": "sha256:1111...", "snapshot": { "model": "gpt-4", "inputHash": "sha256:...", "outputHash": "sha256:..." } }, "step_2": { "bundleType": "cer.ai.execution.v1", "certificateHash": "sha256:2222...", "snapshot": { "model": "gpt-4", "inputHash": "sha256:...", "outputHash": "sha256:..." } } }, "integrity": { "algorithm": "sha256-canonical-json", "projectHash": "sha256:ab12cd34ef56..." } }projectHashThe projectHash is computed using sha256-canonical-json over the canonical content of the Project Bundle. It covers all embedded CERs, the step registry, ordering, and project metadata. Modifying any embedded CER, reordering steps, or changing metadata produces a different hash.This is different from a certificateHash, which covers a single CER. See Certificate Hash vs Project Hash for a detailed comparison.Relationship to CERsA Project Bundle does not replace CERs. Each entry in embeddedBundles contains a full CER that remains independently verifiable by its certificateHash. The Project Bundle adds:Step ordering and sequence via stepRegistryStep identity and labeling (stepId, stepLabel)A single project-level hash covering the entire workflowOptional project-level node receiptDefining Workflow BoundariesNexArt does not automatically detect workflows. The developer explicitly defines the start and end of a workflow and decides which steps are included.A workflow starts when you begin recording CERs for a given process.Each meaningful step must create its own CER.The developer keeps the workflow context consistent and then collects the relevant CERs into a Project Bundle.The workflow ends when you build the Project Bundle from those CERs.Developers often track a shared workflow or conversation identifier in their own system to group related steps. This is a developer-side concern, not a Project Bundle protocol requirement.Conceptual builder exampleThis is a simplified conceptual example showing the general flow. Refer to the AI Execution SDK docs for the exact current helper signatures.Conceptual builder exampleimport { certify, createProjectBundle } from "@nexart/ai-execution"; // Step 1: create CER const cer1 = await certify({ model: "gpt-4", input: "Extract key clauses from the contract.", output: "Clause 1: ..., Clause 2: ..." }); // Step 2: create CER const cer2 = await certify({ model: "gpt-4", input: "Summarize risks from: Clause 1: ..., Clause 2: ...", output: "Risk summary: ..." }); // Build Project Bundle from collected CERs // Step metadata (stepId, sequence, stepLabel) is included when building const projectBundle = await createProjectBundle({ projectTitle: "Contract review pipeline", steps: [ { stepId: "step_1", stepLabel: "Extract clauses", cer: cer1 }, { stepId: "step_2", stepLabel: "Summarize risks", cer: cer2 } ] }); // projectBundle.integrity.projectHash is the verifiable hashImportantNexArt guarantees integrity of what is recorded. It does not guarantee that all steps were recorded. Completeness is controlled by the developer.Best practicesRecord every meaningful step (LLM call, tool call, transformation).Keep step ordering explicit using sequence values.Keep workflow context consistent across steps in your application.Build the Project Bundle immediately after execution completes.Register it on the node if you want public lookup by projectHash.Using agent-kit (recommended)For linear workflows, @nexart/agent-kit removes manual step tracking. Instead of creating CERs individually and assembling them, you use the workflow helpers:startWorkflow() begins a new workflow and generates a workflowIdstep() creates a CER per step. Each step gets its own executionId. The workflowId links them together.finish() builds the Project Bundle synchronouslystep() records the step name as input and the function return value as output. Implicit closure state is NOT recorded.Workflow with agent-kit (v0.3.0)import { startWorkflow } from "@nexart/agent-kit"; const workflow = startWorkflow({ projectTitle: "Contract review" }); const clauses = await workflow.step("Extract clauses", async () => { return await llm.call("Extract key clauses..."); }); const risks = await workflow.step("Summarize risks", async () => { return await llm.call("Summarize risks from: " + clauses); }); const bundle = workflow.finish(); // bundle.integrity.projectHash is the verifiable hashLimitationagent-kit v0.3.0 is designed for linear workflows. For complex DAGs or non-linear execution graphs, use the lower-level SDK helpers (certify + createProjectBundle).VerificationProject Bundles can be verified in two ways:On verify.nexart.io via /p/:projectHash. The site fetches the Project Bundle from the node-backed trust surface and runs verification independently in the browser.With the SDK: verifyProjectBundle() for Node/server environments, or verifyProjectBundleAsync() for browser-safe verification.Verification checks:projectHash integrityEach embedded CER's certificateHashOptional node receipt at the project levelThe node is not required for verification. It provides discovery and independent attestation. Integrity is proven by the hashes alone.See How Verification Works and AI Execution SDK for details. --- # Certificate Hash vs Project Hash URL: https://docs.nexart.io/docs/concepts/hashes Certificate Hash vs Project HashTwo hash types, two scopes. One for single executions, one for multi-step workflows.ComparisoncertificateHashprojectHashScopeSingle execution (one CER)Multi-step workflow (Project Bundle)AlgorithmSHA-256 of canonical CER bundleSHA-256 of canonical Project BundleCoversbundleType, version, createdAt, snapshot, contextAll steps, ordering, per-step CER data, metadataVerification URL/c/:certificateHash/p/:projectHashSDK (sync)verifyCer()verifyProjectBundle()SDK (async)verifyCerAsync()verifyProjectBundleAsync()Tamper EvidenceBoth hashes are tamper-evident. Any modification to the underlying data produces a different hash, making changes immediately detectable during verification.When to Use EachUse certificateHash when you are certifying a single execution: one AI call, one tool invocation, one deterministic operation.Use projectHash when you are certifying a multi-step workflow: an agent run with multiple tool calls, a pipeline with sequential stages, or any process where the relationship between steps matters.IndependenceEach CER inside a Project Bundle retains its own certificateHash. You can verify any individual step by its certificateHash without needing the full Project Bundle. The projectHash provides an additional guarantee that the entire workflow is intact.See Certified Execution Records and Project Bundles for full details on each artifact type. --- # Signed Receipts URL: https://docs.nexart.io/docs/concepts/signed-receipts Signed ReceiptsThe canonical trust artifact returned by a node after it certifies a CER.What is a Signed Receipt?A signed receipt is the attestation proof returned by a NexArt node after it certifies a CER bundle. It is the canonical trust artifact in the NexArt protocol.The receipt binds three things together:The CER's certificateHashThe node's identityA timestampThe Ed25519 signature proves the node witnessed the record at that point in time. The node does not store or own the execution data.Canonical LocationIn a certified CER bundle, attestation data lives under meta.attestation:meta.attestation.receipt - the canonical payload that was signedmeta.attestation.signature - raw Ed25519 signaturemeta.attestation.kid - the signing key identifierThe API response from POST /v1/cer/ai/certify duplicates the receipt and signature at the top level for convenience, but the CER bundle is the canonical source.Trust HierarchyNot all CERs have the same level of attestation. Signed receipts represent the strongest trust level:Signed receipt - full node attestation. The entire CER bundle is witnessed and signed. This is the canonical trust model and the default when you use POST /v1/cer/ai/certify.Hash-only timestamp - only the certificateHash is signed. The node attests the hash exists at a point in time but does not witness the full snapshot. Used when full attestation is not possible.Legacy - older records that may lack attestation data entirely. Verification coverage is limited.For most integrations, signed receipts are what you want. They are the default output of the certify endpoint.Receipt StructureThe receipt object is the canonical payload that gets signed. Verification is always performed against this payload.Attestation Data (meta.attestation)// Inside the CER bundle at meta.attestation: { "receipt": { "certificateHash": "sha256:9e8d7c6b5a4f...", "timestamp": "2026-03-06T12:00:00.000Z", "nodeId": "nexart-node-primary", "kid": "key_01HXYZ..." }, "signature": "", "kid": "key_01HXYZ..." }Field Referencereceipt - the canonical payload signed by the node.certificateHash - SHA-256 hash of the CER bundle being attested.timestamp - attestation time generated by the node (ISO 8601).nodeId - identifies which node produced the receipt.kid - the signing key identifier. Matches a key published at the node's well-known endpoint.signature - raw Ed25519 signature over the canonical receipt payload.The API response also includes signatureB64Url (base64url encoding) for transport convenience.Verification URLsWhen you certify a record via the API, the response includes a verificationUrl. This URL points to the public verifier where anyone can independently check the record:Verification URL Formats// By execution ID https://verify.nexart.io/e/exec_abc123 // By certificate hash https://verify.nexart.io/c/sha256%3A7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069The verification URL is safe to share. The public verifier shows only a redacted, public-safe representation of the record.Key DiscoveryNodes publish their public keys at a well-known endpoint. The kid in the receipt tells you which key to use for verification.Node Key DiscoveryGET node.nexart.io/.well-known/nexart-node.json { "nodeId": "nexart-node-primary", "activeKid": "key_01HXYZ...", "keys": [ { "kid": "key_01HXYZ...", "algorithm": "Ed25519", "publicKey": "MCowBQYDK2VwAyEA..." } ] }Canonical Signing PayloadThe signed payload is exactly the receipt object. The node signs the canonical JSON representation of this payload using Ed25519. The resulting signature is stored at meta.attestation.signature.Verification must be performed against this exact payload. The canonical payload consists of the following fields only:certificateHashtimestampnodeIdkidCanonical JSON serialization must be deterministic: the payload is encoded as UTF-8 with stable lexicographic key ordering. This ensures that independent verifiers produce identical byte sequences and therefore identical verification results. No additional fields may be included in the signing payload.Receipt ImmutabilityA signed receipt is immutable. If any field in the receipt payload is modified after signing, the Ed25519 signature becomes invalid and the attestation cannot be verified.The receipt binds together:The CER's certificateHashThe node identity (nodeId)The attestation timestampThe signing key identifier (kid)If the underlying CER changes, a new CER bundle and a new signed receipt must be generated. There is no mechanism to re-sign or amend an existing receipt.This immutability is a protocol guarantee. Any mutation to a signed receipt renders the attestation unverifiable.Verification RulesA valid signed receipt must satisfy all of the following conditions:The receipt's certificateHash matches the certificateHash of the CER bundle being verified.The Ed25519 signature is valid for the canonical receipt payload.The receipt's kid resolves to a public key published by the node at /.well-known/nexart-node.json.The nodeId in the node metadata document matches the nodeId in the receipt, confirming that the signing key was published by the declared node.If any condition fails, the receipt is invalid and the attestation cannot be trusted. These rules apply uniformly to all compliant verification implementations.Verifying a ReceiptRetrieve the node's public keys from node.nexart.io/.well-known/nexart-node.jsonSelect the key matching the receipt's kidVerify the Ed25519 signature over the canonical receipt payloadConfirm the receipt's certificateHash matches the CER bundleThis process requires no API access to NexArt. You only need the CER bundle and the node's published public key.You can also verify through the public verifier at verify.nexart.io.Protocol Version BindingReceipts are bound to the CER protocol version used by the bundle they attest. The receipt proves that the node witnessed the record according to the protocol rules applicable at that time.Verification tools must interpret the receipt according to the CER Protocol rules applicable to the attested bundle. A receipt signed under an earlier protocol version remains valid when verified against the rules of that version.Future protocol revisions may extend receipt structures while preserving backward verification compatibility. Historical receipts must remain independently verifiable under their original protocol semantics.ScopeThe current NexArt trust model is centered on a canonical attestation node. The receipt protocol is designed so that independent node implementations can verify and interoperate against the same receipt structure in the future, but this page describes the current canonical trust model only. --- # Hash-Only Timestamping URL: https://docs.nexart.io/docs/concepts/hash-timestamping Hash-Only TimestampingA receipt mode that signs only the certificateHash, proving existence at a specific time.What is Hash-Only Timestamping?Hash-only timestamping signs the certificateHash of a CER. The node does not attest the snapshot contents. The receipt proves that the hash existed at a specific time. It does not prove what the hash represents or that the underlying execution data is complete.This mode is distinct from full signed receipts and from redacted reseals. It provides the narrowest form of attestation in NexArt.How It WorksA CER bundle is created with bundleType: "hash-only-timestamp"The certificateHash is present in the bundleThe snapshot may be null, missing, or incompleteThe node signs a receipt binding the hash and timestamp. It does not recompute or verify snapshot contents.ExampleHash-Only Timestamp CER{ "bundleType": "hash-only-timestamp", "version": "1.0", "createdAt": "2026-03-06T12:00:00.000Z", "snapshot": null, "certificateHash": "sha256:9e8d7c6b5a4f..." }When Is It Used?Hash-only timestamping is not a common default. It applies in specific scenarios:Legacy records. Records where full execution snapshots were never captured.Migration. Systems migrating to NexArt that only have hash references from a prior system.Proof-of-existence. Workflows where the goal is to prove a hash existed at a specific time, without attesting the underlying content.VerificationHash-only timestamp records verify as VERIFIED when all applicable checks pass. Per the CER Protocol:Bundle Integrity - PASS. The bundle structure and certificateHash are consistent.Node Signature - PASS. The receipt signature is valid against the node's public key.Receipt Consistency - PASS. The receipt references the correct certificateHash.The attestation scope is narrower than a full signed receipt (snapshot contents are not attested), but the verification status is VERIFIED because all applicable checks pass.Compared to Full Signed ReceiptsA full signed receipt (bundleType: "signed-receipt") attests the entire CER bundle, including the snapshot. Hash-only timestamps attest only the hash reference.Both verify as VERIFIED when all applicable checks pass. The difference is in attestation scope, not verification status. --- # Verification Reports URL: https://docs.nexart.io/docs/concepts/verification-reports Verification ReportsThe result of validating a CER bundle and its attestation data.What is a Verification Report?A verification report summarizes the integrity and attestation state of a CER. It is the result of validating the bundle structure, the node signature, and the consistency between the receipt and the record.Verification may be performed locally using the CER bundle and the node's published keys, or through the public verifier at verify.nexart.io.Verification ChecksEach check returns PASS, FAIL, or SKIPPED:Bundle Integrity. Confirm that the CER bundle hashes are internally consistent and that the computed certificateHash matches the bundle contents.Node Signature. Verify that the receipt signature is valid using the attestation node's published Ed25519 public key, matched by the kid in the receipt. SKIPPED if no attestation is present.Receipt Consistency. Confirm that the receipt at meta.attestation.receipt references the same certificateHash as the CER bundle. SKIPPED if no attestation is present.Verification StatusesThe status field indicates the overall verification outcome, as defined by the CER Protocol:VERIFIED. All applicable verification checks pass.FAILED. One or more verification checks fail. This may indicate tampering, mismatched hashes, or an invalid signature.NOT_FOUND. The requested execution record was not located.Example ReportVerification Report (VERIFIED){ "status": "VERIFIED", "checks": { "bundleIntegrity": "PASS", "nodeSignature": "PASS", "receiptConsistency": "PASS" }, "reasonCodes": [], "certificateHash": "sha256:...", "bundleType": "cer.ai.execution.v1", "verifiedAt": "2026-03-06T12:05:00.000Z", "verifier": "nexart-verifier/1.0.0" }When Checks Are SKIPPEDIf a CER bundle has no attestation, the Node Signature and Receipt Consistency checks are SKIPPED. This is expected for unattested bundles created via POST /v1/cer/ai/create.Verification Report (No Attestation){ "status": "VERIFIED", "checks": { "bundleIntegrity": "PASS", "nodeSignature": "SKIPPED", "receiptConsistency": "SKIPPED" }, "reasonCodes": [], "certificateHash": "sha256:...", "bundleType": "cer.ai.execution.v1", "verifiedAt": "2026-03-06T12:05:00.000Z", "verifier": "nexart-verifier/1.0.0" }When You Get FAILEDA FAILED result means one or more checks did not pass. Common causes:Bundle contents were modified after attestationSignature does not match the node's published keyReceipt references a different certificateHash than the bundleCorrupted or malformed bundle --- # Context Signals URL: https://docs.nexart.io/docs/concepts/context-signals Context SignalsOptional structured metadata recorded alongside an execution. May be hash-bound or supplemental.What are Context SignalsContext Signals are structured metadata recorded alongside an execution to capture external context. They let builders attach additional evidence such as policy check results, environment state, or authorization decisions to a Certified Execution Record.Why They ExistLogs are not verifiable. Traditional logging systems record events but provide no cryptographic proof that the logged data has not been modified.Governance systems lack structured evidence. Compliance workflows often depend on assertions without machine-readable evidence of what actually happened at execution time.Signals attach structured evidence to the record. They become part of the verifiable artifact (or are recorded alongside it) so reviewers can inspect what context was available when the execution ran.Key PropertiesOptional. Signals are not required for CER creation. A record without signals is fully valid.Protocol-agnostic. Any structured metadata can be recorded. The protocol does not prescribe specific signal types.Scope varies. A signal MAY be included in the certificateHash (hash-bound) or recorded as supplemental context (outside the hash scope). Which mode applies depends on the artifact type and how the CER was produced.Hash-bound signals are tamper-evident. Modifying them breaks bundleIntegrity.Supplemental signals do not block core verification. Their absence or modification does not cause core artifact verification to fail. The verifier may surface them as supplemental evidence.Hash-bound vs supplementalBoth modes are valid. A signal being outside the hash scope does NOT mean core artifact integrity has failed. It means that signal is recorded for context, not as part of the cryptographic commitment. See Verification Semantics for how this is reflected in verification reports.ExampleCreate a signal, collect it, and pass it into a certified execution:Creating and attaching signalsimport { createSignal, createSignalCollector, certifyDecision } from "@nexart/ai-execution"; const signal = createSignal({ type: "policy.check", source: "compliance-engine", payload: { policyId: "ret-30d", result: "pass" } }); const collector = createSignalCollector(); collector.add(signal); const result = await certifyDecision({ provider: "openai", model: "gpt-4o-mini", input: { messages: [{ role: "user", content: "Approve this request?" }] }, output: { decision: "approve", reason: "policy_passed" }, signals: collector.signals(), nodeUrl: "https://your-nexart-node.example", apiKey: process.env.NEXART_API_KEY }); console.log(result.certificateHash);CLI UsageThe NexArt CLI supports attaching signals from a JSON file when creating or certifying a CER:Attach signals via CLInpx @nexart/cli@0.7.0 ai create execution.json --signals-file signals.jsonExample signals.json:signals.json[ { "type": "policy.check", "source": "compliance-engine", "payload": { "policyId": "ret-30d", "result": "pass" } } ]VerificationHow signals affect verification depends on whether they are hash-bound or supplemental:Hash-bound signals are part of the data covered by the certificateHash. Any modification causes bundleIntegrity to FAIL.Supplemental signals are recorded alongside the artifact but outside the hash. Their absence or modification does NOT cause core verification to fail. They may be surfaced by the verifier as supplemental evidence.Refer to Verification Semantics for how signal scope is reported in verification results.ImportantNexArt records signals but does not interpret or enforce them. The protocol treats signals as opaque metadata. Any semantic meaning or enforcement logic is the responsibility of the consuming application.Next StepsAI Execution SDK: API reference for the signals parameterNexArt CLI: use --signals-file from the command lineVerification Semantics: how hash-bound vs supplemental signals are reportedCertified Execution Records: the core record that signals attach to --- # AI Execution SDK URL: https://docs.nexart.io/docs/sdk AI Execution SDKAPI reference for certifying AI executions, creating CER bundles, and working with CER packages.OverviewThe AI Execution SDK provides two endpoints for working with Certified Execution Records. Most builders should use the certify endpoint, which handles everything in a single request.Recommended for most integrationsUse POST /v1/cer/ai/certify to create a CER, get node attestation, and receive a verification URL in one call.API EndpointsPOST /v1/cer/ai/certifyCreates a Certified Execution Record, attests it through the node, and returns a signed receipt with a verification URL. This is the simplest way to get a verifiable proof of an AI execution.What it does:Creates a CER bundle with execution metadataComputes the certificateHash (SHA-256)Submits the bundle to the attestation nodeReturns the signed receipt, signature, and a public verification URLCertify RequestPOST /v1/cer/ai/certify Authorization: Bearer NEXART_API_KEY { "model": "gpt-4", "input": "Summarize this contract...", "output": "The contract states that...", "metadata": { "appId": "my-app", "projectId": "proj_abc123" } }Certify Response{ "verificationUrl": "https://verify.nexart.io/e/exec_abc123", "certificateHash": "sha256:9e8d7c6b5a4f3210...", "receipt": { "certificateHash": "sha256:9e8d7c6b5a4f3210...", "timestamp": "2026-03-06T12:00:01.000Z", "nodeId": "nexart-node-primary", "kid": "key_01HXYZ..." }, "signatureB64Url": "MEUCIQD3a8b1c4d5e6f..." }The API response includes receipt and signature fields for convenience. The canonical location for attestation data within the CER bundle is bundle.meta.attestation.POST /v1/cer/ai/createCreates a CER bundle without attestation. The bundle is returned with a certificateHash, but no receipt or verification URL is generated.When to use this:You want to generate the CER bundle for your own recordsYou plan to submit the bundle for attestation separatelyYou need the bundle structure but do not need node signing right nowCreate RequestPOST /v1/cer/ai/create Authorization: Bearer NEXART_API_KEY { "model": "gpt-4", "input": "Summarize this contract...", "output": "The contract states that...", "metadata": { "appId": "my-app", "projectId": "proj_abc123" } }Create Response{ "bundleType": "cer.ai.execution.v1", "version": "1.0", "createdAt": "2026-03-06T12:00:00.000Z", "snapshot": { "model": "gpt-4", "inputHash": "sha256:a1b2c3d4e5f67890...", "outputHash": "sha256:f6e5d4c3b2a10987...", "metadata": { "appId": "my-app", "projectId": "proj_abc123" } }, "certificateHash": "sha256:9e8d7c6b5a4f3210..." }Note: the create response returns the CER bundle directly. There is no receipt, signature, or verification URL. The meta.attestation field is absent. To get attestation, use /certify instead.AuthenticationBoth endpoints require an API key passed as a Bearer token:Authorization: Bearer NEXART_API_KEYCER Bundle ShapeA fully certified CER bundle follows this structure:CER Bundle (Certified){ "bundleType": "cer.ai.execution.v1", "version": "1.0", "createdAt": "2026-03-06T12:00:00.000Z", "snapshot": { "model": "gpt-4", "inputHash": "sha256:a1b2c3d4e5f67890...", "outputHash": "sha256:f6e5d4c3b2a10987...", "metadata": { "appId": "my-app", "projectId": "proj_abc123" } }, "certificateHash": "sha256:9e8d7c6b5a4f3210...", "meta": { "attestation": { "receipt": { "certificateHash": "sha256:9e8d7c6b5a4f3210...", "timestamp": "2026-03-06T12:00:01.000Z", "nodeId": "nexart-node-primary", "kid": "key_01HXYZ..." }, "signature": "", "kid": "key_01HXYZ..." } } }The snapshot contains execution metadata. Input and output content is hashed (SHA-256) rather than stored directly. Attestation data lives under meta.attestation.Key Termscreate vs certify. create produces a CER bundle. certify produces a CER bundle and gets it attested by the node in one step.Attestation vs verification. Attestation is when the node signs a record. Verification is when anyone checks that the signature and bundle are valid.Signed receipt vs hash-only timestamp. A signed receipt attests the full CER bundle. A hash-only timestamp attests only the certificateHash, without the snapshot contents.Context SignalsBoth endpoints accept an optional signals parameter - an array of structured metadata objects recorded alongside the execution.Request with Signals{ "model": "gpt-4", "input": "Summarize this contract...", "output": "The contract states that...", "signals": [ { "type": "policy.check", "source": "compliance-engine", "payload": { "policyId": "ret-30d", "result": "pass" } } ] }When signals are present, they are included in the certificateHash computation. This makes them part of the tamper-evidence chain - any modification to a signal after certification will cause verification to fail.Signals are backward-compatible. Requests without the signals field behave exactly as before. Existing CER bundles without signals remain valid and verifiable.VerificationAs of v0.15.0, the SDK provides both sync and async verification functions:ModeEnvironmentFunctionsSyncNode 18+verifyProjectBundle(), verifyCer()AsyncBrowser, Edge, Node 18+verifyProjectBundleAsync(), verifyCerAsync(), verifySnapshotAsync()You no longer need to write your own browser verifier. The async functions use the Web Crypto API internally.CERs produced by the certify endpoint can be verified across multiple layers:Bundle Integrity. The CER bundle hashes are internally consistent.Node Signature. The receipt signature is valid against the node's published Ed25519 key.Receipt Consistency. The receipt's certificateHash matches the CER bundle.Verification Envelope. When present, meta.verificationEnvelopeSignature validates the authoritative displayed verification surface.Verification statuses: VERIFIED, FAILED, or NOT_FOUND. Each check returns PASS, FAIL, or SKIPPED.Verify at verify.nexart.io or locally using the bundle and node keys from node.nexart.io/.well-known/nexart-node.json. For a full breakdown of verification layers, see AI CER Verification Layers. For browser examples, see Browser Verification.CER Package HelpersAs of @nexart/ai-execution@0.12.0, the SDK includes official helpers for working with the CER package format. A CER package is a transport/export wrapper around the inner cer bundle. The inner cer remains the actual execution artifact.APIisCerPackage(value) - type guard; returns true if the value conforms to the CER package shapecreateCerPackage(params) - creates a CER package from a bundle, receipt, signature, and optional verification artifactsgetCerFromPackage(pkg) - extracts the inner cer bundle from a packageexportCerPackage(pkg) - serializes a CER package to JSONimportCerPackage(json) - deserializes and validates a CER package from JSONverifyCerPackage(pkg) - verifies the inner CER bundle within a packageScope of verifyCerPackage()verifyCerPackage() verifies the inner CER bundle (hash integrity, node signature, receipt consistency). It does not fully verify all package-level trust layers such as the verification envelope. For full package-level verification, use the verification layers documented in the AI CER Verification Layers spec.Creating a CER PackageCreate and export a CER packageimport { createCerPackage, exportCerPackage } from "@nexart/ai-execution"; const pkg = createCerPackage({ cer: bundle, receipt, signature: signatureB64Url, attestation: { nodeId, kid, timestamp } }); const json = exportCerPackage(pkg); // json is a serialized CER package ready for storage or transportImporting and Verifying a CER PackageImport and verify a CER packageimport { importCerPackage, getCerFromPackage, verifyCerPackage } from "@nexart/ai-execution"; const pkg = importCerPackage(jsonString); const cer = getCerFromPackage(pkg); const result = await verifyCerPackage(pkg); // result contains inner CER verification status // Package-level trust layers (e.g. verification envelope) are not fully verified by this helperPackage helpers are additive only. They do not change CER hashing, attestation, or verification semantics. See the AI CER Package Format specification for the normative package structure.Agent KitFor agent workflows, @nexart/agent-kit provides wrapTool() and certifyDecision() as thin convenience wrappers over this SDK.ScopeThe SDK API surface is still evolving. This page documents the current endpoints and data model. Check back for updates as new capabilities are added. --- # NexArt CLI URL: https://docs.nexart.io/docs/cli NexArt CLICommand-line interface for creating, certifying, and verifying Certified Execution Records.Best ForLocal development and testingOffline verification of CER bundlesCI pipelines and automation scriptsEngineers who prefer command-line workflowsOverviewThe NexArt CLI supports three distinct operations for AI execution certification:Local creation: generate a CER bundle and certificate hash without contacting the networkNode certification: send an execution to the NexArt node for attestation and receive a signed receiptLocal verification: verify a CER bundle offline by checking hash integrity and signature validityThe CLI also supports deterministic rendering workflows for canvas-based executions.InstallationInstall / Helpnpx @nexart/cli@0.7.0 --helpEnvironment VariablesNEXART_API_KEY: API key for node certificationNEXART_RENDERER_ENDPOINT: URL of the canonical renderer service (for rendering workflows)Create a CER LocallyGenerate a Certified Execution Record from a JSON execution input. No network call required.Create a CERnpx @nexart/cli@0.7.0 ai create execution.jsonExample execution input:execution.json{ "executionId": "demo-001", "provider": "openai", "model": "gpt-4o-mini", "input": { "messages": [ { "role": "user", "content": "Should this automated report be approved?" } ] }, "output": { "decision": "approve", "reason": "policy_passed" } }Save the bundle to a file:Save CER Bundlenpx @nexart/cli@0.7.0 ai create execution.json --out cer.jsonThis builds the canonical CER bundle, computes the certificate hash, and outputs the record.Certify an ExecutionSend an execution to the NexArt node for attestation. Returns a signed receipt and a public verification URL.Certifynpx @nexart/cli@0.7.0 ai certify execution.jsonExample output:Certify ResultCER certified certificateHash: sha256:... verificationUrl: https://verify.nexart.io/e/demo-001Verify a CER Bundle or PackageAs of v0.7.0, nexart ai verify accepts both raw CER bundles and CER packages.Verify a raw CER bundleChecks hash integrity, signature validity, and receipt consistency.Verify Raw Bundlenpx @nexart/cli@0.7.0 ai verify cer.jsonRaw Bundle Result{ "status": "VERIFIED", "inputType": "bundle", "bundleIntegrity": "PASS", "nodeSignature": "PASS", "receiptConsistency": "PASS" }Verify a CER packageWhen the input file is a CER package, the CLI extracts and verifies the inner CER bundle. Package-level trust layers (e.g. verification envelope) are not fully verified by this command.Verify CER Packagenpx @nexart/cli@0.7.0 ai verify package.jsonPackage Result{ "status": "VERIFIED", "inputType": "package", "verifiedInnerCer": true, "packageTrustLayersVerified": false, "bundleIntegrity": "PASS", "nodeSignature": "PASS", "receiptConsistency": "PASS" }For working with CER packages programmatically, see the CER Package Helpers in the AI Execution SDK.Use in Automation or CIThe CLI can be used in CI pipelines to certify and verify executions as part of automated workflows:CI Example# Certify an execution and save the bundle npx @nexart/cli@0.7.0 ai certify execution.json --out cer.json # Verify the bundle in a later step npx @nexart/cli@0.7.0 ai verify cer.jsonContext SignalsAttach structured metadata to a CER using a signals file:Create with Signalsnpx @nexart/cli@0.7.0 ai create execution.json --signals-file signals.jsonCertify with Signalsnpx @nexart/cli@0.7.0 ai certify execution.json --signals-file signals.jsonSignals are included in the certificate hash. See Context Signals for the full specification.Deterministic RenderingThe CLI also supports deterministic rendering workflows for canvas-based executions:Run a Rendernpx @nexart/cli@0.7.0 run ./examples/sketch.js \ --seed 12345 \ --vars "50,50,50,0,0,0,0,0,0,0" \ --include-code \ --out out.pngVerify a Snapshotnpx @nexart/cli@0.7.0 verify out.snapshot.jsonNext StepsQuickstart: create your first CER in three stepsVerification: deep dive into verification semanticsExamples: copy-ready API requests and response shapesLangChain: certify AI chain and agent executionsn8n: certify workflow automation results --- # CodeMode SDK URL: https://docs.nexart.io/docs/codemode-sdk CodeMode SDKDeterministic generative execution environment for verifiable visual outputs.OverviewThe CodeMode SDK is used for deterministic generative execution inside NexArt.It allows developers to produce deterministic visual outputs that can later be certified and verified. CodeMode enforces canonical execution rules so the same code and seed always produce the same output.Typical uses:Generative artReproducible visual simulationsDeterministic creative systemsExecution ModelCodeMode uses a fixed canvas environment with deterministic randomness. The following rules apply:Canvas size is fixed at 1950 x 2400.createCanvas() must not be called.setup() is used instead of animation loops.random() must be used for deterministic randomness.ExampleCodeMode Examplefunction setup() { background(50); circle(975, 1200, 300); }Deterministic OutputIf the same code, seed, and parameters are used, the renderer produces the exact same output. This property allows verification of rendered artifacts.Any change to the inputs produces a different output, making it possible to detect modifications. --- # UI Renderer SDK URL: https://docs.nexart.io/docs/ui-renderer-sdk UI Renderer SDKDeterministic UI rendering for verifiable interface artifacts.OverviewThe UI Renderer SDK is used to produce deterministic user interface outputs.It allows UI components to render in a controlled environment so the resulting artifact can be reproduced and verified.This is useful for:AI-generated interfacesAutomated report generationVisual artifacts produced by agentsDeterministic RenderingThe renderer ensures that identical inputs produce identical UI output. Inputs may include:Component structureDataParametersSeedOutput ArtifactsOutputs can include:HTML snapshotsRendered imagesStructured artifactsThese outputs can be linked to Certified Execution Records for attestation and verification.VerificationBecause rendering is deterministic, a verifier can re-render the same component and confirm the output hash matches. This enables independent verification of UI artifacts without trusting the original rendering system. --- # Attestation Node URL: https://docs.nexart.io/docs/attestation-node Attestation NodeThe server-side component that signs CERs and issues receipts.Node Role in the ProtocolAttestation nodes act as independent witnesses for Certified Execution Records. A node verifies the integrity of a CER bundle and signs an attestation receipt confirming that the record existed at a specific point in time.Nodes do not own or control the execution data. Their role is limited to validating bundle integrity and producing a signed receipt.Where trust comes fromTrust comes from cryptographic integrity, independent verification, and optional attestation. Not from the node itself. The node is a witness, not a trust authority.Minimal Node RequirementsA NexArt attestation node must satisfy the following protocol contract:Verify the CER bundle structure.Recompute the certificateHash from the canonical bundle.Confirm the computed certificateHash matches the declared value.Generate an attestation timestamp.Produce a signed attestation receipt binding the certificateHash, timestamp, node identity, and signing key identifier.Publish signing keys through the node metadata endpoint.What Does the Node Do?The attestation node is an independent witness in the NexArt system. It does not define truth or control verification. When the API submits a CER bundle, the node:Validates the bundle structureRecords a precise timestampSigns the CER using Ed25519Returns a signed receipt (stored at meta.attestation in the CER bundle)Attestation ModesThe node supports two attestation modes:Full signed receipt. The node attests the complete CER including snapshot contents. The default for cer.ai.execution.v1 bundles.Hash-only timestamp. The node signs only the certificateHash. Used for legacy or incomplete records. Produces a hash-only-timestamp bundle.Node Metadata EndpointAll NexArt attestation nodes must publish a node metadata document at:/.well-known/nexart-node.jsonThis document exposes the node identity and signing keys required for independent receipt verification.The canonical node publishes at node.nexart.io.Required fields:nodeId: unique identifier for the attestation node.activeKid: the key identifier currently used for signing.keys[]: array of signing key entries. Each entry requires:kid: unique key identifier.algorithm: signing algorithm (Ed25519).publicKey: the public key material.status: key status (e.g. active, retired).Node Metadata DocumentGET node.nexart.io/.well-known/nexart-node.json { "nodeId": "nexart-node-primary", "activeKid": "key_01HXYZ...", "keys": [ { "kid": "key_01HXYZ...", "algorithm": "Ed25519", "publicKey": "MCowBQYDK2VwAyEA...", "status": "active" } ] }Signing DetailsAlgorithm. Ed25519.Key rotation. The node may rotate keys over time. Each receipt includes a kid that identifies which key was used. The activeKid field indicates the current primary signing key.Key discovery. All active and historical keys are published at the well-known endpoint so past receipts remain verifiable.Verifying Against the NodeTo independently verify a signed receipt:Fetch the node's keys from /.well-known/nexart-node.jsonFind the key matching the receipt's kidVerify the Ed25519 signature over the canonical receipt payloadOr use the public verifier at verify.nexart.io.Node CompatibilityA CER remains valid regardless of which compliant NexArt attestation node produced the receipt.Verification tools must rely only on:The CER bundleThe signed receiptThe node's published public key materialVerification must not depend on the continued availability of the original attestation node beyond its published verification material.Persistence and RegistrationBeyond signing, the canonical node persists registered artifacts. Persistence is what makes an artifact resolvable on verify.nexart.io.POST /api/stamp persists a single CER attestation.POST /v1/project-bundle/register persists a full Project Bundle.Common registration failure modes:AUTH_INVALID: missing or wrong API key.PERSISTENCE_FAILED: the bundle was signed but writing to the proof tables failed; the artifact will not resolve publicly. Retry with the same payload.HASH_MISMATCH: the recomputed hash does not match the declared hash; usually caused by undefined values breaking canonical JSON.A 200 response is not sufficient evidence of success. Always confirm against the public verifier as the authoritative success signal. See End-to-End Verification.Redacted Reseal BehaviorThe node MAY return a redacted reseal of the original CER for public verification. Reseal exists so that artifacts containing sensitive metadata can still be publicly verified after redaction, without exposing the private fields.A reseal is a NEW bundle with the following properties:bundleType: signed-redacted-resealNEW certificateHash: covers the resealed (redacted) content. This is what the public verifier validates.Provenance pointer: references the ORIGINAL certificateHash. Reference only; not validated.Fresh node signature: covers the resealed content under meta.attestation.The original and resealed hashes can legitimately coexist. They describe the same execution at different visibility levels. See Verification Semantics for the rules to apply when handling reseals.Self-Hosted NodesRoadmap. Self-hosted attestation nodes are not currently available. This feature is planned for a future release. --- # From Execution to Public Verification URL: https://docs.nexart.io/docs/end-to-end-verification From Execution to Public VerificationThe complete end-to-end flow. Local verification proves integrity. Node registration anchors trust. Public verification is an independent witness. They are not interchangeable.A bundle that verifies locally is not publicly verifiableA Project Bundle that passes verifyProjectBundle() locally but has NOT been registered on the attestation node will NOT resolve onverify.nexart.io/p/{projectHash}. Registration is a separate, REQUIRED step.The Full LifecycleEvery verifiable execution moves through the same seven stages. Skipping any stage between local verification and public verification breaks the trust chain.Lifecycle1. Execute AI step (your application) 2. Create CER certifyDecision(...) 3. (Optional) Attest CER on node POST /api/stamp 4. Build Project Bundle createProjectBundle({ steps: [...] }) 5. Verify locally verifyProjectBundle(bundle) 6. Register bundle on node REQUIRED POST /v1/project-bundle/register 7. Public verification verify.nexart.io/p/{projectHash}Trust chainExecution -> CER -> Bundle -> Local Verify -> Node Register -> Public Verify (integrity) (trust anchor) (independent witness)Three Levels of VerificationNexArt provides three distinct verification levels. They answer different questions and are NOT interchangeable.Level 1 - Local SDK Verification (integrity)Proves the artifact has not been modified since it was produced.verifyCer(bundle)verifyProjectBundle(bundle)verifyCerAsync / verifyProjectBundleAsync (browser)What it proves: Bundle integrity. The recomputedcertificateHash /projectHash matches the bundle.What it does NOT prove: That any third party has witnessed the artifact. Local-only artifacts cannot be looked up onverify.nexart.io.Level 2 - Node Certification / Registration (trust anchor)Submits the artifact to the attestation node, which signs a receipt and writes the artifact to its proof tables.POST /api/stamp - attest a single CERPOST /v1/project-bundle/register - register a Project BundleWhat it produces: An Ed25519-signed receipt anchored to the node's public key, plus a durable proof record on the node. This is what anchors trust.Level 3 - Public Verification (independent witness)Anyone can verify a node-registered artifact without your API key.https://verify.nexart.io/c/{certificateHash} - single CERhttps://verify.nexart.io/p/{projectHash} - Project BundleRequires: A node-registered artifact. If the artifact was only verified locally, the public verifier returnsNOT_FOUND.Project Bundle Registration (REQUIRED for public verify)This is the step most often missed. Local verification is not a substitute for registration.EndpointPOST https://node.nexart.io/v1/project-bundle/register Authorization: Bearer Content-Type: application/json ResponseA successful response includes:attestationId - node-assigned identifier for the registered bundleverificationEnvelope - canonical envelope covering the project-level receiptsignature - Ed25519 signature over the envelope by the node's signing keymetadata - node identity, key id, timestamp, protocol versionSuccess DefinitionRegistration is successful ONLY when ALL of the following are true:The node returns a 2xx response with the fields above.The bundle is written to the node's proof tables.https://verify.nexart.io/p/{projectHash} resolves and returns VERIFIED.A 200 response alone is not sufficient evidence of success. Always confirm against the public verifier.Minimal Correct FlowEnd-to-end (Node / TypeScript)import { certifyDecision, createProjectBundle, verifyProjectBundle, } from "@nexart/ai-execution"; // 1. Generate CERs for each step const cer1 = await certifyDecision({ /* step 1 */ }); const cer2 = await certifyDecision({ /* step 2 */ }); const cer3 = await certifyDecision({ /* step 3 */ }); // 2. Build the Project Bundle const bundle = createProjectBundle({ projectTitle: "Contract review pipeline", steps: [cer1, cer2, cer3], }); // 3. Local integrity check (does NOT make it publicly verifiable) const local = verifyProjectBundle(bundle); if (local.status !== "VERIFIED") { throw new Error("Local verification failed"); } // 4. REQUIRED: register the bundle on the attestation node. // Without this step, the bundle will NOT resolve on verify.nexart.io. const res = await fetch("https://node.nexart.io/v1/project-bundle/register", { method: "POST", headers: { Authorization: `Bearer ${process.env.NEXART_API_KEY}`, "Content-Type": "application/json", }, body: JSON.stringify(bundle), }); if (!res.ok) { throw new Error(`Bundle registration failed: ${res.status}`); } const { attestationId } = await res.json(); const projectHash = bundle.integrity.projectHash; // 5. Public verification URL (share this, not the bundle JSON) console.log(`https://verify.nexart.io/p/${encodeURIComponent(projectHash)}`);Common Failure CasesBundle verifies locally but not on verify.nexart.ioCause: The bundle was never registered on the node.verifyProjectBundle()only checks integrity locally; it does not contact the node.Fix: Call POST /v1/project-bundle/register with the full bundle JSON and a valid API key.Node returns 200 but bundle not found laterPossible causes:Wrong endpoint (e.g. calling /api/stamp with a project bundle instead of /v1/project-bundle/register).Wrong payload shape (sending a single CER instead of the full cer.project.bundle.v1 object).Wrong environment (staging API key against production node, or vice versa).Missing or malformed Authorization header.Bundle was written to a non-persistent code path (e.g. a dry-run flag, a test mode, or a proxy that swallows the body).Fix: Confirm the response includesattestationId andsignature, then resolveverify.nexart.io/p/{projectHash} as the authoritative success signal."Partially Verified" confusionThe verifier reports per-pillar results (Bundle Integrity, Node Signature, Receipt Consistency, Verification Envelope). A partial result usually means one of:The bundle has no node attestation, so node-dependent checks return SKIPPED.Context fields outside the certificateHash scope have been edited; they do not break integrity but are not covered by the hash.Different verifier versions evaluate the same artifact at different protocol versions; minor versions are forward-compatible, breaking changes require a new namespace.See Verification Reports for the full per-pillar semantics.Builder ChecklistBefore claiming an integration "works", confirm every item:CER verifies locally with verifyCer().Project Bundle verifies locally with verifyProjectBundle().Bundle registered on the node - response includes attestationId and signature.Bundle appears in node proof tables (lookup by projectHash succeeds).verify.nexart.io/p/{projectHash} resolves and returns VERIFIED.Trust Model in One SentenceSDK proves integrity. Node anchors trust. Verifier provides an independent check. See Trust Model for the full breakdown of who signs what and why each role is necessary.See alsoProject Bundle Registration - the registration step in detail.Verification Statuses & Errors - what every result and error means.Multi-step & Multi-agent Workflows - applying this to agents.Public Reseals & Redacted Verification - why public hashes can differ. --- # AI Execution CER URL: https://docs.nexart.io/docs/ai-execution AI Execution CERThe smallest unit of proof in NexArt: a tamper-evident record of one AI execution step.OverviewAn AI Execution CER is a single, tamper-evident record of one AI execution. Its bundle type is cer.ai.execution.v1. It is the smallest unit of proof in the NexArt protocol. Multi-step workflows compose AI Execution CERs into a Project Bundle.certificateHash is the canonical identityAlways look up an AI Execution CER by certificateHash. executionId is a convenience identifier returned by the certify API. It is NOT a unique artifact identifier and MUST NOT be used as the primary key for storage, deduplication, or public verification URLs.What an AI Execution CER ProvesIntegrity. The recorded execution metadata has not been modified since it was certified.Witness (when attested). An independent attestation node observed the artifact at a specific point in time.It does not prove that the model output was correct, that the execution was reproducible by re-calling the model, or that all related steps were recorded. NexArt proves what was recorded, not the quality of the result. See the Trust Model.What Is Included in certificateHashcertificateHash is SHA-256 over the canonical CER bundle. The following fields are covered:bundleType, version, createdAtsnapshot.modelsnapshot.inputHash, snapshot.outputHashsnapshot.metadata (when present)context.signals when included in the canonical bundle (see below)Any change to any covered field produces a different certificateHash.What Is NOT Included in certificateHashRaw input and output. Only the SHA-256 hashes are stored. The original prompt and completion text are never written into the CER.Optional context attached after hashing. context.signals MAY be transported outside the hash scope when supplied as supplemental metadata rather than as part of the canonical bundle. In that case, signals do not invalidate core integrity if absent or modified. See Verification Semantics.Node attestation. meta.attestation is added by the attestation node AFTER the hash is computed. The receipt itself binds the existing certificateHash; it does not change it.Verification envelope. meta.verificationEnvelope and its signature are added under meta and do not affect certificateHash.Determinism vs VerifiabilityThese two terms are often confused. They are not the same.Determinism means: given the same canonical bundle bytes, the same certificateHash is produced. This is a property of the hashing function and the canonical JSON serialization.Verifiability means: anyone can recompute certificateHash from the bundle and validate the node receipt against the node's published key, without trusting NexArt. This is a property of the protocol.NexArt does not replay the model. The protocol proves the record's integrity and witness, not the model's behavior.Minimal Correct FlowCreate and certify a single AI Execution CERimport { certifyDecision } from "@nexart/ai-execution"; const cer = await certifyDecision({ model: "gpt-4o-mini", input: { messages: [{ role: "user", content: "Approve invoice #42?" }] }, output: { decision: "approve", reason: "policy_passed" }, metadata: { appId: "ap-bot", projectId: "proj_demo" }, }); // canonical identifier - use this for storage, dedup, and public URLs const id = cer.certificateHash; // public verification URL const url = `https://verify.nexart.io/c/${encodeURIComponent(id)}`;Required vs Optional FieldsRequired: model, input, output. The SDK hashes input and output internally; only the hashes are stored.Optional: metadata (appId, projectId), signals (see Context Signals).Avoid passing undefined values inside metadata or signals. Undefined values can break canonical JSON serialization on some runtimes. Either omit the key entirely or use null.NextProject Bundles: group multiple CERs into one verifiable workflow.End-to-End Verification: from execution to public verification.Verification Semantics: reseal, signals scope, original vs public hash.AI Execution SDK: full SDK reference. --- # Verification Semantics URL: https://docs.nexart.io/docs/verification-semantics Verification SemanticsHow 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 TruthcertificateHash 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 certificateHashFor Project Bundles: projectHash plays the same role at the bundle levelexecutionId is not a unique artifact identifierexecutionId 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 HashThe 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-resealNEW certificateHash: covers the resealed (redacted) contentProvenance pointer: references the ORIGINAL certificateHash (reference only, not validated)Fresh node signature: covers the resealed contentReseal provenance shape (illustrative){ "bundleType": "signed-redacted-reseal", "certificateHash": "sha256:", "provenance": { "originalCertificateHash": "sha256:", "reason": "public-redaction", "resealedAt": "2026-04-19T10:12:00.000Z" }, "snapshot": { "...redacted snapshot...": true }, "meta": { "attestation": { "receipt": { "certificateHash": "sha256:" }, "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 ScopeContext 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 ClassesStatusMeaningActionVERIFIEDAll 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.FAILEDOne or more applicable checks FAIL.Do not trust. Inspect the per-pillar report.NOT_FOUNDArtifact not registered on the node.Register on the node, then re-resolve.See Verification Reports for the full per-pillar semantics.Common PitfallsUsing 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.NextEnd-to-End Verification: the full pipeline.How Verification Works: per-pillar checks.Attestation Node: reseal behavior at the node level. --- # Project Bundle Registration URL: https://docs.nexart.io/docs/project-bundle-registration Project Bundle RegistrationRegistration turns a locally verified bundle into a publicly verifiable artifact on verify.nexart.io.Local verification is not public verificationA Project Bundle that passes verifyProjectBundle() locally is not publicly verifiable until it is registered on the node. It will NOT resolve on verify.nexart.io.When to use registrationUse whenMultiple steps or agentsWorkflow-level public verificationExternal auditor must resolve without your SDKNode-signed receipt required as trust anchorSkip whenSingle execution (use Path A + /api/stamp)Independent decisions, not a workflowInternal-only audit trail, never resolved publiclyThe three verification layersThese are distinct and not interchangeable. A bundle can pass one and still need the next.Local SDK verification. verifyProjectBundle(bundle) recomputes hashes and checks step integrity against the bundle's own contents. It proves the artifact has not been modified since it was produced.Node registration. POST /v1/project-bundle/register persists the bundle in the node's proof tables and returns a signed receipt. This is the trust anchor for any third party.Public verification. verify.nexart.io/p/{projectHash} resolves the registered bundle and re-runs verification against the node's stored copy. Anyone with the projectHash can verify, without your code or your SDK.Minimal end-to-end flowimport { certifyDecision, createProjectBundle, verifyProjectBundle, registerProjectBundle, } from "@nexart/ai-execution"; // 1. Produce step CERs (each step is its own verifiable record). const stepA = await certifyDecision({ /* step A inputs */ }); const stepB = await certifyDecision({ /* step B inputs */ }); // 2. Group steps into a Project Bundle (computes projectHash). const bundle = await createProjectBundle({ projectId: "workflow-123", steps: [stepA.cer, stepB.cer], }); // 3. Local verification - integrity only. const local = await verifyProjectBundle(bundle); if (!local.ok) throw new Error("Bundle is not internally consistent"); // 4. Register on the node - REQUIRED for public verification. const reg = await registerProjectBundle(bundle, { apiKey: process.env.NEXART_API_KEY!, }); console.log("Public URL:", `https://verify.nexart.io/p/${reg.projectHash}`);Successful registration response{ "ok": true, "projectHash": "sha256:7d4a...e91", "registeredAt": "2026-04-21T12:00:00Z", "receipt": { "alg": "Ed25519", "kid": "node-key-2026-01", "sig": "base64..." } }What the registration helper doesPOSTs the canonical bundle JSON to /v1/project-bundle/register.Authenticates with your NEXART_API_KEY.Receives a node-signed receipt over the bundle's projectHash.Is idempotent: re-registering the same bundle returns the existing record.Failure modesFor a complete catalogue of node responses and what to do about them, see Verification Statuses & Errors. The most common ones at registration time:HASH_MISMATCH - the recomputed projectHash does not match the value in the submitted bundle. Usually caused by non-canonical JSON (extra whitespace, undefined values, key reordering).PERSISTENCE_FAILED - node accepted the request but could not write to its proof tables. Retry with backoff; the operation is idempotent on projectHash.AUTH_INVALID - missing or rejected API key.Builder checklist before claiming "it works"Each step CER verifies locallyProject Bundle verifies locallyBundle registered on the node (success response received)verify.nexart.io/p/{projectHash} resolvesRelatedEnd-to-End Verification FlowProject Bundles conceptVerification Statuses & ErrorsMulti-step & Multi-agent Workflows --- # Verification Statuses & Errors URL: https://docs.nexart.io/docs/verification-statuses-and-errors Verification Statuses & ErrorsEvery verification outcome and node error, what most likely caused it, and what to do next.Read this with Verification SemanticsThis page is the operational counterpart to Verification Semantics. Semantics defines what results mean. This page maps them to causes and fixes.✅ SuccessArtifact integrity is confirmed. No action required.OutcomeMeaningLikely causeWhat to doVERIFIEDAll applicable checks passed. Artifact integrity is confirmed.Normal success path.Treat the artifact as verified.⚠️ Valid but informationalCore integrity passes. Additional context is reported but does not invalidate verification.OutcomeMeaningLikely causeWhat to doVERIFIED (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_PROTECTEDContext 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.❌ FailuresDo not treat the artifact as verified. Investigate before trusting.CodeMeaningLikely causeWhat to doFAILEDOne 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_MISMATCHRecomputed 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_MISMATCHSame 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_FAILEDNode accepted the request but could not persist it.Transient backend issue.Retry with backoff. Registration is idempotent on projectHash / certificateHash.AUTH_INVALIDAPI 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.🔍 Lookup issuesThe artifact cannot be found at the address used. Usually a registration or identity problem.OutcomeMeaningLikely causeWhat to doNOT_FOUNDNo 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_FOUNDverifyCer / verifyProjectBundle passes locally but verify.nexart.io returns NOT_FOUND.The artifact was never registered on the node.For single CER: call /api/stamp. For Project Bundle: call /v1/project-bundle/register.Decision shortcutLocal 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.RelatedVerification SemanticsEnd-to-End Verification FlowProject Bundle RegistrationPublic Reseals & Redacted Verification --- # Multi-step & Multi-agent Workflows URL: https://docs.nexart.io/docs/multi-step-and-multi-agent-workflows Multi-step & Multi-agent WorkflowsWithout bundling, workflows produce logs. With bundling, they produce verifiable execution evidence.Single CER is still a first-class pathIf your execution is a single LLM call, a single tool call, or a single deterministic run, you do not need a Project Bundle. See Getting Started for Path A.When to use a Project BundleUse whenMulti-step workflows (Step 1 → Step 2 → Step 3)Multi-agent handoffs (Agent A → Agent B → Agent C)Tool-using agents where each call should be auditableBranching or parallel graphs that share a final stateSkip whenA single LLM call, tool call, or deterministic runIndependent decisions with no shared workflow identityInternal logs that never need workflow-level verificationThe mental modelStep - one meaningful unit of execution (one LLM call, one tool call, one agent turn).Step CER - a cer.ai.execution.v1 record for that step.Project Bundle - a cer.project.bundle.v1 artifact grouping the step CERs of one workflow.projectHash - canonical identity of the bundle.Node registration - what makes the bundle publicly verifiable.Linear multi-step exampleThree agents collaborate. Each agent's output becomes a step CER. The three CERs are grouped into one Project Bundle and registered on the node.Agent A ──▶ stepA CER (certificateHash: sha256:aaa...) Agent B ──▶ stepB CER (certificateHash: sha256:bbb...) Agent C ──▶ stepC CER (certificateHash: sha256:ccc...) └─▶ Project Bundle (projectHash: sha256:zzz...) │ ▼ POST /v1/project-bundle/register │ ▼ verify.nexart.io/p/{projectHash}import { certifyDecision, createProjectBundle, verifyProjectBundle, registerProjectBundle, } from "@nexart/ai-execution"; const stepA = await certifyDecision({ /* Agent A inputs */ }); const stepB = await certifyDecision({ /* Agent B inputs, sees Agent A output */ }); const stepC = await certifyDecision({ /* Agent C inputs, sees Agent B output */ }); const bundle = await createProjectBundle({ projectId: "agent-trio-2026-04-21", steps: [stepA.cer, stepB.cer, stepC.cer], }); const local = await verifyProjectBundle(bundle); if (!local.ok) throw new Error("Bundle integrity failed"); const { projectHash } = await registerProjectBundle(bundle, { apiKey: process.env.NEXART_API_KEY!, }); console.log(`https://verify.nexart.io/p/${projectHash}`);Tool-using agentsWhen an agent calls tools, each tool call MAY be a step CER. This gives auditors per-tool-call provenance without requiring you to certify the orchestration loop itself.Tool boundary in, tool boundary out: one step CER per call.Tool inputs and outputs are hashed into the step CER's inputHash and outputHash.The bundle records the order of calls; the projectHash binds the sequence.Non-linear handoffsBranching and parallel execution graphs are supported by the same model. Each branch's step CERs are included in the bundle. The projectHash binds the full set; the bundle's internal step ordering is canonical.Parallel branches: include each branch's step CERs in the bundle.Conditional branches: only the executed branch's step CERs need to be present.Retries: each retry MAY be its own step CER, preserving the audit trail.Agent KitFor linear workflows, @nexart/agent-kit wraps the per-step certifyDecision + createProjectBundle pattern behind startWorkflow / step / finish. It is the recommended entry point for linear pipelines. For non-linear graphs, use @nexart/ai-execution directly.Common pitfallsTreating one workflow as one CER. Use one CER per step, then group.Skipping registration. Local verification does not make the bundle publicly verifiable.Looking up steps by executionId. Always use certificateHash.RelatedProject Bundles conceptProject Bundle RegistrationEnd-to-End Verification FlowAgent Kit --- # Public Reseals & Redacted Verification URL: https://docs.nexart.io/docs/public-reseals-and-redacted-verification Public Reseals & Redacted VerificationA reseal is a new public artifact, not the original record. It is independently signed and does not weaken the original's integrity.Reseal in one sentenceA reseal is a new, independently signed CER covering a redacted view of an original execution. It has its own certificateHash, its own node signature, and a provenance pointer back to the original. The original record remains valid for any holder.Why reseals existOriginal CERs often contain content the publisher cannot expose publicly: raw prompts, customer data, internal tool calls. The public verifier cannot show that content. Instead, it returns a redacted reseal: a new bundle that covers only what is safe to publish, signed by the node.This preserves three properties at once: the original record stays intact and locally verifiable, the public artifact is independently verifiable, and sensitive content never appears in the public surface.Reseal artifact shape{ "bundleType": "signed-redacted-reseal", "certificateHash": "sha256:", "provenance": { "originalCertificateHash": "sha256:", "reason": "public-redaction" }, "receipt": { "alg": "Ed25519", "kid": "node-key-2026-01", "sig": "base64..." } }Requested hash vs returned public hashRequested hash: the hash you put in the URL or query (often the original certificateHash).Returned public hash: the certificateHash of the artifact the verifier actually displays. For redacted resources, this is the resealed hash, not the original.These two hashes MAY differ. The verifier surfaces both, with their roles labelled. A difference is expected behavior, not a failure.What is being verified in the public verifierThe public artifact's integrity: the resealed bundle's certificateHash, signature, and node receipt are cryptographically validated.The original certificateHash is preserved as a provenance pointer. The verifier does not re-verify the original bundle, because the original content is not present.Anyone who holds the original (unredacted) bundle can still verify it locally with verifyCer().What provenance preservesThe original certificateHash, so the reseal is traceable to its source.The reason for redaction (e.g. "public-redaction").A clear bundleType (signed-redacted-reseal) so verifiers do not confuse it with an original.Supplemental signalsA reseal MAY carry supplemental context.signals that are not bound by the new certificateHash. This is reported as VERIFIED (supplemental) and is not a failure. See Verification Semantics.What this is NOTNot a failure of the original artifact. The original is still valid for any holder.Not a hash collision or re-signing of the original. It is a new artifact.Not a way to alter execution history. Reseals can only redact, not modify.RelatedVerification Semanticsverify.nexart.ioVerification Statuses & ErrorsAttestation Node --- # Verification URL: https://docs.nexart.io/docs/verification VerificationHow to verify any NexArt record, with or without API access.Local verification is not public verification.verifyCer() andverifyProjectBundle() prove integrity only. To make an artifact resolvable onverify.nexart.io, you MUST register it on the attestation node. See theEnd-to-End Verification Flow.How Verification WorksVerification confirms the integrity and authenticity of a Certified Execution Record or Project Bundle. The process is:An execution happens.A CER is created, binding execution metadata to a deterministic certificateHash.Optionally, the CER is attested by a node, which adds a signed receipt.Optionally, multiple CERs are collected into a Project Bundle with a projectHash.Verification can happen offline (using the SDK) or at verify.nexart.io.What Verification ProvesVerification answers up to four questions about a Certified Execution Record:Has the CER bundle been modified since it was created?Was the receipt signed by a valid NexArt attestation node?Does the receipt reference the correct certificateHash?Has the verification envelope been altered? (when present)If all applicable checks pass, the record is intact and its attestation is trustworthy. For a detailed breakdown of the three verification layers, see AI CER Verification Layers.How to Verify a RecordThere are three ways to verify a CER through the public verifier at verify.nexart.io. Prefer certificateHash for any persisted reference — it is the canonical identity of the artifact. executionId is convenience metadata only.1. By Certificate Hash (canonical)If you have the certificateHash, use the hash-based URL. The colon in the hash must be URL-encoded:Verify by Certificate Hashhttps://verify.nexart.io/c/sha256%3A7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d90692. By Execution ID (convenience only)executionId is a convenience identifier returned by the certify API. It MUST NOT be used as a primary key for storage or deduplication. Use it for ad-hoc lookup only:Verify by Execution IDhttps://verify.nexart.io/e/exec_abc1233. By Uploading a CER BundleYou can also verify a record by uploading or pasting the full CER JSON bundle at verify.nexart.io. The verifier will recompute the hash and check the signature locally.This is useful when you have the CER file but not the execution ID or verification URL.What Is Publicly Visible?The public verifier uses a redacted, public-safe representation of the record:Verification status, certificateHash, timestamp, and node identity are visible.Raw input and output content is never exposed. The record contains SHA-256 hashes of these fields, not the original text.Metadata fields (like appId) may be included or redacted depending on the record's export settings.Anyone can verify that a record is intact and properly signed without seeing the private data that produced it.What Gets Stored for Public Verification?When a record is certified:The attestation node returns a signed receipt containing the certificateHash, timestamp, node identity, and Ed25519 signature. This is stored at meta.attestation in the CER bundle.A redacted, public-safe version of the record is persisted for verification.Input and output content is hashed (SHA-256). The hashes appear in the record, but the original content is not stored by the node or verifier.You control which metadata fields are included when you create the record.Verification ChecksEach check returns PASS, FAIL, or SKIPPED:Bundle Integrity. Recompute the certificateHash from the bundle contents. If the hash differs, the bundle has been modified.Node Signature. Validate the Ed25519 signature using the public key published at node.nexart.io/.well-known/nexart-node.json, matched by the kid in the receipt. SKIPPED if no attestation is present.Receipt Consistency. Confirm the receipt at meta.attestation.receipt references the same certificateHash as the bundle and that the node identity matches. SKIPPED if no attestation is present.Verification Envelope. When present, validate meta.verificationEnvelopeSignature against meta.verificationEnvelope. This confirms the authoritative displayed verification surface has not been altered. SKIPPED if the bundle does not include a verification envelope.For a detailed breakdown of what each layer protects, see AI CER Verification Layers.Verification StatusesThe verification status reflects the overall outcome, as defined by the CER Protocol:Verification StatusesVERIFIED All applicable checks pass. The CER is intact and, if attested, has a valid signed receipt. FAILED One or more checks fail. The record may have been modified or the signature does not match. NOT_FOUND The requested execution record was not located.Reading Verification ResultsThe verifier reports four distinct outcome classes. They are not all failures:VERIFIED: all applicable checks pass.VERIFIED (supplemental): core integrity passes, but supplemental context (e.g. signals outside the hash scope) is present. This is NOT a failure; supplemental fields are simply not cryptographically bound.FAILED: one or more applicable checks fail.NOT_FOUND: the artifact was never registered on the node. See End-to-End Verification.For the precise semantics of each result class, reseal handling, and the canonical role of certificateHash vs executionId, see Verification Semantics.Expected Outcomes by Bundle Typecer.ai.execution.v1 (with attestation): all checks PASS → VERIFIEDcer.ai.execution.v1 (without attestation): bundleIntegrity PASS, attestation checks SKIPPED → VERIFIEDsigned-redacted-reseal: redacted reseal returned by the public verifier; validated against the NEW resealed certificateHash → VERIFIEDhash-only-timestamp: only certificateHash is attested → VERIFIEDlegacy: older format, limited coverage → VERIFIED or FAILED depending on dataProject Bundle VerificationFor multi-step workflows, verification covers the entire Project Bundle:projectHash integrity: recomputed from canonical content using sha256-canonical-jsonPer-step CER verification: each embedded CER's certificateHash is checked independentlyProject-level node receipt: validated if presentUse verifyProjectBundle() (Node) or verifyProjectBundleAsync() (browser) from the SDK, or verify at verify.nexart.io via /p/:projectHash.Independent Verification (No API Required)You can verify a CER without calling any NexArt API. No trust in NexArt infrastructure is required. All you need is the CER bundle (including meta.attestation) and access to the node's published keys:Recompute the certificateHash from the CER bundle (SHA-256)Compare it with the certificateHash in meta.attestation.receiptFetch the node's public key from node.nexart.io/.well-known/nexart-node.jsonFind the key matching the receipt's kidVerify the Ed25519 signature over the receipt payloadIf all steps pass, you can trust the attestation independently of NexArt infrastructure. No account, API key, or network call to NexArt is required beyond fetching the node's public key.For the full verification contract, see the CER Protocol specification. For SDK functions, see AI Execution SDK (sync and async modes). For browser-specific usage, see Browser Verification. --- # verify.nexart.io URL: https://docs.nexart.io/docs/verify-nexart verify.nexart.ioThe public verification portal for CERs and Project Bundles.Overviewverify.nexart.io is the public verification portal for NexArt records. It supports two verification flows: one for individual CERs and one for Project Bundles.Verification runs in the browserAll cryptographic checks execute locally in the browser using @nexart/ai-execution. The node provides data (bundles, receipts, public keys). Trust comes from the cryptographic verification itself, not from the node serving the data.Certificate Hash VerificationRoute: /c/:certificateHashVerifies a single Certified Execution Record by its certificateHash.Example URLhttps://verify.nexart.io/c/sha256%3A9e8d7c6b5a4f3210...Checks performed:Bundle integrity: recomputes the certificateHash and confirms it matchesNode signature: validates the Ed25519 signature against the node's published key (if attestation is present)Receipt consistency: confirms the receipt references the correct certificateHashVerification envelope: validates the envelope signature (when present)Project Bundle VerificationRoute: /p/:projectHashVerifies an entire Project Bundle by its projectHash.Example URLhttps://verify.nexart.io/p/sha256%3Aab12cd34ef56...Checks performed:Project hash integrity: recomputes the projectHash from all stepsPer-step CER verification: each embedded CER is verified individuallyStep registry consistency: confirms step ordering and structure are intactProject-level node receipt: validates the project-level attestation (if present)Also SupportedBy execution ID: /e/:executionId for records created through the certify APIBy bundle upload: paste or drag-and-drop a CER JSON bundle for offline-style verificationWhat Is VisibleVerification status, hash, timestamp, and node identity are always shownRaw input and output content is never exposed. The record contains SHA-256 hashes only.Metadata fields may be included or redacted based on the record's export settingsTrust ModelThe verifier does not ask you to trust the node. It fetches the CER data and the node's public keys, then runs all checks locally in the browser. If the hashes match and the signatures are valid, the record is verified. The node is an independent witness, not a trust authority.See Attestation and Node Role for more on how the node fits into the trust model. --- # Browser Verification URL: https://docs.nexart.io/docs/browser-verification Browser VerificationVerify CERs and Project Bundles directly in the browser using the async SDK.OverviewAs of @nexart/ai-execution@0.15.0, the SDK provides async, browser-safe verification functions. You no longer need to write your own browser verifier.These functions use the Web Crypto API internally and have no Node.js dependencies.Verify a CERVerify a single CER in the browserimport { verifyCerAsync } from "@nexart/ai-execution"; const result = await verifyCerAsync(cerBundle); if (result.status === "VERIFIED") { console.log("CER is intact and verified"); } else { console.log("Verification failed:", result.checks); }Verify a Project BundleVerify a Project Bundle in the browserimport { verifyProjectBundleAsync } from "@nexart/ai-execution"; const result = await verifyProjectBundleAsync(projectBundle); if (result.status === "VERIFIED") { console.log("All steps verified, projectHash intact"); console.log("Steps:", result.steps.length); } else { console.log("Verification failed:", result.checks); }Verify a SnapshotVerify a snapshotimport { verifySnapshotAsync } from "@nexart/ai-execution"; const result = await verifySnapshotAsync(snapshot); // Verifies snapshot hash integrityEnvironment CompatibilityModeEnvironmentFunctionsSyncNode 18+verifyProjectBundle(), verifyCer()AsyncBrowser, Edge, Node 18+verifyProjectBundleAsync(), verifyCerAsync(), verifySnapshotAsync()See AI Execution SDK for the full API reference. --- # AI CER Verification Layers URL: https://docs.nexart.io/docs/ai-cer-verification-layers AI CER Verification LayersHow NexArt verifies AI Certified Execution Records across three independent trust layers.OverviewNexArt AI CER bundles support up to three independent verification layers. Each layer protects a distinct part of the record, and each can be validated independently.Bundle Integrity - protects execution evidence and contextSigned Attestation Receipt - protects attestation receipt fieldsVerification Envelope - protects the authoritative displayed verification surfaceNot all layers are present on every artifact. Historical records may include only the first two layers. Newer uploaded AI CER bundles may include all three.Layer 1: Bundle IntegrityThe certificateHash is computed as a SHA-256 digest over the canonical fields of the CER bundle:certificateHash computationcertificateHash = SHA-256({ bundleType, version, createdAt, snapshot, context // included when present })This layer guarantees that the execution evidence - including model identifier, input/output hashes, metadata, and any context signals - has not been modified since the record was created.What it protects: execution snapshot, context signals, bundle metadata.Layer 2: Signed Attestation ReceiptWhen a CER is attested by the attestation node, the node returns a signed receipt stored at meta.attestation in the bundle.Receipt Fieldsmeta.attestation.receipt - the receipt payload containing certificateHash, timestamp, nodeId, and kidmeta.attestation.signature - raw Ed25519 signature bytes over the deterministically serialized receipt payloadmeta.attestation.kid - key identifier; resolves via the node's published metadata at node.nexart.io/.well-known/nexart-node.jsonWhat it protects: attestation receipt fields (certificateHash binding, timestamp, node identity, signature validity).Layer 3: Verification EnvelopeUploaded and newer AI CER bundles may include a verification envelope that protects the authoritative displayed verification surface.Envelope FieldsIn the official package format, verification envelope fields are at the package level:verificationEnvelope - metadata describing the v2 verification envelopeverificationEnvelopeSignature - signature over the v2 signable payloadFor legacy/raw bundle artifacts, these fields may appear inside meta as a compatibility fallback.Package-Path Signable Payload (v2)For the official package format, verifiers reconstruct the v2 signable payload as:v2 Signable Payload Construction{ "attestation": package.verificationEnvelope.attestation, "bundle": package.cer, "envelopeType": package.verificationEnvelope.envelopeType }bundle comes from package.cer - the raw CER bundle, not the full packageattestation comes from package.verificationEnvelope.attestationThe full package object is NOT the signed payloadverificationEnvelope itself is NOT the signed payloadFor the package path, cer is used as-is - any mutation to cer after signing will cause this check to failWhat it protects: the authoritative displayed verification surface via the reconstructed signable payload.Field-Level ReferenceThe following fields may be present on an uploaded AI CER bundle:AI CER Bundle with All Three Verification Layers{ "bundleType": "cer.ai.execution.v1", "version": "1.0", "createdAt": "2026-03-17T10:00:00.000Z", "snapshot": { "model": "gpt-4", "inputHash": "sha256:a1b2c3...", "outputHash": "sha256:d4e5f6...", "metadata": { "appId": "my-app" } }, "context": { "signals": [ { "type": "policy.check", "source": "compliance-engine", "payload": { "result": "pass" } } ] }, "certificateHash": "sha256:9e8d7c...", "meta": { "attestation": { "receipt": { "certificateHash": "sha256:9e8d7c...", "timestamp": "2026-03-17T10:00:01.000Z", "nodeId": "nexart-node-primary", "kid": "key_01HXYZ..." }, "signature": "", "kid": "key_01HXYZ..." }, "verificationEnvelope": { "...signed verification surface..." }, "verificationEnvelopeSignature": "MEUCIQD..." } }Tamper BehaviorEach verification layer independently detects specific types of modification:ModificationLayer AffectedResultChange snapshot.modelBundle IntegrityFAILChange context.signalsBundle IntegrityFAILChange meta.attestation.receipt or signatureSigned Attestation ReceiptFAILChange meta.verificationEnvelope or its signatureVerification EnvelopeFAILBackward CompatibilityHistorical artifacts may not include meta.verificationEnvelope. These records are verified using Bundle Integrity and Signed Attestation Receipt only. They remain valid.Historical public artifacts may not hash-cover context. Older bundles that predate context signal support do not include context in the certificateHash computation.The verifier applies compatibility fallback for older artifacts. The verification logic detects the bundle version and applies the appropriate checks.Newer uploaded bundles with a verification envelope have stronger protection. The additional layer provides tamper detection over the displayed verification surface.Relationship to Other DocumentationFor the official package format and bundle immutability rules, see AI CER Package Format.For the CER data model and bundle structure, see the CER Protocol specification.For verification checks and statuses, see Verification.For the attestation node contract, see Attestation Node.For context signals, see Context Signals. --- # AI CER Package Format URL: https://docs.nexart.io/docs/ai-cer-package-format AI CER Package FormatNormative specification for the official NexArt AI CER package and bundle structure.Version: 1.0Status: NormativeThis document defines the official JSON structure for NexArt AI CER artifacts. It is normative: third-party builders, verifiers, and integrations MUST conform to this specification when producing, consuming, or transporting AI CER packages.1. Official Package FormatThe official exported or transported AI CER artifact MUST use the following top-level shape. This object is the package. It is the transport and export envelope. It is NOT the signed CER bundle.Official AI CER Package (top-level shape){ "cer": { /* exact node-signed CER bundle */ }, "receipt": { /* attestation receipt */ }, "signature": "base64url...", "attestation": { /* attestation summary */ }, "verificationEnvelope": { /* verification envelope metadata */ }, "verificationEnvelopeSignature": "base64url..." }The top-level package is the transport/export object. It is not itself the signed CER bundle. For the official AI CER package format, verifiers MUST extract cer as the bundle input. For Verification Envelope v2, verifiers MUST reconstruct the signable payload from verificationEnvelope.attestation, cer, and envelopeType, rather than from the full package object.2. CER Bundle FormatThe cer field MUST contain the canonical CER bundle object. For AI execution records (cer.ai.execution.v1), the bundle MUST use this top-level structure:Canonical AI CER Bundle{ "bundleType": "cer.ai.execution.v1", "certificateHash": "sha256:...", "createdAt": "2026-03-18T00:26:11.619Z", "version": "0.1", "snapshot": { ... }, "context": { ... }, "meta": { ... } }2a. Top-level fields inside cerFieldRequiredDescriptionbundleTypeREQUIREDNamespace identifier. For AI execution: cer.ai.execution.v1certificateHashREQUIREDDeterministic hash of the canonicalized bundle. Format: sha256:createdAtREQUIREDISO-8601 timestamp of bundle creation.versionREQUIREDSchema version string.snapshotREQUIREDExecution data: inputs, outputs, provider, model, hashes.contextOPTIONALStructured context signals. Included in certificateHash when present.metaOPTIONALNormal bundle metadata such as source and tags. See section 2c.JSON key order is not semantically important. Canonicalization handles deterministic ordering before hash computation.2b. cer Immutabilitycer MUST be the exact bundle object that was sent to and signed by the attestation node.Builders MUST NOT mutate cer after node signing.Builders MUST NOT add package-level attestation or verification fields into cer after signing.Any mutation to cer after signing will cause verification envelope failure, because the signable payload includes cer as-is.2c. meta inside cerThe cer.meta object is used for normal bundle metadata. Allowed contents include:source — origin identifier (e.g. application name)tags — array of classification tagsOther fields explicitly defined by the current schema versioncer.meta MUST NOT contain package-level verification artifacts. See section 3.cer.meta MUST NOT receive post-signing package-level attestation injection.3. Fields That MUST NOT Appear Inside cer.metaThe following fields are package-level verification artifacts. They MUST NOT be embedded inside cer.meta in the official format:Prohibited cer.meta fieldsmeta.verificationEnvelope meta.verificationEnvelopeSignature meta.verificationEnvelopeVerification meta.verificationEnvelopeTypeThese fields belong at the package level (top-level siblings of cer), not inside the CER bundle. Embedding them inside the bundle after signing mutates cer, which breaks verification envelope verification because the signable payload includes cer as-is.4. Package-Level Verification ArtifactsThese fields remain outside cer at the package level:receiptThe attestation receipt object returned by the NexArt attestation node. Contains the certificate hash, timestamp, node identifier, and key identifier.signatureBase64url-encoded node signature for the attestation receipt. Used for independent attestation receipt verification.attestationAttestation summary object containing attestation metadata such as node identifier, timestamp, and key identifier.verificationEnvelopeAn object containing metadata describing the v2 verification envelope. Fields include:FieldDescriptionalgorithmSignature algorithm (e.g. Ed25519)attestationAttestation metadata: attestationId, attestedAt, kid, nodeRuntimeHash, protocolVersioncanonicalizationCanonicalization method (e.g. jcs)envelopeTypeEnvelope version identifier (e.g. nexart.verification.envelope.v2)excludedFieldsArray of field paths excluded from the signed payloadkidKey identifier used for signingscopeSigning scope (e.g. full_bundle)signedFieldsIndicator of which fields are signed (e.g. * for all)verificationEnvelopeSignatureBase64url-encoded signature over the v2 signable payload reconstructed from the package. This signature covers the payload built from verificationEnvelope.attestation, cer, and verificationEnvelope.envelopeType.5. Verification Envelope Signable PayloadFor Verification Envelope v2, verifiers MUST reconstruct the signable payload as follows:v2 Signable Payload Construction{ "attestation": package.verificationEnvelope.attestation, "bundle": package.cer, "envelopeType": package.verificationEnvelope.envelopeType }Key rules for payload reconstruction:bundle comes from package.cerattestation comes from package.verificationEnvelope.attestationenvelopeType comes from package.verificationEnvelope.envelopeTypeThe cer object used in the signable payload is the raw CER bundle, not the full package wrapperFor the package path, cer is used as-isverificationEnvelope itself is NOT the signed payloadThe whole package object is NOT the signed payloadThe reconstructed payload is canonicalized (using the method specified in verificationEnvelope.canonicalization) and then verified against verificationEnvelopeSignature.6. Builder RulesBuilders MUST package AI CER artifacts using the top-level cer wrapper format.Builders MUST NOT mutate cer after node signing.Builders MUST NOT add package-level attestation or verification fields into cer after signing.Builders MUST keep verification artifacts at the package level.Builders MUST NOT merge verification envelope fields into cer.meta.Builders MUST verify against cer, not against the whole package.Builders SHOULD preserve the package structure unchanged when storing, exporting, or forwarding artifacts.7. Invalid Package FormatThe following is an invalid official package format:❌ Invalid: cer mutated after signing{ "cer": { "bundleType": "cer.ai.execution.v1", "certificateHash": "sha256:...", "createdAt": "2026-03-18T00:26:11.619Z", "version": "0.1", "snapshot": { "...": "..." }, "context": { "...": "..." }, "meta": { "source": "example-app", "tags": ["demo"], "attestation": { "nodeId": "...", "attestedAt": "..." }, "verificationEnvelope": { "...": "..." }, "verificationEnvelopeSignature": "base64url..." } }, "receipt": { "...": "..." }, "signature": "base64url..." }This format is invalid because:meta.attestation was injected into cer after the node signed the bundle. This changes cer.verificationEnvelope and verificationEnvelopeSignature were merged into cer.meta instead of remaining at the package level.cer no longer matches the exact bundle that was sent to and signed by the node.Verification Envelope v2 will fail because the signable payload uses cer as-is, and the mutated bundle does not match the original signed bundle.8. Valid Package FormatThe following is a complete, valid AI CER package:✅ Valid: official AI CER package{ "cer": { "bundleType": "cer.ai.execution.v1", "certificateHash": "sha256:a1b2c3d4e5f6...", "createdAt": "2026-03-18T00:26:11.619Z", "version": "0.1", "snapshot": { "type": "ai.execution.v1", "executionId": "exec-001", "provider": "openai", "model": "gpt-4o-mini", "inputHash": "sha256:...", "outputHash": "sha256:..." }, "context": { "signals": [ { "type": "policy.check", "payload": { "result": "pass" } } ] }, "meta": { "source": "audiot-demonstrator", "tags": ["demo"] } }, "receipt": { "certificateHash": "sha256:a1b2c3d4e5f6...", "timestamp": "2026-03-18T00:26:12.000Z", "nodeId": "nexart-node-primary", "kid": "k1" }, "signature": "base64url...", "attestation": { "nodeId": "nexart-node-primary", "attestedAt": "2026-03-18T00:26:12.000Z", "kid": "k1" }, "verificationEnvelope": { "algorithm": "Ed25519", "attestation": { "attestationId": "att-uuid-001", "attestedAt": "2026-03-18T00:26:12.000Z", "kid": "k1", "nodeRuntimeHash": "sha256:...", "protocolVersion": "1.2.0" }, "canonicalization": "jcs", "envelopeType": "nexart.verification.envelope.v2", "excludedFields": [ "meta.verificationEnvelopeSignature", "meta.verificationEnvelopeVerification" ], "kid": "k1", "scope": "full_bundle", "signedFields": "*" }, "verificationEnvelopeSignature": "base64url..." }9. Legacy CompatibilityLegacy raw bundle artifacts (without the package wrapper) remain supported by the NexArt verifier.Existing raw bundle verification behavior is unchanged.The package format defined in this document is the recommended format for new builder integrations.Historical artifacts that store verification envelope fields inside cer.meta are accepted by the verifier as a compatibility fallback when no package-level envelope is present.Historical public artifacts MAY not include context in the certificate hash computation. The verifier detects this and validates using the hash rules active at the time the artifact was created.10. Related DocumentationAI CER Verification Layers — the three-layer verification modelCER Protocol — protocol governance, verification semantics, and schema versioningVerification — how to verify CER artifactsAI Execution SDK — programmatic CER creation and verificationAttestation Node — node contract and key publicationCertified Execution Records — conceptual overview of CERs --- # Trust Model URL: https://docs.nexart.io/docs/trust-model Trust ModelHow NexArt establishes and verifies execution integrity.How Trust WorksNexArt establishes execution integrity through three mechanisms:Deterministic hashing. Every CER bundle produces a unique certificateHash (SHA-256). Any change to the record changes the hash.Node attestation. An attestation node signs the certificateHash using Ed25519, producing a receipt stored at meta.attestation in the CER bundle.Independent verification. Anyone can verify the record using the CER bundle and the node's published public keys. No API access is required.Certification FlowHere is what happens when you call POST /v1/cer/ai/certify:Certification Flow1. Your application sends execution data to the NexArt API 2. NexArt creates a CER bundle (bundleType: "cer.ai.execution.v1") and computes the certificateHash (SHA-256) 3. The attestation node signs the certificateHash → produces a receipt 4. The API returns: - certificateHash - receipt (with timestamp, nodeId, kid) - signatureB64Url - verificationUrl 5. Anyone can verify the record at the verificationUrl or independentlyIn the CER bundle, the receipt and signature are stored at meta.attestation. The API response duplicates them at the top level for convenience.Node AttestationThe attestation node is an independent witness. It does not define truth or control verification. When it signs a CER, it produces a receipt that proves:The node witnessed the CER bundle at a specific timeThe certificateHash was computed from the bundle at that timeThe node's identity is bound to the receiptNodes sign using Ed25519. Their public keys are published at a well-known endpoint so anyone can verify independently:Node Key DiscoveryGET node.nexart.io/.well-known/nexart-node.json { "nodeId": "nexart-node-primary", "activeKid": "key_01HXYZ...", "keys": [ { "kid": "key_01HXYZ...", "algorithm": "Ed25519", "publicKey": "MCowBQYDK2VwAyEA..." } ] }The node does not store or own the execution data. It witnesses the record and produces a cryptographic proof.Independent VerificationVerification can be performed without any NexArt API access. You need two things:The CER bundle (including meta.attestation)The node's public key (from the well-known endpoint)Steps:Recompute the certificateHash from the CER bundleCompare it with the certificateHash in meta.attestation.receiptFetch the node's public key matching the receipt's kidVerify the Ed25519 signature over the receipt payloadIf all steps pass, the attestation is trustworthy regardless of whether NexArt infrastructure is available.What Attestation Proves (and Does Not Prove)Attestation proves that:The CER existed at the attested timestampThe record has not been modified since attestationA specific node witnessed and signed the recordAttestation does not prove that:The execution itself was correct or accurateThe inputs or outputs were truthfulThe application behaved as intendedNexArt certifies that a record is intact and was witnessed. It does not evaluate the content of the execution.Trust BoundariesNexArt does not store raw prompts or outputs. CERs contain hashes, not payloads.NexArt does not act as a certificate authority for user identity.The integrating application controls what metadata is included in the CER.Public verification uses a redacted representation. Sensitive data is not exposed. --- # Integration Surfaces URL: https://docs.nexart.io/docs/integration-surfaces Integration SurfacesAll the ways you can connect to NexArt: API, verifier, CLI, n8n, and SDKs.OverviewNexArt can be accessed through several surfaces depending on your use case. This page lists them all in one place.Node APIThe primary integration point for most builders. Two endpoints are available:POST /v1/cer/ai/certify creates a CER (bundleType: "cer.ai.execution.v1"), attests it, and returns a signed receipt with a verification URL. Recommended for most integrations.POST /v1/cer/ai/create creates a CER bundle without attestation. Useful if you want the bundle for your own records or plan to attest it separately.Authentication uses an API key passed as a Bearer token (NEXART_API_KEY).See the API referencePublic Verifierverify.nexart.io is the public verification portal. Anyone can verify a record by:Execution ID: https://verify.nexart.io/e/exec_abc123Certificate hash: https://verify.nexart.io/c/sha256%3A7f83...The verifier uses a redacted, public-safe representation of the record. Sensitive input and output content is not exposed. Verification checks bundle integrity, node signature, and receipt consistency.Learn about verificationAttestation NodeThe attestation node signs CERs and issues receipts. Its public surfaces are:node.nexart.io shows the node's identity and status.node.nexart.io/.well-known/nexart-node.json publishes Ed25519 signing keys (using kid and activeKid fields) for independent verification.See the attestation node docsn8n IntegrationThe NexArt n8n community node allows you to certify AI execution results inside n8n workflows. The node calls POST /v1/cer/ai/certify and returns a verificationUrl that can be stored or shared.See the n8n integration docsNexArt CLIThe command-line interface for creating, certifying, and verifying CERs, plus deterministic rendering. As of v0.7.0, nexart ai verify accepts both raw CER bundles and CER packages.Install and run with:npx @nexart/cli --helpSee the CLI docsSDKsAI Execution SDK for CER creation and attestation workflows.CodeMode SDK for deterministic generative execution.UI Renderer SDK for deterministic UI rendering. --- # CER Audit Workflows URL: https://docs.nexart.io/docs/cer-audit-workflows CER Audit WorkflowsHow Certified Execution Records are packaged, exported, and consumed in audit, compliance, and review workflows.Certified Execution Records can be used as durable execution evidence in audit, compliance, and review workflows. This page defines how CER evidence should be packaged, exported, and reviewed without changing the underlying protocol artifacts.Audit workflows operate at the evidence-packaging and record-management layer, not the cryptographic protocol layer. CER bundles, certificate hashes, signed receipts, and verification semantics remain unchanged.Evidence PackAn evidence pack is a structured export of one or more CER records and their supporting verification materials. The purpose of an evidence pack is to allow independent review, offline verification, and durable audit preservation.An evidence pack may include:CER bundle(s)Signed receipt(s)Verification result(s)Node metadata snapshotExport manifestHuman-readable evidence summaryExport ManifestEvery evidence pack should include a machine-readable manifest describing what was exported, when, and by whom. The manifest enables automated processing and audit trail tracking.Recommended manifest structure:FieldDescriptionexportedAtISO 8601 timestamp of the exportexportedByIdentity or organization that triggered the exportrecordCountNumber of CER records includedexportScopeScope filter used (project, application, time range, etc.)verificationToolTool and version used for verification at export timerecords[]Array of record entriesEach record entry includes:FieldDescriptionexecutionIdUnique execution identifiercertificateHashDeterministic hash of the CER bundlebundleTypeType of bundle included (e.g. full)Example: Export Manifest{ "exportedAt": "2025-06-15T10:30:00Z", "exportedBy": "org:acme-corp", "recordCount": 3, "exportScope": "project:compliance-review-q2", "verificationTool": "nexart-verify@1.2.0", "records": [ { "executionId": "exec_abc123", "certificateHash": "sha256:9f86d08...", "bundleType": "full" }, { "executionId": "exec_def456", "certificateHash": "sha256:a3c1e7b...", "bundleType": "full" }, { "executionId": "exec_ghi789", "certificateHash": "sha256:e4d909c...", "bundleType": "full" } ] }Verification SnapshotEvidence packs should include a verification result captured at the time of export. This allows reviewers to see the verification outcome that was observed when the package was generated.Suggested fields:FieldDescriptionverifiedAtTimestamp of the verificationstatusOverall result (VERIFIED or FAILED)checksIndividual check results (bundleIntegrity, nodeSignature, receiptConsistency)reasonCodesCodes explaining any failuresverifierTool and version usedExample: Verification Snapshot{ "verifiedAt": "2025-06-15T10:30:12Z", "status": "VERIFIED", "checks": { "bundleIntegrity": "PASS", "nodeSignature": "PASS", "receiptConsistency": "PASS" }, "reasonCodes": [], "verifier": "nexart-verify@1.2.0" }Later reviewers may independently re-run verification using the exported artifacts and the verification rules defined in the CER Protocol.Node Metadata SnapshotWhen node attestation is present, evidence packs should include a snapshot of the node metadata used for verification at export time. This improves reproducibility of later receipt verification.Suggested contents:nodeId: identifier of the attestation nodeactiveKid: key identifier active at export timekeys[]: public key material used for receipt verificationprotocolVersion: protocol version if availableExample: Node Metadata Snapshot{ "nodeId": "nexart-node-01", "activeKid": "key-2025-06", "keys": [ { "kid": "key-2025-06", "algorithm": "Ed25519", "publicKey": "MCowBQYDK2VwAyEA..." } ], "protocolVersion": "1.0" }This is an audit packaging recommendation. It does not change the attestation node protocol itself.Export Scope and FiltersEvidence packs may be generated for a variety of scopes. Audits rarely export all records. Scoping ensures relevance and efficiency.Supported export scopes include:A single executionA projectAn applicationA time rangeA specific certificate hashAn execution surfaceMultiple scopes may be combined to produce focused evidence packs suitable for specific review workflows.Offline VerificationEvidence packs should support independent verification without requiring live access to NexArt infrastructure.An auditor should be able to verify a record using:The CER bundleThe signed receiptThe node public key materialThe verification rules defined in the CER ProtocolOnline services may improve convenience (e.g. key discovery, status lookups), but they are not required for evidence validation.Review-Oriented OutputsEvidence packs may include both machine-readable and human-readable materials to support different review workflows.Machine-Readablecer.json: CER bundlereceipt.json: signed attestation receiptverification-report.json: verification resultmanifest.json: export manifestHuman-Readableevidence-summary.html: formatted evidence overviewReviewer notesExported summary reportRelationship to CER Record ManagementAudit workflows rely on the lifecycle, archival, retention, and record-action semantics defined in CER Record Management.Archived records may still be exported into evidence packsHidden records may remain accessible to authorized audit workflowsDeleted records may still be verifiable if previously exportedThe audit workflow model builds on the governance and lifecycle controls defined at the record-management layer. It does not replace them. --- # Integrations URL: https://docs.nexart.io/docs/integrations IntegrationsConnect NexArt to your execution environment. Single-CER and Project Bundle paths are both supported.Two Integration ModelsSingle CER: certify one execution at a time. Works with every integration below. The most common starting point.Project Bundle: group multiple step CERs into one verifiable unit for multi-step or multi-agent workflows. Best paired with Agent Kit or the SDK createProjectBundle helper.Project Bundles are not required. Single-CER integrations are first-class.Choose the Best Integration PathUse the API for direct server-side certification of one execution at a timeUse the CLI for local development, CI pipelines, and offline verificationUse n8n for workflow automation with minimal custom codeUse LangChain when building AI chains, tools, or agents in codeUse Agent Kit to wrap tools as CERs or to assemble linear workflows into Project BundlesIntegrationBest forBundle supportTypical userAPIServer-side single-CER certificationSingle CERBackend developersCLILocal dev, CI, offline verificationSingle CERDevOps, CLI-first developersn8nWorkflow automationSingle CER per stepAutomation engineersLangChainAI chains, tools, agentsSingle CER or Project BundleAI/ML engineersAgent KitAgent tools and linear workflowsSingle CER or Project BundleAgent buildersAvailable Integrationsn8nCertify AI execution results inside n8n automation workflows.LangChainGenerate CERs from LangChain chains, tools, and agent workflows.Agent KitWrap tools as CERs, or build linear workflows that emit Project Bundles.Direct APICall POST /v1/cer/ai/certify directly from any environment.CLICreate and verify CERs from the command line.Public verificationSingle CERs verify publicly once attested by the node. Project Bundles verify publicly only after they are registered on the node. See End-to-End Verification. --- # Projects URL: https://docs.nexart.io/docs/dashboard/projects ProjectsThe primary organizational container in the NexArt dashboard.OverviewProjects are the primary organizational container in the NexArt dashboard. A project groups applications, Certified Execution Records (CERs), and project-level configuration together. Projects make it possible to organize attestations by product, service, or environment.Project StructureThe relationship between projects, apps, and CERs:ProjectApps (applications registered under the project)CER records (attestation records associated with each app)A CER may belong to a specific app within a project, or remain unassigned. Projects are used for organization, filtering, and configuration. They do not affect the cryptographic structure of CERs.Creating a ProjectOpen the NexArt DashboardNavigate to ProjectsClick New ProjectEnter a project nameSave the projectYou can optionally add a description. Additional configuration settings can be adjusted after creation.What a Project ContainsApps. Applications registered under the project. Apps help organize attestations by service or product component.CER Records. All attestation records associated with the project's apps appear in the project view.Project Configuration. Settings that affect how CERs are handled in the dashboard and ingestion pipeline.Project SettingsAuto-stampControls whether CERs created within the project are automatically stamped during ingestion.Enabled. CERs are automatically submitted for attestation.Disabled. Records are created but require manual stamping.See Auto-stamp for details.Retention PolicyDefines how long CER records are retained in the NexArt system. This setting controls storage lifecycle but does not affect the cryptographic validity of CERs.See Retention Policy for available options.Why Use ProjectsProjects help teams:Separate environments (production, staging, testing)Organize multiple applications under a shared contextManage retention policies per projectFilter CER records easily in the dashboard --- # Apps URL: https://docs.nexart.io/docs/dashboard/apps AppsOrganizational units within a project for grouping CER records by application or service.OverviewApps are organizational units within a Project. They represent the specific application, service, or workflow that produced an attestation.ProjectAppsCER recordsApps are used for organization and filtering. They do not change the cryptographic structure of CERs.Why Use AppsOrganization. Separate CER records by application or microservice.Filtering. Filter the dashboard view to show attestations for a specific app.Audit Context. App identifiers are included in CER metadata and audit exports, helping auditors understand which system produced the execution.Operational Visibility. Track which services generate attestations and monitor activity per app.Creating an AppOpen the NexArt DashboardNavigate to ProjectsSelect the project where the app should belongOpen the Apps tabClick Add AppEnter an app nameExamples of app names:customer-chatbotdocument-summarizerfraud-detectorsupport-assistantUsing Apps in AttestationsWhen creating a CER, the app identifier may be included in the snapshot metadata:App identifier in CER metadata{ "snapshot": { "metadata": { "appId": "customer-chatbot", "projectId": "proj_abc123" } } }This allows NexArt to associate the record with the correct application in the dashboard. The association is used for dashboard organization and exports.Apps in the DashboardIn the dashboard, apps let you:Filter CER records by appView attestations generated by a specific serviceExport records scoped to an app --- # Auto-stamp URL: https://docs.nexart.io/docs/dashboard/auto-stamp Auto-stampProject-level setting that controls automatic attestation during CER ingestion.OverviewAuto-stamp is a project-level ingestion setting. It controls whether CERs are automatically submitted for attestation when they are ingested into nexart.io.Auto-stamp is not a client-side or SDK-side interception feature. It runs during ingestion on the NexArt platform and affects only records associated with the configured project.How It WorksEnabled. CERs ingested under the project are automatically sent through the stamping flow during ingestion. Records receive a signed receipt without manual intervention.Disabled. CERs are still ingested and stored, but no automatic stamp is requested. Manual stamping remains available later.Auto-stamp behavior is evaluated during ingestion. It does not change the CER structure itself. It only affects whether an attestation receipt is added automatically.Configuring Auto-stampOpen the NexArt DashboardNavigate to ProjectsSelect a projectOpen the project settingsToggle Auto-stamp CERs during ingestionThe setting applies at the project level. All CERs ingested under that project follow the configured behavior.Manual Stamping Still WorksEven when auto-stamp is disabled, records are still created normally. Users can manually stamp a record later. Available stamping actions include:Full attestation, which produces a signed receiptRedacted reseal, where applicableHash-only timestamp, for legacy or incomplete recordsWhen to Use ItEnable when:You want newly ingested records to become verifiable immediatelyYou want consistent automatic attestation for a projectDisable when:You want to review records before attesting themYou want to control node usage more carefullyYou only want to stamp selected records manuallyRelationship to VerificationAuto-stamp affects whether a record receives a signed receipt automatically. Signed receipts allow all verification checks to return PASS, producing a VERIFIED status with full attestation coverage.If a record is not stamped, it can still verify as VERIFIED for bundle integrity, but the Node Signature and Receipt Consistency checks will be SKIPPED until a stamp is added. --- # Retention Policy URL: https://docs.nexart.io/docs/dashboard/retention Retention PolicyProject-level configuration for how long CER records are intended to be stored.OverviewRetention policy is a project-level configuration that defines how long Certified Execution Records (CERs) are intended to be stored within NexArt. The policy affects record storage lifecycle, not the cryptographic validity of CERs.Retention policies help organizations manage:Storage costsCompliance requirementsRecord lifecycle managementAvailable Options30 days. Short-term storage suitable for development environments or temporary workflows.90 days. Medium-term storage for operational monitoring and short audit windows.1 year. Typical operational retention period for many production systems.Forever. Records are retained indefinitely unless manually deleted or exported.These are project-level defaults applied to new records ingested under the project.Setting a Retention PolicyOpen the NexArt DashboardNavigate to ProjectsSelect a projectOpen Project SettingsChoose a Retention PolicyThe selected policy applies to new records ingested under that project.Current Implementation StatusRetention policy is currently configuration only. The setting is stored and displayed in the dashboard, but:Automatic deletion is not yet enforcedAutomatic archival is not yet enforcedRecords are retained regardless of the configured policy until enforcement is implementedEnforcement will be implemented in a future release.Record Ownership and ExportsEven with a configured retention policy:Users can export CER records at any timeExported records remain valid outside the NexArt platformExported records can still be independently verifiedAudit Exports are the recommended way to archive records before any future lifecycle enforcement takes effect.Future Lifecycle EnforcementFuture versions of NexArt will use the retention policy to automatically manage record lifecycle, including automated archival, deletion after the configured retention window, and enterprise archival tiers. No timelines are guaranteed. --- # Audit Exports URL: https://docs.nexart.io/docs/dashboard/audit-exports Audit ExportsExport verification and attestation information for audit review, analysis, and reporting.OverviewAudit Exports allow users to export verification and attestation information from the NexArt dashboard for audit review, external analysis, record portability, and operational reporting.Exports are generated from the dashboard and reflect the current verification state of records.Supported Export TypesSingle-record audit export (JSON). Export an audit summary for one CER from the record detail view or CER drawer.Project-level export (CSV). Export a CSV summary of records belonging to a project.Single-Record Audit Export (JSON)The single-record export is an audit summary. It is not the raw CER bundle. It is designed for review and reporting rather than raw protocol transport.To export: open a CER in the dashboard and click Export audit report.The export includes fields such as:Single-Record Audit Export{ "exportType": "audit-report", "exportedAt": "2026-03-06T12:10:00.000Z", "execution_id": "exec_8x7k2m4n9p", "certificate_hash": "sha256:9e8d7c6b5a4f...", "bundle_type": "signed-receipt", "surface": "nexart.io", "project": "my-project", "app": "customer-chatbot", "verification": { "status": "VERIFIED", "bundleIntegrity": "PASS", "nodeSignature": "PASS", "receiptConsistency": "PASS" }, "stamp_status": "stamped", "stamp_mode": "auto", "attestor_key_id": "key_01HXYZ...", "node_url": "node.nexart.io", "protocol_version": "1.0", "sdk_version": "0.4.2", "execution_timestamp": "2026-03-06T12:00:00.000Z", "auto_stamp_status": "enabled" }Single-Record Export Fieldsexecution_id is the unique identifier for the execution.certificate_hash is the SHA-256 hash of the CER bundle.bundle_type indicates the record type (signed-receipt, hash-only-timestamp, etc.).surface shows where the record was created.verification contains the verification outcome and individual check results.stamp_status / stamp_mode indicate whether the record is stamped and how.attestor_key_id / node_url provide attestation node information.protocol_version / sdk_version capture version metadata.execution_timestamp records when the execution occurred.auto_stamp_status reflects the project auto-stamp setting at time of ingestion.Project-Level Export (CSV)The project export produces a CSV summary of all records in a project. It is intended for operational review, spreadsheet analysis, audit scoping, and high-level reporting.To export: open a project in the dashboard and click Export CSV.Each row includes:created_atprojectappexecution_idbundle_typesurfacecertificate_hashverification_statusstamp_statusprotocol_versionsdk_versionThe CSV export does not replace the raw CER bundle download.Audit Export vs Raw CER DownloadAudit Export. Summary and reporting format. Easier for auditors and operational workflows. Includes verification state, project context, and attestation metadata.Raw CER Download. Protocol-level bundle. Used for independent cryptographic verification and record portability. Available separately through the CER download flow.Both are available from the dashboard. They serve different purposes. --- # Privacy & Data Handling URL: https://docs.nexart.io/docs/privacy Privacy & Data HandlingHow NexArt handles execution data, what gets stored, and who is responsible for personal data.Execution Data & PrivacyNexArt is execution integrity infrastructure. It stores cryptographic execution records, not raw application data.A Certified Execution Record (CER) typically contains:Certificate hash: a SHA-256 hash that uniquely identifies the recordExecution identifier: a reference ID for the executionInput and output hashes: SHA-256 hashes of the execution inputs and outputs, not the underlying payloadsProtocol and runtime metadata: model, version, and configuration dataNode attestation data: the Ed25519 signature, node identity, and attestor key IDTimestamps: when the record was created and attestedHashes are used to bind execution results to a certification record without storing the underlying data. This means NexArt can verify that an execution happened and was not tampered with, without needing access to what was actually said or generated.What NexArt Does NOT StoreRaw prompts or user inputsRaw outputs or completionsUser-identifiable content, unless explicitly submitted by the integrating applicationPublic Verification RecordsThe public verifier at verify.nexart.io displays redacted, public-safe representations of records. Sensitive execution payloads are not included.Fields visible in a public verification record:Certificate hashExecution IDProtocol versionNode attestation (signature, node identity)Runtime hashMetadata fields provided by the integrating applicationThe verifier exposes only the information required to independently confirm that a record is intact and properly signed. It does not reveal what was executed.Responsibility of Integrating ApplicationsApplications integrating NexArt are responsible for the data they submit to the certification API. NexArt does not inspect or filter the contents of metadata fields.Developers should avoid including personal identifiers in fields such as:executionIdmetadataprojectIdappIdUse internal identifiers instead of personal identifiers:Identifier examples// Preferred executionId: "tx_8347293" // Avoid executionId: "john-smith-payment"NexArt's RoleNexArt operates as an execution integrity infrastructure provider. Its role is limited to:Generating Certified Execution RecordsCryptographically binding execution metadata to a certificate hashProviding node attestations via Ed25519 signaturesEnabling independent verification of recordsNexArt does not process or store the underlying user data that produced an execution, unless that data is explicitly included by the integrating application in the certification request.Operational LogsNexArt may retain limited operational logs for service reliability and security monitoring. These logs may include request metadata such as timestamps, request paths, and status codes. Logs are retained for a limited period and do not include raw execution payloads. --- # Examples URL: https://docs.nexart.io/docs/examples ExamplesCopy-ready examples for API requests, responses, verification URLs, and data structures.Reference ImplementationsEnd-to-end examples showing how NexArt fits into real applications.LangChain exampleCreate and verify CERs in LangChain chains and agent workflows.Official example repo · GitHubn8n exampleTurn n8n workflow outcomes into Certified Execution Records.Official example repo · GitHubCommon Integration PatternsRequest/response shapes you'll use in most integrations.Certify an AI ExecutionSend execution data to the certify endpoint and receive a verifiable record.Certify RequestPOST /v1/cer/ai/certify Authorization: Bearer NEXART_API_KEY { "model": "gpt-4", "input": "Summarize this contract and highlight key obligations.", "output": "The contract requires monthly reporting and a 30-day notice period for termination.", "metadata": { "appId": "contract-assistant", "projectId": "proj_abc123" } }Certify ResponseThe response includes everything needed to share and verify the record.Certify Response{ "verificationUrl": "https://verify.nexart.io/c/sha256%3A9e8d7c6b5a4f3210...", "certificateHash": "sha256:9e8d7c6b5a4f3210...", "receipt": { "certificateHash": "sha256:9e8d7c6b5a4f3210...", "timestamp": "2026-03-06T12:00:01.000Z", "nodeId": "nexart-node-primary", "kid": "key_01HXYZ..." }, "signatureB64Url": "MEUCIQD3a8b1c4d5e6f..." }The API response includes receipt and signature at the top level for convenience. In the CER bundle, this data lives at meta.attestation.Verification URLRecords are verified publicly by certificateHash:Verification URL# By certificate hash (canonical) https://verify.nexart.io/c/sha256%3A9e8d7c6b5a4f3210...certificateHash is the canonical identity of a CER. executionId is a builder-supplied label and is not a unique artifact identifier. Do not build verification URLs around it.Share the /c/ URL with anyone. The public verifier shows the verification status without exposing raw inputs or outputs.Create-Only Response (No Attestation)If you use POST /v1/cer/ai/create, you get the CER bundle but no attestation, receipt, or verification URL.Create Response (No Attestation){ "bundleType": "cer.ai.execution.v1", "version": "1.0", "createdAt": "2026-03-06T12:00:00.000Z", "snapshot": { "model": "gpt-4", "inputHash": "sha256:a1b2c3d4e5f67890...", "outputHash": "sha256:f6e5d4c3b2a10987...", "metadata": { "appId": "contract-assistant", "projectId": "proj_abc123" } }, "certificateHash": "sha256:9e8d7c6b5a4f3210..." }Signed ReceiptThe signed receipt is produced by the attestation node and stored at meta.attestation in the CER bundle.Signed Receipt (meta.attestation)// meta.attestation: { "receipt": { "certificateHash": "sha256:9e8d7c6b5a4f3210...", "timestamp": "2026-03-06T12:00:01.000Z", "nodeId": "nexart-node-primary", "kid": "key_01HXYZ..." }, "signature": "", "kid": "key_01HXYZ..." }Advanced / Protocol ShapesLower-level protocol structures for advanced integrations and verification tooling.n8n FlowCertify AI results inside an n8n workflow using the NexArt community node.AI Step (e.g. OpenAI, Claude)↓NexArt Certify AI Execution↓verificationUrl + receiptCER Bundle (Certified)A fully certified CER bundle with attestation data:CER Bundle (Certified){ "bundleType": "cer.ai.execution.v1", "version": "1.0", "createdAt": "2026-03-06T12:00:00.000Z", "snapshot": { "model": "gpt-4", "inputHash": "sha256:a1b2c3d4e5f67890...", "outputHash": "sha256:f6e5d4c3b2a10987...", "metadata": { "appId": "customer-chatbot", "projectId": "proj_abc123" } }, "certificateHash": "sha256:9e8d7c6b5a4f3210...", "meta": { "attestation": { "receipt": { "certificateHash": "sha256:9e8d7c6b5a4f3210...", "timestamp": "2026-03-06T12:00:01.000Z", "nodeId": "nexart-node-primary", "kid": "key_01HXYZ..." }, "signature": "", "kid": "key_01HXYZ..." } } }Project Bundle (Multi-Step Workflow)A Project Bundle groups multiple step CERs into one verifiable unit. Use this when you have a multi-step or multi-agent workflow that should be verified as a whole. Single-CER use cases do not need a Project Bundle.Build a Project Bundle with @nexart/agent-kitimport { startWorkflow } from "@nexart/agent-kit"; const workflow = startWorkflow({ projectTitle: "Refund decision" }); const policy = await workflow.step("Check policy", async () => { return { eligible: true, policyId: "ret-30d" }; }); const decision = await workflow.step("Final decision", async () => { return { decision: "approve_refund", policy }; }); const bundle = workflow.finish(); // bundle.bundleType = "cer.project.bundle.v1" // bundle.integrity.projectHash = "sha256:..." // bundle.steps[i].certificateHash = "sha256:..." // Register the bundle on the node for public verification. // See /docs/end-to-end-verification.Local SDK verification of a Project Bundle works without registration. Public verification on verify.nexart.io requires the bundle to be registered on the node.Redacted ResealA redacted reseal has sensitive fields removed and is re-signed for safe sharing. The certificateHash is recomputed over the redacted contents.Redacted Reseal{ "bundleType": "signed-redacted-reseal", "version": "1.0", "createdAt": "2026-03-06T12:00:00.000Z", "snapshot": { "model": "gpt-4", "inputHash": "[REDACTED]", "outputHash": "sha256:f6e5d4c3b2a10987...", "metadata": { "appId": "customer-chatbot" } }, "certificateHash": "sha256:1a2b3c4d5e6f7890..." }Hash-Only TimestampAttests only the certificateHash. Snapshot is not included. Verifies as VERIFIED when all applicable checks pass.Hash-Only Timestamp{ "bundleType": "hash-only-timestamp", "version": "1.0", "createdAt": "2026-03-06T12:00:00.000Z", "snapshot": null, "certificateHash": "sha256:7f8e9d0c1b2a3456..." }Verification ReportSummarizes the result of validating a CER.Verification Report (VERIFIED){ "status": "VERIFIED", "checks": { "bundleIntegrity": "PASS", "nodeSignature": "PASS", "receiptConsistency": "PASS" }, "reasonCodes": [], "certificateHash": "sha256:...", "bundleType": "cer.ai.execution.v1", "verifiedAt": "2026-03-06T12:05:00.000Z", "verifier": "nexart-verifier/1.0.0" }Node Key DiscoveryNodes publish their public keys at a well-known endpoint for independent signature verification.Node Key DiscoveryGET node.nexart.io/.well-known/nexart-node.json { "nodeId": "nexart-node-primary", "activeKid": "key_01HXYZ...", "keys": [ { "kid": "key_01HXYZ...", "algorithm": "Ed25519", "publicKey": "MCowBQYDK2VwAyEA..." } ] } --- # n8n URL: https://docs.nexart.io/docs/integrations/n8n n8nCertify AI execution results inside n8n workflows using the NexArt certification API.Early integrationBest ForWorkflow automation with minimal custom codeNo-code / low-code certification pipelinesAutomated reports with verifiable AI outputsCustomer-facing workflows requiring audit trailsCompliance pipelines that need tamper-evident recordsOverviewNexArt integrates with n8n workflows via the standard HTTP Request node. When an AI step produces output, the HTTP Request node sends the execution data to the NexArt API and returns a verificationUrl linking to the public verification portal.This is the recommended path if your AI logic already runs inside n8n workflows.How It WorksAI Step (e.g. OpenAI, Claude)↓HTTP Request (POST /v1/cer/ai/certify)↓verificationUrl + receiptAn AI step produces output (text, image, or structured data).The HTTP Request node sends it to POST /v1/cer/ai/certify. NexArt creates a CER, signs it via the attestation node, and returns a verificationUrl.Store, share, or pass the verificationUrl to downstream steps.ConfigurationSet your API key as a Bearer token credential in the HTTP Request node:NEXART_API_KEY=your-api-keyQuick Demo1. Start n8nnpx n8nOpen the editor at http://localhost:5678.2. Create a workflowAdd a Manual Trigger followed by an HTTP Request node:MethodPOSTURLhttps://node.nexart.io/v1/cer/ai/certifyAuthenticationBearer AuthHeaderContent-Type: application/jsonRequest body:Request Body{ "executionId": "n8n-demo-001", "provider": "openai", "model": "gpt-4o-mini", "input": { "messages": [ { "role": "user", "content": "Should this automated report be approved?" } ] }, "output": { "decision": "approve", "reason": "policy_passed" }, "metadata": { "projectId": "demo", "appId": "n8n-demo" } }3. Execute and verifyRun the workflow. The API returns a CER with a verification link:Certify Response{ "verificationUrl": "https://verify.nexart.io/e/n8n-demo-001", "certificateHash": "sha256:...", "receipt": { ... }, "signatureB64Url": "..." }Attestation data lives at meta.attestation in the CER bundle.Open the verificationUrl to confirm the record at verify.nexart.io.Use CasesCertify AI-generated content in automated publishing pipelinesAttach verification links to customer-facing reportsCreate audit trails for AI decisions in compliance workflowsStore verifiable records alongside workflow outputsOfficial Example Repogithub.com/artnames/nexart-n8n - runnable integration example for n8n workflows.Next StepsVerification: understand how CER verification worksExamples: copy-ready API requests and response shapesLangChain: for teams moving from workflow automation into code --- # LangChain Integration URL: https://docs.nexart.io/docs/integrations/langchain LangChain IntegrationGenerate Certified Execution Records (CERs) from LangChain workflows.Best ForAI agents that make decisions requiring audit trailsLangChain chains and multi-step workflowsDecision systems (moderation, policy review, approvals)Application logic that needs verifiable execution recordsOverviewLangChain workflows can produce Certified Execution Records (CERs) using the NexArt AI Execution SDK. A CER is a cryptographically bound record of an AI execution, including inputs, outputs, and execution metadata. The record produces a deterministic certificate hash and can optionally be attested by a NexArt node.LangChain workflow↓createLangChainCer()↓CER bundle + certificate hash↓ (optional)NexArt node attestation↓verify.nexart.ioTwo Integration PathsThe SDK provides two helpers depending on whether you need node attestation:createLangChainCer(...) creates a CER locally. No network call. Returns a deterministic certificate hash you can verify independently.certifyLangChainRun(...) creates a CER and sends it to a NexArt node for attestation. Returns a signed receipt and a public verification URL.Installationnpm install @nexart/ai-executionThe LangChain integration is available as a subpath import:import { createLangChainCer } from "@nexart/ai-execution/langchain";Create a CER LocallyGenerate a CER from a LangChain run without contacting the node. This creates a Certified Execution Record locally and returns a deterministic certificate hash.Local CER Creationimport { createLangChainCer } from "@nexart/ai-execution"; const { bundle, certificateHash } = createLangChainCer({ provider: "openai", model: "gpt-4o-mini", input: { messages: [ { role: "user", content: "Should this customer refund request be escalated?" } ] }, output: { decision: "escalate", reason: "high_value_customer" } }); console.log(certificateHash);Certify with the NexArt NodeWhen a node URL is provided, the record is attested by the NexArt node and includes a signed receipt. This step is optional. Local CER creation is sufficient for many use cases.Node Attestationimport { certifyLangChainRun } from "@nexart/ai-execution"; const result = await certifyLangChainRun({ provider: "openai", model: "gpt-4o-mini", input: { messages: [ { role: "user", content: "Should this customer refund request be escalated?" } ] }, output: { decision: "escalate", reason: "high_value_customer" }, nodeUrl: "https://your-nexart-node.example", apiKey: process.env.NEXART_API_KEY }); console.log(result.verificationUrl);VerificationA CER produced by LangChain can be verified the same way as any other NexArt record. Open https://verify.nexart.io and verify using:Execution ID: look up by the execution identifierCertificate hash: paste the deterministic hashUploaded CER bundle: upload the full bundle for offline-first verificationUse CasesAI agent decisions that require audit trailsModeration pipelines with verifiable outputsWorkflow approvals backed by tamper-evident recordsAI-assisted automation with certificationOfficial Example Repogithub.com/artnames/nexart-langchain - runnable integration example for LangChain chains and agent workflows.Next StepsQuickstart: create your first CER in three stepsVerification: deep dive into verification semanticsExamples: copy-ready API requests and response shapes --- # Agent Kit URL: https://docs.nexart.io/docs/agent-kit Agent KitA thin convenience layer for producing verifiable execution records from agent tool calls and decisions.What It Is@nexart/agent-kit is a thin convenience layer for builders who want agent tool calls and final decisions to produce tamper-evident, verifiable execution records with minimal integration work.Use @nexart/agent-kit when you want agent steps to emit standard NexArt CERs without wiring the lower-level SDKs manually.It sits on top of two existing packages:@nexart/ai-execution for CER creation and attestation@nexart/signals for structured context signalsWhat it is not@nexart/agent-kit is not an agent framework. It does not provide orchestration, planning, memory, or multi-agent runtime capabilities. It only handles CER production for agent workflows.Installationnpm install @nexart/agent-kitCurrent version: 0.4.0If you also import @nexart/signals or @nexart/ai-execution directly:npm install @nexart/agent-kit @nexart/signals @nexart/ai-executionExportswrapTool()Use wrapTool() when you want an individual tool call to produce its own standard CER.wrapTool(opts) returns a callable. When invoked with arguments, it executes the run function and returns the tool result alongside a standard cer.ai.execution.v1 bundle. Signals and node attestation are optional.wrapTool()import { wrapTool } from "@nexart/agent-kit"; const lookupCustomer = wrapTool({ name: "lookup_customer", model: "gpt-4o", run: async (input) => { // your tool logic return { customerId: "cust_123", tier: "enterprise" }; }, // optional signals: collector.export().signals, attestOptions: { nodeUrl: "https://your-node.nexart.io", apiKey: process.env.NEXART_API_KEY } }); const { result, bundle, certificateHash } = await lookupCustomer({ email: "user@example.com" }); // result = { customerId: "cust_123", tier: "enterprise" } // bundle = standard cer.ai.execution.v1 bundle // certificateHash = "sha256:..."certifyDecision()Use certifyDecision() when you want to certify the final decision or outcome of an agent workflow.It is a thin wrapper over the AI Execution SDK. It supports optional signals and optional node attestation, and returns a standard cer.ai.execution.v1 bundle. It does not change hashing or verification semantics.certifyDecision()import { certifyDecision } from "@nexart/agent-kit"; const { bundle } = await certifyDecision({ model: "gpt-4o", input: { query: "Should we approve this refund?" }, output: { decision: "approve", reason: "within policy" }, // optional signals: collector.export().signals, attestOptions: { nodeUrl: "https://your-node.nexart.io", apiKey: process.env.NEXART_API_KEY } });When to Use WhichUse wrapTool() when you want one CER per tool invocation.Use certifyDecision() when you want one CER for the final decision or workflow outcome.Both can be used together in a single workflow. For example, wrap individual tools to certify each step, then certify the final decision separately.ExampleFull workflow exampleimport { wrapTool, certifyDecision } from "@nexart/agent-kit"; import { createSignalCollector } from "@nexart/signals"; const collector = createSignalCollector(); // 1. Define and invoke a wrapped tool const checkPolicy = wrapTool({ name: "check_policy", model: "gpt-4o", run: async (input) => ({ eligible: true, policyId: "ret-30d" }), signals: collector.export().signals }); const { result } = await checkPolicy({ orderId: "order_456" }); // 2. Add a signal based on the tool result collector.add({ type: "policy.check", source: "refund-agent", payload: { policyId: result.policyId, result: "pass" } }); // 3. Certify the final decision const { bundle } = await certifyDecision({ model: "gpt-4o", input: { orderId: "order_456", policyResult: result }, output: { decision: "approve_refund" }, signals: collector.export().signals, attestOptions: { nodeUrl: "https://your-node.nexart.io", apiKey: process.env.NEXART_API_KEY } });Workflow HelpersFor linear multi-step workflows that produce a Project Bundle, agent-kit provides workflow helpers:startWorkflow(opts) begins a new workflow and generates a workflowIdstep(name, fn) creates a CER per step. Records the step name as input and the function return value as output. Each step gets its own executionId. The workflowId links them. Implicit closure state is NOT recorded.finish() builds the Project Bundle synchronouslyLinear workflow with agent-kitimport { startWorkflow } from "@nexart/agent-kit"; const workflow = startWorkflow({ projectTitle: "Contract review" }); const clauses = await workflow.step("Extract clauses", async () => { return await llm.call("Extract key clauses..."); }); const risks = await workflow.step("Summarize risks", async () => { return await llm.call("Summarize risks from: " + clauses); }); const bundle = workflow.finish(); // bundle.integrity.projectHash is the verifiable hashDesigned for linear workflowsagent-kit v0.4.0 handles simple linear workflows. For complex DAGs or non-linear execution graphs, use the lower-level SDK helpers (certify + createProjectBundle).VerificationBundles produced by @nexart/agent-kit are standard cer.ai.execution.v1 artifacts and verify with existing NexArt verification tooling, including verifyCer() and verify.nexart.io. No special verifier is needed. Project Bundles built with finish() verify via verifyProjectBundle() or verifyProjectBundleAsync().Backward Compatibility@nexart/agent-kit does not change CER hashing, attestation, or verification semantics. It is additive only. Previously created CERs continue to verify identically.RelatedAI Execution SDK - the underlying CER creation and attestation APIProject Bundles - multi-step workflow verificationContext Signals - structured metadata recorded alongside executionsVerification - how CER verification works --- # Builder Guides URL: https://docs.nexart.io/docs/guides Builder GuidesQuick-start paths for common NexArt tasks.Verify a CERNode / serverimport { verifyCer } from "@nexart/ai-execution"; const result = verifyCer(cerBundle); if (result.status === "VERIFIED") { // CER is intact } // Or verify by certificateHash at: // https://verify.nexart.io/c/sha256%3A...Verify a Project BundleNode / serverimport { verifyProjectBundle } from "@nexart/ai-execution"; const result = verifyProjectBundle(projectBundle); // result.status: "VERIFIED" | "FAILED" // result.steps: per-step verification results // Or verify at: // https://verify.nexart.io/p/sha256%3A...Use Browser-Safe VerificationBrowser / Edgeimport { verifyCerAsync } from "@nexart/ai-execution"; const result = await verifyCerAsync(cerBundle); // Same result shape as verifyCer() // Uses Web Crypto API, no Node.js dependenciesSee Browser Verification for a full example with Project Bundles.Register a Project Bundle with the NodeRegister a Project BundlePOST /v1/project-bundle/register Authorization: Bearer NEXART_API_KEY Content-Type: application/json { "bundleType": "cer.project.v1", "metadata": { "projectId": "proj_abc123", "description": "Contract review pipeline" }, "steps": [ { "stepIndex": 0, "cer": { ... } }, { "stepIndex": 1, "parentRef": "sha256:...", "cer": { ... } } ] }The node computes the projectHash, signs a project-level receipt, and returns a verification URL at /p/:projectHash. --- # FAQ URL: https://docs.nexart.io/docs/faq FAQCommon 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 certifyOne automated decision (approve/deny, classify, route)One n8n step output you want to attestAny execution that stands alone as a verifiable artifactWhen should I use a Project Bundle?Multi-step agent workflows where step ordering and integrity matterMulti-agent systems where multiple actors contribute to a single outcomePipelines where the audit unit is the whole workflow, not the individual stepEach 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.See alsoProject Bundle Registration - how to make a bundle publicly verifiable.Verification Statuses & Errors - troubleshooting cheatsheet.Multi-step & Multi-agent Workflows - applying NexArt to agents.Public Reseals & Redacted Verification - why public hashes can differ.