Enterprise AI needs business definitions that govern execution

AI needs business definitions that govern execution

An enterprise can have a data catalog, a governance program, and extensive lineage records while its AI applications still calculate revenue differently. The practical question is which business definition each application uses and who controls that choice. Dependable AI needs enterprise-owned definitions that guide how applications interpret business data and act on it. Models, GPUs (graphics processing units), vector databases for retrieving data by similarity, and agent frameworks for coordinating AI actions supply the computing power and tools to build those applications.

Business definitions have long been recorded as metadata: information that describes data, its meaning, and its use. For decades, catalogs helped employees find datasets, governance programs recorded definitions and owners, and lineage records traced how data moved and changed. AI makes this information essential to running applications because they need consistent meanings for customer, revenue, product, contract, and risk when they reason and act.

Yet recorded information can omit knowledge that employees use every day. A senior analyst may remember that a migration three years ago made a customer identifier unreliable, or that the churn definition changed last quarter. An AI application chooses from the context supplied to it, so those distinctions must be available in a form it can use. Dependable choices require business definitions to be versioned, tested, and controlled as production assets.

Conflicting metrics become automated decisions

A disagreement over revenue shows what happens when an application lacks that context. Finance may exclude returns while sales includes them, leaving two plausible calculations for the same business term. An AI system has no inherent basis for deciding which calculation fits a particular task. It needs governed context that connects the question to the definition that should apply.

Business intelligence teams already encounter this problem when two dashboards show different numbers because their tools calculate the same metric differently. Reconciliation meetings, spreadsheet comparisons, and arguments over the authoritative report allow work to continue. But these practices depend on people recognizing and resolving disagreements that remain embedded in the systems. The approved meaning and the running calculation can still diverge after the meeting ends.

Automated action makes that unresolved disagreement more consequential. A person reviewing a dashboard may catch an incorrect number before using it, while an AI agent, an application that uses a model to choose and carry out actions, can send the same number into a workflow before anyone intervenes. Duplicated calculations, recurring reconciliation, and uncertain ownership therefore become dependencies in processes that can run ahead of human review. AI speeds up the effect of an old disagreement on operational work.

Because the disagreement lies in the business logic, better language generation cannot resolve it on its own. An agent reasons from the context it receives, including contradictory or obsolete definitions, and a fluent answer can make an inappropriate calculation harder to recognize. Increasing model scale does not reconcile those definitions either. Dependable reasoning requires control over both the meaning supplied to the application and the calculation that implements it.

Connect documented meaning to running calculations

Control over meaning adds a responsibility to established data governance. For 20 years, enterprise governance has concentrated on who may access information; AI makes it more important to determine how that information should be interpreted in use. Two analysts with identical permissions can still calculate the same metric differently. Access controls remain necessary, but changing permissions leaves that disagreement unresolved.

Resolving the disagreement requires a connection between an approved definition and its implementation. A glossary may specify how to calculate revenue while a reporting tool or agent runs another calculation. Governance platforms commonly document the intended definition and leave enforcement to a separate process. When the implementation changes independently, the glossary records an intention that no longer determines application behavior.

Keeping the two connected requires ownership, version history, and lineage for each implemented definition. An owner approves its meaning and settles disputes; version history identifies which approved form applies; lineage traces the data and calculations behind a result and where they are used. Together, these controls make changes on either side visible and assign responsibility for reconciling them. Documentation then becomes part of the process that governs execution.

The way enterprises acquired their tools helps explain why this connection can be weak. One team bought a lineage tool to investigate failures, another introduced a catalog for discovery, and a governance platform addressed policy requirements. A semantic layer, a shared place to define business metrics and their calculations, then supported business intelligence. Each purchase met a need at a different time, without necessarily establishing shared business meaning.

As a result, those four tools can maintain four interpretations of the same concept. The catalog may describe a dataset one way, the governance platform may record another definition, and the semantic layer may run a calculation changed since either description was written. Lineage can explain how the resulting number was produced while leaving open which definition should have applied. Each tool can do its job while the disagreement survives.

Separate ownership makes that disagreement harder to resolve across the full process. Funding can exist in four places while no team owns the path from approved definition to executed calculation, and local measures can leave consistency across that path unmeasured. An AI model may then use the first definition it encounters without recognizing an alternative elsewhere. Specialist tools offer valuable capabilities, but someone must also take responsibility for how those capabilities work together.

Even that shared responsibility must extend beyond one platform. An analytics service may enforce its approved definition correctly while an application elsewhere uses a different one. Both implementations can satisfy their local rules and still disagree. The enterprise therefore needs definitions that remain usable and controlled as they cross platform boundaries.

Keep business meaning under enterprise control across platforms

