# Export Lineage Graph 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. {% embed url="" %} 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.
{% hint style="info" %} 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. {% endhint %} *** ## 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.decube.io/lineage/export-lineage-graph.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.