DEV Community: Jb

Demonstrable, Not Documented: What Regulators Are Actually Asking For, and What It Takes to Answer

Jb — Fri, 14 Aug 2026 10:02:33 +0000

For years, AI governance has been treated primarily as a documentation problem.

Write the policy.

Record the model owner.

Complete the risk assessment.

Document human oversight.

Keep the logs.

Show the auditor the dashboard.

All of those things matter.

But across regulation, standards, accountability regimes and litigation, a different expectation is becoming visible:

It is no longer enough to document what was supposed to happen. Organisations increasingly need to demonstrate what actually happened.

Those are not the same thing.

A policy can show that human oversight was required.

It cannot, by itself, show what a human actually saw during one specific decision, whether they intervened, what the AI produced before that intervention, or whether the record being reviewed six months later is the same record that existed when the decision was made.

A governance dashboard can show that a control exists.

It cannot necessarily demonstrate that the control operated during the execution now being challenged.

An internal log can show what a system recorded.

It does not automatically give somebody outside the organisation a reason to trust that the record has remained unchanged.

This distinction between documented compliance and demonstrable compliance is becoming increasingly important.

What makes it particularly interesting is that the pressure is coming from several directions at once.

Different regimes, similar direction

There is no global regulation saying that every AI execution must produce a cryptographically verifiable record.

That would be an overstatement.

The EU AI Act does not prescribe a particular cryptographic evidence architecture.

NIST does not require Certified Execution Records.

ISO/IEC 42001 does not tell organisations which hashing algorithm to use.

The UK's Senior Managers and Certification Regime does not require banks to cryptographically certify AI decisions.

US law does not impose one common AI evidence protocol.

These frameworks were created for different purposes.

But when you look at the practical questions they create for organisations, a pattern appears.

The language is different.

The legal mechanisms are different.

The sectors are different.

The underlying question keeps moving in the same direction:

Can you demonstrate what happened?

The EU AI Act: record the system, then make oversight real

Article 12 of the EU AI Act requires high-risk AI systems to technically allow for the automatic recording of events over the lifetime of the system.

The regulation explicitly connects those logging capabilities with traceability, post-market monitoring and monitoring the operation of high-risk systems.

That already moves the conversation beyond simply knowing which model an organisation deployed.

There must be a record of relevant events during operation.

Article 14 approaches the problem from another direction.

High-risk AI systems must be designed so that natural persons can effectively oversee them.

Depending on the context, those people must be able to understand relevant capabilities and limitations, monitor operation, detect anomalies, interpret outputs, avoid over-reliance on AI, disregard or override outputs, and intervene where necessary.

Article 14 does not say every human intervention needs a cryptographic certificate.

Article 12 does not prescribe one particular evidence format.

But put the two together and a practical question appears:

If you say meaningful human oversight existed, what evidence shows what the human was actually overseeing?

What did the system produce?

What information was available at that point?

Was the recommendation accepted?

Was it overridden?

What system or model version was involved?

What happened immediately before and after the decision?

And is the record being presented today the same record that existed then?

That is where the difference between documenting a control and demonstrating its operation becomes important.

The application timetable has also changed.

Following Regulation (EU) 2026/1744, the amended calendar now sets the relevant high-risk requirements for systems classified under Article 6(2) and Annex III from 2 December 2027, while the corresponding requirements for high-risk systems embedded in regulated products under Article 6(1) apply from 2 August 2028.

That gives organisations more time.

It does not remove the evidence problem.

NIST: traceability has to survive beyond the engineering team

The NIST AI Risk Management Framework is voluntary rather than law.

But the AI RMF Playbook points in a remarkably similar direction.

NIST asks organisations to consider mechanisms that facilitate AI system auditability, including traceability of the development process, data sourcing, and logging system processes and outcomes.

It also explicitly asks whether an AI system can be audited by independent third parties.

That distinction matters.

Operational teams already collect enormous amounts of information.

Logs.

Traces.

Metrics.

Alerts.

Model-performance data.

Those are important for operating AI systems safely and reliably.

But a system being observable to its operator is not the same as its evidence being independently checkable by another party.

NIST does not require cryptographic execution evidence.

That is not the claim.

The important point is that auditability has to survive beyond the engineering team that operates the system.

At some point, somebody outside that trust boundary may need to examine what happened.

ISO/IEC 42001: evidence that a management system is operating

ISO/IEC 42001 approaches AI from the management-system side.

It specifies requirements for establishing, implementing, maintaining and continually improving an Artificial Intelligence Management System.

That includes areas such as responsibilities, policies, AI risk management, data governance, lifecycle controls, monitoring and performance evaluation.

The standard is broader than execution evidence.

It should remain broader.

But management-system assurance has never been only about having the correct policy document.

ISO itself explains that an organisation claiming conformance with a management-system standard needs evidence that it is meeting the relevant requirements, typically gathered through audits. Where an organisation chooses ISO/IEC 42001 certification, that certification is performed by an independent certification body, not by ISO itself.

Now imagine a financial institution has a policy stating:

AI-assisted credit decisions below a defined confidence threshold require human review.

The policy establishes the rule.

The interesting question during an audit is whether the organisation can show what happened when that rule should have applied.

Which execution crossed the threshold?

What recommendation did the system produce?

What information was available?

Was the case routed correctly?

Did somebody review it?

Was the recommendation accepted or overridden?

Which policy version applied at the time?

The policy tells you what should happen.

Evidence tells you what happened when the policy met a real execution.

That distinction becomes more important as AI performs a larger part of the processes those management systems are supposed to govern.

SM&CR: accountability still has a name attached to it

UK financial services introduces another dimension.

The Senior Managers and Certification Regime is not an AI regulation.

It does not require cryptographic AI evidence.

Its relevance here is accountability.

Senior Managers have Statements of Responsibilities identifying what they are responsible and accountable for.

The FCA also places a Duty of Responsibility on Senior Managers and requires them to take reasonable steps in the areas for which they are responsible.

Now introduce AI into a material workflow.

Credit.

Fraud.

Insurance.

Financial crime.

Customer treatment.

Market surveillance.

Trading controls.

The accountable person does not disappear because software performs part of the decision-making.

A different problem emerges.

The person retains responsibility while becoming further removed from individual executions inside the process.

A Senior Manager may be able to explain why a model was approved.

They may be able to show the governance framework.

They may be able to describe the controls.

But if one particular decision is challenged months later, can the organisation establish what the system actually recorded at that decision point?

To be clear, this is an inference from the accountability structure of SM&CR.

It is not a claim that SM&CR requires cryptographically verifiable execution records.

But the accountability logic is difficult to ignore.

Named responsibility becomes harder to discharge when the person who owns the process cannot establish what happened inside the execution they nominally own.

The United States: existing law can create the same evidence problem

The US picture is different again.

Rather than one horizontal federal regime equivalent to the EU AI Act, organisations face a mixture of existing statutes, sector rules, agency enforcement, state requirements and litigation.

That can create the same evidentiary pressure through a different route.

The question may arrive not as:

“Are you compliant with the AI Act?”

but as:

“This decision affected me. Explain why it happened.”

Credit provides a useful example.

Under current Regulation B, 12 CFR §1002.9, a creditor taking adverse action must provide the principal reasons for that decision. The official interpretation states that those specific reasons must relate to and accurately describe the factors actually considered or scored by the creditor.

That obligation matters whether the decision process is simple or technically complex.

There is an important historical clarification here.

The CFPB previously issued Circular 2022-03 specifically addressing adverse-action notices and complex algorithms.

That circular was withdrawn on 12 May 2025 as part of a wider withdrawal of CFPB guidance.

The circular should therefore not be cited as current guidance.

But withdrawing the circular did not remove the underlying Regulation B requirement to provide specific principal reasons for adverse action.

That distinction is useful because it illustrates the broader point.

AI-specific policy can change.

The underlying need to account for consequential decisions may remain.

Employment provides another example of how existing law can reach automated decision systems.

In the iTutorGroup case, the US Equal Employment Opportunity Commission alleged that the company's tutor application software was programmed to automatically reject female applicants aged 55 or older and male applicants aged 60 or older. The case settled for $365,000 plus other relief.

It is more accurate to describe this as an automated hiring software case than as proof of some general AI-specific enforcement regime.

But that is precisely why it is relevant.

Existing legal duties do not necessarily disappear because software performs the decision.

When the dispute concerns one particular outcome, explaining how a system generally works is different from establishing what happened in that specific case.

The structural gap in today's evidence

Across all of these regimes, organisations already produce enormous quantities of documentation.

Risk registers.

Model cards.

Policies.

Audit logs.

Observability traces.

Approval workflows.

Governance dashboards.

Incident reports.

Model validation documents.

None of these are useless.

Most are necessary.

The problem is more structural.

Almost all of the evidence is produced, stored and presented by the same organisation whose system is being examined.

That does not mean the evidence is false.

It means the evidence has a trust boundary.

Imagine a bank presents an internal record showing that an AI-assisted recommendation was produced at 14:32 on 6 February.

Who produced the record?

The bank's system.

Who stored it?

The bank.

Who controls the database?

The bank.

Who generated the export?

The bank.

Who is now asking the external reviewer to rely on it?

The bank.

Again, that does not make the record dishonest.

And some organisations already use strong append-only, WORM or externally anchored logging systems that materially improve this position.

But the fundamental question remains:

What does the examining party have to trust?

The organisation cannot become an independent third party to itself.

And this distinction becomes even more important when cryptography is introduced.

A cryptographic signature produced entirely inside the system being questioned can authenticate that system's assertion. It does not create independent corroboration.

That is subtle, but important.

A digital signature can show that a particular private key signed a particular payload.

A hash can show whether protected content has changed relative to a previously established digest.

Neither automatically proves that the original record was complete, truthful, or faithfully captured from the underlying event.

A useful way to think about it is this:

Operator-controlled evidence is testimony from the system. Independently verifiable evidence gives somebody else a way to check the testimony.

While everyone trusts everyone, that distinction may not matter very much.

When a customer disputes a decision, an insurer challenges an outcome, a regulator investigates an incident, or litigation begins, the trust assumption changes.

The evidence is now being examined by somebody who may explicitly not trust the system that produced it.

That is the point where many AI audit trails become weaker than organisations expect.

Agents make reconstruction harder

The problem becomes more difficult as AI becomes agentic.

A conventional model invocation may look roughly like this:

input → model → output

An agent workflow can look more like this:

input → model → retrieval → tool call → another model → external API → policy check → another agent → action

Some steps are deterministic.

Some are probabilistic.

Some depend on external systems whose state changes.

Some happen inside infrastructure operated by different vendors.

Some may never be directly visible to the human ultimately accountable for the outcome.

The final decision may be straightforward.

The path that produced it may not be.

This weakens one of the traditional fallbacks in governance.

Historically, when the record was incomplete, organisations could often ask the person who made the decision.

With increasingly autonomous systems, that person may no longer exist in quite the same way.

A human may approve the framework.

A human may supervise exceptions.

A human may own the business process.

But software may perform dozens of intermediate actions before anything reaches them.

So months later, asking the accountable person what happened may not answer very much.

The evidentiary question shifts from:

Who remembers what happened?

to:

What record survived what happened?

That is a significant change.

What would a record need to survive challenge?

This is where the discussion should move away from products.

