Skip to main content

Your Business Is an Object Model Whether You Know It or Not

Before you strategize, before you transform, before you add a single AI tool, you need to know what your business actually is. Not what you think it is. What it is. That means defining its objects.

Three-panel comic: the business as it exists in the owner's head — scattered sticky notes, tangled arrows, competing spreadsheets; a clean object-model diagram materializes over the chaos showing labeled nodes for Customer, Seat, Function, Product, Metric; the owner points to a specific node and the AI responds with precise company-aware output.

Every business already has an object model. It is just usually implicit: scattered across the owner's head, a collection of spreadsheets, a Notion workspace that hasn't been opened in months, and tribal knowledge that lives in three employees who have been there the longest. The objects (the customers, seats, functions, products, metrics) exist. Nobody has defined them.

This is not a small problem. It is the problem that makes almost every AI transformation harder than it should be, and most of them fail.

What an object model is​

In software, an object model defines the nouns of a system: what things exist, what properties each thing has, and how things relate to each other. A customer has a name, a contract value, an industry, and a status. A seat has a person in it, a function it belongs to, and a single metric that tells you whether that seat is winning. A product has a margin, a delivery process, and a customer profile.

This is not a software concept that businesses have to borrow. It is a description of what every business already is. The objects are already there. The question is whether your business has ever written them down.

Palantir built their entire government and enterprise practice on a single move: before touching a client's data, they force the organization to define its ontology. What are the actual objects in your world, what are their required properties, and how do they relate to each other? The discomfort of that exercise is the point. The act of defining the objects is also the act of surfacing every conflict the organization has been quietly managing by not looking directly at it.

A corruptible politician in a foreign government is more accurate as a typed object than "government contact." A customer who has not paid in 90 days and has never completed onboarding is not an "active customer." The honest type is something different. Defining the type forces the organization to stop using the comfortable label and start using the accurate one.

Why this matters before AI transformation​

Most companies try to add AI to undefined objects. They build a chatbot on top of data where "customer" means three different things in three different systems. They deploy an agent to report on pipeline health when nobody has agreed on what "qualified lead" means. They automate a process that has never been written down and is running differently in each person's head.

The result is bespoke chaos. Every automation is a one-off because there is no underlying ontology for it to run over. The AI is smart enough to surface the contradictions you have been ignoring for years, but not in a useful way. It just stops working, or gives wrong answers, or requires a human to intervene at every step.

Getting clarity before you transform is partly about this. You need to know where to apply AI, which requires knowing what your business is. But there is a deeper layer: before you can even assess your opportunities correctly, you need to have defined what the things in your business are.

An organization that has done this work can ask an AI agent a question and get a coherent answer. "What is the current state of the Sales function?" returns a real answer because Sales is a typed object with defined properties. "Who are our most at-risk customers this quarter?" returns a ranked list because customer is a typed object with a status property and a defined meaning for "at-risk."

An organization that has not done this work gets: "I don't know, let me check." Every "let me check" is an unmapped object. Every "it depends on who you ask" is a type conflict. These are not technology problems. They are ontology problems.

The three layers of a business object model​

A clean organizational ontology has three layers, and you need all three before AI can operate well on top of it.

What exists. The nouns: seats, functions, customers, products, metrics, projects. Each defined with its required properties and its relationships to other objects. This is where most people stop when they think about documentation, and it is only half the work.

What can change, and how. The verbs: a seat gets filled, a customer moves from prospect to active, a metric gets updated, a project closes. Each state change is typed. This is what makes the data meaningful over time rather than just a snapshot. It is also what makes automation possible: automations run over defined state changes, not over chaos.

What happened. The audit trail: every state change recorded, timestamped, and linked to the objects it touched. This is what makes continuous improvement possible. If you have the history of how your objects have changed, you can find the patterns. You can ask what conditions preceded a customer churning, or what a seat looked like in the months before it became a problem. Without this layer, you are always reacting. With it, you can get ahead.

The payoff: a business you can continuously improve​

The reason this matters for exit readiness is not just that buyers like documentation. It is that a business with a clean object model is a business that can be continuously improved rather than just operated.

Digital transformation is AI transformation, and both are ultimately about the same destination: a business that knows its current state, records it, finds patterns, and improves. But you cannot track current state if you have not defined what the objects are whose state you are tracking. The data layer requires the ontology layer beneath it.

A business that has defined its objects can run coherence checks on itself. Does every seat have a single measurable metric? Does every customer have a defined status? If not, the type system surfaces the gap. This is the equivalent of running a compiler on your business. The errors it finds are not software bugs. They are organizational ambiguities you have been living with.

The business you want to hand off (to a buyer, to a management team, to a set of agents that can run it without you) is a business that can be talked to. You ask it a question and it gives you an answer. You tell it to do something and it does it. That capability is not built on top of good intentions. It is built on top of a clean object model that maps to what the business actually is, not what anyone wishes it were.

The sequence matters. Map the objects. Define the properties. Record the state changes. Build the history. Then transform.

Further reading​

Sources: GameOS Wiki, "Business as an Object Model."