Data Governance Explained: Ownership, Definitions, and Trust

Three order counts, one meeting

At a small shop, marketing reports 100 orders, operations reports 80, and the management dashboard shows 70. The first response is to ask the data engineer to fix the query. But a query cannot decide what the organization means by an order. Before changing code, the team needs to identify the question behind each number, the records used, and the person authorized to settle disagreements.

Data governance establishes decision rights, responsibilities, and rules for how data is defined, used, changed, and cared for. Data management carries out the work, such as storing records, applying checks, and maintaining documentation. The activities overlap in practice. Governance is effective when a person facing a real decision can find the rule, its owner, and the evidence needed to act—not simply when a policy document exists.

Separate a different definition from a broken calculation

Use the following fictional dataset. It contains 100 distinct orders created in one reporting day, all viewed at the same cutoff. Their states at that cutoff are mutually exclusive: 70 were paid and not refunded, 10 were paid and then fully refunded, 15 were awaiting payment, and 5 were cancelled without payment. There are no partial payments, partial refunds, or duplicate order IDs in this example.

Question	Included orders	Result
How many orders were created?	All four groups	70 + 10 + 15 + 5 = 100
How many had been paid by the cutoff?	Paid and not refunded, plus fully refunded	70 + 10 = 80
How many paid orders remained unrefunded at the cutoff?	Paid and not refunded	70

All three calculations match their stated questions. Calling every result “orders” hides the difference. Governance does not require forcing all teams to use 70; it requires names and definitions that let people distinguish the measures and use the right one. These are order-count measures, not revenue or accounting definitions. If two reports claim to implement the same measure for the same scope and cutoff but disagree, investigate the source coverage and transformations as well as the wording.

Definitions also need time. If one of the 70 orders is refunded tomorrow, a report “as known at yesterday’s cutoff” can remain 70, while a restated report of yesterday’s order cohort can become 69. Neither behavior should be accidental. State whether history is frozen at a cutoff or recalculated with later information, and label revisions so a changed number can be explained.

Also distinguish when an event happened from when the reporting system learned about it. A payment made at 23:58 but received by the reporting system at 00:03 was not known there at midnight. An “as known” report excludes that late information; a restatement based on event time may include it. The example below uses information available before the cutoff. Reproducing that view requires preserving what was available then, not merely filtering today’s records by event time.

Ownership gives someone a decision to make

Here, a data owner is accountable for decisions within an assigned data scope. A steward maintains definitions and coordinates day-to-day quality work. A custodian operates technical storage and controls. Titles vary; this is a responsibility model, not a requirement to hire three people. The UK government’s data ownership model provides a formal example of this separation.

In this shop	Assigned responsibility	A decision or action
Commerce lead: owner of order reporting	Agrees the reporting purpose, definitions, and priorities with affected teams	Approves separate names for the three order measures
Analyst: steward	Maintains the definitions, examples, consumer list, and issue record	Checks whether a reported discrepancy is semantic or technical
Data engineer: technical custodian	Implements collection, transformations, checks, and agreed access controls	Repairs a missing-file load and records which outputs changed
Report users and source-system team	Explain use requirements and source behavior; report changes and defects	Notify the steward of a new payment state or an unexplained total

Assign a person or a staffed role, a backup, and a scope. “The data team” is not enough if nobody has authority to approve a definition or prioritize a repair. Ownership here means organizational accountability, not a claim of property rights over people’s information. An owner also cannot override organization-wide restrictions merely by approving a request. Scope-specific decisions must fit the broader rules for permitted use and access.

A combined data product needs its own accountable owner even when its sources already have owners. For example, a report joining orders and support cases needs someone responsible for the combined definition and its fitness for that report. Source owners remain responsible for their source scopes. When teams cannot agree, escalate to a named business authority with the competing uses and impacts documented; do not let the engineer silently choose a definition in code.

Write a definition that another person can implement

A business glossary records meanings of terms such as “paid order.” A data catalog helps people find datasets and their metadata, including descriptions, owners, and available quality information. A glossary can be maintained inside a catalog, but recording a description does not enforce it in every query. Connect the approved definition to the implementation and check the connection when either changes.

For the shop, a compact metric definition record could look like the following. Its version identifies the rule; the source snapshot and cutoff identify the data to which the rule was applied. The limits are part of the definition: a rule for this simplified dataset is not ready for sources that include partial refunds without further decisions.

Measure: paid_orders_not_refunded_v1
Purpose: track retained paid-order count for the daily management report
Unit counted: distinct order_id
Cohort: creation time from 00:00 UTC inclusive to next 00:00 UTC exclusive
Cutoff: next 00:00 UTC; only information available before it is used
Time rule: payment and refund events must also occur before the cutoff
Include: paid by the cutoff and not fully refunded by the cutoff
Exclude: unpaid, cancelled without payment, and fully refunded orders
Scope limit: partial payments and partial refunds are not supported
On unsupported states: flag or withhold the affected result; do not silently drop them
Source: approved order snapshot, with extraction and cutoff recorded
Accountable owner: commerce lead; steward: reporting analyst
Implementation: reporting query version and its tests
Change rule: approve, version, test, and notify affected consumers

To reproduce a cutoff-based result, retain an authorized snapshot for that cutoff or sufficient history to reconstruct it. Reading current states tomorrow cannot necessarily recover what was known yesterday. The data grain describes what one output row represents. A table might contain one row per reporting day and shop, even though the measure counts distinct orders. Confusing the output grain with the counted entity can create duplicates when tables are joined. Also identify the authoritative source for each fact: the order system may define creation time, while a payment system supplies payment events. One warehouse is not automatically the authority for every meaning just because it stores the copies.

Quality is measured against the intended use

