A number needs an owner.

Picture two sheets of paper on a conference table. Each is a report, each was printed that morning, and each has a column headed "Active customers." One says 48,210. The other says 31,975. The meeting that follows spends forty minutes trying to establish which report is wrong, and it ends without an answer, because neither one is.

The first report counts every customer with an open account. The second counts every customer who bought something in the past twelve months. Both were produced from the same database, and both did their arithmetic correctly. The disagreement is not in the numbers. It is in the word "active," which each report's author filled in differently, reasonably, and without telling anyone. (The numbers are invented, but anyone who has sat through a quarterly review will recognize the scene.)

My argument in this essay is that organizations often treat a disagreement between reports as a technical defect when it is really an unmade management decision, expressed as two competing calculations. A database can implement a definition faithfully and enforce it everywhere. What it cannot do is give that definition authority. Authority has to come from a person who answers for what the number means: what it is for, how it is defined, who approved it, and how it is allowed to change. A calculation can be correct and still settle nothing; only a decision settles which calculation the organization means. Every number that matters needs an owner.

Two qualifications before going further. Not every discrepancy is a matter of definition; plenty are plain errors, and those deserve to be fixed as errors. And owning a number does not mean writing the query that computes it, or launching an enterprise governance program to catalog every field in the building.

Three ways two numbers can disagree

When two reports disagree, there are three possible explanations, and they call for very different responses.

The first is bad source data. A customer was entered twice, a cancellation never reached the billing system, a field that should hold a date holds a blank. The second is a bad calculation: a join that counts each customer once per order, a filter that silently drops a region, a date boundary off by a day. Both are defects. Each has a fix, and a competent engineer can find it.

The third is different meanings. Here nothing is broken. Each report computes exactly what its author intended, and the two intentions differ. No amount of debugging will make the numbers converge, because there is no bug.

The telltale sign of the third case is that the data gets cleaned, the code gets reviewed, and the numbers still disagree. Organizations routinely spend weeks treating a disagreement of the third kind as if it were the first or second, sending analysts to hunt for an error that does not exist. The hunt is not only wasteful. It teaches everyone involved that the data cannot be trusted, when the data was fine and the definitions were never agreed.

What hides under a label

The statistician W. Edwards Deming spent much of his career on this problem, though he came at it from the factory floor. In Out of the Crisis he argued that words such as "clean," "safe" or "unemployed" have no shared meaning until someone specifies the test that decides each case, and he summed up the remedy in a phrase: "An operational definition puts communicable meaning into a concept."¹ He added a point that every analyst learns the hard way. Change the procedure for measuring something, and you get a new number, even though nothing in the world has changed.

"Active customer" is a concept in exactly Deming's sense. Turning it into a number requires at least five choices.

• Purpose. Is the number meant to forecast revenue, size a support team, or report growth to investors? Each purpose favors a different definition.
• Population. Does a household with three accounts count once or three times? Are employees, test accounts and resellers in or out?
• Time window. Twelve months, ninety days, or an open account as of today? Measured at the end of the quarter, or at the moment the report runs?
• Exclusions. Does a customer whose only purchase was refunded count? A customer on a free trial?
• Level of detail. Is the unit a person, an account, or a location?

Every one of these choices is defensible, and every one changes the total. The label "Active customers" conceals all five. Hand two capable analysts the same label and the same database, and they will make different choices, not because either is careless but because each is quietly answering a different question.

Correct is not the same as settled

This is where the distinction between a calculation and a decision earns its keep.

An engineer can make a calculation correct. She can show that two reports differ, trace the difference to the time window, and build the agreed rule into the one place every report draws from. What she cannot do, without overstepping her role, is decide which time window the company should use. That depends on what the number is meant to support, and the choice belongs to whoever is accountable for the outcome: the head of finance for a revenue forecast, the head of operations for a staffing plan.

None of this is a way of moving blame from one department to another. The engineers who notice the conflict should surface it, and the business leaders who use the number should not hand the question back to IT and wait. Defining what a number means is shared work. But its final step is a choice, and a choice needs someone with the standing to make it.

The people who built the modern discipline of shared data models said as much long ago. Margy Ross, who with Ralph Kimball helped popularize the shared "conformed" dimensions that let different reports describe customers, products and dates the same way, wrote in 2005 that defining them across an enterprise is "a cultural and geopolitical challenge." Technology, she added, can make the integration easier but cannot solve the problem on its own, and the best stewards of shared data come from the business rather than from IT.² In 2011 she wrote that a shared dimension requires organizational consensus and a commitment to stewardship, and she warned that data sets can look comparable because of similar labels while their underlying business rules quietly differ.³ The architects of the technical solution were the first to say that the hard part was never technical.

One source does not guarantee one meaning

Many organizations respond to dueling reports by building a "single source of truth": one warehouse, one set of tables, one place every report must draw from. It is a good idea, and it solves real problems. It eliminates the case where two reports disagree because they read different copies of the data.

But notice that our two reports already came from the same source. A shared source guarantees that everyone starts from the same facts: the same customers, the same orders, the same dates. It does not guarantee that everyone asks the same question of those facts. The choice between "open account" and "purchased in the last year" is made on top of the shared data, not inside it. A single source of truth narrows the room for accidental disagreement. It cannot remove the need for a decision.

What ownership looks like when it is real

The profession that studies these problems has a vocabulary for them. The Data Management Association's body of knowledge defines data governance as the exercise of authority and control over the management of data assets, and it distinguishes owners, who approve definitions, from stewards, who maintain them.⁴ Translated from the language of programs and frameworks into the needs of a single number, ownership comes down to five things.

