Standardized AI Evidence Shouldn't Require Standardized JSON

Introducing NexArt Evidence Bridge. Standardized evidence should not require standardized operational JSON.

Every company records AI execution differently.

One application calls an execution runId. Another calls it execution.id.

One stores the requested model beside the event. Another puts it in metadata. Inputs may live in an observability platform. Outputs may live in an application database. Governance decisions may sit in a separate service entirely.

That is normal.

Operational systems should use schemas that make sense for the applications running them.

The problem appears when those companies want to turn what they already record into portable, verifiable execution evidence.

The obvious approach is to ask every application to adopt a new evidence schema. We think that is the wrong abstraction.

Standardized evidence should not require standardized operational JSON.

That is why we built NexArt Evidence Bridge.

Evidence Bridge creates a controlled boundary between the JSON an application already produces and the structured execution evidence NexArt can protect and verify.

The application keeps speaking its own language. Bridge defines how that language maps into evidence.

The integration problem behind execution evidence

Most production AI applications already capture useful information about what they do.

A typical event might contain:

• a workflow or transaction identifier
• a timestamp
• the provider and model requested
• input
• output
• model parameters
• tool activity
• a governance decision
• a human approval
• a downstream action

But there is no universal operational schema for representing those things.

One system might produce:

{
  "runId": "run_456",
  "createdAt": "2026-09-08T12:30:00.000Z",
  "provider": "openai",
  "requestedModel": "gpt-4o-mini",
  "prompt": "Summarize the incident report.",
  "result": "Service recovered after cache invalidation."
}

Another might represent essentially the same execution like this:

{
  "execution": {
    "id": "run_456",
    "occurredAt": "2026-09-08T12:30:00.000Z",
    "requested": {
      "provider": "openai",
      "model": "gpt-4o-mini",
      "role": "advisory"
    },
    "input": {
      "prompt": "Summarize the incident report."
    },
    "output": {
      "summary": "Service recovered after cache invalidation."
    }
  }
}

A third company may split those values across traces, database records and governance systems.

All three could be describing similar activity. Their schemas are completely different.

That becomes an adoption problem when the organisation wants to create a consistent evidence artifact.

• Should every service be rewritten?
• Should existing event contracts change?
• Should downstream consumers migrate?
• Should every engineering team learn how to construct a Certified Execution Record?

For a new application, that may be reasonable. For an established enterprise system, it often is not.

Existing JSON contracts may already feed:

• analytics
• monitoring
• data warehouses
• security controls
• customer integrations
• partner APIs
• audit processes
• retention systems
• internal governance tooling

Changing one event schema can therefore affect far more than the AI integration itself.

Evidence infrastructure is unlikely to achieve broad adoption if the first requirement is: rewrite the systems you already run.

Bridge is intended to remove that requirement.

What is NexArt Evidence Bridge?

NexArt Evidence Bridge is a managed transformation and evidence-ingestion layer.

Its job is to separate the format the source application uses from the format needed to produce structured execution evidence.

Conceptually:

Existing application JSON
        ↓
Published mapping profile revision
        ↓
Normalized evidence semantics
        ↓
Evidence eligibility
        ↓
Certified Execution Record
        ↓
Local integrity verification
        ↓
Stored result
        ↓
Optional NexArt Node attestation

The source application continues to emit its existing event.

A mapping profile tells Bridge how to interpret that event.

Bridge can then determine whether the event contains enough information to create the selected NexArt evidence artifact. When it does, Bridge creates the record and verifies its local integrity. Node attestation remains a separate step.

A simple way to describe it is:

Keep your existing event schema. Bridge turns it into structured NexArt execution evidence through an explicit, versioned and reviewable mapping.

No schema rewrite does not mean no integration

There is an important distinction here. Bridge does not make integration disappear.

The application still needs to send its event to Bridge. It still needs to authenticate. It still needs to identify the relevant published mapping profile. Production integrations also need normal concerns such as idempotency, retry handling and error processing.

What Bridge removes is a different category of work.

The application does not need to redesign its own JSON so it looks like a NexArt evidence artifact. It does not need to implement the evidence semantics independently in every service.

