Part 1 — What an ontology is
3. What your model says exists
A team was asked how many households buy from them. The data was complete and clean. The question could not be answered, and the reason had nothing to do with data quality.
In chapter 1 you built the definition. In chapter 2 you learned to place any model on the six steps.
This chapter is about something that is true at every step, including step 1.
A retail team was asked a simple question by their new head of marketing: how many households buy from us?
They had eleven years of clean data. Every order, every customer, every address. They could not answer.
Not "it will take a week." Could not answer, at all.
Ontological commitment
In plain words: the list of things your model says are real.
This is the official name, and you should know it, because it is what the field calls the idea. But the idea itself fits in one line.
What your model can count, it says is real. What it cannot count, it says is not real.
The retail team's model had a Customer table. So customers were real. It had no Household table. So households were not.
They held every address. Two people living at the same address were simply two customers. Nothing was missing from the data. What was missing was the decision that a household is a thing.
Find the invisible questions
The trap is that invisible things do not look invisible. They look like data you already have.
Here is a small schema. Nothing is wrong with it. Work out which questions it can answer.
A perfectly normal schema
Customer
customer_id, name, email, address
Order
order_id, customer_id, order_date, total
Product
product_id, name, category, price
Assume the data is complete and clean. For each question, can this model answer it?
How many orders did each customer place last year?
Which product category earns the most?
How many households buy from us?
What is the average order value?
Which customers switched from one product category to another?
The one people always miss
Almost everybody gets the category question wrong, and it is worth slowing down here.
Product has a category column. So you have categories, surely? You can group by it and draw a chart.
Now look at what a category can and cannot do in that model.
It cannot exist before some product mentions it. It cannot have an owner, a description, or a parent category. It cannot be renamed in one place. Two products can spell it differently and become two categories. Nothing else can point at it.
A category is not a thing here. It is text printed on a thing. When you group by it, you are counting spellings.
This is the most common hidden claim in business data. A text column looks like it gives you a thing. It does not.
Thing, or just text? A ten-second test
Do not ask what it is called. Ask what you can do with it.
| Can you... | If no, it is text |
|---|---|
| count them without counting spellings | not a thing |
| rename it once, everywhere | not a thing |
| give it its own facts, like an owner or a start date | not a thing |
| point at it from somewhere else | not a thing |
| have it exist before anything mentions it | not a thing |
One "no" is enough. A category stored as text fails all five.
Three things to remember
1. Naming is claiming
The moment you name something in your model, you have said it is real. There is no neutral option. Not naming it is also a claim.
2. A column is not a thing
Text sitting on a row looks like data you have. It is not something you can count, rename, or attach facts to. This is the mistake that costs the most, because it looks like success.
3. The gap is silent
Nothing errors. No warning appears. The question simply cannot be asked, and the only sign is a person saying "we do not really track that."
Check yourself
Your model has Employee and Department, and Employee has a `manager_id` pointing at another Employee. The CEO asks: how many management teams do we have, and which ones are short of people? What is the real problem?
Why this matters more with an agent
A person who hits an invisible question notices. They say "we do not really track households" and everyone adjusts.
An AI agent does not notice. It sees an address column, it sees addresses repeating, and it gives you a number. The number looks like an answer. Nobody in the room can tell it was built from a column that was never meant to carry that meaning.
Your model's silent gaps used to be a limit people worked around. Now they are the exact places your agent will make something up.
Creating an entity type is the moment you decide
In Fabric IQ this decision has an exact location. It is the moment you create an entity type.
Create Household, give it a key, bind it to data, and households are now real. Every query can count them. Every relationship can point at them. An agent can reason about them.
Do not create it, and no amount of address data will make households visible.
This is clearer than in a plain database, and it is one of the honest arguments for building an ontology at all. In a warehouse, the line between a thing and a column is blurry. In an ontology it is a decision with a name and a date on it.
The one trap
Do not mistake a column for a thing.
Text on a row cannot be renamed in one place, cannot carry its own facts, cannot be pointed at, and cannot be counted without counting spellings. It is a label, not a thing. Group by it and you get an answer that looks right and is not.
Next, chapter 4. You now know that naming a thing is a claim that it is real. That raises the obvious next question: what kinds of things are there to name? Chapter 4 covers the biggest boxes, the few top-level groups that everything else fits inside, and how knowing them ends arguments before they start.
Do it yourself
Build this step in the interactive Ontology Lab.
Open the lab →Milestone
Finished this concept? Mark it learned to track your progress.