Before asking what software to buy, ask what properties the evidence itself needs.

If an AI execution record is expected to survive external scrutiny, there are at least five properties worth considering.

1. Tamper-evidence over a defined protected set

Saying that a record is “immutable” is not enough.

What exactly is protected?

The input?

The output?

The model identifier?

Parameters?

Tool responses?

Human review?

The execution sequence?

The policy version?

A credible evidence format should explicitly define its protected set.

If a protected field changes, verification should detect it.

Just as importantly, fields outside that integrity boundary should be clearly identified.

Otherwise two people can examine the same artifact while assuming different things were actually protected.

Tamper-evidence is not a vague property of “the record.”

It has a scope.

That scope needs to be explicit.

2. Independent verifiability

This is the property many internal audit trails are missing.

A third party should be able to verify the relevant integrity claims without relying solely on the organisation whose system produced the record.

That does not mean eliminating all trust.

No practical evidence architecture eliminates every trust assumption.

It means making those assumptions visible.

A verifier should be able to answer questions such as:

Does the integrity proof match the protected artifact?
Is the signature valid?
Which key signed it?
What fields were protected?
Has the execution chain changed?
What verification material was used?
If verification fails, why did it fail?

That last point matters.

A verification system that returns only a green badge is difficult to audit itself.

Independent verification should be repeatable enough that two conforming verifiers examining the same artifact under the same rules reach the same result.

A backend saying VALID is an assertion.

A verifier showing why the integrity checks pass is something different.

3. An independent assertion of time

A timestamp written by the application itself is weak evidence of when the record actually existed.

The application controls the value.

That becomes important when timing is part of the dispute.

Was the record created when the execution happened?

Or after the complaint arrived?

Those are very different evidentiary positions.

For higher-assurance records, an external time assertion can reduce dependence on the operator.

Trusted timestamping, including mechanisms based on RFC 3161, is one established approach.

The point is not that every AI execution requires an external timestamp.

The point is that when time itself matters, the evidence should not rely exclusively on the party whose chronology is being questioned.

4. Portability

Evidence should not disappear because a vendor relationship ends.

A record expected to survive challenge should be capable of leaving the system that created it.

That means portable artifacts.

Published verification rules.

Stable identifiers.

Exportable trust material.

Historical public keys where signatures are involved.

A reviewer should not need an active subscription to the original SaaS platform simply to determine whether an old record remains intact.

This becomes increasingly important as organisations change vendors, merge systems, replace models and retire infrastructure.

Long-term accountability and vendor lock-in are uncomfortable partners.

5. Privacy

There is one final requirement that is easy to overlook.

The evidence cannot create a second data problem.

Many AI workflows where evidence matters most involve highly sensitive information:

financial data.

medical records.

customer communications.

legal documents.

identity information.

internal investigations.

commercially sensitive material.

An evidence architecture that requires all of that information to be disclosed to every external verifier has solved one trust problem by creating another.

Privacy therefore has to be part of the evidence model.

Possible mechanisms include:

minimisation
redaction
hashing
cryptographic commitments
selective disclosure
protected evidence packs
controlled reviewer access

The exact mechanism can vary.

The requirement is broader:

Producing evidence that a record exists and remains intact should not automatically require disclosing all of the sensitive data behind it.

Why a common specification matters

None of these properties is individually new.

Hashing exists.

Digital signatures exist.

Trusted timestamping exists.

Canonical serialization exists.

Redaction exists.

Evidence packaging exists.

The problem appears when every organisation implements them differently.

One vendor hashes the entire JSON object.

Another hashes selected fields.

One changes serialization rules between software versions.

Another signs a digest but does not retain historical verification keys.

One stores an application timestamp in its own database and describes that as independent time.

Another provides a downloadable artifact that only its own SaaS product can interpret.

Another removes fields after sealing them without clearly defining what happens to the integrity boundary.

Every one of these systems may call the result an “AI audit trail.”

The artifacts remain incompatible.

The verification semantics remain inconsistent.

And the person examining the evidence has to understand a different trust model for every provider.

That is why a common specification matters.

AIEF: define the evidence requirements before defining the vendor

AIEF, the AI Execution Framework, is an open, implementation-agnostic framework for verifiable AI execution evidence.

Its current public specification is v0.2.5, Public Comment.

That is also the current canonical public name used by aief.dev and its suggested citation.

AIEF does not define how AI should make decisions.

It does not determine whether a model output was correct.

It does not define fairness.

It does not replace an AI governance programme.

And it does not require one vendor's technical architecture.

It asks a narrower question:

What properties should an execution artifact have if another party may need to verify it later?

The AIEF specification defines concepts including:

execution artifacts
declared protected sets
stable serialization
tamper-evidence
deterministic verification
standardised PASS and FAIL outcomes with reason codes
independent validation
external dependency evidence
chain integrity for multi-step workflows
retention and portability
privacy and redaction controls

For probabilistic AI systems, AIEF makes another important distinction.

Verification is not:

“Rerun the model and hope it produces the same answer.”

AIEF uses a cache-as-truth model.

The recorded output is the historical object being audited.

Verification checks the integrity of that recorded artifact rather than pretending a probabilistic model, an external API, or a changing retrieval system will necessarily reproduce the same historical result.

AIEF also defines its boundary carefully.

Successful verification can establish that protected fields remain consistent with the declared integrity proof.

It does not prove:

that the decision was correct
that the model was fair
that the output was truthful
that every relevant event was captured
that the business decision was appropriate
that the originating system acted in good faith

That last limitation is especially important.

AIEF explicitly distinguishes artifact integrity from artifact authenticity.

A perfectly intact artifact can still have been falsely issued in the first place.

Higher-assurance situations may therefore require additional provenance, attestation, runtime trust, external timestamping or other mechanisms.

A standard becomes more credible when it is explicit about what it does not prove.

AIEF is published openly and invites comment from builders, auditors, regulators, academics and practitioners.

Its implementation registry is separate from the specification itself.

That separation matters.

AIEF defines the evidence model. Implementations are free to implement it differently.

One implementation: NexArt

NexArt is one implementation listed in AIEF's implementation registry.

The registry describes entries as factual and self-declared, and explicitly states that inclusion is not an endorsement.

That is the correct relationship.

AIEF is the open framework. NexArt is an AI Evidence Layer and Verifiable Execution Infrastructure that implements this class of evidence in a production system.

NexArt represents individual executions as Certified Execution Records, or CERs.

Multi-step executions can be assembled into Project Bundles.

The evidence flow is conceptually straightforward:

execution data → protected artifact → integrity anchor → attestation material → verification

The distinction between those stages matters.

The application or integration remains responsible for capture.

NexArt does not independently prove that every relevant event was captured, or that application-supplied facts were truthful.

What the evidence layer can establish is that the protected record has not subsequently changed without detection and, where attestation is present, that the corresponding signing key signed the relevant record.

The cryptography is ordinary on purpose

NexArt CERs use SHA-256 certificate hashes over a defined protected projection.

Canonicalization is protocol-bound.

Current protocol 1.3.1 uses RFC 8785 JSON Canonicalization Scheme, while older supported records can use their earlier canonicalization profile.

When a CER is node-certified, the NexArt attestation node adds an Ed25519-signed receipt.

The node publishes its verification key material publicly through a well-known endpoint so that signature checking does not require asking the originating application whether the signature is valid.

As of this writing, the production node publicly identifies its operator as NexArt.

That is worth saying explicitly.

Independent verification is not the same claim as independent node ownership.

The value is that a third party holding the evidence and authentic public-key material can perform the cryptographic checks independently of the organisation whose AI workflow produced the record.

That is a narrower claim.

It is also a more defensible one.

External time evidence

NexArt also supports external RFC 3161 timestamp evidence as an additional verification layer.

This should not be confused with the node's own attestedAt time.

A node-issued timestamp comes from the signing system itself.

An RFC 3161 timestamp can provide a separate time-of-existence assertion from an external Time Stamp Authority.

Timestamp state is record-specific, so a verifier should inspect whether external timestamp evidence is actually present rather than assume it from the existence of a CER.

That is exactly the kind of distinction an evidence system should make visible.

Confidential execution without putting raw input and output into the proof record

Privacy creates another challenge.

A financial institution may need to prove that a record has not changed while having no legal or commercial reason to disclose the customer's underlying data to the verifier.

NexArt protocol 1.3.1 addresses this using HMAC-SHA256 commitment envelopes for raw input and output.

The implementation boundary is important.

For 1.3.1, the client transmits the raw input and output to the NexArt attestation node over TLS.

The node processes those values transiently and replaces them with cryptographic commitments before building the certified record.

According to the current protocol documentation, the raw input and output are excluded from the certified snapshot and from the persistent proof record, and the certification flow is designed not to persist them.

The resulting CER contains commitments rather than the plaintext input and output.

This does not mean every field in the record is confidential.

Fields such as the prompt and model parameters can remain plaintext, so integrations still have to decide carefully what information belongs in each part of the evidence record.

And NexArt does not claim that the raw values never cross the customer boundary.

They do cross to the node over TLS in the documented 1.3.1 flow.

That precision matters.

The goal is not to turn “confidential execution” into a vague privacy slogan.

It is to define exactly where plaintext exists, where it does not, and what remains independently verifiable afterward.

Check the evidence yourself

The easiest way to understand independently verifiable evidence is to stop describing it and give somebody something they can inspect.

A public NexArt record is identified by its certificate hash.

One public sample used in a July 2026 public verification audit was:

sha256:2e9cfd2bdaa5125578722ed12508f5f5091cc7108bc4f87c94d835c841719082

Open the record in the public verifier.

The July audit recorded:

SHA-256 integrity: PASS
Ed25519 signature: PASS
key source: public well-known key
external timestamp authority: DigiCert
RFC 3161 timestamp status: OK

The public verification URL continues to resolve at the time of writing.

Public record lookup requires no NexArt account or API key.

You can also query the public resolver directly:

CERT="sha256:2e9cfd2bdaa5125578722ed12508f5f5091cc7108bc4f87c94d835c841719082"

curl -fsS \
  "https://node.nexart.io/v1/cer/public?certificate_hash=${CERT}"

The important point is not that a NexArt webpage displays the word Verified.

The useful property is that the evidence exposes the material needed to check its cryptographic claims against published verification rules and public keys.

And the scope of that result needs to remain precise.

Successful verification can establish that the protected record remains intact and that the relevant signing key signed it.

Where valid external RFC 3161 evidence is present, it can also establish an external time-of-existence assertion.

It does not prove the AI's answer was correct.

It does not prove the underlying model call was independently observed.

It does not prove the application's capture boundary was complete.

It does not prove the decision was lawful, fair or appropriate.

That is not a weakness in the definition.

That is what makes the definition useful.

Documented compliance and demonstrable compliance are different things

The AI governance industry has spent a lot of time helping organisations document what they intend to do.

That work is necessary.

Policies matter.

Governance matters.

Model validation matters.

Human accountability matters.

Logs matter.

Observability matters.

But as AI systems begin making and influencing more consequential decisions, another layer becomes increasingly important.

Evidence of what actually happened inside the defined capture boundary.

The regulatory regimes discussed here do not use identical language.

They do not impose identical legal requirements.

And none of them mandates AIEF, NexArt, Certified Execution Records or any particular cryptographic architecture.

