Lineage Explorer

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.

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 cryptographic ledger, an append-only store that maintains a Merkle tree over every entry. To verify a Lineage Record, the Explorer recomputes the record's hash and walks the Merkle path up to the anchored root.

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

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.