---
title: "Glossary, taxonomy, ontology: data semantics before AI agents"
url: https://zerofive.ai/en/blog/insights/glossary-taxonomy-ontology-ai-data
canonical: https://zerofive.ai/en/blog/insights/glossary-taxonomy-ontology-ai-data
language: en
published: 2026-10-28
updated: 2026-10-26
author: "ZeroFive.AI"
tags: glossary, taxonomy, ontology, semantic layer, insurance, AI Rating
abstract: "Glossary, taxonomy and ontology explained with an insurance example: why data semantics must be governed before connecting AI agents to company data."
---

# Glossary, taxonomy, ontology: data semantics before AI agents

**In short.** A glossary, a taxonomy and an ontology answer different questions about data: what a term means, which category an object belongs to, how objects relate to one another. An AI agent connected to company data needs those answers written down and approved by someone, otherwise it picks a definition on its own and returns plausible numbers that nobody can trace back. The work starts with a short glossary built on the KPIs that reach the board, with a business owner for every term.

Ask three functions of the same insurance company how much premium they wrote this year and you will get three different numbers, all of them correct: underwriting reasons in earned premiums, finance in booked premiums, the sales network in premiums written by its own portfolio, and each has spent years building reports and habits around its own definition.

As long as the people reading those numbers know the context, a phone call clears up the difference. When the reader is an AI agent connected to the data warehouse there is no phone call, and the agent picks one of the definitions without telling anyone. It does so with confidence, returning a value in the same tone whichever path it took.

According to the Artificial Intelligence Observatory of Politecnico di Milano (February 2026), 71% of large Italian companies have active artificial intelligence projects and only 9% have structured AI governance. When we measure an organisation's AI Readiness, part of that gap has a very precise shape: the data is there, often there is even a catalogue that says where to find it, but there is no written agreement on what the words the company uses to describe its own business actually mean.

A catalogue solves search, meaning is a different problem, and it is handled by three tools that companies confuse with one another quite regularly (sometimes even inside data governance programmes).

![ZeroFive.AI infographic: glossary, taxonomy and ontology compared, with the example of the motor loss ratio by intermediary](/glossario-tassonomia-ontologia-en.png)

## The business glossary

A glossary is the governed list of business terms: for each term a definition, the accepted synonyms, an owner and a review date. It looks like the simplest of the three and it is the one most often missing, because definitions live in the head of whoever built the first report, or in queries nobody has reread for years.

Three sample entries from an insurance glossary:

- **Earned premium**: premiums booked in the year net of the change in the unearned premium reserve, that is, the part of the premium that covers the risk of the year.
- **Open claim**: a claim that has been filed and not yet closed, with or without payment, including reopened claims.
- **Active customer**: a policyholder with at least one policy in force at the reference date.

Definitions matter less than people think, because they can be discussed and changed. What weighs more is ownership and process: every term has a business function that approves it, and a rule that sets who can change it and how the change reaches the reports and systems that use it, otherwise the glossary ends up in a shared folder, updated once and then forgotten.

## The taxonomy

A taxonomy classifies concepts into categories and subcategories, usually as a hierarchy, and is used to group and aggregate: it is the structure that lets you add up the premiums of a class or read a portfolio by product family.

In Italian insurance a reference taxonomy already exists and is written into law, because Article 2 of the Private Insurance Code (Legislative Decree 209/2005) classifies business into life and non-life classes, each with its own numbering.

- Class
    - Non-life
        - Land motor vehicles (class 3)
        - Fire and natural forces (class 8)
        - Motor vehicle liability (class 10)
    - Life
        - Class I, insurance on the duration of human life
        - Class III, benefits linked to funds or indices

Each insurer then builds its own management aggregations on top of that classification, and that is where the misunderstandings start: for the sales department "motor" may include class 3 and class 10, for management control only class 10, and the report that reaches the board depends on who prepared it.

A taxonomy, however, knows a single relationship, belonging, so it knows that a motor liability policy sits in non-life but ignores who sold it and which claims it generated. For that information you need a model that admits relationships of a different kind.

## The ontology

An ontology is a formal model of concepts, properties and relationships, which can include explicit logical constraints: a policy has one and only one policyholder, a claim refers to a policy in force on the date of the event.

- Policyholder → holds → Policy
- Policy → belongs to → Class
- Policy → is sold by → Intermediary
- Policy → covers → Insured asset
- Claim → is filed on → Policy