That is not the argument.

The argument is simpler.

Across record-keeping, human oversight, auditability, management-system assurance, named accountability and legal challenge, organisations are being pushed toward a stronger evidentiary position.

From:

“Here is our policy.”

to:

“Here is what our records show happened.”

And eventually from:

“Here is what our system says happened.”

to:

“Here is the evidence. Check it yourself.”

That is the difference between documented compliance and demonstrable compliance.

The gap between the two is where a growing amount of AI risk now sits.

NexArt adds external DigiCert timestamping and a confidential mode

Jb — Mon, 10 Aug 2026 17:39:28 +0000

NexArt adds external DigiCert timestamping and a confidential mode so organisations can verify AI execution records without exposing sensitive data.

We are committed to creating records that do not require trust in the producer or in NexArt itself.”

NexArt today announced two major enhancements to its Certified Execution Records, adding independent RFC 3161 timestamping through DigiCert’s public timestamp authority and a new Confidential Execution Mode for organisations that need verifiable AI execution records without exposing sensitive data.
NexArt is an AI evidence layer that enables organisations to produce tamper-evident, cryptographically verifiable records of what their AI systems and agents actually executed. These records are designed to help teams prove what happened during an AI execution to auditors, clients, regulators, partners or internal reviewers.
Any third party can independently verify a NexArt Certified Execution Record using standard cryptographic methods. No NexArt account is required, and verification does not depend on trusting the original operator.
The new independent timestamping capability adds an external trusted time source to Certified Execution Records, strengthening their evidentiary value for audits, disputes, incident reviews and regulated workflows.
Confidential Execution Mode addresses a key requirement for organisations handling sensitive, regulated or proprietary data. Using keyed HMAC-SHA256 commitments, NexArt allows records to be created and verified without the verification node seeing plaintext inputs or outputs. This allows authorised parties to verify the integrity of the execution record while keeping sensitive data private.
“NexArt released its first SDK six months ago, following a year of engine development. These additions continue our focus on building evidence that stands on its own,” said Jeremy Bouedo, founder of NexArt. “We are committed to creating records that do not require trust in the producer or in NexArt itself.”
NexArt records and verifies what was executed by an AI system. It does not provide governance, model evaluation, output scoring, fairness assessment or legal compliance certification. Those responsibilities remain with the organisation deploying the AI system.
Certified Execution Records can be verified at verify.nexart.io.

About NexArt
NexArt, a product of Artnames Ltd, provides an independent AI evidence layer for verifiable AI execution. NexArt helps organisations create Certified Execution Records, Project Bundles and confidential execution evidence so they can prove what happened to parties who do not need to trust them.
Contact:
Jeremy Bouedo
jeremy@artnames.io
nexart.io

How to Verify an AI Execution Record Without Trusting the Provider

Jb — Mon, 15 Jun 2026 10:37:47 +0000

A developer-focused walkthrough of verifying a Certified Execution Record using only its bytes, public node metadata, and standard cryptographic primitives.

A 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.

Most 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.

This 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.

This article walks through what it actually means to verify a CER without trusting the original provider, using the current public NexArt model.

The core problem
Most 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.

If 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:

Can the record be checked later?
Can tampering be detected?
Can the trust material be validated separately?
Does verification depend on trusting the same provider that produced the execution?
That is the gap verifiable execution is meant to close.

What real proof requires
To turn an execution into something stronger than an internal claim, you need three things.

Canonical form. The record must have one deterministic representation for hashing and signing.
Integrity. If the record changes later, that change must be detectable.
Authenticity. You need a way to prove who attested to the record.
Without canonical form, hashing becomes unstable. Without integrity, later modification cannot be detected. Without authenticity, the record may still only be self-asserted.

What a CER looks like
A 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.

{
  "bundleType": "cer.ai.execution.v1",
  "version": "0.1",
  "createdAt": "2026-05-15T14:30:00Z",
  "snapshot": {
    "executionId": "exec_123",
    "provider": "openai",
    "model": "gpt-4o-mini",
    "input": {
      "messages": [
        { "role": "user", "content": "Summarize this contract." }
      ]
    },
    "output": { "text": "This contract..." },
    "parameters": { "temperature": 0.2 }
  },
  "certificateHash": "sha256:7b1f9a2c..."
}

The 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.

Step 1: Canonicalize the correct payload
You 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.

function cerHashProjection(bundle) {
  const projection = {
    bundleType: bundle.bundleType,
    version: bundle.version,
    createdAt: bundle.createdAt,
    snapshot: bundle.snapshot
  };
  if (bundle.context !== undefined) projection.context = bundle.context;
  if (bundle.contextSummary !== undefined) projection.contextSummary = bundle.contextSummary;
  return projection;
}

Then 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.

Step 2: Recompute the certificate hash

import crypto from "node:crypto";

function sha256Hex(data) {
  return "sha256:" + crypto.createHash("sha256").update(data).digest("hex");
}

const canonicalJson = toCanonicalJson(cerHashProjection(bundle));
const recomputed = sha256Hex(canonicalJson);

if (recomputed !== bundle.certificateHash) {
  throw new Error("Integrity check failed");
}

If 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.

Step 3: Fetch the public trust material
NexArt's public node metadata is exposed at the well-known node endpoint:

curl -s https://node.nexart.io/.well-known/nexart-node.json > keys.json

This 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:

curl -s "https://node.nexart.io/v1/cer/public?certificateHash=<HASH>" > record.json

That public endpoint requires no API key.

Step 4: Verify the attestation receipt signature
The 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.

import crypto from "node:crypto";

function verifyEd25519(publicKeyPem, messageCanonical, signatureBase64url) {
  return crypto.verify(
    null,
    Buffer.from(messageCanonical),
    publicKeyPem,
    Buffer.from(signatureBase64url, "base64url")
  );
}

const receipt = bundle.receipt || bundle.meta?.attestation?.receipt;
const signature =
  bundle.receiptSignature ||
  bundle.signature ||
  bundle.meta?.attestation?.signature;

if (!receipt || !signature) throw new Error("Missing attestation material");

const receiptCanonical = toCanonicalJson(receipt);
const ok = verifyEd25519(publicKeyPem, receiptCanonical, signature);
if (!ok) throw new Error("Invalid attestation signature");

The 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.

Step 5: Understand the trust boundary clearly
A 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.

So the honest way to say it is:

Public verification gives you a real trust surface.
Privacy-aware public lookup is not the same as publishing the full original private execution.
That is a feature, not a flaw.

Step 6: Use the CLI when you want protocol-correct verification
If you want a simpler local verification path, the NexArt CLI already provides one:

nexart ai verify bundle.json

That 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.

What this proves
A successful verification proves a few specific things:

The protected CER payload has not been altered since sealing.
The attestation material was signed by the expected node identity.
The record you are checking matches the cryptographic identity claimed by its certificateHash.
That 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."

What this does not prove
Verification of a CER does not automatically prove:

That every conceivable relevant fact was included.
That the underlying model was correct.
That a probabilistic model would reproduce the same output now.
That the record was written to a public ledger.
That an external timestamp authority was used.
That nothing outside the protected record influenced the broader business decision.
Those are different layers. The system is about execution integrity and evidence, not universal truth claims. That discipline keeps the evidence model credible.

Why this matters
In 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.

A 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."

That 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.

Closing
A 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.

A 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?

That is the standard serious AI systems will increasingly need to meet.

What I actually want from an AI evidence layer (and why I built NexArt)

Jb — Mon, 11 May 2026 10:41:31 +0000

I want to talk about a problem that doesn't get enough attention in AI engineering: when something goes wrong, most teams cannot actually prove what their AI did.

Not "show me the logs." Not "here's a screenshot of the dashboard." I mean prove it. Cryptographically. To an auditor, a regulator, or a customer who has no reason to trust you.

This isn't a hypothetical. It comes up the moment a customer disputes a refund decision, or compliance asks for evidence, or a partner wants to verify the inputs that led to an output. Logs describe what you remember. They don't prove what actually happened.

I'm the founder of NexArt, and we built it specifically to close that gap. In this post I want to walk you through what NexArt is, why it exists, and how to drop it into your stack in roughly an hour.

So what is NexArt, in one paragraph

NexArt is verifiable execution infrastructure for AI systems. Every time your AI runs, NexArt produces a Certified Execution Record (CER), which is a tamper-evident, cryptographically signed artifact that binds the inputs, outputs, parameters, and context into a single record. Anyone (auditors, partners, regulators, your own customers) can verify that record independently at verify.nexart.io. No account, no API key, no dependency on us.

The model we follow is simple: free to create, paid to certify, public to verify.

It is not observability. It is not a logging tool. It is not an eval framework. Think of it as the evidence layer underneath your AI: proof that what ran is what you say ran.

What it does not do

This part is worth being clear about, because the category is new and easy to mix up with other tools.

NexArt does not claim the model's output is correct. It does not score quality or alignment. It does not replace your observability stack or your evals. What it does is prove what executed, with what inputs, at what time, against what parameters, and bind all of that into one artifact that anyone can verify without trusting you.

The promise is integrity of the record, not quality of the model. Different problem.

Why this matters now

A few situations where the lack of execution evidence really bites:

Audit and compliance work. ISO 42001, SOC 2, and the EU AI Act all push toward demonstrable, reproducible evidence of AI decisions.
Customer disputes. Someone claims your AI denied them unfairly. What is your proof of the exact inputs and parameters at that moment?
Agent workflows. Multi-step agents make many decisions per run. Without a sealed trail, you cannot reliably reconstruct which step did what.
Debugging. Reproducing a failed run from a tamper-evident record is a very different experience from stitching together five different log sources.

The pattern I keep seeing is that teams discover this gap during an audit or a dispute. By then, the executions they need to prove are already gone.

How it works

The flow is intentionally small. Four steps, each with one job:

Capture. Inputs, outputs, and execution context are recorded at runtime.
Seal. A canonical, tamper-proof fingerprint (the certificateHash) binds them into a single record. This happens locally and offline.
Attest. An independent attestation node signs the record and issues a receipt plus a verification envelope.
Verify. Anyone can re-derive the hash, validate the signature, and check the envelope. No trust in NexArt or in you is required.

Verification itself happens in three independent layers:

Layer 1, Integrity. Recompute SHA-256 over the canonicalized whitelist and compare it with certificateHash.
Layer 2, Receipt. Validate the Ed25519 signature from the attestation node.
Layer 3, Envelope. Validate the bundle-level signature over the attestation projection.

Each layer reports independently as PASS, FAIL, or SKIPPED. A sealed-only (offline) bundle gives you PASS / SKIPPED / SKIPPED. A certified bundle gives you three PASS lines. SKIPPED is not a failure, it just means that layer doesn't apply to that bundle yet.

Quick implementation

This is the canonical integration: one function call wrapped around your model inference. No proxy, no middleware, no infrastructure change.

1. Install the SDK

npm install @nexart/ai-execution

2. Set two environment variables

export NEXART_NODE_URL="https://node.nexart.io"
export NEXART_API_KEY="<your-api-key>"

3. Wrap an execution

import {
  certifyLangChainRun,
  verifyAiCerBundleDetailed,
} from "@nexart/ai-execution";