Bridge can own concerns such as:

• mapping source fields into evidence semantics
• evidence-target eligibility
• CER construction
• canonicalization
• certificate-hash generation
• local CER verification
• mapping revision management
• transformation-origin reporting

The value is not zero integration. The value is a narrow ingestion integration instead of a source-schema migration and custom evidence implementation.

For an enterprise evaluating adoption cost, that difference matters.

A mapping profile defines meaning, not just field names

Mapping JSON is easy. Mapping meaning is harder.

Consider this source event:

{
  "job": {
    "job_id": "incident-summary-9842",
    "finished_at": "2026-09-08T12:30:00.000Z"
  },
  "llm": {
    "vendor": "openai",
    "requested_model": "gpt-4o-mini",
    "temperature": 0.2
  },
  "request": {
    "incident_report": "API latency increased after a cache deployment."
  },
  "response": {
    "summary": "The cache deployment caused elevated API latency."
  }
}

Bridge might interpret that using mappings such as:

/job/job_id           → source.eventId
/job/finished_at      → source.occurredAt
/llm/vendor           → metadata.ai.provider
/llm/requested_model  → metadata.ai.model
/request              → execution.input
/response             → execution.output

It might also define a constant:

"advisory"            → metadata.ai.executionRole

That last mapping is important. It is not simply renaming a field. It is making a semantic statement about the execution. And semantics cannot always be inferred safely from property names.

A field named model, for example, might mean:

• the model requested by the application
• the model declared in a provider response
• an internal routing alias
• a model family
• a fine-tuned deployment
• a fallback model

Those concepts may be related. They are not interchangeable.

Bridge can help suggest mappings, but important mappings should be reviewed by someone who understands the source system.

The objective is not to make every payload eligible. The objective is to represent what the source event genuinely supports.

The Origin Trace: show where the evidence came from

A normalized record tells you what Bridge produced. That is only half the story.

A reviewer may also need to know: why does this field have this value?

That is the role of the Origin Trace. For each mapped value, Bridge can preserve information such as:

• the destination field
• the source JSON path
• whether the value came from a constant
• which transformation was applied
• whether the mapping was required
• whether the mapping succeeded

For example:

Destination: metadata.ai.provider
Origin:      /llm/vendor
Transform:   string
Result:      "openai"

Destination: metadata.ai.executionRole
Origin:      constant
Result:      "advisory"

Why does this matter?

Imagine a reviewer sees executionRole = advisory. Without the Origin Trace, that person may not know whether advisory:

• came directly from the application's event
• came from a profile constant
• was normalized from another source value
• was inferred by software

Those are materially different statements. A normalized event can otherwise hide the assumptions that produced it.

The evidence record shows the resulting claim. The Origin Trace shows how Bridge arrived at that claim. That makes the transformation itself inspectable.

Why published mapping revisions are immutable

The mapping used to interpret an event is part of its history. That means it cannot quietly change later.

Suppose version 1 of a profile interprets /result → execution.output.

Six months later, the application's architecture changes. The correct source becomes /reviewedResult → execution.output.

If Bridge simply edits the original profile in place, historical evidence referencing that profile would now point to a mapping whose meaning had changed. The evidence artifact might not have changed. But the explanation of how it was derived would have.

That is not a good evidence model.

Bridge therefore treats published profile revisions as immutable. A changed mapping creates a new revision. Historical transformation results remain tied to the exact revision that processed them.

A result can therefore retain information such as:

• profile ID
• profile revision
• profile hash
• source digests
• normalized event
• evidence result

Switching the active revision changes future ingestion. It does not rewrite history. This creates a stable relationship between the source event and the rules used to interpret it.

A valid transformation does not automatically mean sufficient evidence

This is one of the most important distinctions in Bridge. Bridge asks two different questions.

1. Can this event be mapped?

This is mapping validity. A mapping may fail because:

• a required path is missing
• a timestamp cannot be parsed
• a number conversion fails
• a configured transformation is incompatible with the source value
• a required rule produces no value

That is primarily a transformation question.

2. Does this event contain enough information for the selected evidence target?

