How Evidence Bridge Works

The pipeline

receive -> hash -> parse -> map -> eligibility -> create CER
       -> verify locally -> persist -> attest -> verify receipt -> timestamp state

Source digests and provenance

Evidence Bridge records two different source digests.

Raw source digest

This is calculated from the exact HTTP request bytes received by Evidence Bridge.

sha256:<digest-of-original-request-bytes>

Changing whitespace or JSON property order changes the raw digest.

Canonical source digest

The JSON is parsed and canonicalized using the Bridge's deterministic canonicalization rules before hashing.

sha256:<digest-of-canonical-json>

Equivalent JSON with different whitespace or property ordering can therefore have a different raw digest but the same canonical digest. The raw digest identifies the exact submitted byte representation. The canonical digest identifies the parsed JSON content under canonical serialization.

Bridge provenance

The evidence provenance includes values such as:

{
  "sourceRawDigest": "sha256:...",
  "sourceCanonicalDigest": "sha256:...",
  "profileId": "...",
  "profileRevision": 1,
  "profileHash": "sha256:...",
  "engineVersion": 1,
  "targetConfigHash": "sha256:...",
  "sourceSystem": "...",
  "externalEventId": "..."
}

These values establish the provenance of the Bridge transformation. They do not prove that the source system itself reported the truth.

Raw payloads are ephemeral by default

Evidence Bridge is designed to avoid unnecessary retention of customer source payloads. The normal flow is:

receive -> hash -> parse -> map -> create evidence -> discard raw payload

Evidence Bridge retains the cryptographic provenance needed to understand how the evidence was produced without requiring permanent storage of the original source JSON. Where confidential evidence requires private opening material, that material is stored separately from the public CER and remains tenant-scoped. Source payloads are never publicly stored.

One certificate identity

Local certificate hash
= submitted certificate hash
= Node-attested certificate hash

Evidence Bridge creates and verifies the CER before sending it to the Node. The Node verifies and attests that exact producer-created CER. The Node does not rebuild the execution record or replace its certificate identity.

Safe retries

Evidence creation and Node attestation are separate operations. Evidence Bridge persists the created CER before Node attestation. If a Node or network request fails, retrying the attestation reuses the same persisted CER and the same certificate hash. It does not reconstruct or reseal the execution.

For ingestion idempotency:

same tenant
+ same profile/revision
+ same idempotency key
+ same source digest
= the authoritative existing result is returned

Reusing the same idempotency key for different source content fails rather than silently creating conflicting evidence.

Bridge status model

Evidence Bridge reports six independent status dimensions. They are intentionally separate, because a failure in one does not invalidate the others.

Mapping                 VALID
Evidence target         Operational Execution V1
CER                     CREATED
Local integrity         VERIFIED
Node attestation        VERIFIED
Independent timestamp   VERIFIED

Mapping                 VALID
Evidence target         Operational Execution V1
CER                     CREATED
Local integrity         VERIFIED
Node attestation        FAILED
Independent timestamp   NOT_VERIFIED

A Node outage does not make the locally created CER invalid. Do not collapse these states into a single generic pass or fail.

What happens when evidence is incomplete

• Unknown mapped outcome: mapping and eligibility fail.
• Missing execution ID: target ineligible.
• Applied outcome without an applied change: target ineligible.
• Authorization-only payload: target unsupported.
• Local cryptographic verification failure: the Node is not called.
• Wrong or incomplete confidential opening set: the Node is not called.
• Node unavailable: the existing CER is retained for retry.
• Certificate hash mismatch in the Node response: attestation verification fails.
• Unknown Node key: receipt verification fails.
• Invalid RFC 3161 chain: the timestamp is not marked VERIFIED.

See Attestation and verification for how node receipts and timestamp evidence are checked.