async function main() {
  // Capture, seal, and certify in one node round-trip.
  const { bundle, certificateHash, verificationUrl } =
    await certifyLangChainRun({
      provider: "openai",
      model: "gpt-4o-mini",
      input: {
        messages: [
          { role: "user", content: "Should this refund be approved?" },
        ],
      },
      output: { decision: "approve", reason: "policy_passed" },
      nodeUrl: process.env.NEXART_NODE_URL!,
      apiKey: process.env.NEXART_API_KEY!,
    });

  console.log("certificateHash :", certificateHash);
  console.log("verificationUrl :", verificationUrl);

  // Independent verification of the returned bundle.
  const report = await verifyAiCerBundleDetailed(bundle);
  console.log("Integrity (Layer 1) :", report.integrity);
  console.log("Receipt   (Layer 2) :", report.receipt);
  console.log("Envelope  (Layer 3) :", report.envelope);
}

main().catch((err) => {
  console.error("FAILED:", err);
  process.exit(1);
});

4. Run it

npx tsx test-harness.ts

You should see something like this:

certificateHash : sha256:9f2b1c8e4a7d6f3b...
verificationUrl : https://verify.nexart.io/c/sha256:9f2b1c8e4a7d6f3b...
Integrity (Layer 1) : PASS
Receipt   (Layer 2) : PASS
Envelope  (Layer 3) : PASS

Three PASS lines tell you a few things at once. The bundle is byte-identical to what the node attested. The receipt signature validates against the node's key. And the verification envelope correctly binds the attestation back to the bundle.

Open the verificationUrl in any browser. Anyone, including someone who has never heard of you, can confirm the record. No account, no API key. That's it. You now have audit-grade execution evidence for that AI call.

Offline mode, when you don't want a network call

Not every execution needs to hit the node. NexArt supports a fully offline flow that's useful for air-gapped environments, local testing, or batching certification for later.

import { sealCer, verifyAiCerBundleDetailed } from "@nexart/ai-execution";

const { bundle, certificateHash } = sealCer({
  provider: "openai",
  model: "gpt-4o-mini",
  input: { messages: [{ role: "user", content: "What is 2 + 2?" }] },
  output: { text: "4" },
});

const report = await verifyAiCerBundleDetailed(bundle);
// report.integrity === "PASS"
// report.receipt   === "SKIPPED"
// report.envelope  === "SKIPPED"

Two things to keep in mind here. SKIPPED is expected for a sealed-only artifact, so don't treat it as a failure. And when you're later ready to make the record publicly verifiable, submit the bundle to the attestation node. The same certificateHash will receive a signed receipt. The identity of the record never changes.

Multi-step workflows: Project Bundles

Real systems aren't a single call. Agents plan, retrieve, decide, and act across many steps. For those, NexArt has Project Bundles. Each step becomes its own CER, and the bundle ties them into one verifiable artifact with its own projectHash.

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 hash for the whole workflow

One workflow. Many executions. One artifact you can hand to anyone.

The point of independent verification

Here is the part most evidence systems quietly skip. Verification cannot require trust in the system that created the record. If it does, it isn't really evidence.

A few design choices follow from that:

The SDK creates records locally.
The attestation node certifies them independently.
The verifier at verify.nexart.io is a separate public surface, with no login and no API key.
Verification can also run offline, using only the bundle and the node's published public key.

To verify a record, anyone can open https://verify.nexart.io/c/{certificateHash} directly, or paste an execution ID, certificate hash, or upload the JSON bundle on the home page, or run verifyAiCerBundleDetailed(bundle) locally in their own code. All three paths land at the same answer.

This is what makes the evidence portable. You can hand it to an auditor, a regulator, a counterparty, or a customer, and they do not have to trust you for it to mean something.

A few pitfalls worth mentioning

Some mistakes I've seen in real integrations, in case they save you some time:

Don't mutate a certified bundle. Re-ordering keys, adding fields, or re-serializing will break certificateHash. Persist bundles byte-for-byte after certification.
Don't look records up by executionId. Always use certificateHash, which is the canonical identity. Two attempts of the same execution can share an executionId but produce different hashes.
Don't hash the full bundle yourself. Hashing is over a strict whitelist (bundleType, version, createdAt, snapshot, plus optional context and contextSummary) using JCS canonicalization (RFC 8785). The SDK does this for you.
Don't treat SKIPPED as a failure. It's the correct result for sealed-only artifacts on Layers 2 and 3.

Where to dig in next

Main site: nexart.io
Docs and quickstart: docs.nexart.io
Public verification surface: verify.nexart.io
LangChain example repo: github.com/artnames/nexart-langchain
n8n example repo: github.com/artnames/nexart-n8n

One last thought

We've spent the last decade making AI systems more capable. The next decade is going to be about making them accountable. As more decisions get automated, the cost of not having execution evidence quietly compounds. Every uncertified run is a record you can't recover later.

If you're building anything where someone might one day ask "prove it," I'd start certifying now. One function call, one record, one link anyone can verify is a much better position to be in than scrambling to reconstruct logs the week before an audit.

That's NexArt. If you try it, I'd genuinely love to hear what works and what breaks. Feedback from real integrations is how the protocol gets sharper.

Thanks for reading.

Jeremy, founder of NexArt

How NexArt Protects AI Execution Evidence From Tampering

Jb — Fri, 03 Apr 2026 19:21:39 +0000

If an AI execution record is going to matter later, the real question is simple:

Who could tamper with it, and when?

That question shows up fast in serious environments.

A workflow makes a recommendation.

An agent triggers an action.

A decision gets reviewed months later.

At that point, nobody really cares how pretty the dashboard was.

They care about something much more basic:

Can the record still be trusted?

That is where most ordinary logging models start to break down.

And it is exactly where NexArt’s trust model becomes useful.

The weak default model
Most AI systems today still rely on some mix of:

application logs
traces
observability tooling
stored outputs
internal databases
That is useful for operations.

It is much weaker for proof.

The problem is not that logs are worthless. The problem is that logs are usually still controlled by the same system, team, or customer that produced the result in the first place.

That creates several weaknesses.

A customer-controlled log can be rewritten.

Telemetry can be incomplete.

Context can be lost.

And when something is challenged later, teams often reconstruct what happened from multiple systems rather than preserving one stable record at the point of execution.

That works for debugging.

It is much weaker for disputes, audits, and high-trust workflows.

The result is a familiar but fragile position:

“This is what our system says happened.”

Not:

“This is what can still be independently checked later.”

What NexArt changes
NexArt changes the model by turning important AI executions into Certified Execution Records, or CERs.

A CER is not just another log entry.

It is a certified execution artifact.

At a high level, the flow is simple:

a workflow runs
a CER is created from that execution
the CER is certified through the NexArt certification layer
a minimum certified record is stored outside the customer’s control
verification can later check whether the protected fields still match the certified state
That outside-the-customer-control part is the key difference.

Once a CER has been certified, the customer cannot retroactively rewrite that independently stored certified state after issuance.

That already makes NexArt meaningfully different from:

customer-owned logs
customer-controlled audit tables
standard observability products
internal “trust us” record systems
What this protects against today
This current model already protects against several very real enterprise problems.

Customer-side rewriting of history
If a team later wants to alter the record of an execution after certification, verification should fail.

That matters because many audit trail systems still rely on the customer’s own infrastructure to preserve history.

NexArt shifts that baseline.

Post-hoc edits to important fields
If protected fields such as inputs, outputs, or declared metadata are changed after certification, the record should no longer verify.

That changes the trust conversation from reconstruction to integrity checking.

Over-reliance on internal telemetry
A team no longer has to say:

“Please trust our logs.”

Instead, it can point to a certified artifact with an integrity anchor and an independent verification path.

Disputes over what actually happened
When an output is challenged later, the record does not need to be rebuilt from fragments. It can be inspected as a preserved execution artifact.

That is not a small operational improvement.

It is a different evidence model.

The trust boundary that still remains
This is the part that matters for serious enterprise buyers.

A strong trust model is not one that claims to eliminate every trust assumption.

It is one that states them clearly.

NexArt already gives you one important protection layer:

the customer cannot silently rewrite certified evidence after issuance.

But a security-minded evaluator may still ask a different question:

What trust do we still place in NexArt itself?

That is the right question.

Because there are really two layers here.

Layer one: customer-side tamper resistance
This is what NexArt already provides today.

It protects against customer-side rewriting, post-hoc edits, and over-reliance on internal logs.

Layer two: trust in the certification environment
A more demanding enterprise buyer may still ask:

could a privileged NexArt operator interfere with the certification path?
what if the host running the certification node is compromised?
what about tampering before or during certification, rather than after it?
That is a different layer of trust.

And being honest about it increases credibility, not weakness.

The point is not that NexArt’s current model is broken without more.

Become a Medium member
The point is that customer-side tamper resistance and certification-environment trust are not the same question.

Why this is already stronger than ordinary logs
This distinction matters because most teams still treat “audit trail” and “evidence” as if they were the same thing.

They are not.

An ordinary log says:

“Here is what our system recorded.”

A certified execution artifact says:

“Here is the record, here is the integrity anchor, and here is how you can verify whether it still matches the certified state.”

That is already a substantial trust improvement.

You do not need hardware-backed attestation to make that true.

You already need only three things:

a preserved execution artifact
certification outside customer control
deterministic verification over the protected set
That is the baseline evidence layer.

The next layer: hardware-backed attestation
For some enterprise environments, that baseline will still not be enough.

Especially in highly controlled settings such as:

banking
insurance
regulated financial operations
other high-assurance enterprise deployments
Those buyers may want stronger assurance around the certification path itself.

That is where hardware-backed attestation becomes relevant.

In simple terms, hardware-backed or enclave-backed attestation can strengthen trust in the environment that performs certification.

It helps answer a harder question:

Can the certification process itself be tied to a trusted runtime boundary?

That matters most when the buyer wants stronger guarantees not only that the customer cannot rewrite evidence later, but also that the certification path itself is operating inside a more strongly bounded environment.

That is an important extension.

But it should be framed correctly.

The right way to think about it
NexArt today already provides a meaningful independent evidence layer.

Hardware-backed attestation is not a rescue of a broken model.

It is a stronger enterprise trust extension for the most demanding environments.

That distinction matters.

The right framing is:

NexArt is the execution evidence layer
hardware-backed attestation is a premium trust extension
Not the other way around.

A simple trust-layer model
A useful way to remember this is to think in layers.

Layer 1: Record integrity
Has the record been altered?

Layer 2: Independent certification
Was the record sealed outside customer control?

Layer 3: Runtime trust extension
Can the certification path itself be hardware-attested?

Most systems today never really get to Layer 2.

They remain inside customer-controlled evidence.

NexArt moves the system to Layer 2.

Hardware-backed attestation extends that trust model into Layer 3.

Where AIEF helps
This layered way of thinking is one reason AIEF is useful as a framing tool.

The AI Execution Integrity Framework is an implementation-agnostic framework that defines baseline control objectives, evidence expectations, conformance levels, and a minimal verifier interoperability contract for AI execution integrity artifacts. It is explicitly scoped around integrity and verifiability of the recorded artifact rather than correctness, fairness, or future output determinism.

That helps clarify something important:

trust maturity can increase in layers.

You do not need to start at the highest-assurance tier to have meaningful evidence.

AIEF helps make space for a practical baseline and a stronger enterprise assurance tier.

