Why OCOM
Your organization is not your software
Why I wrote OCOM, an open specification that describes an organization as a system of governed objects.
Every company I have worked with kept its real operating knowledge in three places: people's heads, chat threads, and a file share. The official systems held fragments. The ERP knew invoices, the CRM knew contacts, the wiki knew what someone wrote down in 2021 and nobody dared to delete. Each described the organization in its own dialect. Nobody held the whole.
The costs are concrete and everyone has seen them:
- A new analyst spends their first week searching for what the company already knows, and still misses half of it.
- Three systems hold three definitions of "customer", and every integration between them is a diplomatic negotiation.
- A decision made two years ago still constrains today's work, but the only trace of it is a chat thread nobody can find, so the argument happens again.
- The one person who actually knows how billing works goes on vacation, and half the company's questions quietly queue up behind their return.
- An AI assistant, connected to all of the above, confidently cites a policy that was superseded eighteen months ago.
The last symptom is new, and it is the one that finally made me write things down.
The pattern under the symptoms
Most organizations describe themselves through the systems they run on. When a platform changes, the description of the organization changes with it, even though the organization itself did not. The knowledge that survives platform migrations lives in prose: documents, wikis, slide decks, tickets.
And prose fails a simple test. Take any operational statement your company relies on ("enterprise customers get a dedicated support channel", "refunds above X require legal review") and ask four questions:
- Identity. What exactly is this about? Which objects, which scope, which cases?
- Ownership. Who answers for this being true? Not who wrote it, who owns it now?
- Lifecycle. Is it current, superseded, or not yet in force? Since when? Until when?
- Evidence. Why should anyone believe it? What decision, contract, or event backs it?
A document answers none of these by construction. A database answers them only inside one application's walls. So operational knowledge either floats free of governance (prose) or gets locked into a vendor's schema (systems). Both drift, silently.
For twenty years this was an accepted tax. Humans compensated: they asked a colleague, they knew whom to trust, they remembered what was stale. Then we started connecting AI to these archives, and the compensation stopped working. A language model reads the superseded policy with exactly the same confidence as the current one. Retrieval finds text, not truth. An assistant wired to an ungoverned archive is not a knowledge system; it is a very confident rumor mill. The failures we tolerated as friction became failures we cannot tolerate as answers.
I have come to a blunt conclusion from building and reviewing these systems: documents describe intent; agents need operating facts. Who owns this. What state it is in. What decisions constrain it. What changed recently and why. No amount of embedding quality substitutes for that structure. Structure comes before intelligence.
What OCOM is
OCOM (Object-Centric Operating Model) is an open, technology-independent specification that describes an organization through the things it manages and the relationships between them, independently of the software used to run it.
The core idea fits in one sentence: an organization is a system of governed objects, where every object carries identity, ownership, lifecycle, and evidence, and everything else (dashboards, documents, graphs, search indexes, agent context) is a rebuildable projection of that governed source, never a second source of truth.
Two of those four words are not yet definitions. Identity and Ownership are Core Vocabulary terms; Lifecycle is defined at the Models tier; Evidence is specified at the Memory tier with its Definition reserved for a future version (AO-021), and it is not one of an Object's Core Characteristics at all. The sentence is the idea of OCOM, not a claim that all four are specified to the same depth (AO-053).
A customer, a payment, a campaign, a decision: each is described once, consistently, in a way that stays valid whether it lives in one system today or a different one next year. The same description can be read by a person trying to understand the business, by a system exchanging data with another system, and by an AI agent that needs context it can actually rely on. One model, three kinds of readers, no drifting dialects.
For AI specifically, the whole write policy fits in one sentence: the model proposes; it never gets the pen on the record. Extraction, summarization, and drafting are proposal layers feeding a governed record through explicit promotion, with a human owner wherever the stakes or the contradictions demand one. Everything an agent reads is current, owned, and trustworthy by construction, and everything it writes is a claim awaiting judgment.
Full honesty: I did not design any of this for AI. The model was written for human reasons (drift, arguments, lost decisions) before agents were on my radar, and I was surprised myself by how cleanly it fits what agents turned out to need. In hindsight the reason is boring: an agent is a reader with no intuition, no hallway context, and no shame about being confidently wrong. The discipline humans could always compensate for is the discipline agents cannot live without. So the real AI opportunity here is not smarter models. It is organizations that are finally legible to them, where "who owns this, what state is it in, why do we believe it" is answered the way a person would answer it: by looking it up.
OCOM is not a product, not a database schema, and not software. There is nothing to install and nothing to buy. It is a specification in the RFC tradition: a set of concepts and rules for describing operational reality, meant to remain stable while the technology underneath changes. It is published under an open license at ocom.uno.
What happened when I applied it
OCOM was not born general. The first version was written for an iGaming operation, an industry that concentrates this problem like few others: many partners, many systems, money moving in both directions, and a regulator asking "why" about every number. Only later did it become clear that almost nothing in the model was specific to the industry. The mess is universal; iGaming just runs into it faster.
I did not write OCOM in the abstract. Its principles run in production: in systems I operate myself, and in several iGaming and IT companies where I work as the architect or consultant and the in-house teams do the implementing. Those rollouts sit under NDA, which is why the specification's Examples carry an anonymized reference case instead of client names. What that claim is worth, and what it is not, is stated on the Evidence Register: it is an owner declaration, the lowest of four levels, and not publicly verifiable. The sequence in that case (identity first, events and evidence second, the commercial and governance layers, then projections) is the sequence the real rollouts converged on. It reads as a clean line because it is a distillation: the wrong turns of any single rollout are not in it. They also can never become public case studies from my side, and that is precisely why the specification is open: the public evidence has to come from implementations I do not control.
To state the boundary plainly: this site sells nothing and offers no service. The consulting work above is disclosed so that a reader can weigh the evidence with my interest in view, not as an offer, and the specification is licensed for anyone to apply without me in the room.
The honest report: the discipline is not free. Declaring one governed source means arguing about ownership early, when it is uncomfortable, instead of late, when it is expensive. Treating projections as disposable means investing in rebuildability up front, in whatever systems you already run; the specification itself prescribes no storage or projection technology. What you get back is a different class of question becoming trivial: "which version is in force for this case", "who answers for this number", "why does the report disagree with production". Those stop being detective work and become lookups. What adoption requires, and what it does not, is set out in the FAQ annex.
One goal deserves to be named plainly, because it drove the design from day one: operational knowledge should belong to the organization, not be rented from the memories of its employees. When how-things-work lives in one specialist's head, every vacation is an outage risk and every resignation is a small fire. Writing that knowledge into governed objects is how a company stops being hostage to tribal memory. And, fairness demands the flip side, it is also how the specialist finally gets to hand off cleanly, take a real vacation, and be valued for judgment rather than for being the only one who remembers.
And one honest boundary: if your operation is a straight line, do not adopt this. A five-person company with one product and a two-step process does not need governed objects; the discipline would cost more than the drift it prevents. OCOM applies where several systems, teams, and money flows describe the same things differently, and the cost of that disagreement has become visible.
Where it stands
OCOM's Core Vocabulary is at v0.1, released; governance and the sequential reading path (Specification v0.2) are baselined. It is early. Terminology, structure and scope may still change through the change process before 1.0, and the repository README says so.
The specification has a single author, but it has already been argued with: by the CTOs and teams implementing it, and by every production incident that bent a concept until it held. What it has not had enough of yet is public argument, and that is exactly what this page is for. Read the Executive Overview, take one messy corner of an organization you know, model it, and tell me where the model bends or lies. That critique is worth more to me than any praise.
Organizations are not defined by their software. They are defined by the operational relationships between the entities that create, transform, exchange, and preserve value. We have spent decades giving software better and better descriptions of itself. I think organizations deserve the same.