An ontology is a model of your business
An ontology is a description of the things your business deals with, how they connect and the rules that apply to them.
For a flooring distributor, the things include customers, products, product lines, vendors, orders and purchase orders. The connections say how they relate: a customer places an order, an order contains products, a product belongs to a vendor's product line, and a purchase order fills an order. The rules say what has to be true: an order needs a customer the business knows, and a product has to be in the catalog before anyone can sell it.
None of this is new to the people who run the business. They carry the model in their heads. An ontology writes it down in a form that software can use.
How it differs from a spreadsheet and a database
Most businesses already have spreadsheets and a database, so it is fair to ask what an ontology adds.
| Spreadsheet | Database schema | Ontology | |
|---|---|---|---|
| What it describes | One list, laid out for people | Tables and columns, laid out for storage | The things in the business and how they connect |
| Where the meaning lives | In column headings and in people's heads | In column names, often abbreviated | In the model: a purchase order is a purchase order |
| Where the rules live | In formulas, if anywhere | In application code | In the model, next to the things they apply to |
A database schema is about storage: which columns go in which table. An ontology is about meaning. The two work together. Once the ontology is right, the database can be shaped to fit it, which is what happened in the flooring project below. Don't copy your old database: design the data model first explains why that order of work matters.
Three examples
Many healthcare systems, one model
In an Intelligence Factory healthcare integration project, data came from nearly three dozen EHR and EMR systems, as reported in the original case. Each system had its own fields and formats. The work extracted the data, mapped each source to one shared ontology of entities and relationships, reviewed the results and reused the mappings. The differences between systems stayed in the source mappings, so everything downstream dealt with one model.
900 tables with cryptic names
In an aviation ERP project, the original case describes an Oracle database with more than 900 tables and thousands of columns, with names such as MT05_TRK_LNK. The database's documentation was turned into a crosswalk from those names to business concepts such as purchase order, line item and vendor. A question such as "Show me purchase orders from last month" was mapped to an approved function instead of free-form SQL. The reported starting set was 10 to 15 function classes, expanded as real questions came in, and the question parsing ran locally. Ask your business data questions in plain English covers this approach.
A flooring wholesaler leaving Zoho
A flooring wholesaler had run on a Zoho system customized over 15 years. Its data sat in XLS spreadsheets, CSV exports, PDFs, database backups, Dropbox folders and raw web pages. We built an ontology of how the business's data should look in a couple of days, mapped it to the CommerceServer schema and changed the schema to fit. An automated pipeline then imported 15 years of history, hundreds of thousands of records, in minutes. How a flooring wholesaler left 15 years of Zoho patches in one month tells the whole story.
The model kept working after the import. During a one-month parallel run, staff emailed the PDFs Zoho produced, and Buffaly agents read each one into the ontology, checked it and entered it in CommerceServer. Buffaly is our own software engineering system, and we use it to build and change CommerceServer. The parallel run explains how that month worked.
Rules belong in the model
In most systems, business rules end up scattered: some in code, some in spreadsheets, some in people's memory. An ontology can hold a rule next to the things it applies to.
In The Ontology Does the Reasoning, a rule is added once to a branch of a medical code hierarchy, and inheritance applies it to everything under that branch. A new code under E11 is treated as a chronic condition automatically, without anyone updating a list.
The same idea fits a distributor. A vendor program could be attached once to a product line, and every product in that line, including products added later, would follow it. Put business rules in your data model, not in code or a chatbot covers this in more detail.
Why AI needs one
When AI is connected straight to a database or a folder of files, it has to guess what the data means. It sees a column called MT05_TRK_LNK, or three spreadsheets that each spell a customer's name differently, and fills in the gaps. That is where wrong answers come from. Why AI gives wrong answers about your business data explains this in more detail.
An ontology removes the guessing. The AI works with things the business has defined: this customer, this product, this purchase order. It can also be limited to approved actions on those things. In Buffaly, the AI holds a reference to a record and can change it only through a typed action that checks the rules first. In the published Proof by Construction test, an agent was told to skip review and approve its own work; every attempt was blocked and logged. Can you trust an AI agent with orders, prices and invoices? looks at which actions a business should keep behind a person.
The model also changes what you need from the AI itself:
- With the structure in place, the model's size matters less. You don't need the most expensive AI model explains why.
- New handling is added to the same model as work comes in, so the system builds on what it has already learned. AI that learns your business while it works covers this.
- Routine work can run against the model. Automating order entry from emailed PDFs shows one example.
What it takes to build one
Building an ontology starts with the business, not with software. For the flooring wholesaler, the ontology was built from its scattered sources in a couple of days. The people who run a business already know most of the model. The work is to write it down and check it against the real data. The data advantage big companies pay millions for, built around a small business describes what a small business gets once it has one.
To get ready, gather these:
- Where your data lives today. The system you run on, its exports, and the spreadsheets, PDFs and backups around it.
- The things you deal with every day, in your own words. Customers, products, vendors, orders, and whatever is particular to your trade.
- The connections that cause mistakes. Which order a purchase order fills, which product line a product belongs to, which customer gets which price.
- The rules people enforce from memory. What needs approval, what can never be sold below a price, what has to happen before an order ships.
- The questions you ask most often. A short list is enough to start; more can be added as real questions come in.
Start with a model of your business
If your business runs on a system that has been patched for years, or you want AI to answer questions about your data without guessing, the first step is a model of your business. Tell us about your current system, or read how full service works.