Introduction

Scenario: Across a multi-program enrollment, an intelligence-fusion dataset has started ingesting raw contact reports that contain personally identifiable information no analyst was cleared to bulk-handle, and your governance team must lock down the exposure automatically and prove a deletion clock now governs the data it feeds.

This unit moves you from setting access boundaries to operating governance continuously across the data lifecycle. The previous units established who may see a resource — Organizations, Projects and roles, Markings, CBAC, and Restricted Views. Here you operationalize the other half of data protection: understanding the blast radius of a change with Data Lineage, putting an enforceable retention clock on data with Data Lifetime, and catching sensitive data the moment it lands with the Sensitive Data Scanner so that a Security Marking is applied automatically rather than waiting on a human to notice. For a defense org admin, this is the difference between a one-time access decision and a governed pipeline that stays compliant as new data arrives.

The driving problem is concrete. A fusion dataset in one program's Project is now pulling in contact reports with embedded PII, and that root dataset feeds downstream datasets that analysts across the enrollment query daily. Three governance tools answer three distinct questions. Data Lineage answers 'if I change or delete this, what else is affected?' — it is the impact-analysis graph spanning the root and its downstream derivations. Data Lifetime answers 'how long are we legally and operationally allowed to keep this?' — it applies a lineage-aware retention policy, either a fixed deletion date or latest-view-only, and crucially deleting a transaction also deletes the downstream transactions derived from it. The Sensitive Data Scanner answers 'how do we catch this automatically?' — it scans data with match conditions and fires a match action, and the action you will configure applies a Security Marking, turning a detection into an immediate mandatory lockdown.

Your deliverable is a retention policy applied to the root dataset plus a Sensitive Data Scanner scan whose match action applies a Marking, with that Marking verified as present on the affected dataset. A central honesty theme runs through this unit: the live check can confirm the Marking side-effect via the Get Access Requirements preview endpoint and confirm the governed datasets resolve, but it cannot read back the Data Lifetime retention configuration, the Lineage graph, or the SDS scan definition — no public READ API enumerates them. Those are documented, self-attested checkpoints, and you will record them precisely so a reviewer can audit the governance posture even though the platform exposes no API to confirm the configuration directly.

Capability focus: Data Lineage (impact); Data Lifetime (fixed-deletion vs latest-view-only retention); Sensitive Data Scanner match conditions → apply-Marking match actions. · Artifact: A retention policy plan + an SDS scan whose match action applies a Marking, verified on the affected dataset.

Key concepts

Companion video

1. 1

   Confirm the SDS-applied Marking is present on the scanned dataset

   This step verifies the side-effect of the Sensitive Data Scanner, not the scan itself: after the scan's match action runs, the Security Marking should now be present on the scanned root dataset. Configure the SDS scan with a match condition that detects the PII (a built-in PII pattern, a regex, or overlap with reference data) and an apply-Marking match action that attaches your Security Marking; once data matches, the Marking is applied automatically and becomes a mandatory conjunctive control. The live check calls Filesystem Get Access Requirements on the scanned dataset with preview=true and confirms the expected Marking appears among the resource's access requirements (which combine conjunctive Markings with disjunctive Organizations). Note two honesty points: this is a preview endpoint, so confirm it is enabled in your environment, and a failure surfaces as 'blocked' rather than a silent pass — it verifies the Marking effect on the dataset, not the scan configuration that produced it.

   not startedinstance check

   Run check

   Confirms the Sensitive Data Scanner match action's side-effect: the Security Marking is now on the scanned dataset.

2. 2

   Confirm the governed datasets exist for the lineage/retention scope

   Retention and lineage only make sense across an actual dependency chain, so this step confirms the governed datasets resolve: the root dataset that ingests the PII and at least one downstream dataset derived from it. The retention policy you apply to the root is lineage-aware — deleting a transaction on the root deletes the downstream transactions derived from it — so both ends of the chain must exist for the policy to have meaning. The live check resolves the root and the downstream dataset by their keys and confirms they return with schemas, establishing the span the Data Lifetime policy and Data Lineage impact review cover. This is an existence check only: the actual deletion behavior is time-based and cannot be asserted synchronously, so the check proves the lineage chain is in place, not that any data has yet been deleted.

   not startedinstance check

   Run check

   Confirms the root and a downstream dataset resolve with schemas (the lineage chain the retention policy spans).

3. 3

   Document the Data Lifetime retention policy configuration

   This is a documented, self-attested checkpoint: no public READ API enumerates Data Lifetime retention configuration, so the platform cannot machine-confirm it and you must record it for a reviewer to audit. Write down the policy type you applied to the root dataset — Fixed deletion date versus Latest view only — and explain why it fits the mission data's legal and operational retention requirement. Record the namespace the policy is governed under and the governance role responsible for it (Namespace Viewer, Dataset Editor, or Data Governance Officer, with the Data Governance Officer typically owning policy decisions). Critically, attest that you understand the lineage-aware behavior: deleting a transaction on the root also deletes the downstream transactions derived from it, so retention propagates through the pipeline confirmed in the previous step. This attestation is the audit record that stands in for an API the platform does not provide.

   not startedself-attested

   Mark complete

   Self-attested: the Data Lifetime policy type (fixed deletion date vs latest view only), namespace, and governance role.

4. 4

   Document Data Lineage impact review and SDS scan definition

   This is also a documented, self-attested checkpoint, because neither the Data Lineage graph nor the Sensitive Data Scanner scan definition is exposed by a public READ API here. First, record your Data Lineage impact review: which downstream datasets and consumers depend on the root, so you can state the blast radius before retention deletions or Marking application take effect across the enrollment. Second, record the SDS scan definition you built — the match condition (regex, overlap with reference data, or a built-in PII pattern) and the match action you chose, which for this unit is apply-Marking (the alternatives being create-Issue or obfuscate-via-Cipher) — and whether the scan is one-time or recurring as new data arrives. Because the apply-Marking effect was confirmed live in step one, this attestation documents the configuration behind that verified side-effect so a reviewer can audit the full governance posture even though the definition itself is not API-readable.

   not startedself-attested

   Mark complete

   Self-attested: the downstream impact reviewed in Data Lineage and the SDS match condition + apply-Marking action chosen.