That is exactly the right way to think about NexArt’s current model and its enterprise roadmap.

Why this matters now
This matters because more AI systems are moving into environments where records need to survive scrutiny.

The EU AI Act is the clearest legal example today. The European Commission’s timeline states that the majority of the AI Act’s rules apply from 2 August 2026, and that Annex III high-risk AI systems come into application then. Article 12 requires high-risk AI systems to technically allow automatic recording of events over their lifetime.

That does not mean the law mandates CERs, or hardware-backed attestation, or one specific architecture.

It does mean that weak, customer-controlled, reconstructive evidence models are going to look less convincing over time.

In the U.S., there is still no single federal equivalent to the EU AI Act. In practice, the closest broad reference point is the NIST AI Risk Management Framework, which is voluntary and sector-agnostic, plus sector-specific obligations and supervisory expectations.

Across both environments, the direction is similar:

systems increasingly need records that are more defensible than ordinary logs.

Practical takeaway
Most teams do not discover their evidence problem while everything is going well.

They discover it when:

a decision is challenged
an output is disputed
a reviewer asks for proof
an audit asks what actually happened
At that point, reconstruction is weaker than preservation.

NexArt already gives teams something that customer-controlled audit trails and observability tools usually do not:

an independent certification layer for AI execution evidence.

That is meaningful today.

And for high-assurance enterprise environments, hardware-backed attestation is the next trust layer, not the first one.

Next step
If you are evaluating AI execution evidence for enterprise use, the right next step is not theoretical.

It is practical.

Look at how a Certified Execution Record works in practice.

Inspect how verification behaves.

Then decide whether your environment needs baseline independent certification, or a stronger runtime trust extension on top of it.

Explore:

the CER page
the public verifier
enterprise pricing / evaluation
a proof walkthrough

How to Add Verifiable Execution to LangChain and n8n Workflows (with NexArt)

Jb — Thu, 02 Apr 2026 14:58:36 +0000

Most AI workflow tooling helps you run chains, agents, and automations.

Very little helps you prove what actually ran later.

That gap matters more than it seems.

If a workflow output gets challenged, reviewed, or audited, logs are often not enough. They describe what happened, but they are still controlled by the same system that produced the result.

This is where verifiable execution becomes useful.

In this article, we’ll walk through a simple pattern for adding Certified Execution Records (CERs) to:
• LangChain workflows
• n8n automations

The goal is not to add complexity.

It’s to make workflow outputs defensible, inspectable, and verifiable later.

The Problem

Most AI systems already have:
• logs
• traces
• run metadata
• observability dashboards

That’s useful.

But it does not give you a durable, independently verifiable record of execution.

Example:
• an agent makes a recommendation
• a chain classifies a request
• a workflow triggers an action

Later someone asks:
• What exactly ran?
• What inputs produced this result?
• Which model and parameters were used?
• Was this record modified later?
• Can this be verified without trusting the original app?

In many systems, the answer is still:
• internal logs
• partial reconstruction
• “trust us”

That’s weak for anything that might be:
• audited
• reviewed
• disputed
• relied on downstream

What NexArt Adds

NexArt produces a Certified Execution Record (CER).

A CER is a tamper-evident execution artifact that binds:
• input
• output
• model/provider metadata
• parameters
• execution context
• certificate hash

The pattern is simple:
1. Run your workflow
2. Create a CER from the result
3. Verify it locally or register it
4. Later → anyone can inspect or verify it

The key shift:

The output is no longer “something that happened in logs”
It becomes a portable, verifiable record

Where to Start

We’ve published two example repos:
• LangChain example
• n8n example

They show the same pattern:
• execute
• create CER
• inspect certificate hash
• verify

Part 1 — LangChain

What this looks like

LangChain is a natural fit for CERs because many workflows involve:
• prompt chains
• tool-calling agents
• classification pipelines
• decision helpers

These are exactly the places where questions show up later.

Minimal pattern

const output = await chain.invoke({
  question: "Summarize the key risks in Q4 earnings."
});

const bundle = createLangChainCer({
  provider: "openai",
  model: "gpt-4o",
  prompt: "You are a helpful assistant.",
  input: { question: "Summarize the key risks in Q4 earnings." },
  output,
});

Then verify:

const result = verifyCer(bundle);

console.log(result.ok);
console.log(bundle.snapshot.certificateHash);

That’s it:
• execute
• create CER
• verify

What gets captured

A typical CER includes:
• workflow input
• workflow output
• model/provider metadata
• parameters
• execution context
• certificateHash

The certificateHash is the integrity anchor.

Multi-step / agents

For agent workflows:
• certify important tool calls
• certify intermediate decisions
• certify final outcome

This creates a traceable, verifiable chain of evidence, not just a final blob.

Why this matters

A normal chain output says:

“this is what the chain returned”

A CER-backed output says:
• this was the input
• this was the output
• this was the execution context
• this record can be verified later

That’s a completely different trust model.

Part 2 — n8n

The approach

You don’t need a custom node.

Start with:
• normal workflow
• HTTP Request node
• small certifier service

Typical flow
1. Workflow runs
2. Output is produced
3. HTTP node sends payload to certifier
4. Certifier returns:
• certificateHash
• bundle
5. Optionally verify

Example payload

{
  "provider": "openai",
  "model": "gpt-4o",
  "input": {
    "ticketId": "SUP-1042",
    "priority": "high",
    "summary": "Customer cannot access production dashboard"
  },
  "output": {
    "classification": "escalate",
    "reason": "production-impacting access issue"
  },
  "workflowId": "support-triage"
}

Response:

{
  "certificateHash": "sha256:...",
  "bundle": { ... }
}

Where this fits best

This pattern is especially useful for:
• approvals
• classification workflows
• routing decisions
• policy checks
• automation outcomes

Anything that might later be:
• reviewed
• audited
• challenged

CERs vs Logs

Logs say:

“this is what the system says happened”

CERs say:
• this is the execution record
• this is the integrity anchor
• this can be verified independently

CERs don’t replace observability.

They add something observability usually lacks:

portable, tamper-evident execution evidence

When to Use This

Start where outcomes matter:
• approvals
• classifications
• decisions
• agent actions
• workflow outputs consumed downstream

Simple rollout
1. Add CER to one workflow
2. Verify locally
3. Add certification if needed
4. Expand gradually

Don’t over-engineer it.

Final Thought

Most AI tooling is optimized for:
• execution
• iteration
• observability

That’s fine.

But once outputs matter, the question changes:

Not “did it run?”
But “can you prove what ran?”

That’s what CERs are for.

How to Add Verifiable Execution to an AI Agent in Under 30 Minutes

Jb — Fri, 27 Mar 2026 09:42:05 +0000

Your AI agent made a decision last week.

Today, someone asks you to prove exactly how it happened.

Which input did it receive?

Which tools did it call?

What sequence of steps led to the outcome?

What changed in the workflow?

Can you prove the record was not modified after the fact?

For most teams, this is where confidence starts to collapse.

Not because the agent necessarily failed.

Because the evidence does.

As AI agents move from demos into financial workflows, internal automation, support systems, and operational tooling, this problem becomes much more serious. It is no longer enough to say an agent worked. You need to be able to show what it did, how it did it, and whether that record can still be trusted later.

That is where most systems break.

And that is exactly where verifiable execution becomes useful.

The Problem Most Agent Builders Eventually Hit
At first, agent workflows feel manageable.

You can inspect logs, review traces, and debug errors as they happen. In early prototypes, that is often enough.

But once agents start making decisions that matter, the questions change.

You are no longer only asking:

Did the workflow complete?
Did the tool call succeed?
Did the model return a result?
You are now asking:

What exactly happened during this run?
Can we reconstruct the full chain of actions?
Can we explain this decision to someone else?
Can we verify the execution without trusting our own internal systems?
These questions show up fast in the real world.

For example:

a support agent issues the wrong refund
a fraud agent flags a legitimate transaction
an operations agent triggers the wrong workflow
a compliance agent escalates the wrong case
a multi-step agent behaves differently from one run to the next
When that happens, logs help, but they rarely give you a clean answer.

They give you fragments.

And fragments are not evidence.

Why Logs Are Not Enough for Agent Systems
Logs are useful. They are essential for operating software.

But they were built for observability, not proof.

That difference matters a lot more in agent systems because agent execution is usually:

multi-step
dynamic
dependent on tool calls
influenced by changing runtime context
spread across multiple systems and services
So when you try to answer a simple question like:

“Can you prove what the agent actually did?”

you often end up pulling from:

application logs
model traces
API records
database entries
monitoring dashboards
tool-specific logs
At that point, you are no longer looking at one record.

You are running a reconstruction exercise.

That introduces real problems:

records are fragmented
context is incomplete
timelines are hard to correlate
outputs are difficult to defend
external validation is nearly impossible
Even if you log everything, you are still relying on:

trust in your own infrastructure

That is exactly the thing many teams need to reduce.

The Stakes Are Getting Higher
This is not just a debugging issue anymore.

It becomes more serious as agents move into workflows involving:

money
approvals
compliance
customer actions
internal operations
regulated processes
In these environments, the standard changes.

The question is no longer:

“Did the system seem to work?”

It becomes:

“Can you defend what it did when the decision is challenged?”

That is a much higher bar.

And standard logs were never designed to clear it.

The Shift: From Logging Agents to Certifying Them
There is a better model.

Instead of trying to reconstruct an agent’s behavior after the fact, you capture the execution as it happens and turn it into a tamper-evident artifact.

This is the core idea behind verifiable execution.

And for agent workflows, that means generating a Certified Execution Record, or CER.

Definition: Certified Execution Record (CER)
A Certified Execution Record is a structured, tamper-evident artifact that captures an AI execution, including inputs, parameters, context, and outputs, in a form that can be independently verified later.

The key difference is simple:

Logs describe events.

CERs capture the execution itself.

What You Are Building in Under 30 Minutes
By the end of this process, you will have:

an AI agent that emits a Certified Execution Record
a portable artifact that captures inputs, tool calls, decisions, and outputs
a way to verify the execution independently
a workflow that produces audit-ready execution evidence by default
That means you are not just running an agent.

You are creating a record of what it did that can be:

stored
reviewed
shared
verified later
Step 1: Install the NexArt SDK

npm install @nexart/agent-kit @nexart/ai-execution

The goal here is to remove friction.

You should not have to manually assemble execution artifacts or wire low-level primitives just to make an agent verifiable.

That is what @nexart/agent-kit is designed to handle.

Step 2: Wrap Your Agent Execution
Here is a minimal example:

import { runWithCer } from "@nexart/agent-kit"

;

const result = await runWithCer({
  input: "Should we approve this transaction?",
  agent: async (input) => {
    const decision = await yourAgent.run(input);
    return {
      output: decision,
      tools: decision.toolsUsed,
      reasoning: decision.reasoning
    };
  }
});

What happens here:

your agent runs normally
execution context is captured automatically
a Certified Execution Record is generated as part of the run
This is the important shift:

you are no longer treating verification as something you add later.

Write on Medium
It becomes part of the execution path itself.

Step 3: Export the CER

import { exportCer } from "@nexart/ai-execution;"

const cerBundle = exportCer(result.cer);

This produces a portable execution artifact.

That means the result can now be:

