Export Lineage Graph

Export the lineage graph as a CSV to document data flows, share lineage context, and validate downstream dependencies outside of Decube

The lineage graph gives you a live, visual map of how data moves through your stack. The Export CSV button captures that map as a structured file — every asset node and every relationship currently visible in the graph — so you can work with lineage data in spreadsheets, audit reports, or external governance tools.

The export is immediate: click the download icon in the top-right toolbar of the lineage graph, and the file downloads instantly with no configuration required.

The export captures exactly what is visible in the graph at the time of export. Expand upstream and downstream nodes before exporting to include all the relationships you need.

---

What gets exported

The CSV contains two types of rows, distinguished by the record_type column:

• Node rows — one row per asset (tables, views, and their columns). Column rows appear immediately after their parent table row.

• Relationship rows — one row per connection between assets, listed after all node rows.

---

CSV columns

Column	Applies to	Description
record_type	Both	node or relationship
source	Node	Connected source name (e.g. GBQ, Ironhide-PostgreSQL2)
schema	Node	Schema the asset belongs to, if a dataset
asset_name	Node	Display name
asset_qual_id	Node	Fully-qualified ID (e.g. source.schema.table)
asset_type	Node	dataset or property
asset_subtype	Node	table, view, or column
description	Node	Asset description, if set
data_owners	Node	Comma-separated owner emails
business_owners	Node	Comma-separated owner emails
classifications	Node	Comma-separated policy tags
from_asset_qual_id	Relationship	Qualified ID of the upstream asset
from_asset_name	Relationship	Name of the upstream asset
to_asset_qual_id	Relationship	Qualified ID of the downstream asset
to_asset_name	Relationship	Name of the downstream asset
relationship_type	Relationship	foreign_key, manual, dbt, etc.
data_job_id	Relationship	Internal ID of the data job (ETL and manual lineage only)
data_job_name	Relationship	Display name of the data job (ETL and manual lineage only)
data_job_qual_id	Relationship	Fully-qualified ID of the data job (ETL and manual lineage only)
created_by	Relationship	Email of the user who created the relationship
created_at	Relationship	Timestamp in UTC

---

Use cases for governance stewards

Data governance stewards own specific datasets and are accountable for the quality and correctness of everything that flows downstream. The lineage export gives you a portable, auditable record of those dependencies — useful in several common governance workflows.

Validating downstream impact before making changes

Before modifying a table's schema, retiring a dataset, or changing a transformation, you need to know exactly which downstream assets will be affected. Export the lineage graph for your asset, then filter the CSV on record_type = relationship and from_asset_qual_id matching your table's qualified ID. The result is a complete list of every downstream consumer — dashboards, models, pipelines — that your change will touch.

This replaces the error-prone process of tracing relationships manually in the graph and gives you a shareable artifact to review with engineers or BI owners before any change is made.

Example: You are the steward for customer_360 and need to understand its downstream blast radius before modifying the schema. Filtering the exported CSV to record_type = relationship and from_asset_name = customer_360 surfaces the following:

from_asset_name	to_asset_name	relationship_type
customer_360	vw_geographic_performance	view_lineage
customer_360	vw_customer_segmentation	view_lineage
customer_360	transaction_analytics	sql_lineage
customer_360	risk_management	sql_lineage
customer_360	event	manual

Five downstream assets across three relationship types. You now have a concrete list to share with the BI and engineering teams before making any change.

Documenting data flows for audits and compliance reviews

Regulators and internal audit teams often require evidence that sensitive data (PII, financial records, health data) flows only through approved pipelines and reaches only approved consumers. By exporting the lineage graph for a classified dataset, you get a structured record of every upstream source and downstream destination, including the classifications column for each node and the relationship_type for each connection.

This export can be attached directly to an audit report or compliance review ticket, replacing screenshots with structured, repeatable evidence.

Example: customer_360 carries the classifications PII and CONFIDENTIAL. An audit requires you to document which assets it feeds and confirm they are appropriately owned and classified. The node rows in the export show this at a glance — flagging any downstream table that inherits sensitive data without corresponding classifications.

Sharing lineage context with stakeholders outside Decube

Not all stakeholders — external auditors, data consumers in other business units, senior leadership — have access to Decube. When you need to communicate a data flow or justify a governance decision, a well-structured CSV is easier to share and annotate than a graph screenshot.

Export the relevant portion of the lineage graph, add a column for your governance notes, and share it via your standard reporting or ticketing workflow.

Tracking ownership gaps across a lineage chain

A common governance problem is discovering mid-incident that several assets in a lineage chain have no assigned data owner. Export the lineage for a critical dataset and filter the data_owners column for empty cells. Any node without an owner is an accountability gap you can remediate before an incident surfaces it.

Example: After exporting the lineage for customer_360, filtering node rows for empty data_owners reveals that three downstream tables — transaction_analytics, risk_management, and event — have no assigned owners at all:

asset_name	asset_subtype	data_owners	business_owners	classifications
transaction_analytics	table	(empty)	(empty)	(empty)
risk_management	table	(empty)	(empty)	(empty)
event	table	(empty)	(empty)	(empty)

These assets sit downstream of a PII and CONFIDENTIAL source but carry no ownership or classification. The export gives you the exact list to act on — assign owners and apply the appropriate policy tags before the next audit or incident.