Lineage is not analytics

Graphs are persuasive. A screen filled with nodes and arrows can make almost any system look as if it understands itself. That is exactly why governance systems need to be disciplined about what their graph means.

Lineage answers a specific question: what governed records are related to this exact version or decision? It can connect a prompt version to an experiment candidate, evaluation run, replay job, policy, or governance decision. It should preserve the direction and type of those relationships, expose the bounded evidence available, and make missing links visible.

That is already valuable. It does not need to become a dependency heat map, an asset-health score, a prompt-quality ranking, or an automatic recommendation engine to justify its existence.

Relationships before rankings

The difference is not semantic nitpicking. A relationship is a recorded fact: this candidate used this model version; this evaluation run was produced for this candidate; this decision was made under this policy. A ranking is an interpretation: this model is better, this prompt is risky, this asset is healthy, this team should change something.

Interpretations can be useful, but they require explicit metrics, time windows, baselines, ownership rules, and policy assumptions. If those inputs are absent, the graph should not turn density or proximity into a false governance signal.

Bounded context is usable context

Unbounded ontology exploration has a predictable failure mode: every relevant record is swallowed by every adjacent record until an operator is looking at a wall of tiny boxes. The result may be technically complete and operationally useless.

Kavach starts from an exact asset version or decision and asks the backend for a bounded neighbourhood. The lineage tab provides a compact orientation view; Graph Explorer provides the deeper inspection surface with explicit depth, relationship, node-type, and direction filters. The browser does not fetch an entire graph and invent a narrative from layout.

That constraint also makes the interface honest. It tells the operator that they are looking at relevant local context, not a universal model of every dependency in the organization.

The graph is a projection

Kavach’s ontology is downstream of authoritative control-plane records. Prompt, model, dataset, experiment, evaluation, replay, policy, job, and decision relationships are synchronized from backend facts. If projection work lags or fails, the system can expose that state and reconcile it; the graph does not become a parallel source of truth.

This matters for review. A graph node is not proof because it has a label. It is useful because operators can trace it back to a registry record, audit event, evaluation artifact, or governance decision that owns the underlying claim.

Analytics have a place—but a different contract

Cost trends, latency distributions, prompt-quality rankings, asset health, business ownership views, and impact analysis all require a richer analytical contract. They need defined aggregation windows, data retention choices, permission boundaries, scoring logic, and often organization-specific semantics.

Those features should be added when their inputs and claims are explicit. Until then, a registry and lineage surface should remain legible: versions, references, provenance, and audit history. That baseline makes later intelligence features more trustworthy because they have stable facts to build on rather than a graph-shaped guess.

Lineage makes questions cheaper

The practical test is simple. An operator reviewing a result should be able to move from an asset version to the candidate that used it, the run that evaluated it, the policy that governed it, and the decision that followed—without searching unrelated systems by timestamp and intuition.

That is what lineage is for. It does not answer every operational question. It makes the questions that matter to governance cheaper, more precise, and easier to defend.