stored for future review
attached to a workflow
sent to another team
used in audit or incident analysis
validated independently later
This is where the system starts to feel different.

You are no longer left with logs buried inside an internal stack.

You now have a standalone record of what happened.

Step 4: Verify the Execution
Once the CER exists, you can verify it independently.

Option A: CLI

npx nexart ai verify cer.json

Option B: Public verifier
👉 https://verify.nexart.io

You can:

upload a CER
inspect execution data
verify integrity
review attestation if present
No login required. No dependency on your internal system. No need to trust the original application.

That changes the trust model completely.

What This Looks Like Before and After
Before
the agent runs
logs are scattered across systems
debugging is manual
audits require reconstruction
trust is implicit
After
the agent runs
a CER is created automatically
the execution is captured in one artifact
verification is immediate
trust becomes checkable
That is the practical difference between observability and execution evidence.

Why This Is Easier Now Than It Used to Be
This workflow is much easier to adopt today than it was even recently.

The NexArt builder stack has been tightened around a cleaner execution-evidence workflow so builders can certify agent execution without dealing with unnecessary assembly work.

That includes improvements across the stack:

agent workflows can emit standard CERs directly through @nexart/agent-kit
CER packages can be detected, assembled, exported, imported, and verified through @nexart/ai-execution
the CLI can verify both raw CER bundles and CER packages
the broader stack now aligns around the same supported artifact shapes
That matters because execution evidence only works if builders can use it without fighting the tooling.

The goal is not just stronger verification.

It is making strong verification easy enough to become part of everyday development.

Just as importantly, these changes remain additive and backward-compatible.

That preserves one of NexArt’s most important properties:

previously created CERs must remain independently auditable and verifiable over time.

Why This Matters Specifically for Agents
Agent systems are harder to reason about than simple model calls.

A single execution may involve:

multiple prompts
tool selection
branching decisions
external API calls
intermediate state changes
final actions
When something breaks, the problem is usually not just the final output.

The real question is:

What sequence of actions and decisions produced this outcome?

That is an execution problem.

And execution problems need structured evidence, not scattered logs.

CERs give you that structure.

They let you capture:

what the agent saw
what it did
what tools it used
what output it produced
whether that record is still intact
That is what makes agent execution defensible.

Where You Should Start
You do not need to make every agent verifiable on day one.

Start where the operational or trust risk is highest.

Good starting points include:

agents that affect users directly
agents that call external tools
financial or operational workflows
approval or escalation flows
systems likely to be reviewed later
anything that could become a dispute or audit issue
That is where verifiable execution creates immediate value.

A Better Mental Model
Most systems today operate like this:

Execution → Logs → Reconstruction

With NexArt, the model becomes:

Execution → Certified Artifact → Verification

That removes a lot of pain:

less manual correlation
less guesswork
less dependence on internal trust
better portability
better long-term defensibility

Why This Is Becoming the New Standard
As AI systems move into higher-stakes environments, the standard is changing.

Teams increasingly need:

execution integrity
tamper-evident records
independent verification
audit-ready evidence
clearer provenance for agent decisions
In that world, logs still matter.

But they are not enough on their own.

They tell you what happened from inside the system.

Execution evidence lets you prove it from outside the system too.

That is a very different capability.

Try It Yourself
If you want to see this in practice:

👉 Verify a record → https://verify.nexart.io

👉 Get started → https://docs.nexart.io

You can generate and verify your first CER in minutes.

Final Thought
AI agents are becoming decision-makers, not just assistants.

As that happens, the bar gets higher.

It is no longer enough to say:

“We logged what happened.”

You need to be able to say:

“Here is what happened. You can verify it.”

That is the shift from observability to verifiable execution.

And for agent systems, that shift is going to matter a lot.

Why We Built verify.nexart.io

Jb — Wed, 25 Mar 2026 11:28:24 +0000

AI systems are increasingly used to ...
AI systems are increasingly used to produce outputs, decisions, and actions that matter.

They:

trigger workflows

call external tools

influence financial and operational outcomes

act across multiple systems as agents

But there is a structural problem.

Most AI systems do not provide a clean way to independently verify what actually ran.

They produce outputs.

They generate logs.

They may even store execution data.

But they rarely provide a place where that execution can be checked by someone else.

That is the gap verify.nexart.io is designed to solve.

The Problem: Execution Without Independent Verification
Most AI systems today follow a familiar pattern:

execution happens

logs are generated

results are stored inside the system

If someone wants to understand what happened, they must rely on:

internal dashboards

logs controlled by the system operator

exported data from the original environment

This creates a dependency:

you can only verify the system by trusting the system.

That is not real verification.

Definition: Independent Verification
Independent verification is the ability to validate an execution record without relying on the system that produced it.

It means that:

the record can be inspected outside the original environment

integrity can be validated independently

results do not depend on internal access or trust

This is a critical requirement for AI auditability and execution integrity.

Why Verification Needs Its Own Surface
Execution and verification are not the same thing.

Producing a record is one step.

Validating that record is another.

In most systems, these two steps are tightly coupled.

The system that generates the data is also the system that displays and verifies it.

This creates a limitation:

verification is not portable

verification is not independent

verification is not usable by third parties

A true verification system requires a separate surface.

One that allows anyone to:

inspect a record

validate its integrity

understand what happened

do so without trusting the origin

What verify.nexart.io Does
verify.nexart.io is a public verification surface for Certified Execution Records (CERs).

It allows anyone to take an execution record and validate it independently.

What You Can Do with verify.nexart.io

Look up or upload a CER
You can:

enter a certificate hash

upload a record

access a previously generated execution

Inspect execution metadata
Each record exposes structured information such as:

inputs and parameters

execution context

runtime fingerprint

output hash

certificate identity

This provides a clear view of what was recorded.

Verify integrity
The system checks:

whether the record has been altered

whether hashes match

whether the structure is valid

This ensures the record is tamper-evident.

Replay or validate execution
Where supported, you can:

replay the execution

verify deterministic consistency

confirm that outputs match expectations

This moves beyond static inspection into active verification.

Review attestation
If attestation is present, you can:

verify signatures

confirm origin

validate that the record was produced by a known system

Do all of this independently
Most importantly:

You can do all of this without trusting the original application.

That is the key difference.

Making Verification Usable for Builders
Verification only matters if builders can actually produce verifiable records in the first place.

One of the common challenges with execution-evidence systems is friction:

too many primitives

complex assembly of execution records

inconsistent formats

difficult verification workflows

If producing a verifiable record is hard, adoption slows down.

NexArt has focused on reducing this friction across the builder stack.

A More Usable Execution-Evidence Workflow
The NexArt ecosystem has been refined so that producing and verifying Certified Execution Records is more consistent and easier to adopt.

Today, builders can:

generate CERs directly from agent workflows

capture tool calls and final decisions as structured execution evidence

work with standardized record formats

verify the same artifacts across SDK, CLI, and verification surfaces

This removes the need to manually assemble execution records or wire low-level primitives.

What This Enables in Practice
These improvements make it possible to:

treat agent execution as verifiable by default

package execution records in a consistent format

move records across systems without breaking verification

validate records using the same structure everywhere

Just as importantly, these changes are additive.

Existing Certified Execution Records remain valid and independently verifiable.

This is critical.

Execution evidence must remain stable over time for auditability to work.

From Concept to Infrastructure
These changes move NexArt beyond a conceptual model.

It becomes:

easier to integrate

easier to use

easier to verify

consistent across tools

While still maintaining strict execution integrity.

From Records to Verifiable Artifacts
NexArt is not just about producing execution records.

It is about turning those records into verifiable artifacts.

Definition: Certified Execution Record (CER)
A Certified Execution Record is a tamper-evident, cryptographically verifiable artifact that captures the inputs, parameters, context, and outputs of an AI execution in a form that can be independently validated.

Producing a CER is one step.

Making it independently verifiable is another.

verify.nexart.io is where that second step happens.

Why We Built It
We built verify.nexart.io because execution evidence is only useful if it can be checked.

This matters for multiple audiences.

For Builders
debug and validate execution

share results with others

prove behavior without exposing internal systems

For Counterparties
verify claims made by another system

inspect execution context

validate outputs independently

For Auditors
review execution records

validate integrity

support governance and compliance processes

For Future Review
revisit past executions

validate records months later

ensure long-term integrity

For Disputes
provide evidence of what happened

reduce ambiguity

support structured resolution

A record that cannot be independently checked is limited.

Verification is what makes it useful.

Why This Is Not Just Another Dashboard
A dashboard is built for operators.

It is:

internal

tied to a specific system

optimized for monitoring

A verification surface is different.

It is:

independent

portable

usable by third parties

designed for validation

This represents a shift.

From: “We tell you what happened” To: “You can verify it yourself”

Why This Matters for AI Systems
As AI systems become more complex and more autonomous, verification becomes critical.

This is especially true for:

agent execution

multi-step workflows

compliance-sensitive systems

financial and operational decisions

In these environments, trust cannot rely on internal systems alone.

It must be supported by independent verification.

A New Standard for AI Infrastructure
Verification is becoming a core layer in AI infrastructure.

The stack is evolving to include:

model providers

orchestration frameworks

observability tools

governance systems

execution verification infrastructure

This layer ensures that:

execution records are trustworthy

verification is independent

auditability is possible

verify.nexart.io is part of that layer.

The Core Idea
Producing a record is not enough.

That record must also have a place where it can be independently checked.

That is what verify.nexart.io provides.

Final Thought
AI systems are becoming more powerful.

But power without verification creates risk.

If systems are going to be trusted, they must be open to inspection.

Not through dashboards.

Not through logs.

But through verifiable artifacts that anyone can check.

verify.nexart.io is a step toward that model.

Try It
https://verify.nexart.io

https://docs.nexart.io

https://nexart.io

AI Auditability and the EU AI Act: Why Execution Evidence Matters

Jb — Tue, 24 Mar 2026 09:54:46 +0000

AI systems are moving from experimentation into regulated environments.

They are now used to:

evaluate financial transactions
support compliance decisions
automate internal workflows
assist in hiring and lending
operate as agents across multiple systems
As this shift happens, one requirement is becoming unavoidable:

AI systems must be auditable.

The EU AI Act makes this expectation explicit.

But there is a problem.

Most AI systems today are not built to support real auditability.

Definition: AI Auditability
AI auditability is the ability to reconstruct, inspect, and validate how an AI system produced a decision, including inputs, parameters, context, and outputs.

Auditability is not just about visibility.

It requires verifiable execution evidence.

What the EU AI Act Requires in Practice
The EU AI Act does not prescribe a single technical architecture.

But it establishes clear expectations, especially for high-risk AI systems.

These expectations include:

Traceability
Systems must allow reconstruction of decisions and behaviors.

Record-Keeping
Organizations must maintain records of system operation over time.

Transparency
Outputs and decision processes must be explainable and reviewable.

Accountability
Organizations must be able to justify and defend system outcomes.

At a practical level, the regulation is asking:

Can this system’s decisions be reconstructed, understood, and validated after the fact?

The Reality: Most AI Systems Cannot Do This
In theory, many teams believe they are covered.

They have:

logs
tracing systems
monitoring dashboards
database records
But these tools were not designed for auditability.

They were designed for observability.

Why Logs and Traces Are Not Enough
There is a common assumption:

“If we log everything, we can reconstruct anything.”

