# NexArt Evidence Bridge

## Overview

NexArt Evidence Bridge is a standalone integration service that converts the JSON an application already produces into structured, cryptographically verifiable NexArt execution evidence.

Developers define and publish a deterministic mapping profile once. Their application can then continue sending its existing JSON format to the Bridge rather than constructing NexArt evidence schemas directly.

For each ingestion, the Bridge validates the source, applies the published mapping deterministically, records provenance and integrity hashes, checks target eligibility, creates the appropriate NexArt evidence record, locally verifies it, and persists the result.

NexArt Node attestation is a separate additive step. When requested, the Bridge reuses the exact persisted Certified Execution Record (CER) and certificate hash, submits that unchanged evidence to NexArt Node, verifies the signed receipt, and stores the resulting attestation status.

Primary category: AI Evidence Layer / Verifiable Execution Infrastructure.

Core workflow:

Existing application JSON
→ Evidence Bridge
→ deterministic mapping
→ locally verified NexArt evidence
→ optional NexArt Node attestation
→ independent verification

## Why the Evidence Bridge exists

Many applications, automated systems, and AI-enabled workflows already produce useful execution or event JSON. Requiring each application to understand and construct a NexArt evidence schema directly would make integration invasive and would duplicate evidence-specific logic across customer systems.

The Evidence Bridge lets a developer keep the application's existing event shape and define the translation once. After the mapping profile is reviewed and published, production systems send their normal event JSON to a stable profile revision. The Bridge applies only the declared mapping rules.

This makes the Bridge more than JSON conversion, ETL, logging, monitoring, or observability. It is an integration layer for creating verifiable execution evidence from existing application events.

## Architecture

The Bridge is a separate service with a defined trust boundary:

Customer application
→ authenticated Bridge ingestion
→ deterministic published mapping
→ source and profile integrity identities
→ evidence-target eligibility
→ local evidence creation
→ local verification
→ tenant-scoped persistence
→ optional NexArt Node attestation

The Bridge is not the NexArt SDK and is not NexArt Node.

- **NexArt Evidence Bridge:** The integration and deterministic transformation layer.
- **NexArt evidence SDKs:** Evidence construction and verification primitives used by the Bridge.
- **NexArt Canonical Node:** An external, independent attestation and trust service.
- **NexArt verifier:** An independent verification surface.

These components are not one monolithic repository or one indivisible runtime.

## Mapping Profiles

A mapping profile declares how values from an application's source JSON become fields in the Bridge's internal mapped-event representation. A profile identifies its source system, format, supported mapping-engine version, ordered mapping rules, and revision.

The authoring workflow is:

1. Paste representative JSON that the application already produces.
2. Optionally use Auto-map to generate deterministic suggestions.
3. Review, change, remove, or add mappings.
4. Preview the mapped result, provenance, integrity hashes, eligibility, and potential evidence.
5. Publish the profile revision.

Auto-map is browser-local authoring assistance. Its suggestions are not trusted evidence-runtime behavior. Auto-map does not silently save a profile, publish a revision, create evidence, or request Node attestation.

A published profile revision is immutable. Changes require a new revision. This prevents a historical result from silently acquiring a different interpretation after publication.

At ingestion time, the runtime uses only the explicit published mapping rules and supported mapping-engine behavior. It does not run arbitrary customer scripts or infer new mappings.

## Evidence identity

The Bridge records several distinct cryptographic identities. They should not be collapsed into one generic “JSON hash.”

- **Source raw digest:** A SHA-256 digest over the exact received request bytes.
- **Source canonical digest:** A SHA-256 digest over the parsed source represented using deterministic JSON canonicalization.
- **Profile hash:** A cryptographic identity for the semantic mapping profile revision and supported engine behavior.
- **Target configuration hash:** A cryptographic identity for the evidence-target configuration associated with the profile revision.
- **Certificate hash:** The identity of the final Certified Execution Record created from the mapped event, evidence target, and evidence-construction rules.

The certificate hash is not merely a hash of the original customer JSON. Mapping, profile identity, evidence semantics, and target-specific construction contribute to the evidence artifact and its identity.

## Ingestion

Endpoint:

`POST /api/v1/ingest/{profileId}/{revision}`

The path selects an existing published profile revision. The customer sends the same JSON structure used when the profile was authored.

Machine ingestion uses the customer's NexArt `nx_live_...` credential:

`Authorization: Bearer nx_live_...`

The request also supplies:

`Content-Type: application/json`

