Lineage Explorer | Developer Docs

The Lineage Explorer (/trace-explorer) is where you reconstruct exactly what an AI agent did, in what order, with what data. It turns the OpenTelemetry spans your instrumented agents emit into a readable execution timeline, then lets you verify that timeline against a cryptographic ledger so its integrity can be proven to an auditor. A Lineage Record is KLA's name for a single trace: the full, ordered tree of steps for one agent run, from the triggering prompt through every tool call to the final output.

The Explorer serves two readers at once. A developer uses it to debug a misbehaving run. A compliance, risk, or audit officer uses it to reconstruct, after the fact, precisely what happened and prove it was not altered. Both work from the same record.

Execution timelines

Every governed run produces a tree of spans. The Explorer renders that tree as a timeline so you can see the shape and duration of the run at a glance, then drill into any step.

Nested steps: prompt construction, model completions, retrieval reads, database queries, and outbound HTTP calls, with start time, duration, and parent-child relationships.
GenAI semantic attributes: each step carries standard OpenTelemetry GenAI fields, including genai.agent.name, genai.system.instructions, genai.tool.name, genai.tool.parameters, genai.token.usage, and genai.cost.usd.
Policy outcomes inline: where a step hit the policy engine, the timeline shows the decision (allow, warn, require_approval, or block) so you can see governance and execution side by side.

ℹ️ Note

Spans pass through the KLA Collector, which redacts PII before anything is stored. The Explorer shows the redacted record, so investigation does not re-expose sensitive inputs.

flowchart TD
  A["Trigger prompt"] --> B["Plan step"]
  B --> C["Tool: lookup_claim"]
  B --> D["Tool: fetch_policy_doc"]
  C --> E{"Policy decision"}
  D --> E
  E -->|allow| F["Model completion"]
  E -->|require_approval| G["Decision Desk"]
  F --> H["Final output"]

Data lineage across agent chains

Modern systems chain agents: one agent's output becomes another's input. The Explorer follows a value across those boundaries so you can answer "where did this field come from?" When an orchestrator hands a sub-agent a customer reference, and that sub-agent retrieves a document used to draft a final response, the lineage links the originating input to every downstream step that consumed it. For a developer chasing a bad output, this collapses hours of log-grepping into a single traversal. For an auditor, it establishes provenance: which source data influenced which decision.

Merkle proof verification

A timeline is only evidence if you can prove it was not edited. As spans are recorded, their hashes are anchored into an ImmuDB append-only cryptographic ledger. To check a Lineage Record, the Explorer recomputes the record's hash and confirms it matches the anchor recorded for that record. (Full Merkle-inclusion verification against the ledger's signed root is performed against the live ledger; the exported bundle retains the ledger proof for offline review.)

Match confirms the record is byte-for-byte what was sealed at execution time.
Mismatch flags tampering or corruption for investigation.

🛡️ Important

Verification is largely independent of the running application: the signatures and recomputed hashes hold on their own, which is what makes a Lineage Record defensible evidence rather than just a log. (Confirming the record's inclusion in the ledger's signed state still relies on the ledger proof retained with the record.)

sequenceDiagram
  participant U as Reviewer
  participant LE as Lineage Explorer
  participant L as ImmuDB ledger
  U->>LE: Open Lineage Record
  LE->>LE: Recompute record hash
  LE->>L: Request Merkle proof
  L-->>LE: Path to anchored root
  LE->>U: Verified or Tampered

You can fetch a record's verification status over the API:

curl https://api.kla.digital/v1/lineage/lr_8f21/verify \
  -H "Authorization: Bearer $KLA_ACCESS_TOKEN" \
  -H "x-tenant-id: acme-prod"

Export to the Evidence Room

When a record (or a filtered set of records spanning an incident or audit window) needs to leave the Explorer as a formal artifact, you forward it to the Evidence Room. There it is packaged into a Sealed Evidence Bundle: signed records, full lineage, policy state, and the verification logs, ready to share with a regulator or attach to a Control Pack. The Explorer is where you investigate; the Evidence Room is where you certify and export.