# Data Governance

Establishes ownership, definitions, quality, access, and lineage for the organization's...

- Repository: https://github.com/cbrock84/headcount (2554 stars)
- Category: Data and ML
- License: MIT
- Last updated: 2026-10-18
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add cbrock84/headcount --skill data-governance -g -a claude-code -y`
Codex: `npx skills add cbrock84/headcount --skill data-governance -g -a codex -y`
Cursor: `npx skills add cbrock84/headcount --skill data-governance -g -a cursor -y`
Gemini CLI: `npx skills add cbrock84/headcount --skill data-governance -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add cbrock84/headcount`

## Description

Establishes ownership, definitions, quality, access, and lineage for the organization's data. Use this when metrics disagree between teams, when nobody knows which dataset is authoritative, when setting up data ownership or access policy, when data quality is unreliable, or before opening a dataset to a wider audience.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Data governance

Governance has a reputation for bureaucracy because it is usually implemented as approval queues.
Done properly it is the opposite: it makes data usable without asking anyone.

## Start with definitions, not policy

The highest-value governance artifact is a metric dictionary. For each business metric:

- The **plain-language definition**, what it counts, and what it deliberately excludes.
- The **computation**, unambiguously: source table, filters, time grain, timezone.
- The **owner**, a person who decides when it is disputed.
- **Known caveats**, when it is misleading, and what changed historically.

Most metric disputes dissolve once both parties read the same definition and discover they were
measuring different things. Almost none require a policy.

Watch the ones that look obvious. "Active customer," "revenue," and "signup" each have half a dozen
defensible definitions, and the ambiguity surfaces at the worst moment.

## Ownership

Every dataset has a named owner accountable for its quality and access, a person, not a team.
Unowned datasets decay, and nobody notices until a decision is made on stale data.

The owner should sit with the business meaning, not with the pipeline. The team that generates the
data understands what it means; the platform team understands how it moves.

## Quality, measured rather than asserted

Test data like code, continuously, and alert on failures:

- **Freshness**, did it arrive when expected?
- **Volume**, is the row count within its normal range? A silent drop to zero is the classic
  failure.
- **Uniqueness and nullity** on key fields.
- **Referential integrity** across joins.
- **Distribution**, has the shape shifted in a way nothing explains?

The point is finding breakage before a decision is made on it. A pipeline that fails loudly is
better than one that silently produces yesterday's numbers.

## Access

The rest: https://github.com/cbrock84/headcount/blob/HEAD/plugins/data-analytics/skills/data-governance/SKILL.md