Business Lineage Rules | Kada Knowledge Base

UDPATED IN RELEASE 6.1

Business Lineage propagation follows a small set of rules. This page groups all 12 rules into five types, each with a diagram you can read on its own, plus the exact mechanics underneath if you want them.

Tip: How to quickly identify if an attribute has been propagated or directly linked

Propagated attributes always start with the prefix “business_”. For example:
- Direct link: relates_to
- Propagated link: business_relates_to

The Three Propagation Mechanisms

Almost every rule below is a variation of one of these three ways an attribute can move from one asset to another.

Propagation Mechanisms	Direction	Applies to
Roll up	Column → its own parent table (one level only)	Terms, Warnings, Issues, DQ Tests
Push down	Table → its own columns (one level only)	Layer, System of Record
Propagate along lineage	Any upstream asset → any downstream asset, any number of hops	Terms, Warnings, Issues, DQ Tests, Source in K, System of Record

5 Groups of Propagation Rules

Core Mechanics (rules 1-4) — How Layer, System of Record, and other attributes move by default
How Paths Combine (rules 5-6) — What you see when table-level and column-level paths both reach the same asset
Manual Edges (rule 7) — Two ways to manually connect two tables, and what each one carries
Deletion (rules 8-9) — Removing an asset or attribute stops propagation, with one exception
Hidden Flags & Suppression (rules 10-12) — What looks like it should block propagation, and what actually does

Group 1: Core Mechanics

How Layer, System of Record, and other attributes move by default.

Rule 1: Layer Is Inherited by Columns, Not Chosen by Them

If a table is set to the Raw layer, every column in it automatically shows Raw too, greyed out, because you can't change it at the column level. Set the table to Consumption instead, and its columns follow.

Under the hood

Follow the chain from Raw to Consumption to Presentation.
Each table's own columns show the same Layer as their table, marked as inherited and locked — you can't override it at the column level.
This is push-down in action: Layer is only ever set on the table itself, and it flows down exactly one level, to that table's own columns.

Rule 2: Column Attributes Roll Up Once — Then Stop

Link a Term to Column A and it correctly shows up on Column B too, thanks to a direct lineage link between them. It also shows up on both columns' parent tables (rolled up). But it doesn't keep travelling further down the table chain.

Under the hood

Column A is linked directly to a Term.
Because Column A feeds Column B through lineage, Column B picks up that Term too, marked as propagated rather than direct.
Both parent tables, Raw and Consumption, then show the Term as rolled up.
It stops there: Consumption 2 and Presentation show no Term at all — a roll-up doesn't keep travelling downstream on its own.

Rule 3: System of Record Propagates Across Tables and Pushes Down

Set a System of Record on the Raw table, and it shows up on Consumption and Consumption 2 downstream (arriving "via propagated upstream"), and it also correctly shows up on all of Raw's own columns.

Under the hood

The System of Record is linked directly to the Raw table.
From there it travels two ways at once:
- Downstream to Consumption and Consumption 2, where each shows it as arrived from upstream.
- Down to Raw's own columns, where each shows it as inherited from its table.
System of Record is the only attribute that does both at the same time — but it never moves directly from one column to another the way Terms do.

Rule 4: Table-Level Attributes Never Push Down to Columns

A Warning linked to the Raw table correctly shows up on Consumption and Presentation downstream. But check the columns that belong to those tables, the Warning isn't there. Warnings roll up and propagate along lineage, but are never pushed down.

Under the hood

A Warning is linked directly to the Raw table.
It travels downstream as expected: Consumption and Presentation both pick it up, marked as propagated.
But look at the columns belonging to those same tables — none of them show the Warning.
This is the mirror image of Rule 3: Layer and System of Record travel down to columns, but Warnings, Terms, Issues, and DQ Tests never do.

Group 2: How Paths Combine

What you see when table-level and column-level paths both reach the same asset.

Rule 5: Linked at Both Levels? Both Views Show It — Independently

If WarningA is linked directly to the Raw table, and separately, directly, to Column A within that table (Column A belongs to Raw), you'll see it in both places when you look: once on the table-level Business Lineage view, once on the column-level Business Lineage view. Neither link depends on the other.

Under the hood

The Warning is linked directly in two separate places:
- Once to the Raw table itself.
- Once to Column A, which belongs to that table.
Each link works completely on its own:
- The table-level link carries the Warning table-to-table as normal.
- The column-level link separately rolls it up and carries it column-to-column.
Changing or suppressing one link has no effect on the other.

Rule 6: How Layer and Attribute Paths Combine Downstream

