Stop Building Big Ontologies: Start with a Minimum Viable Closed Loop

01. Don't Rush to Build

The previous article "The Real Trouble Starts the Day the Ontology Is Built" drew a comment asking for practical steps. The answer: there is no new framework; the method lies in the gap between "building" and "making it live." Break that wall and the path appears.

Contrary to the current hype around ontologies, knowledge graphs, and enterprise brains, you should not start with a grand master diagram. An ontology begins with a real, painful problem, not a big picture. Pick your sharpest pain point: orders that keep failing fulfillment, equipment downtime with no clear root cause, or cross‑department arguments over "the same customer." Translate that problem into ontology terms: what are the objects? Which states change? What rules judge the situation? What actions follow? You'll find you don't need an "enterprise‑wide panorama ontology"; you only need an ontology that solves this specific problem. It may be tiny — three classes, two states, three rules — but it works. Projects often die at step one because teams try to map the entire enterprise into one diagram; the more complete the diagram, the further it drifts from the business.

02. Close One Minimum Loop (MVP)

Many assume ontologies are built layer by layer: model first, then ingest data, then run events, then connect actions. The sequence is correct, but waiting until all four layers are finished before running is fatal — the project stalls and likely never runs. The right approach: follow a single business line and punch through all four layers in one go.

Using the order example:

Identity layer: Unify "Company A" across ERP, CRM, and MES into a single object.

State layer: Record every status change from "pending review" to "scheduled" to "shipped."

Judgment layer: Define the rules the system uses to decide "will this order be delayed?"

Action layer: When the judgment says "delay expected," automatically notify the warehouse or update the status.

These four layers are not sequential phases; they form a single chain. This is the ontology version of an MVP — minimum viable, but with a complete closed loop. It's not a feature cut; it's a scope narrowing: all four layers present, serving only one business line. Once that line runs, you have pre‑validated the three core risks of any ontology project: Can data align? Can states propagate? Do judgments and actions connect? A small version validates all three in three months, far better than a two‑year big‑bang reveal. Get one line working so the business actually improves because of the ontology; only then do you earn the right to talk about replication and extension. Ontologies grow; they are not built.

03. Let Governance Grow with the Business, Don't Pre‑Build Committees

The previous article mentioned a governance trio: Business Owner, Data Steward, Governance Committee. Some think this structure must exist before the ontology moves. Reverse it: governance is a by‑product, emerging only after the business runs and forces decisions.

To close the first loop you must answer: who owns the definitions on this line? For example, "what counts as a delay?" IT cannot decide; a business person must own it. Assign one business owner for that line — one person decides, accountable for issues. When you have five lines and five owners start clashing, then form the Ontology Governance Committee. At that point it's a natural evolution, not an imposed structure. A committee created upfront becomes a talking shop with no real decisions to make because no concrete "business" yet forces them.

04. Switch Your Metrics

The most dangerous trap is measuring the wrong things. Stop using "build" metrics:

How many classes? How many attributes?

How many data sources connected?

How fast does the graph database run?

These measure "building," not "living." Switch to "live" metrics:

How many business decisions actually trust the ontology? (Not "how many queries," but "when they make a call, do they believe it?")

Time from a definition change proposal to system‑wide effect. (Days → hours means it's alive.)

Percentage of ontology data that is "potentially stale." (This number should approach zero.)

One year after launch, how many people still maintain and use it? This is the most important. If people still argue when the ontology is wrong, it's alive. If only IT maintains it in silence, it's dead — quietly.

Summary

Four sentences capture the entire method:

Start from one real problem; don't draw a big picture.

Punch through all four layers along one business line — build the smallest complete closed loop.

Let governance grow with the business; don't erect empty committees first.

Measure by "decisions that trust it," not by node counts.

Miss these four, and even the prettiest ontology becomes waste paper in three years. Hit them, and the diagram turns into something the enterprise actually uses.