A company does not need to model everything with equal precision.
That is where ontology projects go wrong. They try to create an exhaustive dictionary of the business. Every field, every label, every workflow state, every local exception. The result is a heavy artifact that impresses architects and annoys operators.
The better starting point is simpler: identify the core objects of the business.
Core objects are the things the company repeatedly makes decisions about. They appear across systems. They carry rights, obligations, money, work, and accountability. If they are poorly defined, the company pays for it constantly.
Most businesses have some version of these objects:
- customer;
- account;
- legal entity;
- user;
- workspace or tenant;
- product;
- SKU or plan;
- contract;
- order;
- invoice;
- payment;
- entitlement;
- usage event;
- support issue;
- project;
- workflow;
- employee;
- team;
- role;
- asset;
- obligation;
- decision.
The list varies by business model. A marketplace needs buyer, seller, listing, transaction, payout, dispute, and trust signal. A healthcare company needs patient, provider, encounter, diagnosis, claim, authorization, and care plan. A manufacturing company needs item, supplier, purchase order, inventory location, work order, shipment, and quality event. A SaaS company needs account, user, workspace, subscription, entitlement, product event, ticket, renewal, and invoice.
The point is not the universal list. The point is that every business has a small set of objects that anchor reality.
The danger is that these objects are often defined by software defaults.
CRM says account, contact, lead, opportunity. ERP says customer, vendor, item, invoice, cost center. Product says user, org, workspace, feature flag, event. Billing says subscription, plan, invoice, payment method, tax rate. Support says organization, requester, ticket, incident, SLA. Data warehouse says dimension, fact, entity, key, model. Workflow tools say task, request, approval, status.
Each system’s object model reflects its product logic. That logic may be useful. It is not automatically your operating model.
The object model is the operating model.
If the company lets each system define core objects independently, it will eventually discover that the same business thing has five identities.
A “customer” may be a parent account in CRM, a bill-to customer in ERP, a subscription owner in billing, a workspace in product, an organization in support, and a row in the customer dimension. None of those are inherently wrong. But if leaders do not decide how they relate, the company will spend years reconciling them.
Core object design starts with decisions, not fields.
Ask: what decisions do we make about this object?
For customer, decisions might include segmentation, territory assignment, credit risk, renewal motion, executive sponsorship, incident communication, pricing exception, expansion eligibility, and support tier.
For product, decisions might include roadmap investment, packaging, entitlement, margin, support readiness, compliance, localization, and sunset.
For contract, decisions might include renewal date, committed terms, billing rules, usage limits, legal obligations, price increases, and termination rights.
For employee or role, decisions might include access permissions, approval authority, budget ownership, workflow assignment, and escalation.
Once you know the decisions, you can define the object at the level that matters.
A customer is not simply whatever CRM calls an account. For some decisions, the customer is the economic buyer. For others, it is the legal contracting entity. For others, it is the product workspace receiving value. For others, it is the invoiced entity. For others, it is the support organization entitled to help.
That does not mean chaos is acceptable. It means the company needs explicit object views and translation rules.
A practical object definition should include:
- business meaning;
- system of record;
- unique identifier;
- lifecycle states;
- creation rule;
- merge/split/archive rules;
- key relationships;
- ownership;
- edit rights;
- dependent metrics;
- dependent workflows;
- known exceptions.
This sounds tedious. It is less tedious than discovering during a migration that no one can map contracts to active products, or discovering during an AI rollout that agents cannot tell whether a customer is allowed to receive a recommendation.
The most overlooked core object is the obligation.
Companies track customers, products, contracts, invoices, tickets, and tasks. They often fail to track obligations as first-class objects: what the company has promised, to whom, under what conditions, by when, with what penalties, and with which owner.
Obligations live in contracts, emails, implementation notes, roadmap commitments, support escalations, compliance requirements, partner agreements, and executive promises. If they are not modeled, they become institutional memory. Then the person who remembers leaves.
AI makes this worse and better. Worse, because agents can act without understanding obligations if the model is implicit. Better, because AI can help extract obligations from messy text if the company designs where those obligations go and how they are governed.
Another overlooked object is the decision.
Companies make decisions constantly but rarely model them. A decision has an owner, inputs, tradeoffs, date, scope, rationale, communication path, and consequences. If decisions are not captured, the company relitigates them. If AI is asked to explain strategy without decision records, it reconstructs context from fragments.
Modeling decisions does not mean bureaucratic theater. It means recording important calls in a way that future humans and systems can use.
The practical move is to run a core object inventory.
Pick ten objects that matter most. For each one, list every system where it appears. Then answer three questions:
- Does this system define the object, consume the object, or create a local view of it?
- Which decisions depend on this object being correct?
- Where do definitions or identifiers currently diverge?
You will find the operating model hiding in the seams.
Do not try to fix every object at once. Start with the objects that carry money, customer commitments, access rights, product entitlements, compliance risk, executive metrics, or AI action.
Those are the objects that deserve design.
A company with clear core objects is easier to run. Its dashboards are less fragile. Its workflows are less arbitrary. Its integrations are less painful. Its AI systems have something real to reason over.
A company without clear core objects is always one system migration, one reporting project, one reorg, or one agent deployment away from discovering how much of its reality was implied.
