11.1 Governance Responsibilities and Decision Authority: Every Rule Must Have an Explanation, an Executor, and an Exception Approval Process

The data platform now hosts hundreds of pipelines. In the task system, mission_status means "the task is complete"; in the inventory system, it means "inventory has been settled." Both teams claim authority. When data errors occur, the platform team says it only manages runtime, while business teams say they did not build the data model. No one can decide which definition should prevail.

Data governance begins with defining decision authority, not with hastily building a catalog. Who defines the rules? Who produces the data? Who enforces controls? Who bears responsibility for impact? And when conflicts arise, who has the authority to resolve them?

Learning Objectives

• Distinguish the responsibilities of data owner, steward, custodian, and consumer;
• Identify key data elements and establish authoritative sources;
• Translate principles into actionable controls, exceptions, and evidence;
• Design governance processes for data changes, conflicts, and retirement.

1. Governance Goes Beyond Approval Count

Governance should make correct usage easier and expose incorrect usage earlier. It must at least answer these questions:

Which data is critical for key decisions?
Who approves business definitions?
Who is responsible for production quality?
Who implements platform controls?
Who can access data and for what purposes?
Who is affected by changes, and how are they notified?
Who resolves rule conflicts and exceptions?
When should data be retained, archived, or deleted?

If rules exist only as PDFs (without system controls, defined owners, or operational evidence) they remain just aspirations. Conversely, sending every request to a central committee creates bottlenecks and leads to shadow data.

2. Four Responsibilities Must Be Clearly Defined

Organizations may differ in name or structure, but roles must cover these four key responsibilities:

Data Owner

Responsible for the business meaning, permitted uses, quality objectives, and risk acceptance, ultimately holding decision-making authority. The owner should be a business leader capable of mobilizing resources and bearing the impact of decisions, rather than an engineer assigned by default alone.

Data Steward

Maintains terminology, rules, classifications, and issue tracking; coordinates between data producers and consumers. The steward drives ongoing governance, but should not be expected to independently resolve all issues.

Data Custodian / Platform Owner

Responsible for implementing storage, backup, access control, encryption, logging, and platform reliability. This role handles the technical execution of controls and does not automatically inherit business definitions.

Producer and Consumer

The producer maintains the logic for data generation and the data contracts. The consumer defines use cases, validates outputs, and reports issues when problems arise. A consumer cannot avoid responsibility simply because they are "only reading" data.

An individual may hold multiple roles, but each decision must have a single, clearly defined accountable owner.

These are four responsibility categories; producer and consumer remain distinct roles. In RACI, R performs the work, A is ultimately accountable, C is consulted, and I is informed. An illustrative assignment is:

Decision or work	R	A	C	I
Define task completion state	Task steward	Task business owner	Settlement owner, consumers	Platform team
Implement and validate state mapping	Producer	Task business owner	Steward, consumers	Platform team
Deploy field access controls	Custodian	Platform control owner	Data owner, security lead	Producers, consumers

This is an example allocation, not a universal role standard. Multiple A assignments should not leave one decision waiting on everyone else. Conflicts spanning distinct authoritative facts need an agreed escalation route.

3. Start with Key Data Elements

You don’t need to govern every field on day one. Begin by identifying Critical Data Elements (CDEs): those that directly impact financial outcomes, operational decisions, security posture, compliance requirements, or key customer decisions.

For each CDE, document the following:

Business name and definition
Calculation methodology, units, and granularity
Allowed values and meaning of nulls
Primary authoritative source and derived copies
Owner, steward, producer
Purpose of use and sensitivity classification
Data quality SLOs and controls
Key downstream decisions
Change and retirement processes

“Critical” must be justified and reviewed with a scheduled re-evaluation date. If all fields are labeled as highest priority, governance resources risk losing focus and prioritization.

4. Authority is Not the Largest Table

A System of Record defines the authoritative boundary for maintaining a class of facts. For example, employee contracts are maintained by the HR system, and telemetry from tasks are recorded by an event platform. While wide tables can be easier to analyze, they should not serve as sources of truth for identity facts unless there are defined write-back rules.

The same entity may have multiple authoritative dimensions, identity, status, and financial settlement each managed by different systems. It is essential to define:

• Primary keys and identity resolution rules;
• Update order and conflict resolution priorities;
• How late arrivals, corrections, and revocations propagate;
• Temporary sources when the authoritative system is unavailable;
• How reconciliation occurs after recovery.