This is evidence eligibility. An event can map perfectly and still be insufficient to create a particular Certified Execution Record.

For example, an event might include input, output and an execution ID, but no requested model or execution role required by the selected AI Execution V2 representation.

Bridge should not invent those values simply so the event becomes eligible. Instead, the result can be explicit:

Mapping:         VALID
Evidence target: AI Execution V2
Eligibility:     NOT ELIGIBLE

Missing semantics:
- metadata.ai.model
- metadata.ai.executionRole

CER created:     NO

NOT ELIGIBLE is not necessarily an error. It can simply mean: this source event does not contain enough evidence to support this target truthfully.

That distinction is deliberate. Bridge should not upgrade incomplete telemetry into stronger claims than the source supports.

When the event is eligible

When the required semantics are present, Bridge can create the relevant Certified Execution Record. For AI Execution V2, that can include protected evidence relating to areas such as:

• execution identity
• timing
• requested provider and model
• input
• output
• parameters
• execution role
• supported governance references
• execution context

NexArt then creates the cryptographic identity of the evidence artifact. The protected content is canonicalized under the applicable protocol and the resulting certificate hash identifies that artifact. Bridge performs local verification against the record it created.

The trust state can therefore distinguish:

Mapping:              VALID
Evidence eligibility: ELIGIBLE
CER created:          YES
Local integrity:      VERIFIED
Node attestation:     NOT ATTEMPTED
External timestamp:   NOT ATTEMPTED

That is intentionally more specific than one generic green badge. Different checks establish different things. They should remain visible as different things.

What local integrity verification actually establishes

This distinction matters enough to state plainly.

A successful integrity check can establish that the protected record is consistent with its cryptographic identity. In practical terms, it can help answer: has the protected artifact changed relative to the certificate hash that identifies it?

That is useful. It is not the same as proving that everything inside the record is true.

Suppose the source application records the wrong model name. Bridge can map that model name accurately. The resulting CER can be perfectly well formed. Its certificate hash can verify correctly. The record can remain completely unchanged. It would still contain the wrong model claim.

Cryptography protects the claim. It does not turn the claim into truth.

Likewise, the resulting evidence does not automatically establish that:

• the declared provider received the request
• the declared model actually served it
• every relevant tool call was captured
• the output was generated exactly as described
• the execution was authorized
• the output was correct
• a governance decision was legally sufficient
• no related event was omitted

This is a core NexArt trust boundary. A CER is a tamper-evident record of captured execution claims. It is not a magic proof that every statement made by the producer was true.

A well-formed CER created from poor source data is still poor evidence. The quality of the final artifact depends on the quality of the capture boundary and the accuracy of the mapping profile.

Local evidence and Node attestation are separate

Bridge does not need to pretend every record has been externally attested.

The normal ingestion flow can stop after:

JSON → mapping → evidence eligibility → CER → local verification → stored result

If the organisation wants an additional attestation layer, the stored CER can separately be submitted to a NexArt Node. The important point is that the artifact already exists. Its certificate hash already exists. The Node does not need to invent a replacement evidence record simply in order to attest it.

For caller-produced AI Execution V2 records, the current NexArt Node verifies the submitted bundle under the applicable SDK contract, preserves the supplied certificate identity, and can add an Ed25519-signed receipt and verification envelope.

Stored CER
    ↓
NexArt Node
    ↓
Artifact verification
    ↓
Signed attestation
    ↓
Public trust material

That means an organisation can choose different evidence policies. For example:

• create locally verifiable records for a broad set of workflows
• request Node attestation only for higher-impact executions
• attest after a human review
• keep selected evidence entirely internal
• apply different evidence requirements in different environments

The status should always tell the reviewer what actually happened. Local verification should not be presented as Node attestation. Node attestation should not be presented as external timestamping. And no cryptographic status should be presented as proof that the underlying business decision was correct.

Bridge and direct SDK integration solve different problems

Evidence Bridge does not replace direct SDK integration.

If you are building a new high-assurance AI system and control the actual execution boundary, using the NexArt SDK directly may be the stronger architecture. You can capture the evidence at the exact point where:

• the provider is called
• a tool executes
• an agent takes an action
• a governance decision is produced

