Before writing code, a spec, or a prompt for an agent, you need to answer a question that is almost never asked out loud: what concepts does our problem consist of, and how are they related? The answer goes by the scary word "ontology," but behind it is a simple and very practical thing. Let's unpack it without the philosophy.
An ontology is a system of concepts
A domain ontology describes which concepts exist in the domain, what properties they have, and how they relate. "An order consists of line items. An order has an owning customer. An order is paid by a payment. A cancelled order cannot be paid" — that's a slice of an online store's ontology: four concepts, relations between them, and one rule.
The key insight: every project has an ontology — the only question is whether it's written down. The team operates on some system of concepts either way. If it isn't recorded, it lives in heads — a different version in each. The product manager means one thing by "order," the developer another, support a third. All three versions work until they meet in the same sprint.
For a product engineer this is not an abstraction but a daily tool: you are the one person who brings the business's concepts, the code, and the agent together. Fail to align the concepts and you won't align the product.
A model is never "correct" — it is fit for purpose
The first beginner trap is searching for the "true" model of the domain. It doesn't exist. The same world can be described by different systems of concepts, all of them valid — but differently effective for different tasks.
Example: what is a "customer" for a store? For marketing — a profile with interests. For payments — a payer with details. For delivery — a recipient with an address. Three different models of the same person, and an attempt to build one "universal" concept yields the worst of all: a bloated notion inconvenient for everyone.
The quality criterion for a model is not truth but fitness: does it help solve the tasks it was built for, and does everyone understand it the same way.
Levels of abstraction
The second practical tool is knowing which level you're speaking at. Concepts stack into floors:
- A concrete instance — order #4211 by Ivanov for 3,400 ₽.
- A type — "order": every order has a number, a customer, line items, a status.
- A type of types — "business entities": orders, customers, payments are all entities with a lifecycle.
- Methodology — the rules by which we describe entities at all (say, the convention "every entity has an owner and a state model").
Half of the tangled arguments in teams are arguments between people standing on different floors. One discusses a concrete order ("but here's an order without a customer!"), the other — the type ("an order without a customer doesn't exist by definition"). Noticing "we're on different levels" saves hours.
There are also base sets of concepts that almost any model reduces to. One well-known set: object, relation, state, event, class. Look closely — that's the skeleton of any domain model: entities, links, statuses, domain events, and types. Classic ontology work and DDD arrived at the same place from different directions.
Why a product engineer needs this in the AI era
Concept mismatches used to be smoothed over by people: an analyst would ask again, a developer would guess, a tester would notice. An agent won't ask. The model works only with what you gave it and fills the gaps with plausible guesses — confidently and silently. If "order" is one thing in your head and another in the prompt, the agent implements a third.
So the system of concepts is the first artifact worth writing down once you've taken on the problem: concepts, relations, rules. It will then become a vocabulary shared by the team and the agent and turn into a spec — but it all starts here, with an honest answer to "what does our problem consist of."
In short
- An ontology is the domain's system of concepts: concepts, properties, relations, rules. Every project has one; the question is whether it's written down or lives in heads in divergent versions.
- A model is never "true" — only fit for the task; a universal concept "for everyone" is usually the worst for each.
- Concepts live on levels of abstraction (instance → type → type of types → methodology); cross-level arguments cause half the misunderstandings.
- Almost any model reduces to a base set: object, relation, state, event, class — the skeleton of both a domain model and a future spec.
- In the AI era the cost of unwritten concepts has grown: an agent doesn't ask again — it fills gaps with guesses.
Next — a conceptual model is not a database schema: why jumping "straight to tables" breaks projects, and what to model before the storage structure.