When you land on an asset's Business Lineage tab, what you see is a blend: the Layer badge always comes from the table-level chain only, while any Warnings, Terms, or Issues you see could have arrived via the table chain, the column chain, or both.

Under the hood

Table A is set to the Raw layer and linked to a Warning.
Table B is set to Consumption, and its Column 123 (which inherits Consumption) is separately linked to that same Warning.
On Table B's Business Lineage tab:
- The Layer badge shows Raw — coming only from the table-to-table path.
- The Upstream Warnings list shows the Warning from both the table path and the column path combined, since Warnings can arrive either way.

Group 3: Manual Edges

Two ways to manually connect two tables — and they carry different things.

Rule 7: Manually-Added Edges: Business vs. Technical Lineage

There are two different ways to manually draw a connection between two tables, and they're not interchangeable. A manually-added Business Lineage edge only tells K "this table sits upstream for layer purposes," it won't carry Terms or other attributes across. A manually-added Technical Lineage edge behaves like a real, discovered lineage edge: it carries everything.

Under the hood

With a manually-added Business Lineage edge: Table A (which has a Term linked to it) is manually connected to Table B, which then connects on to Table C.
- Table B correctly picks up Table A as its Raw layer source.
- But the Term never reaches Table B.
With a manually-added Technical Lineage edge instead:
- The same kind of connection now carries the Term as expected.
- Table A is correctly recognized as the Raw source two hops away, at Table C.

Group 4: Deletion

Removing an asset or attribute stops propagation — with one exception.

Rule 8: A Deleted Asset in the Path Stops Propagation

If a table partway along a lineage chain gets deleted, nothing beyond it will show that chain's upstream context anymore, not the layer reference, not any attribute that was travelling through it.

Under the hood

Table X feeds into Table A, which feeds into Table B, and a Term is linked to Table A.
Once Table A is deleted, Table B stops showing both the upstream Raw reference and the Term — neither one makes it across the gap left by the deleted table.
This holds whether the deleted asset is a table or a column.

Rule 9: A Deleted Attribute Stops Propagating — Except Warnings

Deleting the Term, Issue, DQ test, Source in K reference, or System of Record object itself (as opposed to the table it's attached to) also stops it from propagating. Warnings are the one exception, a deleted or inactive Warning keeps propagating as if nothing happened.

Under the hood

General case: a Source in K reference gets deleted while the table it's linked to, Table A, stays intact. Table B, downstream, no longer shows that Source in K reference.
Exception: do the same thing with a Warning instead — delete the Warning but keep Table A, and Table B still shows the Warning anyway. Warnings ignore this rule entirely.

Group 5: Hidden Flags & Suppression

What looks like it should block propagation, and what actually does.

Rule 10: "Hidden" Flags Do Not Block Propagation

Some objects can be marked hidden, either hidden within K itself, or hidden at the source system. That's a visibility setting, not a deletion, and it doesn't interrupt propagation.

Under the hood

Mark a Source in K reference as hidden in K, then link it to Table A, which feeds into Table B.
Table B still correctly shows both the upstream Raw reference and the Source in K reference — the hidden flag made no difference.
The same is true if it's marked hidden at the source system instead.
Only deletion blocks propagation — hiding something never does.

Rule 11: Suppressing an Item Doesn't Stop It Propagating — Unless Deleted Too

If you suppress a Term on one table because it's noise there, that suppression is local, the term still shows up correctly on the next table downstream, exactly as if you hadn't touched it. Suppression only disappears from the chain if the table carrying it is also deleted.

Under the hood

Table X feeds into Table A, which feeds into Table B.
Suppress a Term on Table A without deleting anything, and Table B still shows that Term arriving from upstream — suppressing it on Table A didn't stop it travelling further.
Now also delete Table A, and Table B stops showing it entirely.
Deletion overrides everything; suppressing an item by itself does not.

Rule 12: Suppressing the Lineage Edge Itself Does Block Propagation

There's a difference between suppressing an attribute on an asset and suppressing or deactivating the lineage connection between two assets. The first doesn't block downstream propagation (see Rule 11). The second does, because the path itself is broken.

Under the hood

Table X feeds into Table A, but this time the lineage connection between them is marked suppressed or inactive — not the tables or the Term themselves.
Table B no longer shows the upstream Raw reference or the Term, even though nothing was deleted.
A suppressed connection simply isn't a path K will carry anything across.

Change history

Version 6.1 · 2026-08-17

New New page. Business Lineage feature released as part of Version 6.1.

Last updated: August 08, 2026