Preview draft. Copy and visuals are pending review and may change before launch.

Concept

Authorization and data lineage for derived data

Whether a derived artifact is safe to share more broadly than its source depends entirely on what was actually done to produce it — a question its shape alone can't answer.

← Back to the library

Data, Access Models, and Boundaries · Published 2026-09-06

A derived artifact's classification doesn't follow automatically

Derived data is produced by computing, aggregating, or transforming other, source data, rather than being collected directly — a dashboard built from raw event logs, a risk score computed from underlying records, a cached summary of a larger dataset. None of these automatically inherit the exact classification of their source, and none of them automatically escape it either; what actually determines the right answer is the specific transformation applied, not the fact that a transformation happened at all.

Data lineage — a traceable record of where a piece of data came from and what transformations produced it — is what makes this question answerable rather than a guess. Without lineage, an artifact's actual sensitivity has to be inferred from its shape or simply assumed, neither of which reliably gets the answer right.

Two symmetric mistakes this prevents

The failure runs in both directions, and lineage guards against both equally: treating a summary as automatically safe because it's 'just an aggregate,' when it can still leak sensitive information depending on how it was aggregated; and treating every derived artifact as automatically as sensitive as its source, when a genuinely well-designed aggregation may in fact be safe to share considerably more broadly than the raw records it was built from. Getting either direction wrong either exposes something that shouldn't be exposed, or needlessly restricts something that didn't need to be restricted.