Ontology does not live in one place.

That is why it is hard to govern.

If ontology lived only in the data warehouse, the data team could fix it. If it lived only in the CRM, RevOps could fix it. If it lived only in the ERP, finance systems could fix it. But the company’s model of reality is distributed across every system where work is recorded, interpreted, routed, approved, measured, or automated.

It lives in CRM account hierarchies, opportunity stages, lifecycle fields, owner assignments, and qualification rules.

It lives in ERP customers, vendors, items, cost centers, legal entities, invoice rules, payment terms, revenue schedules, and approval policies.

It lives in billing systems: subscriptions, plans, add-ons, tax treatment, coupons, credits, invoices, payment methods, and dunning logic.

It lives in product data: users, workspaces, events, sessions, feature flags, entitlements, roles, organizations, tenants, and usage limits.

It lives in finance models: ARR logic, margin allocation, forecast assumptions, cash timing, headcount plans, budget ownership, and board metrics.

It lives in the data warehouse: identity stitching, dimension tables, fact tables, transformation logic, bridge tables, historical snapshots, semantic layers, and metric definitions.

It lives in BI tools: filters, dashboard defaults, drilldowns, hidden calculations, certified reports, uncertified copies, and executive screenshots.

It lives in support tools: organizations, requesters, ticket types, severity, SLA rules, routing, escalation paths, incident links, and knowledge base categories.

It lives in workflow tools: request forms, approval thresholds, status states, routing logic, required fields, automations, and handoff rules.

It lives in spreadsheets: exception maps, account plans, renewal trackers, margin models, product packaging matrices, implementation plans, and the “real” version of a metric nobody trusts in the dashboard.

It lives in docs and Slack: policy interpretations, historical decisions, customer promises, roadmap exceptions, approval precedents, and tribal definitions.

Now it lives in AI systems: prompts, retrieval indexes, tool permissions, agent memory, eval sets, workflow harnesses, context windows, and action policies.

This distribution is normal. The mistake is pretending one platform can make it disappear.

A CRM cannot be the whole ontology. An ERP cannot be the whole ontology. A data warehouse cannot be the whole ontology. A knowledge base cannot be the whole ontology. Each system sees the business through the work it supports.

The operating question is not “Where should everything live?”

The better question is “Which system is authoritative for which object, definition, relationship, and action?”

Authority should follow the nature of the decision.

Finance systems should usually own financial truth: invoices, payments, recognized revenue, legal entities, cost centers. Product systems should usually own product behavior: usage events, workspaces, feature entitlements, user roles. CRM may own commercial pipeline, account ownership, and opportunity motion. Support systems own ticket history and SLA execution. Workflow systems own approval state and process evidence. The warehouse often owns reconciled analytical views, not original reality.

That distinction matters.

The warehouse is often treated as the place where ontology problems are solved. It can help enormously. It can stitch identities, document definitions, expose conflicts, and provide stable analytical models. But if the source systems keep producing contradictory operating truth, the warehouse becomes a reconciliation factory.

It reports the mess. It does not remove the mess.

Spreadsheets deserve special attention. Operators use them because they are flexible, fast, and close to the work. They often contain the best current understanding of a messy domain. They also create risk when they become shadow systems of record.

Do not dismiss a spreadsheet as bad behavior. Ask what business concept it models that official systems do not.

Maybe finance has a product-margin model because ERP item structures are too crude. Maybe CS tracks renewal risk manually because product usage and support signals do not connect. Maybe product ops maps feature-to-package relationships because billing entitlements lag reality. Maybe RevOps maintains account hierarchy corrections because CRM cannot handle global complexity cleanly.

Each spreadsheet is a clue.

AI adds a new layer. Retrieval systems build indexes over documents. Agents call tools. Workflow copilots summarize tickets, accounts, calls, and dashboards. If the company does not define which sources are trusted for which questions, AI will blend approved policy, draft notes, stale spreadsheets, and local exceptions into one answer.

That is not an AI hallucination in the narrow sense. It is an ontology failure exposed through AI.

A practical mapping exercise helps.

For each core object, create a row:

  • where it is created;
  • where it is edited;
  • where it is consumed;
  • where it is reported;
  • where it is manually corrected;
  • where AI can access it;
  • which system is authoritative for which decision;
  • which conflicts are known;
  • who owns resolution.

Do this for customer, product, contract, invoice, entitlement, usage, support issue, employee, role, workflow, obligation, and decision.

The map will be ugly. Good. Ugly is useful when it is visible.

The most useful findings will usually be uncomfortable: a “temporary” spreadsheet that has become a planning system, a BI filter that quietly defines an executive metric, a billing field that determines product access, a support category that functions as an SLA proxy, or an AI prompt that embeds a policy no one formally approved. Those are not side details. They are places where the operating model has escaped formal ownership.

The goal is not to centralize all ontology into a committee document. The goal is to make distributed authority explicit enough that systems can cooperate.

Ontology lives where work happens.

Govern it there.