.svg)
ADOC 26.9.0 stitches orchestration, processing, catalog, and storage into a single lineage graph.
Four questions decide how a data incident goes. What does this failure touch downstream? What caused the alert on this table? Can we prove where this data came from? And how many tools does it take to answer the first three?
In most enterprise platforms the answer to the last question is four. A catalog, a quality tool, a pipeline monitor, and a lineage viewer, all open at once, correlated by hand, while the incident runs. The first three questions take hours because of it. Existing approaches each cover one part of this and stop. Platform-native lineage is authoritative inside a single engine and blind at its edge: Unity Catalog knows what happened inside Databricks, Glue Catalog knows what happened inside AWS, and neither knows which DAG scheduled the run. Query-log reconstruction reads SQL history in the warehouse and infers relationships from it, which produces a credible picture of the transformation layer and nothing above or below it. Documented lineage in a catalog is accurate on the day someone writes it down, then degrades quietly as the platform changes.
All three collect lineage. None of them connect it.
That was tolerable while humans did the correlating. It is not tolerable now. A human hitting a gap in a lineage graph asks a colleague. An agent hitting the same gap returns an answer. When an agent is asked what breaks if this table changes, it reads the absence of an edge as the absence of a dependency, and reports a blast radius of three tables when the real number is thirty. Enterprise pipelines routinely reach 2,000 to 3,000 nodes, so nobody is checking its work. Grading each edge is what makes the graph safe for an agent to reason over. An automated workflow can weight a recorded trigger differently from a timing match. It cannot do that when every edge looks the same.
Cross-layer lineage, now in ADOC 26.9.0
ADOC now resolves the relationships between all four layers automatically and renders them as one navigable chain: Airflow DAG, triggered processing job, catalog-registered input and output assets, storage.
The distinction worth holding onto is that ADOC does not replace the lineage those platforms already produce. It consumes it. Unity Catalog, Glue Catalog, Trino Catalog, and Redshift External Catalog are inputs to the stitching process, and each remains authoritative for its own layer. ADOC resolves the edges between them, which is the part no single platform can own, because no single platform sees the handoff.
The full blast radius, in one view
This is the capability everything else depends on. When a source dataset changes or a processing job fails, you trace the complete downstream impact from the Airflow DAG that scheduled the work, through the Spark or Trino job that transformed it, to every catalog-registered asset that was written. No manual cross-referencing across tools.
The chain is built from concrete mappings rather than inference: Trino table to Glue table, Glue table to S3 asset, Unity Catalog table to its storage asset, Redshift external table to Glue table. Where a match exists in the catalog metadata, the edge is drawn.
From alert to root cause without switching tools
A data quality alert on a downstream table used to send an engineer backward through the processing layer to the orchestration schedule by hand, tool by tool. That path is now a single view. In a stack where a DAG can run for four to eight hours before anything downstream is written, the expensive part of an incident is not the fix. It is establishing what ran and what it touched.
Every node in the chain resolves to a real asset. Processing-layer assets identified through OpenLineage events are matched against existing entries in the ADOC catalog, so clicking a node lands you on its detail page with full profile, quality history, and observability data attached. A graph whose nodes carry quality context is the difference between knowing data moved and knowing whether to trust it on arrival.
Audit evidence that maintains itself
Regulated industries need demonstrable provenance from source to consumption, and the usual way to produce it is a documentation project before an examination. Cross-layer stitching maintains that record automatically across storage, transformation, and catalog registration. The graph is computed on every pipeline run, so the evidence is current by default rather than assembled retrospectively.
One lineage view instead of four
Teams stop maintaining separate maps in Airflow, the data catalog, and the processing platform, and stop reconciling them under pressure during an outage. ADOC becomes the single authoritative lineage view across all four layers.
The distinction worth holding onto is that ADOC does not replace the lineage those platforms already produce. It consumes it. Unity Catalog, Glue Catalog, Trino Catalog, and Redshift External Catalog are inputs to the stitching process, and each remains authoritative for its own layer. ADOC resolves the edges between them, which is the part no single platform can own, because no single platform sees the handoff.
To get started: View Documentation
The takeaway, by persona
One graph resolves a different question for each role that touches it.
The key shift: lineage stops being a picture each team interprets separately, and becomes one record every team acts on.
Two prerequisites matter. Airflow needs to be integrated with ADOC through the OpenLineage Airflow provider, emitting events to the ADOC OpenLineage endpoint. Processing engines need to be onboarded as ADOC data sources and configured to emit OpenLineage events, and the relevant catalogs need to be crawled and visible in the ADOC asset catalog before stitching can resolve processing-layer assets.
Beyond that, no additional configuration is required. Once the integrations are in place, ADOC resolves the relationships from the metadata each layer already emits.
Take a look
Cross-layer stitching is available now in ADOC 26.9.0, and it is a foundation rather than a finish line. Deeper column-level traversal across layers, more orchestrators, and richer agent reasoning over the connected graph are what get built on top of it next.
.png)