Compared with a taxonomy the nature of the link changes, because here every relationship has a name and a meaning, and the entities it connects belong to different domains, from the portfolio to the distribution network to claims handling. The model is written in a format a machine can read and draw inferences from, with standards that have existed for years (W3C's RDF and OWL) and mature domain ontologies, such as FIBO for financial services, maintained by the EDM Council.

We devoted the first of our [AI Strategy Papers](/en/papers), Govern Meaning, to this tool, covering how an ontology is designed and maintained over time. How to build one starting from the entities of a single process is in [enterprise ontology](/en/blog/insights/enterprise-ontology-for-ai), and why a system without structure guesses instead of reasoning is in [ontologies as infrastructure](/en/blog/insights/ontologies-infrastructure-ai-reasons-or-guesses).

## An example from motor insurance

Imagine asking an AI assistant connected to the insurer's data: "Show me the motor loss ratio by intermediary over the last twelve months".

It looks like a simple question. To answer it well, though, the agent needs each of the three tools for a different part:

1. **Glossary**: the loss ratio is the ratio between earned claims and earned premiums, and the glossary says which meaning of premium to use.
2. **Taxonomy**: it says which classes make up "motor" in the definition the insurer has adopted for management reporting.
3. **Ontology**: it says that you get from intermediary to claim through the policy, and forces a decision on which intermediary a claim is attributed to when the policy has since moved to another agency.

That decision does not belong to IT, it is a choice about how the company wants to assess its own network, and it is the kind of question that reaches the executive committee. Once the decisions are taken, the semantic layer turns them into measures and calculation rules that the agent queries without reinventing them at every request. Without that foundation the agent answers anyway, with a plausible number that nobody, the next day, will be able to reconstruct.

## Semantics, RAG and agents

A RAG system that knows synonyms and definitions retrieves the right documents even when the user speaks everyday language, where customer, policyholder and insured overlap while for the policy they are distinct roles. An agent that has the ontology knows how to move across tables and systems without guessing the joins, a knowledge graph makes the relationships between entities queryable, and the semantic layer exposes metrics with a single definition for whoever consumes them, person or model.

All of this improves grounding, that is, the link between the model's answers and the company's data. Whether the answers are correct is another matter: an ontology can be wrong or stuck two reorganisations ago, a glossary can hold definitions nobody approved, and even with clean semantics you still need systematic evaluation of the answers and a step in which a person checks the numbers headed for an official document.

## Semantics in the AI Rating

In ZeroFive's [AI Rating](/en/blog/ai-governance/ai-rating-objective-score) model, data semantics falls under the Readiness dimension, alongside governance and skills, and we consider it one of the most reliable signals of whether a pilot can become a production system. A pilot runs on a small scope, with data prepared by hand and people who know how to read it; a production system works on the whole portfolio, with users who have never seen that data.

Buying a knowledge graph platform before deciding what "active customer" means moves the problem into a more expensive tool, which is why in our value chain measurement comes before purchase.

Semantics also enters the Risk dimension. For high-risk systems, Article 10 of the AI Act requires data governance and management practices for the datasets used to develop and test the system, and the cases listed in Annex III include risk assessment and pricing in life and health insurance, with obligations that, after the Digital Omnibus, apply from 2 December 2027. An approved glossary and a documented ontology make it much easier to explain which data was used and with what meaning, which is the first thing whoever has to check will ask, even if on their own they do not prove alignment. How the rating applies to an insurer is in [AI Rating for insurance](/en/blog/strategy/ai-rating-insurance-perimeter-gate).

## Where to start

The first step is a short glossary, built on the terms that appear in the KPIs presented to the board and in the reports management reads every month: for each one a definition, a business owner and, when two functions use the same term in different ways, a decision taken by whoever has the authority to take it. It is political work before it is technical. And that is why we bring it to the level of executive sponsors instead of leaving it to the data team alone.

The taxonomy comes right after, starting from the aggregations already used in reports and making them explicit. The ontology should be built first on the domain where the first agent will work, then extended as the scope grows, because a complete model of the company written in advance ages before it is used. On the data quality underneath all of this, see [data readiness](/en/blog/insights/data-readiness-ai-projects).

## In short

- **Glossary**: fixes the meaning of terms.
- **Taxonomy**: classifies concepts and lets you aggregate them.
- **Ontology**: describes the relationships between business entities and makes them readable by machines.

Before connecting an agent to company data, there is a question to bring to the committee: how many of the terms in the board's KPIs have a written definition and an owner today?

If you want to measure it with us, the AI Rating checks it within the Readiness dimension: write to hello@zerofive.ai or [book a meeting](https://calendly.com/fabiolalli/zerofive).