A dataset can be suitable for a weekly trend report and unsuitable for deciding whether a particular customer has paid. The required detail, delay, and consequences differ. The Government Data Quality Framework organizes quality around fitness for purpose. In practice, identify the use, choose checks that provide relevant evidence, and agree what should happen when they fail.

Common data quality dimensions ask different questions. Completeness concerns required records and values being present; uniqueness concerns unwanted duplication of the entity being represented. Consistency concerns agreement where facts should agree, and timeliness concerns availability when needed. Validity concerns compliance with allowed formats, ranges, and rules; accuracy concerns whether values reflect reality. A permitted payment status can still be wrong for a particular order, and complete records can still contain errors. The UK guidance on quality dimensions explains these distinctions. For the shop, the distinction becomes concrete in the following checks.

Check	Evidence it provides	Remaining limit
Compare received files with an expected source manifest	Whether expected deliveries are present	The source manifest itself may be wrong or incomplete
Require one source snapshot row per order ID	Whether the chosen representation duplicates keys	Distinct IDs do not prove distinct real purchases
Reject unknown payment-state values	Whether values fit the approved vocabulary	A permitted value can still have been assigned incorrectly
Compare totals by state with the designated source at the same cutoff	Whether this transformation agrees with that reference	Agreement cannot prove the reference recorded reality correctly
Check that the accepted report is available by the agreed time	Whether the refresh commitment is met	A timely report can still be incomplete or inaccurate

A quality rule needs a response and an owner. An unknown payment state can be isolated while the steward and source team determine its meaning, but the affected result must be flagged as incomplete or withheld rather than silently presented as a full count. A late noncritical report might keep its previous version with a visible timestamp. A payment-status decision may need to stop until evidence is available. These policies depend on the use; a single “99% quality” badge does not say which errors remain or whether they matter.

A new source value is a governance event

Suppose the source introduces partially_refunded. The engineer can update a filter, but should not decide alone whether that order belongs in the existing measure. The current definition does not specify how to count this unsupported case. That is a limit of the rule, not permission to silently remove the order. Apply the agreed quality response while the meaning is resolved. The source team explains the event and its timing; report users explain their decisions; the owner chooses whether to extend the measure, create another one, or retain the existing scope. The steward records the decision and examples.

Version the agreed change and test boundary cases before switching consumers. Use lineage, the recorded dependencies from sources through transformations to outputs, to find affected reports, exports, and AI applications. Lineage can be incomplete, so confirm important consumers with their owners. State the effective date, whether old periods will be recalculated, how old and new values compare, and when the previous definition will be retired. A column that keeps its name while changing meaning can break a consumer without causing a software error.

Close the issue in the source-to-consumer path

Imagine that the 100-order file arrives with only 95 records. A steward opens an issue with the affected scope, cutoff, expected and observed counts, and the outputs that may be wrong. The engineer checks extraction and loading; the source team checks what was produced. The owner or a delegated decision-maker applies the agreed policy for publishing, labeling, or blocking the affected result. Logging the issue does not itself protect a report that remains in use.

After repair, rerun the affected calculations and compare keys and relevant totals, not just the number of rows. Notify users if published results changed. Close the issue with evidence of restored coverage, corrected outputs, and any remaining limitation. If an exception must be accepted, record its scope, reason, approver, expiry, and review trigger. An indefinite exception with no reviewer quietly becomes an undocumented rule.

Start with one decision that repeatedly causes trouble

A small team can begin with one important dataset and its consumers: assign responsibility, document the disputed terms, implement a few meaningful checks, and record changes and incidents where people can find them. A shared document and a controlled issue tracker may be enough for this first scope. A catalog becomes useful when discovery and dependency management exceed what the team can reliably maintain by hand. The tool should support the agreed work rather than stand in for it.

Evaluate progress through actual decisions. Can a report user find the definition and owner? Can the team explain a revised number? Does a quality alert reach someone able to respond? Are affected consumers told before a meaning changes? More catalog entries or more meetings do not establish those outcomes. Trust grows when people can see what a result means, what evidence supports it, and what happens when it is wrong.

Govern useful combinations before collecting more

Combining purchase history with customer reviews may help explain demand, but additional data is not automatically useful or permitted. State the decision, the required fields, the people affected, and how the proposed combination will be assessed. More records can repeat the same bias or add linkage errors; a larger dataset alone is not evidence of a better decision.

Shared expertise can help teams maintain definitions and investigate problems. A small organization may use a designated steward and regular review; a larger one may establish a specialist group. Neither a center of excellence nor a catalog replaces a named decision-maker. An exploratory workspace should have an owner, access boundaries, a retention period, and a controlled route for publishing accepted outputs.

Check your understanding

1. Marketing reports 100 created orders and operations reports 80 orders that had been paid. Must one team have a data-quality defect?

Solution

No. Under the fictional cohort and cutoff, both measures are correct for their definitions. Give them distinct names and confirm that each fits its intended decision. Investigate a defect if a report fails its own definition, uses the wrong scope, or claims equivalence to a different measure.

2. A report has 100 unique, nonempty order IDs, so its owner calls it complete and accurate. What evidence is missing?

Solution

Unique populated IDs establish those narrow checks, not whether all expected orders arrived or whether their states match reality. Compare the covered scope and keys with a reliable source reference, investigate discrepancies, and check the fields needed for the intended decision. Even reference agreement has limits if the reference is wrong.

3. A source adds partial refunds and the engineer changes a shared query immediately. The output still loads successfully. What was skipped?

Solution

The team skipped agreement on meaning, an authorized decision, versioned examples and tests, consumer impact assessment, and a transition policy. An unsupported state also requires the agreed quality response; silently dropping it does not repair the definition. Loading successfully checks execution, not whether the new measure answers the approved question. Establish those decisions and inspect any results already published under the unapproved change.