Data Ownership Is an Operating-Model Decision

Before an AI assistant reports your customer count or recommends a discount, decide who approves the meaning of those terms. Sales, finance, and operations can use the same word for different records and decisions. Give each definition an accountable business owner, a correction process, and a tested implementation so staff can tell which answer applies to their work.

Start with the decision that uses the data

Ask what a person will do with the answer. A sales manager counting accounts to assign coverage needs a different population from a finance manager counting customers with outstanding receivables. Both counts can be correct if their definitions and dates are clear. Calling both “customers” without context leaves staff to discover the difference after acting.

Take a recent decision and trace the records behind it. For an account review, inspect the CRM account, contracting entity, billing account, and delivery locations. Ask which identifiers connect them and who can correct that connection. Counting a parent group, a legal entity, and a delivery site as interchangeable units changes the result.

A data-engineering discussion about what governance actually means starts with a reader struggling to understand the term and its many definitions. Treat that as a reader question, not a survey. In a working team, governance becomes easier to explain through a concrete decision: who can approve the customer definition that an account-planning tool uses?

Start with a small set of consequential terms in a specific workflow. Include the terms that change a payment, a forecast, or a customer commitment. Our guide to mapping a workflow and its exceptions helps find those points. A catalogue of every field can wait while the team resolves the definitions that block delivery.

Keep legitimate local meanings explicit. Marketing may track people who have expressed interest, while billing tracks entities with posted invoices. Name those populations precisely and document their relationship. A shared definition should support a shared decision; it needn't erase every department's distinct purpose.

Separate business ownership from technical custody

The business owner decides the meaning and acceptable use of a defined data concept within their assigned authority. They approve quality expectations, resolve disputes, and prioritise corrections. Choose someone who understands the consequences of the decision and can obtain the time or budget needed to address problems.

The steward maintains the definition and handles the day-to-day issue queue. They investigate mismatched records, coordinate corrections, and keep examples current. The technical custodian operates the relevant systems, pipelines, and access controls. These are responsibilities you can allocate; they don't necessarily require three new job titles.

Microsoft's Purview governance model separates a central data office, owners, stewards, and consumers within a federated approach. It provides a reference for dividing the work. Your company still needs to name the people, their authority, and the process for escalating a disagreement.

A database administrator can keep a table available and secure without authority to decide whether freight belongs in a commercial margin measure. A finance leader can approve that measure without permission to deploy code. Connect their responsibilities through an approval and release process so neither person has to make the other's decision alone.

Document the escalation route for shared concepts. For example, finance and sales may agree on several named margin measures but disagree about which measure controls discount approval. The designated commercial sponsor resolves that policy question with the relevant owners. A committee that can discuss the issue but can't decide it leaves the workflow blocked.

Assign ownership to customer, contract, order, and margin

Give each concept a named owner and identify the departments affected by it. Then work through edge cases together. A cancelled order, a contract amendment, or a customer group with several billing entities can expose gaps that a short glossary entry misses.

This table proposes a conversation, not a universal reporting structure. An SME's operations director may hold several responsibilities. A corporate group may divide ownership by legal entity or business unit. Preserve a clear decision-maker for each shared use even when several people maintain the underlying records.

Separate the owner of a record from the owner of a derived measure. The warehouse team may maintain shipment events while finance approves the recognised-revenue calculation. The measure depends on those events, but its ownership doesn't transfer authority to change the source shipment record.

Make cross-department relationships explicit. A signed agreement can cover several customer accounts, and one order can produce several shipments. Record those relationships before asking AI to join the datasets. A correct label on each source doesn't establish a correct combined calculation.

Write an agreement the team can implement

Create a short definition record with a stable identifier and an owner. State the business purpose, included population, exclusions, source, and update cadence. Add example records and the expected result. A sentence such as “active customers are customers doing business with us” doesn't provide enough information to build or test a count.

Specify the unit of analysis, often called the grain. For an order measure, say whether each row represents an order header or an order line. Define the status and event date used for inclusion. Identify the reporting time zone and cutoff so teams don't compare different periods under the same label.

For a calculated measure, document the formula, source fields, currencies, and treatment of missing inputs. State how returns, credits, and late corrections affect it. Name the person who approves these rules. Use the company's accepted accounting or commercial policy where relevant rather than letting an engineer infer it from available columns.

Put implementation details beside the business record. Link the approved SQL view, semantic-model definition, API, or report logic to its tests and release version. In a small company, a versioned document and a tested query may be enough to begin. Choose more tooling when discovery, reuse, or change volume justifies it.

Include the permitted audience and uses, with the relevant approval route. Business ownership doesn't automatically grant the owner unrestricted access or permission to share records. Microsoft notes that Purview catalogue roles don't themselves grant access to the underlying data. Keep metadata administration and actual source permissions separate in your design too.

Resolve a margin disagreement in a worked example

Consider an illustrative distributor whose AI assistant answers “What was the margin on this sale?” The sale has A$1,000 in revenue after the agreed deductions, A$700 in product cost, and A$50 in outbound freight. These figures are invented to explain the ownership decision; they aren't client results or an accounting-policy recommendation.

