One Million Ontologies

We’re targeting one million ontologies at Inferal.

I have spent decades writing software, which is long enough to develop strong opinions about preventing mistakes. Type systems, interfaces, and contracts make assumptions visible before code runs.

They cannot guarantee that two systems mean the same thing. customer_id: UUID can compile even when the producer means a CRM account and the consumer joins it to a legal party. Both services may satisfy their interfaces as written.

Types Did Their Job

This is not an argument against type systems. Quite the opposite. Types changed how I think about software. They force a useful question early: what kind of thing is this, and what operations make sense for it?

Good interfaces do the same at a boundary. They state what a component accepts, what it returns, and what it promises to preserve. Contracts make assumptions available to tools instead of leaving them in somebody’s head.

But the protection is only as good as the contract. Two services can agree that a value is a UUID without agreeing on the identity behind it. They can validate the same JSON, return 200 OK, and quietly attach a workspace to the wrong contracting organization.

The image at the top makes the joke with “customer.” A CRM account, a legal party to a contract, a person entitled to open a support ticket, and a product workspace are different things. People call all of them “the customer” until a piece of software has to renew an agreement, grant access, or send an invoice.

The problem is no longer the representation of a value. It is the meaning of the thing represented and its relationship to everything around it.

What Workflow Engines Exposed

I have built workflow engines before: interpreters for BPMN and Amazon States Language. You learn a lot by implementing formal descriptions of control flow. One lesson is that a system can execute the wrong model with extraordinary precision.

A workflow language can specify which step comes next while leaving the identity of its domain objects implicit. Unless it is given a domain model, it cannot tell whether customer in one step means the account, the contract party, or the person authorized to act. Adding another branch does not supply that missing model. It gives the ambiguity somewhere else to go.

Rules address a different part of the problem. Instead of spelling out a sequence, they state the conditions under which something should be inferred or done. But a rule such as “activate an agent when inventory is unavailable” carries its own unresolved nouns. Which inventory? Unavailable where, for which channel, and at what time?

Inferal’s operational models combine current entities and relationships with policies and rules. Ontologies provide the identity criteria and meaning those models need.

Ontologies Are Not Type Systems Writ Large

The analogy has a limit. A program’s type system primarily constrains which values and operations are valid. Nominal, refinement, and dependent types can encode many domain distinctions, but those commitments are usually local to a program or interface. An ontology makes concepts, identity criteria, relationships, and permitted inferences explicit across systems inside a defined context.

A schema primarily constrains how data is represented, though it can encode domain constraints. A rule derives a conclusion or triggers an action. The ontology supplies the shared interpretation under which schema fields and rule predicates are used.

It continues the lesson I learned from types: an assumption becomes much more useful once software can inspect it.

Most systems already contain local semantic commitments. They are scattered through database constraints, API documentation, validation code, spreadsheets, policies, and operating practice. These artifacts are not ontologies by themselves. They are evidence from which one can be constructed and tested.

Inferal runs operational models in the data stack. Source data is synchronized into entities and relationships, and policies and rules evaluate the resulting state.

Before activating an agent for a renewal, the model has to resolve the CRM account against the contract party and covered workspaces, including the people authorized to act. An inventory promise has to distinguish physical stock, reservations, quarantined lots, and expected receipts, each attached to a place and time.

The ontology defines those concepts and relationships. Mappings bind source records to its terms. Provenance records where assertions came from, and governance identifies which sources are authoritative in this context. Policies and rules then evaluate the current state.

Without that foundation, the stack can keep every record current, activate an agent at exactly the right moment, and still act on the wrong entity.

Why in the World Should There Be One Million?

Software engineering also taught me not to solve every boundary problem by deleting the boundaries.

One ontology for the world is hopeless. One ontology per company is the same mistake with a more plausible calendar invitation. A company contains many recurring decisions and exchanges, each with its own participants, authority, tolerable loss, and rate of change.

We want an ontology for each context where meaning has to survive a boundary: one for a renewal, one for an inventory promise, one for deciding which parties a supplier review covers. Here, a context is a repeatable decision or exchange with known participants and some authority over its terms.

One million is a target and a design constraint, not a count extracted from a market-sizing spreadsheet. We count independently governed, scoped ontologies, not every version, import, or runtime projection.

Software already packages computational machinery as libraries. Business-domain ontologies, vocabularies, and standards also exist, sometimes in great depth. What is still uncommon is a package ecosystem that makes semantic modules easy to discover, version, compose, test, and specialize for operational use.

A supplier-review model should be able to import common concepts for legal entities and agreements, then state its own authority and scope. Reuse lowers the cost of that local model without forcing every organization to define supplier in the same way.

At one million, full pairwise alignment would create nearly 500 billion possible pairs. Please do not build that spreadsheet. Mappings should exist only where information crosses a real boundary, and they may be directional, conditional, partial, or lossy. Equivalence everywhere is a much stronger claim than safe translation for one exchange.

When many contexts keep making the same commitment, the common part can earn its way into a standard. Not before.

The Product Bet

Ontology engineering, knowledge graphs, and rule engines all predate Inferal. The question for us is whether a narrowly scoped ontology can be created and kept current cheaply enough to participate in everyday operations.

A target of one million rules out a process centered on consultants and a steering committee. Drafting, testing, versioning, and alignment have to happen in the product.

An agent can draft a candidate ontology from the systems involved and probe it with counterexamples, such as one CRM account mapping to two contract parties. The owner decides what governs and tests the result. Every decision made under an accepted ontology records its source facts and the exact ontology, mapping, policy, and rule versions that produced it.

The millionth ontology will probably be boring. It may only distinguish an expected receipt from stock physically available and relate both to a product, location, delivery window, and sales channel. That is enough for policy and rules to decide whether the receipt can support a promise.

I have spent a career using types and contracts to make invalid states harder to represent. At Inferal, we want operational models to make invalid interpretations harder to act on.