In practice, this breaks down quickly.

AI execution is often:

distributed across services
dependent on external APIs
dynamically constructed at runtime
influenced by context signals
composed of multiple steps
This leads to:

fragmented data
incomplete records
difficult correlation
platform dependency
mutable history
When a decision is questioned months later, teams often cannot produce a single, reliable record of what actually happened.

Visibility vs Auditability
This is the core distinction.

Visibility answers:

What can we observe while the system runs?

Auditability answers:

Can we prove what actually happened?

To meet EU AI Act expectations, systems must go beyond visibility.

They need execution integrity.

Definition: Execution Integrity
Execution integrity means that an AI system can produce a complete, tamper-evident, and verifiable record of what actually ran.

This includes:

inputs
parameters
runtime environment
context signals
outputs
And critically:

proof that the record has not been altered
The Missing Piece: Execution Evidence
Execution evidence is what makes auditability real.

Instead of reconstructing events from logs, the system produces a structured record during execution.

This record becomes:

a source of truth
a verifiable artifact
a unit of audit
This changes the model:

Traditional systems

Execution → Logs → Reconstruction

Verifiable systems

Execution → Evidence → Verification

Certified Execution Records (CERs)
Certified Execution Records provide a concrete implementation of execution evidence.

Definition: Certified Execution Record (CER)
A Certified Execution Record is a tamper-evident, cryptographically verifiable artifact that captures the full context of an AI execution, including inputs, parameters, runtime conditions, and outputs.

Become a Medium member
A CER includes:

inputs and parameters
execution context and signals
runtime fingerprint
output hash
certificate identity
Because these elements are bound together, CERs provide:

execution integrity
auditability
independent verification
long-term traceability
How Execution Evidence Maps to EU AI Act Requirements
Execution evidence directly supports regulatory expectations.

Here is a simple mapping:

Traceability
Execution evidence provides structured records of inputs, context, and outputs.

Record-Keeping
Certified Execution Records act as persistent, tamper-evident records of system activity.

Transparency
Execution records can be inspected and reviewed after the fact.

Accountability
Execution evidence allows organizations to prove what happened and defend decisions.

This is not about adding more logs.

It is about changing how execution is recorded.

Tamper-Evident Records and Attestation
Two technical properties are essential for auditability.

Tamper-Evident Records
Execution records are cryptographically protected.

This ensures:

any modification is detectable
records remain trustworthy
integrity can be validated independently
Attestation
Attestation adds a layer of verifiable origin.

It allows a system to:

sign an execution record
prove where it was generated
enable third-party validation
Together, these properties provide a foundation for trustworthy AI systems.

Why This Matters for High-Risk AI Systems
The EU AI Act places stronger requirements on high-risk systems.

These include systems used in:

finance
healthcare
employment
law enforcement
critical infrastructure
In these environments, organizations must:

reconstruct decisions
explain outcomes
provide evidence
support audits and investigations
Logs alone are not sufficient.

Execution evidence becomes necessary.

AI Agents Make Auditability Harder
Modern AI systems are evolving into agent-based systems.

Agent execution often includes:

multi-step reasoning
tool usage
external data retrieval
dynamic decision-making
state changes across systems
This creates complex execution chains.

Without structured evidence, these chains are difficult to:

reconstruct
validate
audit
Execution evidence allows these workflows to be captured as verifiable records.

A New Layer in AI Infrastructure
Auditability is no longer just a compliance feature.

It is becoming a core infrastructure layer.

The modern AI stack now includes:

model providers
orchestration frameworks
observability tools
governance systems
execution verification infrastructure
This layer is responsible for:

producing execution evidence
ensuring execution integrity
enabling independent verification
supporting auditability
This is where platforms like NexArt operate.

What This Means for Builders and Enterprises
If you are building or deploying AI systems, you should ask:

Can we produce a verifiable record of each execution?
Can we prove that records have not been altered?
Can we support audits without relying on internal logs?
Can we provide evidence months or years later?
If the answer is no, auditability is incomplete.

Execution evidence fills that gap.

Final Thought
The EU AI Act does not require a specific technology.

But it requires something more fundamental:

the ability to trust AI systems.

That trust is not built on logs.

It is built on evidence.

As AI systems become more regulated and more critical, the standard shifts from:

“Can we observe the system?” to: “Can we prove what it did?”

That is the foundation of AI auditability.

Learn More
https://nexart.io
https://docs.nexart.io
https://verify.nexart.io

Verifiable AI Execution vs zkML: What NexArt Proves, What It Doesn’t, and How Privacy Works in Practice

Jb — Mon, 23 Mar 2026 15:22:46 +0000

AI systems are becoming more powerful, more autonomous, and more integrated into real-world workflows.

At the same time, a new phrase is appearing everywhere: verifiable AI

But that phrase is used to describe very different things.

Sometimes it refers to:

proving that a model ran
proving that a record was not altered
proving that a computation is correct
proving something without revealing data
proving compliance or auditability
These are not the same problem.

And they are not solved by the same infrastructure.

This is where confusion starts.

This article clarifies the distinction between verifiable AI execution and zkML, explains what NexArt actually proves, and outlines the privacy model NexArt supports today.

The Confusion Around Verifiable AI
The term “verifiable AI” is often used as a catch-all.

But in practice, it covers at least two distinct categories:

execution evidence systems
computation proof systems
NexArt and zkML sit in different parts of this landscape.

Understanding that difference is critical.

What NexArt Actually Does
NexArt focuses on verifiable execution records.

It produces Certified Execution Records (CERs), which are:

cryptographically sealed execution artifacts
structured records of inputs, outputs, parameters, and context
tamper-evident and independently verifiable
optionally signed through attestation
These records are designed to capture AI execution evidence.

Definition: Certified Execution Record (CER)
A Certified Execution Record is a tamper-evident, cryptographically verifiable artifact that captures the essential facts of an AI execution, including inputs, parameters, runtime context, and outputs, in a form that can be independently validated later.

What a Certified Execution Record Proves
A CER allows a system to prove:

that an execution record has not been modified
what inputs and parameters were recorded
what output was produced
what execution context existed
the integrity and chain of custody of the record
This provides execution integrity and supports AI auditability.

What NexArt Does Not Prove
It is important to be precise.

NexArt does not:

guarantee LLM determinism
prove that an output is correct
prove hidden computation correctness
provide zero-knowledge privacy by default
NexArt is not trying to prove that a computation is correct.

It is proving that a record of execution is authentic, tamper-evident, and intact.

What zkML Proves Instead
zkML, or zero-knowledge machine learning, focuses on a different problem.

It aims to prove that:

a specific computation was executed correctly
a model produced a result according to a defined circuit
certain properties hold without revealing underlying data
This often involves:

zero-knowledge proofs
cryptographic circuits
privacy-preserving computation
Definition: zkML
zkML refers to techniques that use zero-knowledge proofs to verify that a machine learning computation was performed correctly, often without revealing the underlying data or model details.

zkML Is About Computation, Not Execution Records
This is the key distinction:

zkML is computation-proof infrastructure.

NexArt is execution-evidence infrastructure.

zkML answers:

Can we prove this computation is correct?

NexArt answers:

Can we prove what actually ran?

These are different trust problems.

Transparent Evidence vs Private Proofs
These two approaches represent different trust models.

NexArt
Transparent by default.

designed for auditability
supports debugging and investigation
captures full execution context
produces tamper-evident execution records
Best suited for:

enterprise AI workflows
governance and compliance
agent execution tracking
incident analysis
zkML
Private proof by design.

proves correctness without revealing full data
supports confidential computation
minimizes information disclosure
Best suited for:

privacy-sensitive environments
on-chain verification
hidden model or data scenarios
These models are not mutually exclusive.

They can be combined.

Privacy in NexArt: The Levels That Exist Today
NexArt is transparent by default, but supports selective privacy through structured mechanisms.

Here is a practical privacy ladder.

Privacy Level 1 — Full Transparency
The execution record contains the full data.

Best for:

internal systems
debugging
full audit visibility
Trade-off:

maximum auditability
minimal confidentiality
Privacy Level 2 — Verifiable Redaction
Sensitive fields are removed, but the resulting record remains verifiable.

Become a Medium member
Best for:

external sharing
customer-facing verification
controlled disclosure
Trade-off:

protects sensitive data
the redacted artifact becomes the new verifiable record
Privacy Level 3 — Hash-Based Evidence
Sensitive values are represented as hashes or envelopes.

This allows later proof without revealing the data immediately.

Best for:

selective disclosure
proving a value existed
partial confidentiality
Trade-off:

preserves integrity
does not provide full privacy guarantees
Privacy Level 4 — External Evidence Reference
Sensitive data remains outside the CER, referenced through hashes or metadata.

Best for:

enterprise-controlled environments
restricted access systems
compliance workflows
Trade-off:

stronger operational privacy
depends on external systems for full verification
Key principle

NexArt is transparent by default, but selective privacy can be applied without breaking execution integrity.

What NexArt Privacy Is Not
To avoid confusion, it is important to be explicit.

NexArt privacy is not:

zero-knowledge proof of computation correctness
full confidential inference
hidden-model verification
zk-style privacy without zk complexity
NexArt’s privacy model is based on:

selective redaction
integrity preservation
structured execution evidence
It does not attempt to replace zero-knowledge systems.

Why Execution Evidence Still Matters
Many real-world AI systems need:

tamper-evident execution records
auditability and governance evidence
structured context around decisions
signed execution artifacts
independently verifiable records
These needs exist even without privacy-preserving computation proofs.

This is especially important in:

enterprise AI systems
agent execution workflows
governance pipelines
incident investigations
regulatory reporting
Execution evidence is often the first requirement.

Where This Fits in AI Regulation (EU AI Act and Beyond)
Regulation is increasing the demand for verifiable AI systems.

Frameworks like the EU AI Act emphasize:

traceability of decisions
documentation of system behavior
auditability of AI workflows
accountability in high-risk systems
These requirements do not necessarily mandate zero-knowledge proofs.

In many cases, they require something more practical:

structured execution records
tamper-evident execution evidence
the ability to reconstruct and review decisions
This is where verifiable AI execution becomes relevant.

Systems like NexArt support:

AI auditability
governance workflows
compliance documentation
without requiring full computation-proof infrastructure.

Where NexArt and zkML Can Work Together
These systems can be complementary.

A practical architecture could look like:

NexArt records execution context, inputs, outputs, and provenance
zkML proves correctness of specific sensitive computations
together, they provide both:
auditability
privacy where needed
For most systems today:

execution evidence is the practical starting point
computation proofs can be added selectively
What This Means for Builders
If you are building AI systems, ask:

Do you need tamper-evident execution records?
Do you need auditability and governance evidence?
Do you need to track agent execution and decisions?
Do you need selective privacy for certain fields?
Do you truly need zero-knowledge computation proofs?
In many cases:

NexArt provides the execution evidence layer
zkML or similar systems may be added for specific use cases
Conclusion
Verifiable AI execution is not the same as zero-knowledge AI proofs.

NexArt is built for execution evidence:

tamper-evident execution records
attestation
auditability
execution integrity
This is different from proving hidden computation correctness.

Both categories matter.

But they solve different problems.

Not every trust problem in AI is a zero-knowledge problem.

Many are execution-evidence problems first.

