Label Inheritance

A sensitive table is labelled and protected. Someone joins it with two other tables and writes the result to a new dataset, which carries no label — and therefore no controls.

Label inheritance closes that gap by propagating classification through lineage: a derived dataset takes the highest sensitivity of everything that fed it, automatically, at creation.

Why manual classification cannot cover this

Manual labelling depends on the person creating the data knowing the taxonomy, caring, and choosing correctly at the moment they are focused on something else. Applied to derived data it is worse still, because derivation happens constantly and most derived datasets are created by people who never saw the source's label.

The result is a predictable pattern: sources are labelled, derivatives are not, and the estate's protected proportion falls steadily as analysis proceeds.

Implementation patterns

• Propagation through lineage at creation, defaulting to the maximum of the inputs.
• A small taxonomy — three or four levels people can hold in their heads. A twelve-level scheme is applied inconsistently, which is worse than a coarse one applied uniformly.
• Automated inference on sources from content scanning, schema rules and source-system defaults, with humans confirming rather than originating.
• A documented downgrade path — aggregation or masking genuinely does reduce sensitivity — but as an explicit, reviewed, logged action rather than a default. Automatic downgrade is how classification erodes.
• Labels bound to enforcement: access, retention, encryption, export. Consequence is what keeps classification current; a label that changes nothing is not maintained.
• Unlabelled data defaulting to the more restrictive level, converting a silent hole into visible friction that someone resolves.

Industry example

Platforms holding both their own data and customer-owned content find that one dimension is not enough. Content uploaded by a customer carries the customer's obligations, which may exceed the platform's own defaults — so the label has to record whose data it is alongside how sensitive it is, and inheritance must carry both.

The same distinction appears in any multi-tenant or partner-data setting: sensitivity and ownership are independent axes, and a scheme with only the first cannot express "not ours to decide about".

Failure scenarios

• No propagation, so derived data is unprotected and the gap widens with every transformation.
• Automatic downgrade on aggregation, which is exactly the case where [[differencing-attack]] risk survives the aggregation.
• Lineage coverage gaps, where data moved by an unmonitored path arrives unlabelled — inheritance is only as complete as the lineage.
• Labels with no enforcement, which decay because nothing depends on them.
• A taxonomy too large to apply consistently.

Trade-offs

Taking the maximum over-classifies: a dataset containing one sensitive column is entirely restricted, which constrains legitimate analysis and pushes users toward extracting the harmless columns manually — an unmonitored path that produces the exact gap the scheme was meant to close.

Column-level labelling with masking is the better answer where the platform supports it, since it keeps the dataset usable while protecting the parts that need it. Where it does not, the reviewed downgrade path is what keeps over-classification from becoming a workaround generator.

Interview question

"An analyst joins a restricted customer table with two open tables and saves the result somewhere new. What should happen automatically, and what breaks if it does not?"