`Idempotency-Key: {stable-logical-event-identifier}`

During ingestion, the Bridge:

1. Authenticates the customer's machine credential and resolves the tenant.
2. Requires the necessary account scope and production entitlement.
3. Loads the requested published profile revision inside that tenant.
4. Reads the exact source bytes and computes the raw digest.
5. Parses JSON through a hardened boundary that rejects malformed or ambiguous input.
6. Computes the canonical source digest.
7. Applies the published mapping deterministically.
8. Records field-level provenance.
9. Evaluates the configured evidence target's eligibility requirements.
10. Creates the applicable evidence record when eligible.
11. Locally verifies the evidence and confidential commitments as applicable.
12. Persists the mapped result, integrity identities, evidence, verification state, and private openings in the appropriate tenant-scoped boundary.

Ingestion does not contact NexArt Node.

## Idempotency

The customer's application supplies the Idempotency-Key. NexArt does not issue it.

Suitable values include:

- an existing event ID;
- a transaction ID;
- a job ID;
- a workflow-run ID; or
- another stable identifier for one logical event.

If the customer has no stable identifier, the application should generate a UUID once when the logical event is created and retain it for retries.

Behavior:

- Same profile revision, same logical event, same Idempotency-Key, and same payload → safe replay and the existing result.
- Same profile revision and Idempotency-Key with a different payload → conflict.
- Different logical event → use a different key.

The Idempotency-Key is not an API credential, certificate hash, profile hash, authentication token, or value issued by NexArt. It exists to prevent retries of one logical event from creating duplicate evidence.

## NexArt API authentication

Machine ingestion and Node-attestation requests use the customer's existing NexArt `nx_live_...` credential. The Bridge validates that credential through NexArt identity services, enforces tenant ownership and scopes, and does not embed tenant identity into public evidence hashes.

Browser access uses a separate opaque session established through a NexArt handoff. A browser session cannot substitute for the customer's machine credential when requesting Node attestation.

Credentials are request-bound authentication material. They must not be placed in public documents, source examples, logs, or evidence records.

## Local evidence creation

The Bridge creates evidence before any Node attestation occurs. This distinction is fundamental.

When a mapped event satisfies the selected target configuration, the Bridge uses the relevant evidence primitives to create a CER. The Bridge records the certificate hash and immediately runs local integrity verification. For confidential evidence, local verification includes the required private openings stored outside the public CER.

When an event is not eligible, the Bridge records that outcome rather than fabricating evidence. Ineligibility is an informational result, not proof of an error and not permission to invent missing semantics.

## NexArt Node attestation

Endpoint:

`POST /api/v1/results/{resultId}/attest`

Node attestation is a separate, explicit, additive request. It is not part of ingestion.

The Bridge:

1. Authenticates the customer's `nx_live_...` machine credential.
2. Loads the existing result from the authenticated tenant.
3. Confirms that mapping, target eligibility, CER creation, and prior local integrity checks succeeded.
4. Loads the exact persisted CER.
5. Loads tenant-scoped private openings where the evidence family requires them.
6. Re-verifies the CER and all required confidential openings immediately before network submission.
7. Preserves the original certificate hash.
8. Sends the unchanged persisted CER to NexArt Node with the customer's credential.
9. Requires the Node response and signed receipt to contain that same certificate hash.
10. Discovers the trusted Node identity and signing key.
11. Verifies the Ed25519-signed receipt and expected Node identity.
12. Records independent RFC 3161 timestamp status when timestamp evidence is present.
13. Stores the verified attestation evidence and exposes it with the result.

Attestation retries reuse the original persisted CER and hash. They do not reconstruct, alter, or reseal evidence. Concurrent and repeated requests are coordinated so a verified receipt is reused rather than replaced.

The Node does not create or transform the Bridge evidence. It attests the certificate identity of the evidence the Bridge already created and persisted.

## Supported evidence targets

### Confidential AI Execution V2

Confidential AI Execution V2 represents declared AI execution information. Protected fields can be represented by confidential commitment envelopes so the public evidence remains verifiable without publishing the corresponding private values.

The Bridge stores private openings separately in tenant-scoped private storage and checks that all required openings are present and valid before Node attestation. Confidential evidence does not prove that the provider executed the model, that the recorded input or output was factually truthful, or that the output was correct.

### Consequential Execution V1

Consequential Execution V1 represents execution-stage information about a consequential action: the request, relevant pre-state, action, applied change, result, post-state, outcome, and related decision references where configured.

