Create a Mapping Profile

Open the profile builder

• Custom JSON profile
• OpenTelemetry profile

Authoring flow

1. Choose a source format. Select Custom JSON or OpenTelemetry.
2. Choose an evidence type. Select AI Execution or Consequential Execution explicitly.
3. Paste a representative event. Use safe sample data with every field you intend to map.
4. Auto-map or add rules. Review source paths, values, destinations, required flags, transforms and unmapped fields.
5. Preview. Check mapping validity, eligibility, commitments, CER creation and local verification.
6. Publish. Publish only after reviewing every mapping and Preview result.

The source format controls validation and Auto-map aliases. It does not silently select an evidence type. Preview does not publish the profile or attest a record through NexArt Node.

Destination paths MUST NOT overlap. Do not map one rule to metadata.ai.parametersand another to metadata.ai.parameters.temperature. Map the parent object or its leaves, but not both.

Profile workflow

Source -> Mapping -> Evidence policy -> Preview -> Publish

• Auto-map provides deterministic suggestions; every suggestion MUST be reviewed.
• Published revisions are immutable.
• Optional request and result evidence can be explicitly included or left unbound.
• The Bridge warns when supported mapped evidence would otherwise be omitted from the CER.
• For Consequential profiles, the evidence policy also sets Protected or Readable per field and optional terms-digest validation.
• Any policy change requires a new profile revision.

Evidence inclusion

For Consequential profiles, mapped values do not automatically imply that every supported optional field is included in the final CER. Explicit inclusion currently supports preserving optional evidence such as request and result. Use Preview to confirm what enters the resulting CER. See Consequential Execution.

Draft, review, publish, ingest

A mapping profile starts as a draft. Users can preview mappings against sample JSON, review the resulting evidence fields, and make changes before publishing.

Published profile revisions are immutable. If a mapping needs to change, create a new revision rather than modifying the published revision. This allows an evidence result to retain a stable reference to the exact mapping configuration used to create it.

Each published revision records:

• Profile identity
• Profile revision
• Profile hash
• Mapping engine version
• Target configuration hash

These values become part of the Bridge provenance attached to the evidence record. See How it works.

Transforms

The mapping engine exposes a closed set of deterministic operations:

• JSON Pointer extraction
• Constants
• Required and optional mappings
• Primitive conversions
• Timestamp normalization
• Object and array preservation
• Selected-value hashing
• Explicit valueMap normalization

A valueMap normalizes a source vocabulary to the evidence vocabulary. Source value:

"APPLIED"

Mapping configuration:

{
  "APPLIED": "applied",
  "FAILED": "failed"
}

Output:

"applied"

Unknown values fail closed unless explicitly configured. Evidence Bridge does not support arbitrary JavaScript, expressions, eval, callbacks or network transforms.

Conceptual example

The following is a conceptual illustration of a mapping profile, not the literal stored schema.

{
  "name": "Operational remediation",
  "target": "consequential-execution-v1",
  "mappings": [
    {
      "from": "/execution_id",
      "to": "source.eventId",
      "required": true
    },
    {
      "from": "/execution_timestamp",
      "to": "source.occurredAt",
      "required": true
    },
    {
      "from": "/pre_state",
      "to": "execution.preState",
      "required": true
    },
    {
      "from": "/outcome",
      "to": "execution.outcome",
      "valueMap": {
        "APPLIED": "applied",
        "PARTIAL": "partial",
        "FAILED": "failed"
      }
    }
  ]
}

Actual profile API fields may contain additional immutable revision and provenance metadata.

Integration types

Preset source profile. Used when a platform emits a predictable execution format. A predefined template creates a tenant-owned draft profile that the user reviews and publishes. Agent frameworks, workflow systems, automation platforms and deployment systems are candidate future presets rather than shipped integrations.

Generic evidence template. AI Execution and Consequential Execution, used when the customer already has a payload close to one of the canonical evidence models.

Custom JSON. Used when the source has its own schema and requires a custom mapping. See Custom JSON.