1. A named owner in the business, with the authority to approve the definition and its changes.
2. A written definition and intended use: what the number counts, what it excludes, and what decision it serves.
3. One implementation: the single place the number is computed, which every report uses.
4. Validation examples: a handful of specific cases, such as three customers and whether each counts, so that anyone can check the implementation against the definition.
5. A route for disputes and changes: who to ask when the number looks wrong, and how a proposed change is approved and announced.

The owner does not need to write SQL or compute anything personally. What the owner provides is authority, and authority is exactly what the technical side cannot supply. Ownership without authority is ceremonial: a name typed into a catalog field that nobody consults when a dispute breaks out. Ownership without maintenance decays: a definition approved three years ago for a business that has since changed shape.

When two definitions are both right

None of this means a company must agree on one definition of every word. Finance may legitimately need "customers with an open account," because that is who can be billed. Marketing may legitimately need "customers who purchased in the last twelve months," because that is who is likely to buy again. Forcing either team to adopt the other's definition would make its number worse at its job.

The problem was never plurality. It was ambiguity: two different measures sharing one name. The cure is to name them apart ("open-account customers" and "twelve-month purchasers"), give each its own owner and scope, and publish a reconciliation that shows how one becomes the other. In our example, the reconciliation is a single line: 16,235 customers have an open account but have not bought anything in a year. With that line on the page, the two reports stop being a contradiction and become two answers to two questions.

Definitions have histories

Suppose the owner decides that "active" should mean six months instead of twelve. The next report shows a sharp drop in active customers. Nothing happened to the customers; the ruler changed. A trend line that runs across the change now compares two different things, and anyone reading it without knowing about the change will draw the wrong conclusion.

Public companies face this problem in the open. In February 2019, Twitter announced that it would stop reporting monthly active users after the following quarter and would report "monetizable daily active users" instead, a narrower measure counting people who logged in through apps that could show ads. The company acknowledged that it had considered a disclosure comparable to other companies' and chosen not to make one.⁵ The following year, the Securities and Exchange Commission issued guidance on the key performance indicators companies discuss in their filings. It said that when a company changes how it calculates a metric, it should consider disclosing the differences, the reasons, and the effects on previously reported figures, and should consider recasting prior periods so that they can be compared.⁶

Internal reports deserve no less care than public ones. The owner has two honest options: restate the history under the new definition, which preserves comparability, or keep the old figures and mark the change with an effective date, which preserves fidelity to what was reported at the time. Neither is right everywhere. What is wrong everywhere is changing the definition and saying nothing.

Why AI raises the stakes

Everything so far applies to reports built by people. It applies with more force to answers produced by machines. When someone types "How many active customers do we have?" into an AI assistant connected to company data, the assistant must choose a definition, and it will answer fluently whichever one it picks. A human analyst who was unsure might ask a colleague. A language model that is unsure tends to produce a confident sentence.

Research on systems that translate questions into database queries shows how much depends on definitions being supplied rather than guessed. In BIRD, a benchmark published in 2023 by researchers at the University of Hong Kong and their collaborators, GPT-4 answered about 55 percent of questions correctly when it was given short notes of domain knowledge, such as how a ratio is calculated or what a coded value means. Without those notes its accuracy fell to about 35 percent. Human experts scored about 93 percent.⁷ The notes were, in large part, definitions. The model could compute; it could not know what the organization meant.

Vendors have noticed. A Google Cloud article published this week argues that AI agents need business context to tell, for instance, revenue from projected revenue, and that the data products feeding them should carry named owners and service commitments.⁸ That is a vendor's argument for its own products, not independent evidence, but its premise is sound. The right behavior for an assistant is to use the approved definition, to say which definition it used, or to ask. Documentation alone does not make an assistant reliable. Its absence guarantees that the assistant will guess.

Objections, considered

"This creates bureaucracy." It can, if it starts with a mandate to define everything. It should start with the five or ten numbers that appear in executive and board meetings and have already caused a dispute. Assigning an owner and writing one card per number costs a few hours. The forty-minute meeting about the two reports costs more than that every quarter.

"Different departments legitimately see the business differently." They do, and they should keep their different measures. The objection is not to plurality but to identical labels hiding incompatible assumptions. Name the measures apart and reconcile them, and every department keeps the number it needs.

"The data catalog, or the semantic layer, should solve this." These tools are valuable: they publish definitions where people can find them, and they make one implementation the default for every report. But a tool can only publish and execute meaning that people have agreed. Typing a name into a catalog's "owner" field does not give that person authority, and it does not produce agreement. As Ross observed two decades ago, technology can help with the work but does not do it for you.²

A database can enforce a definition. Only an owner can give it authority.

Back to the table

Return to the two sheets of paper. Success is not forcing them to agree. Success is knowing whether they should agree, being able to explain in one line why they differ, and having someone accountable for the choice. A leader can get there with four questions at the next reporting meeting.

• Which decision is this number for? If no one can say, the number has no owner yet.
• Who can approve a change to its definition? And when did it last change?
• If two reports carry this label, should they agree? If not, where is the reconciliation?
• Which definition would an AI assistant use? If the answer is "whichever it finds first," the assistant is guessing.

Give each sheet its own name, its own owner and a footnote that says what it counts. Each sheet will still be a calculation, and each footnote will record a decision. The next meeting about active customers takes five minutes, and it is about customers.