That gives the application precise control over the evidence boundary.

Bridge addresses another common situation: the execution data already exists. The schema already exists. Other systems already consume it. Changing it creates migration cost.

In that environment, Bridge lets the organisation define a controlled semantic translation without forcing the operational event contract itself to become an evidence schema.

The two approaches can coexist. An enterprise might use:

• direct SDK integration for a new agent platform
• Bridge for older AI applications
• Bridge for partner payloads
• direct capture for selected high-assurance workflows

The right choice depends on the system boundary and the assurance required. Bridge is not intended to make direct instrumentation obsolete. It is intended to make verifiable execution evidence adoptable in places where source-schema migration would otherwise become the blocker.

What Bridge should not become

There is a temptation with any normalization layer to make the output look more complete than the input. Bridge should resist that. It should not be used to:

• invent missing model information
• reconstruct executions that were never captured
• describe normal software activity as AI execution without supporting evidence
• turn a governance PASS into a claim of legal compliance
• imply Node attestation where only local verification occurred
• claim complete execution coverage without another basis for that claim
• hide mapping assumptions from later reviewers

The objective is not to produce the strongest-looking record possible. The objective is to produce the strongest record the source evidence actually supports. That is a very different design philosophy.

Privacy is part of the evidence problem

Execution evidence can be highly sensitive. It may contain:

• personal data
• customer information
• proprietary documents
• security incidents
• financial information
• internal instructions
• operational identifiers
• governance decisions

An integrity layer cannot ignore that. And hashing should not be confused with anonymization.

A digest does not automatically make low-entropy or guessable information private. Access control, retention, encryption and data-handling policies remain separate responsibilities.

NexArt also supports confidential evidence mechanisms where selected values can be represented through commitments rather than exposed as plaintext in the evidence artifact.

But the principle remains the same: evidence integrity and data protection are complementary requirements. One does not replace the other.

The important product is not the JSON conversion

It would be easy to describe Evidence Bridge as a JSON transformation product. That misses the point. Converting one JSON document into another is not particularly difficult.

The more important problem is preserving the meaning and history of the transformation. Months later, can a reviewer determine:

• what source event was processed?
• which profile revision interpreted it?
• where did an important evidence field come from?
• what transformation was applied?
• was the value copied, normalized or supplied as a constant?
• did the event contain enough semantics for the selected evidence target?
• was a CER actually created?
• which information was protected?
• did local integrity verification pass?
• was Node attestation requested?
• what still depends on the producer's claims?

Those questions make the transformation part of the evidence lifecycle rather than invisible middleware. That becomes useful during incident investigation, customer disputes, internal audits, vendor reviews, AI governance assessments, model migrations, policy changes, postmortems and regulatory inquiries.

The goal is not to answer every governance question automatically. The goal is to leave the people answering those questions with a clearer, more portable and more inspectable record.

Evidence without forcing every system to look the same

This is the central idea behind NexArt Evidence Bridge.

Standardized evidence does not require standardized operational schemas.

Companies should be able to keep the event contracts that already run their applications while still producing evidence with a common integrity and verification model. Bridge creates the boundary between those two worlds.

On one side: the company's existing JSON, systems and operational terminology. On the other: structured NexArt execution evidence. And in the middle: an explicit, immutable and reviewable semantic transformation.

Bridge does not eliminate the need for good instrumentation. It does not make weak telemetry strong. It does not prove every captured claim is true. It does not remove the need for responsible evidence handling.

What it does is make the path from an existing operational event to a verifiable execution record explicit and reproducible without requiring the source application to redesign its schema around NexArt.

That may sound like a small architectural distinction. For enterprise adoption, it is not.

There is a large difference between saying:

Replace your existing event model with ours.

and:

Keep the event model your systems already depend on. Define how it becomes evidence.

The second is how evidence infrastructure can fit into systems that already exist.

And that is what NexArt Evidence Bridge is built to do.

Explore NexArt Evidence Bridge at bridge.nexart.io, or read the Evidence Bridge product overview. Learn more about NexArt's AI evidence layer and verifiable execution infrastructure at nexart.io.