Lineage
Trace what a semantic node depends on and what depends on it, using the graph-based Lineage browser in Context Studio.
When to use it — Before you change or remove a node, or when you need to understand where a node's data comes from and where it flows.
Where to find it — Context Studio → Governance group → Lineage tab.
Who can use it — Weaver and Luminary.
Lineage answers two questions about a node: what does this depend on? and what depends on this? It reads the semantic knowledge graph and walks the edges in both directions, so you can see the full chain of relationships, not just the immediate neighbors.
This is the graph-based lineage browser that lives inside Context Studio. It is distinct from the lineage view in Forge, which focuses on a single metric's authoring context. Use Lineage here when you want a workspace-wide, node-to-node dependency picture.
Overview
When you pick a node and select View lineage, Context Studio walks the knowledge graph from that node and returns two lists:
- Upstream dependencies — the objects this node depends on (edges pointing into the node).
- Downstream dependents — the objects that depend on this node (edges pointing out from the node).
Each result row shows the related object's object type (as a badge), its object id, and the relationship type that connects it. Rows are indented by their level, so you can read how many hops away each dependency sits. The walk follows the graph up to several hops, so an indirect dependency two or three steps away still appears, nested under the chain that leads to it.
When to use it
- Before editing a node — check the downstream dependents so you know which dashboards, topics, or analysts could be affected by your change.
- Before deleting a node — confirm nothing important depends on it.
- When tracing data provenance — follow the upstream chain to see which sources and nodes a metric ultimately draws from.
- When debugging a surprising result — walk the graph to confirm a node is wired to the dependencies you expect.
If you want a count-based summary of consumers (dashboards, alerts, Orion answers, topics, analysts) rather than the raw graph, use Impact Analysis instead — it is the companion tab in the same Governance group.
Concepts
| Term | Meaning |
|---|---|
| Node | A semantic object in your model (for example, a domain node defined in CML). You pick one node as the starting point for the lineage walk. |
| Upstream dependency | An object the selected node depends on. These are the inbound edges — the things that feed the node. |
| Downstream dependent | An object that depends on the selected node. These are the outbound edges — the things the node feeds. |
| Object type | The kind of related object on each row, shown as a badge (for example a reveal, topic, analyst, decision, prism, or mosaic). |
| Relationship type | The label on the graph edge that explains how two objects are connected. |
| Level | How many hops the related object sits from the node you selected. Level 1 is a direct neighbor; higher levels are indirect and are shown indented. |
| Knowledge graph | The set of edges between semantic objects that Lineage walks. See Knowledge Graph for how those edges are built. |
Getting started
You need a workspace with at least one semantic node, and the Weaver or Luminary role to open Context Studio's governance tabs.
Open Context Studio
Navigate to Context Studio from the main navigation.
Open the Lineage tab
In the left navigation, find the Governance group and select Lineage.
Confirm your nodes loaded
The Select node dropdown is populated from the nodes in your workspace. If it is empty, you have no nodes yet — define one in Forge first.
Step-by-step
Select a node
Open the Select node dropdown and choose the node whose lineage you want to trace. The list is sorted by node name.
View the lineage
Click View lineage. The button shows Loading… while the graph walk runs, then renders the results. The button stays disabled until you have picked a node.
Read the upstream dependencies
The Upstream dependencies section lists everything the node depends on. Each row shows the object-type badge, the object id, and (where present) the relationship type. A left-pointing arrow marks the direction.
Read the downstream dependents
The Downstream dependents section lists everything that depends on the node, marked with a right-pointing arrow. Use this list to gauge the blast radius of a change.
Follow the indentation
Within each section, deeper rows are indented. A level-2 row nested under a level-1 row means the dependency is two hops away, reached through the row above it.
Examples
Suppose you want to understand the lineage of a node called orders.
- In the Lineage tab, pick
ordersfrom the Select node dropdown. - Click View lineage.
A typical result looks like this:
Upstream dependencies
← [node] customers derived_from
← [reveal] net_revenue computed_from
Downstream dependents
→ [reveal] total_orders references
→ [topic] Sales Performance uses
→ [analyst] Weekly Sales Brief uses
→ [mosaic] Executive Dashboard pinsHere orders depends on the customers node and the net_revenue reveal upstream. Downstream, the total_orders reveal and the Sales Performance topic both depend on it directly; the Weekly Sales Brief analyst depends on it indirectly through that topic, which is why it is indented one level deeper.
The underlying request the tab makes is:
GET /api/context/lineage/node/<node-id>It returns an upstream list and a downstream list; each item carries object_type, object_id, relationship_type, and level.
Best practices
- Check downstream before any destructive change. Renames and deletes ripple outward — the downstream list shows you exactly what to revalidate.
- Trace upstream to verify provenance. If a metric looks wrong, walk its upstream chain to confirm it draws from the sources you intend.
- Pair Lineage with Impact Analysis. Lineage gives you the node-by-node chain; Impact Analysis gives you the rolled-up counts of affected dashboards, alerts, and Orion answers. Read both before a risky change.
- Keep the graph current. Lineage is only as complete as the edges in the knowledge graph. If a relationship is missing, see Knowledge Graph to understand how edges are generated.
Tips
The arrows tell you the direction at a glance: ← points back to upstream dependencies (what feeds the node) and → points forward to downstream dependents (what the node feeds). Read indentation as distance — deeper rows are farther from the node you selected.
Common mistakes
- Confusing upstream and downstream. Upstream is what the node depends on; downstream is what depends on the node. Deleting a node breaks its downstream dependents, not its upstream dependencies.
- Assuming an empty list means no relationships exist. A section showing None found means no edges of that direction are recorded in the graph for this node — it does not prove nothing uses the node in reality. Confirm the Knowledge Graph is populated.
- Forgetting indirect dependents. The walk follows multiple hops, so deeply indented rows are still affected by your change even though they are not direct neighbors.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| The Select node dropdown only shows "Choose a node…" | The workspace has no nodes, so the node list came back empty. | Define a node in Forge, then reopen the Lineage tab. |
| View lineage stays greyed out | No node is selected — the button is disabled until you pick one. | Choose a node from the dropdown first. |
| Both sections show None found | The selected node has no edges recorded in the knowledge graph. | Check the Knowledge Graph to confirm edges have been generated for this node. |
| A dependency you expect is missing | The relationship is not (yet) an edge in the graph. | Verify the relationship exists in the model and that the graph has been built; see Knowledge Graph. |
| The lineage looks stale after a model change | The graph edges had not refreshed when you ran the walk. | Re-run View lineage after the graph updates. |