Product

Trajectory Lineage Foundation: From Flat Nodes to Real Chains

5 min read

The problem we just solved

Until today, every trajectory PromptKing stored was a flat list.

Every node was treated as a root. Parent relationships were discarded on write. The system could record what happened, but it could not reconstruct how one step led to the next. Proof Weaver correctly reported that no trajectory chain was available — because none existed.

That is a real limitation for any governance system that claims to understand agent behavior over time. Without parent links, you cannot distinguish a linear tool call from a branch, a handoff, or a silent context loss. You cannot later ask whether a decision was made on a derived observation or an explicit tool result. The graph simply did not exist.

What changed in v4.90.23

We closed the data-production gap on the Anthropic path first.

A real trajectory was reconstructed and written to the live database through a direct parser-to-database path:

  • Root node → lineage_basis: unknown
  • ToolCall → lineage_basis: derived
  • Observation → lineage_basis: explicit (matched via a real tool_use_id)
  • Decision → lineage_basis: derived

Parent links landed correctly. No cycles. No cross-trajectory pollution. Adversarial malformed nodes were rejected and persisted as null / unknown with warnings, not silently rewritten.

Proof Weaver now evaluates trajectory_chain_available = true on this trajectory. It was false on every prior row in the database.

The other five vendor parsers were deliberately left untouched. lineageBasis was added as optional so that no mechanical changes were forced on them. Honest unknown was preferred over fabricated links.

What this does not claim

  • Automatic production routing for Anthropic messages through the default pipeline. A separate parser-resolution collision was found during this work — a broader matcher can claim an Anthropic-shaped message before the Anthropic parser gets a chance — and is logged as its own follow-up. Tonight's result was validated through a direct parser-to-database path specifically because of that limitation, not through default automatic routing.
  • Universal six-vendor lineage
  • Full Proof Weaver product validation beyond the chain-availability signal
  • Transactional multi-step persistence (pre-existing, unchanged)

One real parent-linked trajectory now exists. That is the foundation.

Why it matters

Governance that cannot reconstruct a chain cannot later answer the questions that actually matter in production:

  • Was this decision made on an explicit tool result or a derived observation?
  • Did a handoff occur between agents or tools?
  • Where did context potentially degrade?

A flat list of nodes cannot support those questions. A real chain can.

This work stays strictly out-of-path. It does not intercept execution. It does not invent links. It simply stops discarding the structure that was already present in the vendor's own message shape.

The questions only we answer

When an agent takes multiple steps, who can reconstruct the real parent-child relationships instead of a flattened list?

Can the governance system distinguish an explicit tool-result link from a same-message derivation — and honestly mark the cases it cannot determine?

Does the same law of evidence apply whether the trajectory came from Anthropic, another vendor, or a future multi-agent graph?

One trajectory now carries real lineage. The rest of the surface can build on it.

See your organization's AI spend data

PromptKing connects to your AI vendors and surfaces exactly this analysis — for your seats, your vendors, your budget.

← Back to Insights
Trajectory Lineage Foundation: From Flat Nodes to Real Chains | PromptKing Insights | PromptKing AI FinOps