# Observability & Governance Layers The lineage graph now lets you overlay two contextual layers — **Observability** and **Governance** — directly on top of your existing lineage view. Instead of switching tabs or searching separate pages to understand data health or classification coverage, you can activate these layers to see the relevant information right where the data flows. {% embed url="" %} ### Who benefits from these layers * **Data consumers and analysts** use the Observability layer to quickly check whether any upstream or downstream tables are experiencing data quality incidents before acting on a dataset. Rather than navigating away to search through the Incidents list, you stay on the lineage canvas and get the context you need in seconds. * **Data engineers** use the Observability layer for impact analysis and troubleshooting. When an incident fires, you can instantly see how far the problem propagates — identifying every upstream source and downstream consumer affected — and prioritise your fix without manually tracing the pipeline. * **Data governance stewards and compliance teams** use the Governance layer to audit where sensitive data lives and flows. You can filter the view to a specific classification, such as PII or Confidential, and trace exactly which columns carry that classification through the entire lineage graph. This gives you a fast, visual answer to "which downstream tables consume columns tagged as PII?" — a question that would otherwise require cross-referencing the catalog across multiple assets. ### Accessing the layers Both layers are accessed from a floating toolbar at the bottom of the lineage canvas. 1. Open the **Lineage** tab on any table's Asset Details page. 2. Click the action button in the bottom toolbar — labelled **Discover and manage data quality and governance layers**. 3. The toolbar expands to reveal two toggles: **Show Incidents (Data Quality)** and **Show Governance (Classifications)**. 4. Toggle on one or both layers. To close the toolbar without changing your selection, click **X**. *** ### Observability layer #### What it shows When you enable **Show Incidents (Data Quality)**, every table node on the canvas that has open or muted incidents from the last 30 days receives a **red outline** and an incident badge showing the count. Tables without active incidents remain visually unchanged, so affected nodes stand out immediately. At the column level, expanding the column selector dropdown on any node reveals individual column badges for columns that have their own incidents.

Observability layer toggled on to show all incidents on the datasets in the graph.

#### How to investigate an incident from the lineage graph 1. Enable the **Show Incidents (Data Quality)** toggle in the floating toolbar. 2. Identify the red-outlined nodes on the canvas — these are the tables with active incidents. 3. Click the action icon on the right side of an incident badge to open the **Incidents** side drawer. 4. The drawer lists all open and muted incidents for that table from the last 30 days. Scroll through the list to review each case. 5. Click any incident card to open the full incident detail page in a new tab. 6. To investigate at the column level, open the column selector dropdown on any red-outlined node. Columns with their own incidents display a badge with a count. Select a column to keep the badge in focus as you trace its lineage upstream or downstream. {% hint style="info" %} The incident count shown on the badge and inside the side drawer reflects only **open and muted** incidents from the **last 30 days**. Resolved incidents older than 30 days do not appear. {% endhint %}

List of incidents for a dataset, accessed from the lineage graph.

#### Example: tracing the impact of a freshness incident Your monitoring detects a freshness incident on a source table. With the Observability layer active, you can see at a glance which downstream tables also show red outlines — indicating they surface incidents that may be caused by or related to the upstream problem. Click the incident badge on each affected node to review the details, then click through to each incident page to assess severity and assign owners, all without losing your position on the lineage canvas. *** ### Governance layer #### What it shows When you enable **Show Governance (Classifications)**, every table node that contains classified columns displays an aggregated classification count badge. Hovering over this badge reveals a tooltip listing the specific classifications applied across that table's columns. At the column level, expanding the column selector shows individual classification badges per column. Hovering on a column badge tells you exactly which classifications are applied to that column. By default, all classifications configured in your organisation are shown.

Lineage graph with classifications highlighted.

#### How to audit classification coverage across your lineage 1. Enable the **Show Governance (Classifications)** toggle in the floating toolbar. 2. Review the classification count badges on each node. Hover over any badge to see the breakdown of classifications for that table. 3. To focus on a specific classification type — for example, PII only — click **Manage** in the toolbar. 4. In the **Manage Classification Display** modal, select the classifications you want to highlight (you can select multiple). 5. Click **Save Preferences**. The lineage graph reloads to show only nodes and columns tagged with your selected classifications. 6. Expand the column selector dropdown on any node to see which individual columns carry those classifications.

Lineage with column classifications marked.

#### Example: confirming a PII column's downstream reach Your team is preparing for a compliance review and needs to confirm that a column tagged as PII is not being consumed by any unvetted downstream systems. Enable the Governance layer, then click **Manage** and filter to the PII classification. The graph highlights only assets that contain PII-tagged columns. Expand the column selector on the source table to confirm the specific column, then trace its downstream path across the canvas. Any downstream table that also shows a PII classification badge is consuming that sensitive data — giving you a clear audit trail to document or act on. *** ### Using both layers together You can enable both toggles simultaneously. This is useful when you need to correlate data quality health with classification sensitivity — for example, to determine whether a table carrying PII data is also currently experiencing an incident. In this combined view, a node can show both a red outline (active incidents) and a classification badge (sensitive columns), giving you the full picture in a single glance. *** ### Frequently Asked Questions **Does the classification count on a table badge reflect a table-level attribute?** No. The count shown on a table node is an **aggregated total** of all classifications applied across that table's individual columns. Classifications are attached at the column level — the table badge simply gives you a summary at a glance. **Can I have multiple classification filters active at the same time?** Yes. The **Manage Classification Display** modal lets you select as many classifications as you need. The lineage graph filters to show nodes containing columns tagged with any of your selected classifications. **Do the layers affect column-level lineage selection?** No. You can use the column selector dropdown alongside the active layers. The Observability and Governance badges remain visible on whichever column you select, so you can trace a specific column's lineage while still seeing its health and classification status. **Why does my incident count differ from what I see on the Incidents page?** The badge and side drawer count only **open and muted** incidents from the **last 30 days**. If you are comparing this to a broader incidents list that includes resolved incidents or a longer date range, the numbers will differ by design. --- # 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/automated-lineage/observability-and-governance-layers.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.