Learn More
https://nexart.io
https://docs.nexart.io
https://verify.nexart.io

AI Audit Trails vs Verifiable Execution

Jb — Mon, 23 Mar 2026 09:15:01 +0000

AI systems are increasingly expected to be auditable.
They make decisions, trigger workflows, call external tools, and interact with systems where outcomes matter.
As a result, most teams implement audit trails.
But there is a growing gap between what audit trails provide and what modern AI systems actually require.
That gap is the difference between tracking behavior and proving execution.
This article explores that gap, and why verifiable execution is emerging as a new foundation for AI auditability and execution integrity.
Definition: AI Audit Trail
An AI audit trail is a record of events, actions, or decisions generated by a system, typically captured through logs, traces, or monitoring tools.
Audit trails are designed to answer:
What did the system report happened?
They are essential for visibility.
But visibility is not the same as proof.
Why Audit Trails Exist
Audit trails play an important role in modern systems.
They help teams:
understand system behavior
debug issues
track decisions over time
provide operational visibility
support baseline compliance requirements

In many traditional applications, this level of tracking is sufficient.
But AI systems are different.
The Limitation of Audit Trails
Audit trails are built on logs.
Logs were not designed to serve as durable evidence.
This introduces several structural limitations:
records may be incomplete
data is fragmented across systems
logs depend on the originating platform
records can be modified or overwritten
correlation across services is difficult

Even when logs are comprehensive, they rarely form a single, coherent record of AI execution.
More importantly:
They cannot be independently verified without trusting the system that produced them.
Visibility vs Auditability
A common misunderstanding is that visibility equals auditability.
It does not.
Visibility answers:
What can we observe about the system?
Auditability requires answering:
Can we validate what actually happened?
To achieve real auditability, systems need execution integrity.
Definition: Execution Integrity
Execution integrity means that a system can provide reliable, tamper-evident evidence of what actually ran, including inputs, parameters, runtime conditions, and outputs.
It ensures that:
execution records are complete
records cannot be silently modified
results can be validated independently

This is where audit trails fall short.
What Verifiable Execution Means
Verifiable execution introduces a stronger model for AI execution.
Instead of relying on logs, the system produces a structured artifact that represents the execution itself.
This artifact is:
complete
portable
tamper-evident
independently verifiable

It allows teams to answer a different question:
Can we prove what actually ran?
Audit Trails vs Verifiable Execution
The difference becomes clearer when comparing their purpose.
Audit Trails
track events and system activity
provide visibility into workflows
depend on internal logs
are difficult to validate independently
are not designed as long-term evidence

Verifiable Execution
captures execution as a structured artifact
produces tamper-evident records
enables independent verification
supports portability across systems
is designed for long-term auditability

Audit trails help you observe.
Verifiable execution helps you prove.
Why AI Systems Break Traditional Audit Models
AI systems introduce characteristics that traditional audit models were not designed for:
dynamic prompt construction
probabilistic model behavior
multi-step workflows
tool usage and external API calls
distributed execution across services
evolving context signals during runtime

This makes execution harder to reconstruct after the fact.
Even if every component logs its activity, the full execution may not exist as a single, verifiable record.
Tamper-Evident Records and Attestation
Verifiable execution relies on stronger primitives than logs.
Tamper-Evident Records
Execution data is cryptographically bound so that any modification breaks the record.
This ensures:
integrity can be validated
changes cannot be hidden
records remain trustworthy over time

Attestation
Attestation adds an additional layer of trust.
It allows a system to:
sign an execution record
prove that it originated from a specific environment
enable third parties to validate authenticity

Together, these mechanisms provide a foundation for execution integrity.
The Role of Certified Execution Records (CERs)
Certified Execution Records (CERs) provide a practical implementation of verifiable execution.
A CER captures the full context of an AI execution in a structured, cryptographically verifiable format.
It includes:
inputs and parameters
runtime fingerprint
execution context
output hash
certificate identity

Because these elements are bound together, CERs provide:
tamper-evident records
execution integrity
auditability
independent verification

CERs turn execution into evidence.
The Execution Verification Layer
A new layer is emerging in AI infrastructure.
You can think of the modern AI stack as:
model providers
orchestration frameworks
observability systems
governance tools
execution verification infrastructure

This execution verification layer is responsible for:
producing verifiable execution artifacts
enabling independent validation
supporting long-term auditability
ensuring execution integrity

This is where concepts like CERs, attestation, and deterministic execution come together.
Why This Matters Now
AI systems are being deployed in environments where:
decisions have financial impact
workflows affect compliance
systems act autonomously
outputs may be disputed

In these environments, teams need more than logs.
They need:
auditability
execution integrity
verifiable execution

They need to be able to say:
This is what happened, and we can prove it.
A Shift in Standards
The standard for AI systems is evolving.
From:
"We can track what happened"
to:
"We can prove what happened"
Audit trails are not going away.
But they are no longer sufficient on their own.
They need to be complemented by verifiable execution.
Final Thought
Audit trails provide visibility.
Verifiable execution provides proof.
As AI systems become more complex and more embedded in real-world decisions, proof becomes the more important requirement.
The systems that can produce tamper-evident, verifiable records of AI execution will define the next generation of trustworthy infrastructure.
Learn More
https://nexart.io
https://docs.nexart.io
https://verify.nexart.io

Execution Drift in AI Systems (and Why It Matters More Than You Think)

Jb — Fri, 20 Mar 2026 09:45:31 +0000

AI systems are often assumed to be stable.

If the code does not change, the system should behave the same way.

In practice, that assumption breaks down quickly.

Two executions with the same inputs can produce different results.

This is not always a bug.

It is a property of modern AI systems.

Definition: Execution Drift
Execution drift is the phenomenon where identical inputs produce different outputs over time due to changes in environment, dependencies, models, or execution conditions.

It is one of the most under-discussed challenges in AI systems today.

Why Execution Drift Happens
Even when a system appears unchanged, several factors can cause outputs to shift:

dependency updates
runtime version differences
model updates or fine-tuning
prompt or orchestration changes
environment configuration differences
non deterministic execution paths
These changes are often subtle and may not be visible in logs.

But they affect results.

A Simple Example
A workflow runs today and produces a result.

The same workflow runs next week with the same input.

The output is different.

Nothing obvious changed.

But under the surface:

a model version updated
a dependency changed
a parameter default shifted
a runtime environment evolved
From the outside, the system looks the same.

From the inside, it is not.

Why This Becomes a Problem
Execution drift makes systems harder to reason about.

It impacts:

reproducibility
debugging
auditing
benchmarking
compliance
If a system cannot reliably reproduce or explain its outputs, it becomes harder to:

defend decisions
investigate issues
certify behavior
maintain long-term trust
This is not just a technical issue.

It becomes an operational and governance problem.

Why Logs Do Not Solve Drift
A common assumption is that logs can help reconstruct what happened.

In reality, logs are not enough.

Logs:

do not capture full execution state
are fragmented across services
may miss environment details
are difficult to correlate
are not designed for verification
Even with detailed logs, drift can remain invisible.

You may see what happened.

You cannot always prove why it happened.

Drift vs Reproducibility
Execution drift is closely related to reproducibility.

But they are not the same.

Reproducibility asks:

Can we run this again and get the same result?

Execution drift shows:

We often cannot.

And more importantly:

We may not know why.

The Role of Determinism
One way to reduce drift is to introduce determinism.

Learn about Medium’s values
Deterministic systems aim to produce the same output given the same inputs and conditions.

This can involve:

fixed seeds
controlled environments
versioned dependencies
stable execution pipelines
However, full determinism is not always possible in AI systems.

Especially when models are probabilistic.

Why Determinism Alone Is Not Enough
Even with deterministic practices, systems still need to answer a different question:

What actually ran?

Determinism helps with predictability.

It does not guarantee that past executions can be verified later.

This is where another layer becomes important.

From Drift to Verifiable Execution
Instead of trying to eliminate drift entirely, systems can focus on making execution visible and provable.

This means capturing:

inputs
parameters
runtime fingerprint
execution context
outputs
as a single structured record.

This record becomes an artifact of the execution.

Certified Execution Records and Drift
Certified Execution Records (CERs) help address execution drift by capturing what actually happened during a run.

A CER allows teams to:

verify a specific execution
compare executions over time
understand why outputs differ
detect drift explicitly
Even if outputs change, the system can show:

this is what ran

this is what changed

That is a stronger position than relying on logs alone.

Why This Matters Now
Execution drift was manageable when systems were simple.

Teams could rerun workflows, inspect logs, and move on.

But AI systems are now:

more complex
more distributed
more autonomous
more integrated into critical workflows
Drift is no longer an edge case.

It is a default condition.

A Shift in Thinking
Instead of asking:

“How do we prevent drift entirely?”

A more practical question is:

“How do we make drift visible, explainable, and verifiable?”

That shift changes how systems are designed.

It moves focus from:

perfect stability

verifiable execution

Final Thought
Execution drift is not a bug.

It is a property of modern AI systems.

The real challenge is not eliminating drift.

It is understanding it, capturing it, and proving what actually happened.

Systems that can do that will be easier to:

trust
audit
scale
integrate into real-world environments
And that is where verifiable execution becomes essential.

Learn More
https://nexart.io
https://docs.nexart.io
https://verify.nexart.io

DEV Community: Jb

Demonstrable, Not Documented: What Regulators Are Actually Asking For, and What It Takes to Answer

Different regimes, similar direction

The EU AI Act: record the system, then make oversight real

NIST: traceability has to survive beyond the engineering team

ISO/IEC 42001: evidence that a management system is operating

SM&CR: accountability still has a name attached to it

The United States: existing law can create the same evidence problem

The structural gap in today's evidence

Agents make reconstruction harder

What would a record need to survive challenge?

1. Tamper-evidence over a defined protected set

2. Independent verifiability

3. An independent assertion of time

4. Portability

5. Privacy

Why a common specification matters

AIEF: define the evidence requirements before defining the vendor

One implementation: NexArt

The cryptography is ordinary on purpose

External time evidence

Confidential execution without putting raw input and output into the proof record

Check the evidence yourself

Documented compliance and demonstrable compliance are different things

Further reading and primary sources

The open framework

NexArt implementation

Regulatory and standards sources

NexArt adds external DigiCert timestamping and a confidential mode

How to Verify an AI Execution Record Without Trusting the Provider

What I actually want from an AI evidence layer (and why I built NexArt)

So what is NexArt, in one paragraph

What it does not do

Why this matters now

How it works

Quick implementation

1. Install the SDK

2. Set two environment variables

3. Wrap an execution

4. Run it

Offline mode, when you don't want a network call

Multi-step workflows: Project Bundles

The point of independent verification

A few pitfalls worth mentioning

Where to dig in next

One last thought

How NexArt Protects AI Execution Evidence From Tampering

How to Add Verifiable Execution to LangChain and n8n Workflows (with NexArt)

How to Add Verifiable Execution to an AI Agent in Under 30 Minutes

Why We Built verify.nexart.io

AI Auditability and the EU AI Act: Why Execution Evidence Matters

Verifiable AI Execution vs zkML: What NexArt Proves, What It Doesn’t, and How Privacy Works in Practice

AI Audit Trails vs Verifiable Execution

Execution Drift in AI Systems (and Why It Matters More Than You Think)