The approved product gross-margin measure in this example subtracts product cost from revenue. It reports A$300, or 30%. A separately approved commercial contribution measure also subtracts outbound freight. It reports A$250, or 25%. The two results describe different measures using the same sale.

Finance names and approves both measures, including their exact inputs. The commercial owner decides which approved measure governs a discount review. Staff then select the intended measure, and the AI assistant labels its answer with the measure, period, and actual or estimated cost basis. If the question doesn't establish the intended measure, the assistant asks for that choice.

Test the relationships too. If the sale has two shipment rows, a careless join can count its A$1,000 revenue twice. Huang, Damalapati, and Wu's 2023 research on aggregation consistency in semantic layers examines inflated totals caused by join fanouts. Their work supports testing aggregation behaviour; it doesn't decide which costs belong in your company's margin policy.

Include the sale's split shipments and a later credit in the test set. Require the technical team to demonstrate the accepted result and the finance owner to approve the interpretation. Document whether a late adjustment changes a prior-period report or enters a subsequent view under the relevant policy. That decision affects what the assistant should say about historical figures.

Keep reporting separate from action authority. A correct margin answer doesn't authorise a price change. If the assistant prepares a discount recommendation, apply the approved threshold, reviewer, and system controls described in our guide to when AI should read, recommend, or act.

Connect AI to the approved meaning

Make the definition available where the assistant obtains its answer. Bind a metric request to an approved query or service, and return the definition identifier with the result. For contracts, connect the record to its authorised version and effective dates. A prompt containing a vague business term leaves too much interpretation to the model.

A semantic layer centralises metric definitions and the query logic that uses them. dbt's current Semantic Layer documentation describes shared metric definitions and AI access through its MCP server. That is an implementation option after business approval. A shared calculation still needs correct inputs, an appropriate definition, and tested behaviour.

Test the mapping from the reader's question to the intended concept. “Orders this month” needs a choice of accepted orders, shipped orders, or another named measure. Include ambiguous questions in evaluation and require a clarification or labelled choices. A confidently returned number can conceal a definition error even when the calculation ran correctly.

Return the source and freshness information that changes interpretation. Tell the reader whether the result covers posted transactions through yesterday or current unapproved requests. If a source fails, use the approved stale-data policy or stop the answer. Don't silently substitute another department's report because it is available.

Check permissions at the point of retrieval and in downstream outputs. A valid definition doesn't entitle every user to customer-level records or commercial costs. Test the roles that will use the assistant, including the denied cases. Keep access enforcement in the application and source systems rather than relying on an instruction in the prompt.

Give corrections and definition changes different paths

Distinguish a wrong record from a proposed change to meaning. A shipment linked to the wrong account needs a source correction. A request to count delivery sites instead of legal entities changes the population. The first follows the authorised record-maintenance process; the second needs definition approval and an impact review.

Let staff flag an answer with its source reference and reason. The steward investigates whether the problem lies in the record, mapping, calculation, or assistant's interpretation. Assign the issue to the person who can fix that layer. Track its status so staff don't need to submit the same problem repeatedly.

Before releasing a new definition, list affected reports, workflows, and AI tools. Compare the old and new results on representative cases, document the approved difference, and choose an effective date. Preserve the earlier definition where staff need to reproduce a historical decision. A name alone isn't sufficient version history.

Notify the people whose work changes. Explain the new population or calculation and show an example of the resulting difference. Update the help text and evaluation cases alongside the implementation. A code release that changes the answer without informing the process owner creates a second operating problem.

Escalate unresolved disputes through a named sponsor and deadline. Record who can decide, what evidence they need, and which workflows stay paused. Keep a safe existing process available if the new use can't proceed. An AI engineer shouldn't settle a commercial-policy dispute merely to finish a deployment.

Fund ownership as part of the operating model

Allocate time for stewardship and correction in the team's workload. If the company gives someone responsibility without time, access, or an escalation route, the issue queue grows while the title stays on a chart. Track resolution time and repeated defects alongside the completion of definition records.

For an SME, begin with the owner and steward responsibilities inside existing roles and a small shared register. For a larger organisation, use local domain owners with central rules for identifiers, access, and change records where they need to align. Our guide to central, embedded, and federated AI teams covers the wider delivery structure.

A PE portfolio team can agree a common reporting measure while each company owns its source mapping and reconciliation. Ask for the local definition, exceptions, and approval before comparing companies. Different cost coverage or consolidation boundaries can make a portfolio ranking misleading even when every spreadsheet uses the same heading.

VC investors can ask a startup to trace a customer result through its approved definitions and correction history. Inspect what happens when a customer's operating terms change. A reusable product needs a maintained route for those changes, and its deployment economics should include the work required to support them.

For a first release, choose a live workflow and finish its small set of definition records. Demonstrate the agreed results, denied-access cases, and correction route with the people who will operate it. The sponsor can then fund the next domain using evidence of resolved questions and maintained definitions, rather than the size of the catalogue.