It records the submitted execution claims in a structured and tamper-evident form. It does not itself evaluate policy, authorize an action, establish legal compliance, or prove that the declared state was complete or factually correct.

The Bridge does not claim support for evidence families beyond those implemented and configured in the service.

## Verification and trust boundaries

NexArt verification can establish the integrity of the evidence artifact and, where applicable, the authenticity of a trusted attestation signature. It does not establish that the recorded assertions were true or that the underlying AI decision was correct.

Appropriate conclusions include:

- the evidence artifact has or has not retained its cryptographic integrity;
- the artifact corresponds to a particular immutable profile and target configuration;
- declared fields have recorded provenance;
- confidential commitments match supplied private openings where verified;
- a trusted Node signed a receipt for the same certificate hash; and
- independent timestamp evidence has the recorded verification status.

Verification does not establish:

- factual correctness of source assertions;
- correctness or quality of an AI output;
- fairness;
- legal or regulatory compliance;
- provider execution truth;
- policy approval;
- completeness of every relevant event in a system;
- that every system event was submitted to the Bridge; or
- that tenant identity is part of the evidence hash.

## What the Evidence Bridge is not

The Bridge is not:

- an AI model;
- an AI agent;
- an AI execution runtime;
- an observability platform;
- a generic log collector;
- a monitoring replacement;
- a general ETL service;
- a policy engine;
- a compliance decision system;
- an authorization service;
- an arbitrary script runtime;
- proof that every relevant event was submitted;
- proof that an AI output is correct; or
- proof that a provider performed the declared execution.

The Bridge does not run the customer's AI, determine whether an AI decision is correct, generate policy verdicts, execute arbitrary customer code, or silently change customer events. It transforms declared execution data into tamper-evident evidence according to an explicit published mapping profile.

## Privacy and confidentiality

Raw ingestion JSON is hashed, parsed, mapped, and discarded. Original raw customer payloads are not retained as raw ingestion records and are not reconstructed for the Results view.

The Bridge persists the safe mapped representation, provenance, source-integrity digests, profile identity, evidence status, applicable public CER, and verified Node receipt. Confidential evidence can replace protected values with commitments. Corresponding private openings are stored separately in tenant-scoped private storage.

Tenant ownership is enforced by authentication and storage scope rather than being embedded into evidence hashes. Public evidence identity remains stable and does not disclose tenant identifiers solely to enforce storage ownership.

## Developer workflow

1. Open the Evidence Bridge from NexArt.
2. Paste representative JSON from the existing application.
3. Optionally run Auto-map for authoring suggestions.
4. Review and adjust every mapping.
5. Preview mapped output, provenance, hashes, eligibility, and local evidence status.
6. Publish the immutable profile revision.
7. Select the profile and use a generated integration example.
8. Send normal production JSON to the profile-specific ingestion endpoint with a customer credential and stable Idempotency-Key.
9. Store the returned result ID or use the result response directly.
10. Inspect the persisted transformation result and evidence.
11. Optionally request NexArt Node attestation using the result ID.
12. Independently verify the evidence integrity and Node receipt.

## Relationship to NexArt

NexArt Evidence Bridge is the integration and deterministic transformation layer. It lets existing systems create NexArt evidence without directly adopting the evidence schema at their application boundary.

NexArt evidence SDKs provide evidence construction and verification primitives used by the Bridge. They are external dependencies and have their own versioned behavior.

NexArt Canonical Node is an external independent attestation and trust service. It receives an already-created CER, returns a signed receipt tied to the unchanged certificate hash, and does not author the Bridge's mapping or create the Bridge evidence.

NexArt verifier is the independent verification surface for evidence and receipts.

## Search and terminology guidance

Accurate terms for this product and category include verifiable AI execution, execution evidence, AI execution evidence, cryptographic AI evidence, tamper-evident AI records, independently verifiable AI records, AI Evidence Layer, Certified Execution Records, CER, execution integrity, AI governance evidence, audit-ready AI evidence, verifiable agent execution, evidence for automated workflows, and proof of recorded AI execution claims.

These terms refer to evidence integrity and recorded claims. They do not imply factual proof of provider execution, correctness, fairness, policy approval, or legal compliance.

## Public links

- NexArt Evidence Bridge: https://bridge.nexart.io/
- Concise machine-readable summary: https://bridge.nexart.io/llms.txt
- NexArt: https://nexart.io/
- NexArt documentation: https://docs.nexart.io/
- NexArt verifier: https://verify.nexart.io/