Cross-platform use is normal because enterprises operate across clouds, legacy applications, software-as-a-service tools, business intelligence platforms, and AI services from several providers. Operating entirely inside one vendor’s environment is the exception. Definitions of revenue or customer must therefore retain their meaning as different technologies consume them. Otherwise, the same fragmentation moves into AI workflows, where automated activity can make conflicts harder to spot than reports viewed side by side.

Native platform capabilities help teams govern definitions within those environments. Every major cloud vendor offers some form of governance, metric definition, or AI-context capability, optimized for its platform. Local usefulness does not establish agreement with definitions maintained elsewhere. Teams already coordinating separately owned metadata tools consequently face a second task: keeping the platforms that consume those definitions aligned.

Vendor neutrality addresses this need for portability and enterprise control. A definition should remain usable by different technologies so that replacing infrastructure does not require rebuilding the business logic inside each new platform. This reduces dependence on a vendor’s representation of the business and gives the enterprise more freedom to change its technology. Ownership of meaning becomes a strategic concern alongside ownership of the underlying data.

A shared operational basis for definitions can support that freedom while allowing different technologies to consume them. It does not require every workload to move to one platform, one database, or one physical repository. The architecture must let the enterprise approve, change, and maintain its business meaning across those choices. Portability becomes useful when that authority reaches the systems executing the definitions.

Version, test, and deploy business definitions as production assets

Putting that authority into practice extends the role of metadata management. Its first generation established dataset discovery, ownership records, and catalogs; the proposed second generation uses the same business context to govern how applications reason, calculate, and apply policy. The forecast for the next five years is a move toward execution-oriented metadata management, with the next decade increasingly dependent on definitions that guide decisions before applications act. This extends metadata’s role beyond explaining enterprise activity after the event.

The proposed architecture supports that change by bringing lineage, cataloging, governance, and business definitions onto a shared metadata foundation. A common operational model represents the business context, and consuming systems read from it directly. An agent can reason using governed definitions, an analytics platform can calculate metrics from them, and a policy mechanism can apply the corresponding rules. Provenance, the record of the data, definitions, and processing behind an outcome, makes the resulting machine-made decision traceable.

A common model also gives teams something specific to change and control. Business definitions enter version control, which records revisions and their history, so owners and consumers can distinguish the current approved definition from earlier forms. When a business rule changes, applications need the version relevant to their work. Versioning makes that choice explicit instead of leaving it to whichever copy an application encounters.

Each revision then moves through a development pipeline: the process used to prepare, test, and release production changes. Teams test the effects of a definition change before deployment, then make the governed version available to AI agents, analytics platforms, databases, and applications. Approval and release become connected steps with identifiable owners. A change in business meaning is treated as a production event because it can change what consuming systems do.

This production process applies engineering discipline to business meaning, as enterprises already do for code, infrastructure, and security. Ownership, versioning, impact testing, deployment, and operational controls make definitions maintainable dependencies. The architecture allows different deployment arrangements while requiring approved meaning to stay connected to system behavior. The next management decision is who owns that connection.

MetadataOps is the proposed discipline for assigning and carrying out this responsibility. A MetadataOps engineer owns the production path of business definitions, including versioning, testing, and deployment, while a platform engineer remains responsible for the production path of code. For a definition used across platforms, the accountable owner must be able to approve changes and ensure that consuming systems receive the governed version. Teams then have someone clearly responsible for failures between an approved rule and its implementation.

That responsibility begins before an agent retrieves information for a request. Context engineering determines what enters an agent’s context window, the material available to the model while it processes the request, while MetadataOps determines what governed material exists for retrieval. Context engineering can select relevant information, but selection alone cannot reconcile contradictory definitions in the underlying collection. The information available for retrieval must already carry an approved meaning, an identifiable version, and a controlled production lifecycle.

Key executive takeaways

• Govern business definitions as production assets: Business owners need to approve definitions for revenue, customer, and risk, with identifiable versions that AI applications can use consistently. These definitions determine how applications interpret data and act on it.
• Resolve conflicting metrics before automating decisions: Finance and sales owners need to settle which revenue calculation applies to each task. AI agents can carry unresolved disagreements into operational workflows before human review.
• Connect approved meaning to running calculations: Governance and platform owners need shared accountability for the path from an approved definition to its implementation. Ownership, version history, and lineage make changes visible and help identify where calculations diverge.
• Keep definitions under enterprise control across platforms: Technology leaders need portable business definitions that remain governed across clouds, analytics tools, and AI services. A shared metadata foundation supports that control while allowing different deployment choices.
• Assign ownership for the definition lifecycle: A MetadataOps owner manages versioning, impact testing, and deployment of business definitions to consuming systems. This production discipline gives AI agents approved, traceable context before they retrieve information and act.