This sprint I built something with an intimidating name and a very practical job: an ontology for Domi. The word tends to either scare people off (it starts in Greek philosophy) or get waved around as enterprise-software incense. It deserves better, because underneath it is one of the most useful ideas in building software that an AI has to operate — and it’s simple enough to explain over coffee.

What an ontology actually is

In philosophy, ontology is the study of what exists. In software, an ontology is much humbler: it’s an explicit, written-down answer to “what exists in this domain, and how does it relate?” — one the machine can read, not just the humans.

Every application has an implicit ontology. Your banking app believes in accounts, transactions, and payees. A hospital system believes in patients, encounters, and orders. The difference between an implicit ontology and a real one is whether that vocabulary lives in one declared place — or is smeared across the database schema, the UI labels, the API docs, and the heads of whoever wrote them.

That difference didn’t matter much when only humans and hand-written code touched the system. It matters enormously the moment an AI agent does. An agent can’t absorb tribal knowledge from the hallway. When Claude or ChatGPT connects to Domi and wants to be useful, the quality of everything it does traces back to one question: does it know what a household is made of?

The elements of an ontology

Strip away vendor vocabulary and an ontology has five working parts:

1. Entity types — the nouns. The kinds of things that exist.
2. Link types — the grammar. Which nouns can connect to which, and what the connection means. This is where meaning actually lives: “insurance policy” and “vehicle” are just words until a link says this policy covers that vehicle.
3. Taxonomies — the adjectives. Controlled vocabularies that classify entities: a contact can be a dentist or a plumber; an obligation can be rent or a streaming subscription. Open-ended enough to grow, closed enough to be queryable.
4. Properties and constraints — what each entity carries, what’s required, and — increasingly important — how sensitive each piece is. In a household system, “sensitivity” isn’t a footnote; it decides what gets encrypted, what an agent may see, and what needs a human’s explicit yes.
5. Actions — the verbs. This is the part most definitions skip and the one I’ve come to think matters most: not just what exists, but what may be done to it, by whom, with what confirmation. A vocabulary of nouns tells an agent what it’s looking at; a vocabulary of verbs tells it what it’s allowed to touch.

I’ll be honest about the inspiration: I spent an evening studying how Palantir’s Ontology works — the system that made this idea a product category. I adopted the shape (a semantic layer of nouns and links, a kinetic layer of verbs, security woven through both) and deliberately rejected the machinery a solo consumer product doesn’t need: no stored graph database, no code generation, no actions that fire without a human in the loop.

Domi’s ontology, concretely

As of this week, Domi’s vocabulary is declared in one machine-readable file, and the build fails if the code ever drifts from it. Here’s what’s actually in it.

Seventeen nouns, in five clusters. The household graph: members, assets, contacts, obligations, and affiliations — the people, the things, the outside world, the commitments, and what each person does with their time (school, job, the soccer club). The activity stream: tasks, events, transactions, documents, notes, and shopping lists. The objective layer: areas (permanent life domains like Health or Finances), projects (things that finish), and goals (things you measure). The collaboration layer: sharing groups and invitations. And the container itself — the household.

Fourteen links. Eleven are stored junctions: who has custody of which asset, who is married to whom and who is whose parent, which insurance covers which vehicles and which family members, which vendor services which residence, who’s attending an event, which documents back a task, which lists belong to whom. One is a containment edge — the heat pump is in the pool, the pool is at the house. And two are derived, never stored: siblings (computed from shared parents — why store what you can infer?) and the member-to-organization edges that fall out of affiliations. One honest declaration in the file: the visual graph renders only four of the seventeen entity families. That was always true; now it’s written down as a decision instead of lurking as an accident.

Thirteen taxonomies — the registries that classify things: twenty-nine kinds of obligation (rent to streaming), twenty kinds of contact, the asset kinds, the transaction categories. Each registry value is bound to its place in the ontology, so a new category can’t appear without declaring what it describes.

Sensitivity classes on every noun. Most entities carry their prose in an encrypted envelope under the household’s own key; assets keep an encrypted overflow for things like a VIN; structural rows are plain metadata. The ontology states which is which — so “what does the agent see?” and “what does a stolen backup leak?” have declared answers.

And thirteen verbs. The action registry went live this week: create a task, complete it, snooze it; create a shopping list, add to it, check things off; capture a note, an event, a contact, an obligation, an affiliation, a project, a goal. Every action declares the minimum household role that may perform it and whether it needs explicit confirmation. One dispatcher enforces all of it — there is no side door. This is precisely what made it safe to let external AI assistants write to Domi this week, not just read: the assistant doesn’t get “database access”, it gets thirteen well-defined verbs, each with a permission floor, a rate limit, and an audit trail.

Why bother

Because the vocabulary was already there — scattered. Before this week it lived in four places that didn’t know about each other: the database schema, the classification registries, the graph renderer, and the tool list. To answer “what exists in Domi?” you had to read all four and hope they agreed. Now one file answers, and a test fails if it lies.

And because everything that comes next stands on it. The agent that runs errands on trusted websites, the per-assistant permission sets, the mobile app’s understanding of the household — they all need the same thing the connected assistants need today: a house that knows its own words.