{"slug": "how-to-verify-an-ai-execution-record-without-trusting-the-provider", "title": "How to Verify an AI Execution Record Without Trusting the Provider", "summary": "NexArt introduces Certified Execution Records (CERs) for AI systems, enabling independent verification of execution records without trusting the provider. The CER uses canonical JSON, integrity anchoring, and signed trust material to allow third parties to detect tampering and validate authenticity. A developer walkthrough demonstrates verifying a CER using only its bytes, public node metadata, and standard cryptographic primitives.", "body_md": "A developer-focused walkthrough of verifying a Certified Execution Record using only its bytes, public node metadata, and standard cryptographic primitives.\n\nA client challenges an AI decision six weeks later. They do not want a dashboard screenshot. They do not want a model card. They want something much harder: show me exactly what happened, and prove it.\n\nMost systems fail this test. Logs can be edited. Pipelines evolve. Re-running a model rarely reproduces the original result. You end up explaining what should have happened instead of proving what did.\n\nThis is where execution evidence starts to matter. In NexArt, that evidence takes the form of a Certified Execution Record, or CER. A CER is not just a log entry with a checksum. It is a structured execution artifact with a deterministic identity, integrity anchoring, and signed trust material that can be checked later. The core flow is simple: artifact, hash, trust surface, independent verification.\n\nThis article walks through what it actually means to verify a CER without trusting the original provider, using the current public NexArt model.\n\nThe core problem\n\nMost AI accountability systems are still closed loops. The application produces the decision. The application writes the logs. The provider stores the logs. The provider explains the logs later. That may be enough for debugging. It is much weaker when someone outside the system wants proof.\n\nIf a customer, auditor, partner, or regulator asks what happened in one specific execution, the real question is no longer \"do you have logs?\" It becomes:\n\nCan the record be checked later?\n\nCan tampering be detected?\n\nCan the trust material be validated separately?\n\nDoes verification depend on trusting the same provider that produced the execution?\n\nThat is the gap verifiable execution is meant to close.\n\nWhat real proof requires\n\nTo turn an execution into something stronger than an internal claim, you need three things.\n\nCanonical form. The record must have one deterministic representation for hashing and signing.\n\nIntegrity. If the record changes later, that change must be detectable.\n\nAuthenticity. You need a way to prove who attested to the record.\n\nWithout canonical form, hashing becomes unstable. Without integrity, later modification cannot be detected. Without authenticity, the record may still only be self-asserted.\n\nWhat a CER looks like\n\nA current AI execution CER uses the cer.ai.execution.v1 bundle type, with top-level fields such as bundleType, version, createdAt, snapshot, optional context and contextSummary, and certificateHash.\n\n```\n{\n  \"bundleType\": \"cer.ai.execution.v1\",\n  \"version\": \"0.1\",\n  \"createdAt\": \"2026-05-15T14:30:00Z\",\n  \"snapshot\": {\n    \"executionId\": \"exec_123\",\n    \"provider\": \"openai\",\n    \"model\": \"gpt-4o-mini\",\n    \"input\": {\n      \"messages\": [\n        { \"role\": \"user\", \"content\": \"Summarize this contract.\" }\n      ]\n    },\n    \"output\": { \"text\": \"This contract...\" },\n    \"parameters\": { \"temperature\": 0.2 }\n  },\n  \"certificateHash\": \"sha256:7b1f9a2c...\"\n}\n```\n\nThe most important field is certificateHash. But the key detail is this: the certificate hash is not computed over the entire bundle blindly. The current spec computes the hash from a strict projection over bundleType, version, createdAt, snapshot, and context / contextSummary when present. Fields like certificateHash, meta, and any declaration or verification material are outside the hash projection. That matters because it tells you exactly what the integrity anchor covers.\n\nStep 1: Canonicalize the correct payload\n\nYou cannot hash raw JSON as-is. Two logically identical objects can serialize to different byte sequences if key order changes. The protocol uses RFC 8785 JCS canonicalization for hashing and signing. Alternative serialization is not acceptable for protocol-correct verification.\n\n``` js\nfunction cerHashProjection(bundle) {\n  const projection = {\n    bundleType: bundle.bundleType,\n    version: bundle.version,\n    createdAt: bundle.createdAt,\n    snapshot: bundle.snapshot\n  };\n  if (bundle.context !== undefined) projection.context = bundle.context;\n  if (bundle.contextSummary !== undefined) projection.contextSummary = bundle.contextSummary;\n  return projection;\n}\n```\n\nThen canonicalize that projection using an RFC 8785 implementation. If you are using NexArt's own package surface, prefer helpers like toCanonicalJson in @nexart/ai-execution rather than ad hoc normalization.\n\nStep 2: Recompute the certificate hash\n\n``` python\nimport crypto from \"node:crypto\";\n\nfunction sha256Hex(data) {\n  return \"sha256:\" + crypto.createHash(\"sha256\").update(data).digest(\"hex\");\n}\n\nconst canonicalJson = toCanonicalJson(cerHashProjection(bundle));\nconst recomputed = sha256Hex(canonicalJson);\n\nif (recomputed !== bundle.certificateHash) {\n  throw new Error(\"Integrity check failed\");\n}\n```\n\nIf the recomputed hash matches, the integrity anchor passes. If it does not match, one of two things is true: the bundle content changed, or the hash is not the correct one for that artifact. Either way, verification fails.\n\nStep 3: Fetch the public trust material\n\nNexArt's public node metadata is exposed at the well-known node endpoint:\n\n```\ncurl -s https://node.nexart.io/.well-known/nexart-node.json > keys.json\n```\n\nThis is where public node identity and key material are published for verification flows. If you want to fetch a public CER from the node trust surface, the documented public lookup flow is:\n\n```\ncurl -s \"https://node.nexart.io/v1/cer/public?certificateHash=<HASH>\" > record.json\n```\n\nThat public endpoint requires no API key.\n\nStep 4: Verify the attestation receipt signature\n\nThe public response includes attestation material. The node trust model uses Ed25519 signing, attestation receipts, and verification-envelope semantics. At a practical level, the next step is: take the receipt payload, canonicalize it correctly, find the matching public key, and verify the signature.\n\n``` python\nimport crypto from \"node:crypto\";\n\nfunction verifyEd25519(publicKeyPem, messageCanonical, signatureBase64url) {\n  return crypto.verify(\n    null,\n    Buffer.from(messageCanonical),\n    publicKeyPem,\n    Buffer.from(signatureBase64url, \"base64url\")\n  );\n}\n\nconst receipt = bundle.receipt || bundle.meta?.attestation?.receipt;\nconst signature =\n  bundle.receiptSignature ||\n  bundle.signature ||\n  bundle.meta?.attestation?.signature;\n\nif (!receipt || !signature) throw new Error(\"Missing attestation material\");\n\nconst receiptCanonical = toCanonicalJson(receipt);\nconst ok = verifyEd25519(publicKeyPem, receiptCanonical, signature);\nif (!ok) throw new Error(\"Invalid attestation signature\");\n```\n\nThe important point is not the exact code shape. The important point is that authenticity is checked separately from integrity. The certificate hash tells you the artifact content matches. The signature tells you the attestation came from the expected node identity. Those are distinct checks.\n\nStep 5: Understand the trust boundary clearly\n\nA CER public lookup response is enough to verify the certificate hash, verify the receipt signature, and inspect the trust material around the record. The public response is redacted for privacy. Public verification is not the same as reconstructing every original private field. Full envelope-level verification of the exact original unredacted bundle requires access to that original artifact, not only the public projection.\n\nSo the honest way to say it is:\n\nPublic verification gives you a real trust surface.\n\nPrivacy-aware public lookup is not the same as publishing the full original private execution.\n\nThat is a feature, not a flaw.\n\nStep 6: Use the CLI when you want protocol-correct verification\n\nIf you want a simpler local verification path, the NexArt CLI already provides one:\n\n```\nnexart ai verify bundle.json\n```\n\nThat gives developers a protocol-aware way to validate a CER bundle locally without reimplementing the full flow from scratch. The verification path involves correct canonicalization, correct hash projection, correct trust-material handling, and correct signature checks. Those details matter.\n\nWhat this proves\n\nA successful verification proves a few specific things:\n\nThe protected CER payload has not been altered since sealing.\n\nThe attestation material was signed by the expected node identity.\n\nThe record you are checking matches the cryptographic identity claimed by its certificateHash.\n\nThat is already a meaningful standard. It is far stronger than a screenshot, a dashboard entry, a database row, an internal log line, or a provider simply asserting \"this is what happened.\"\n\nWhat this does not prove\n\nVerification of a CER does not automatically prove:\n\nThat every conceivable relevant fact was included.\n\nThat the underlying model was correct.\n\nThat a probabilistic model would reproduce the same output now.\n\nThat the record was written to a public ledger.\n\nThat an external timestamp authority was used.\n\nThat nothing outside the protected record influenced the broader business decision.\n\nThose are different layers. The system is about execution integrity and evidence, not universal truth claims. That discipline keeps the evidence model credible.\n\nWhy this matters\n\nIn most AI systems today, verification still means trusting the provider. Trust their logs. Trust their backend. Trust their screenshots. Trust their claims about what happened.\n\nA CER changes that. It gives you a record whose integrity can be checked, whose attestation can be validated, and whose trust material can be examined separately from the originating system's own assertions. That is the difference between \"our system says this happened\" and \"here is a record you can verify yourself.\"\n\nThat difference becomes much more important once AI systems are used in workflows that matter later: customer disputes, regulated reviews, procurement scrutiny, internal investigations, high-value automation, multi-step agent workflows.\n\nClosing\n\nA system you have to trust blindly is not really a verification system. It may be useful. It may even be well engineered. But it is still a closed loop.\n\nA Certified Execution Record is different. It turns execution into something portable, mathematically checkable, and less dependent on the provider's own say-so. That does not solve every accountability problem in AI. But it does solve a foundational one: can someone outside the system verify what happened without having to trust the system that produced it?\n\nThat is the standard serious AI systems will increasingly need to meet.", "url": "https://wpnews.pro/news/how-to-verify-an-ai-execution-record-without-trusting-the-provider", "canonical_source": "https://dev.to/arrotu/how-to-verify-an-ai-execution-record-without-trusting-the-provider-3334", "published_at": "2026-06-15 10:37:47+00:00", "updated_at": "2026-06-15 10:44:58.267127+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-safety", "ai-research", "developer-tools"], "entities": ["NexArt", "OpenAI", "GPT-4o-mini", "RFC 8785"], "alternates": {"html": "https://wpnews.pro/news/how-to-verify-an-ai-execution-record-without-trusting-the-provider", "markdown": "https://wpnews.pro/news/how-to-verify-an-ai-execution-record-without-trusting-the-provider.md", "text": "https://wpnews.pro/news/how-to-verify-an-ai-execution-record-without-trusting-the-provider.txt", "jsonld": "https://wpnews.pro/news/how-to-verify-an-ai-execution-record-without-trusting-the-provider.jsonld"}}