lineage-pii-and-governance

Name: lineage-pii-and-governance
Author: vaquarkhan

19stars4forks

How to install lineage-pii-and-governance?

vaquarkhan/data-engineering-agent-skills/lineage-pii-and-governance

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill lineage-pii-and-governance

Installs into the current project.

Summary

Applies governance, lineage, ownership, and sensitive-data controls to data changes. Use when a pipeline touches published datasets, regulated information, or shared business metrics.

Files · 1

View on GitHub

SKILL.md

1	# Lineage, PII, And Governance
2
3	## Overview
4
5	Governance is an engineering concern, not a cleanup exercise. This skill ensures that every meaningful data change accounts for ownership, lineage, access, and sensitive-data handling before release.
6
7	## When to Use
8
9	- publishing a new table, model, or stream
10	- changing business-critical metrics
11	- handling personal, financial, health, or otherwise sensitive data
12	- modifying access controls or data-sharing patterns
13	- changing upstream or downstream lineage
14
15	## Workflow
16
17	1. Identify ownership and consumers.
18	Every published dataset should have:
19	- an owner
20	- intended consumers
21	- known downstream dependencies
22
23	2. Classify the data.
24	Determine whether fields are:
25	- public
26	- internal
27	- confidential
28	- regulated or sensitive
29
30	3. Define required controls.
31	Controls may include:
32	- masking
33	- tokenization
34	- row-level restrictions
35	- column-level restrictions
36	- encryption requirements
37	- retention or deletion rules
38
39	4. Update lineage and documentation.
40	Record how the data flows from source to publish layer, including major transformations.
41
42	5. Verify policy enforcement in implementation.
43	Do not stop at documentation. Check that access and masking rules are actually reflected in code or platform configuration.
44
45	## Common Rationalizations
46
47	\| Rationalization \| Reality \|
48	\| --- \| --- \|
49	\| "It is only internal data." \| Internal datasets still create exposure, misuse, and compliance risk. \|
50	\| "We will document lineage later." \| Lineage that is not updated during change work becomes stale immediately. \|
51	\| "Security will handle masking downstream." \| Sensitive data should be controlled as close to production as possible. \|
52
53	## Red Flags
54
55	- published data has no named owner
56	- sensitive fields are copied without classification
57	- lineage updates are missing for a shared metric
58	- access rules are assumed but not enforced
59
60	## Verification
61
62	- [ ] Dataset ownership and consumers are identified
63	- [ ] Sensitive fields are classified
64	- [ ] Required controls are implemented or explicitly planned
65	- [ ] Lineage and documentation reflect the change
66	- [ ] Governance checks are based on real enforcement, not comments alone

People who liked this also viewed

6 picks

Type

lineage-pii-and-governance

19stars4forks

View on GitHub

How to install lineage-pii-and-governance?

vaquarkhan/data-engineering-agent-skills/lineage-pii-and-governance

$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill lineage-pii-and-governance

Installs into the current project.

Summary

Applies governance, lineage, ownership, and sensitive-data controls to data changes. Use when a pipeline touches published datasets, regulated information, or shared business metrics.

Files · 1

View on GitHub

SKILL.md

1	# Lineage, PII, And Governance
2
3	## Overview
4
5	Governance is an engineering concern, not a cleanup exercise. This skill ensures that every meaningful data change accounts for ownership, lineage, access, and sensitive-data handling before release.
6
7	## When to Use
8
9	- publishing a new table, model, or stream
10	- changing business-critical metrics
11	- handling personal, financial, health, or otherwise sensitive data
12	- modifying access controls or data-sharing patterns
13	- changing upstream or downstream lineage
14
15	## Workflow
16
17	1. Identify ownership and consumers.
18	Every published dataset should have:
19	- an owner
20	- intended consumers
21	- known downstream dependencies
22
23	2. Classify the data.
24	Determine whether fields are:
25	- public
26	- internal
27	- confidential
28	- regulated or sensitive
29
30	3. Define required controls.
31	Controls may include:
32	- masking
33	- tokenization
34	- row-level restrictions
35	- column-level restrictions
36	- encryption requirements
37	- retention or deletion rules
38
39	4. Update lineage and documentation.
40	Record how the data flows from source to publish layer, including major transformations.
41
42	5. Verify policy enforcement in implementation.
43	Do not stop at documentation. Check that access and masking rules are actually reflected in code or platform configuration.
44
45	## Common Rationalizations
46
47	\| Rationalization \| Reality \|
48	\| --- \| --- \|
49	\| "It is only internal data." \| Internal datasets still create exposure, misuse, and compliance risk. \|
50	\| "We will document lineage later." \| Lineage that is not updated during change work becomes stale immediately. \|
51	\| "Security will handle masking downstream." \| Sensitive data should be controlled as close to production as possible. \|
52
53	## Red Flags
54
55	- published data has no named owner
56	- sensitive fields are copied without classification
57	- lineage updates are missing for a shared metric
58	- access rules are assumed but not enforced
59
60	## Verification
61
62	- [ ] Dataset ownership and consumers are identified
63	- [ ] Sensitive fields are classified
64	- [ ] Required controls are implemented or explicitly planned
65	- [ ] Lineage and documentation reflect the change
66	- [ ] Governance checks are based on real enforcement, not comments alone

People who liked this also viewed

6 picks

Type