The "single source of truth" principle requires that every fact have a clearly defined write authority and conflict resolution mechanism, without requiring all data to be replicated into a single location.

The opening conflict need not end with one table winning. Task completion and inventory settlement are separate facts. Name them execution_status and settlement_status, maintain separate state machines, and explicitly define any combined business-ready state. One boolean field merely hides the disagreement inside the schema.

5. Rules Must Connect Control with Evidence

A governance policy can be broken down into:

Purpose: Why is this rule necessary?
Scope: Which data, systems, and use cases are covered?
Requirements: What must or must not happen?
Control: Is it enforced through code, configuration, or manual steps?
Evidence: Where are logs, audit results, or approval records stored?
Owner: Who monitors and resolves issues?
Exceptions: Who can approve exceptions, for how long, and what compensating controls exist?
Review: When must it be re-evaluated due to environmental changes?

For example, a rule like "sensitive fields are accessible only for authorized purposes" requires field classification, policy enforcement points, access logging, periodic reviews, and an emergency access process, rather than a slogan alone.

An exception needs scope, approval grounds, compensating controls, and an expiry action. For temporary analytical access, revoke access at expiry and check cached credentials and derived exports. A date in a ticket does not expire a permission. Internal risk acceptance by a business owner cannot override external legal or contractual constraints.

6. Federated Execution and Central Baselines

The central team is well-suited to maintain cross-domain baselines: identity, classification, audit formats, interoperability standards, and thresholds for major risks. Domain teams, on the other hand, are closer to data semantics and are better positioned to manage definitions, quality rules, and product commitments.

Federated governance is not about working in isolation. It requires:

• A small number of non-negotiable global standards;
• Scalable domain-specific rules;
• Machine-checkable common interfaces;
• A mechanism for resolving cross-domain disputes;
• Transparent records of exceptions, outstanding obligations, and expiration timelines.

7. Data Schema Changes Also Require Compatibility Strategies

Adding nullable columns generally poses low risk, but renaming fields, changing units, altering enum meanings, or backfilling historical data can disrupt downstream systems.

Even a nullable column addition can break positional CSV readers, strict schema checks, or SELECT * consumers. Changing seconds to milliseconds while retaining the numeric type can pass schema checks entirely. Compatibility covers format, units, missing-value meaning, and business interpretation.

The change process must at least include:

1. A clear statement of semantic, technical, and privacy impacts;
2. Identifying consumers via data lineage;
3. Selecting between a compatibility window, dual-writing, or a new version;
4. Publishing sample data and migration guidance;
5. Monitoring discrepancies between old and new data views;
6. Confirming with consumers that migration is complete before retiring the old version;
7. Retaining and verifying documentation of all decisions and outcomes.

Emergency fixes can follow a fast track, but post-incident logging and impact review must never be skipped.

8. Governance Meetings Should Focus on Decisions

An effective governance rhythm can include:

• Resolving definition conflicts and addressing high-priority quality incidents weekly;
• Reviewing exceptions, overdue fixes, and critical data SLOs monthly;
• Quarterly reassessment of CDEs, purposes, retention policies, and owners;
• Impact and risk reviews prior to major changes.

Meeting outputs must be decisions, owners, deadlines, and evidence locations. Reporting dashboards without assigning actions turns governance into a performative process.

Common Misconceptions

• Platform teams are naturally the sole owners of all data: While platform teams control storage, they don’t necessarily define business semantics.
• Forming a committee guarantees governance: Decision-making authority and execution control may still be absent or unenforced.
• Managing all fields at the same level is the fairest approach: Critical risks often receive insufficient resources as a result.
• A System of Record must be a single central database: Authority boundaries can be distributed based on the nature of the facts being recorded.

Exercise

1. Create a RACI matrix for mission_status and designate the final decision authority.
2. Select five Critical Data Elements from a business process and explain why each is critical.
3. Rewrite "Data must be secure" in terms of scope, controls, evidence, exceptions, and review.
4. Design a compatibility, notification, and retirement process for changes in enum semantics.

Summary

Governance must ultimately result in an executable decision system, rather than more paperwork alone. When responsibilities for definition, production, platform, and usage are separated, conflicts have a clear arbiter, rules gain enforceability, and exceptions don't become permanent.

The next lesson shifts focus to data quality operations: which metrics constitute service commitments, and what actions are taken when issues arise, blocking, isolating, degrading, or alerting.