Classification and lineage
Governance needs to know two things about every piece of data: how sensitive it is and where it came from. In the data platform those are not annotations added later, a classification and a lineage record travel with the asset, and the same is true of a message as of a table.
Classification travels with the data
- Every asset carries a classification. It is part of the asset, not a sidecar catalog entry a query can miss.
- A result inherits its inputs' classification. A governed read produces a result that carries a classification derived from the assets it read, so downstream handling knows the sensitivity of what it holds.
- Tag and classification policy governs catalogued assets and is evaluated as part of enforcement.
For the classification model itself, levels, compartments, and how a classification bounds an action. See Security classification.
Lineage captured on every read
Lineage and provenance are captured as a by-product of the read, backed by a coverage registry, so the platform can answer "where did this come from" and "what will break if I change this" from recorded fact rather than reconstruction. See the catalog and lineage for the catalog surface over these records.
Honesty about propagation and SLAs
What not to claim
- Classification tags do not propagate automatically along lineage. Capture and policy are the describable capabilities; automatic tag propagation is not a claim to make.
- Data-product SLA definitions exist, but SLA enforcement is not a claim. A data product can carry a contract; the enforcement of that contract is not active.
Across the deployment matrix
- Single-cell and multi-cell: an asset keeps its classification and lineage as it replicates across cells.
- Sovereign / air-gapped: classification and lineage are recorded locally on the cell; nothing depends on an external service.
- Cloud-enabled: the same records, reachable through the catalog and open interfaces.