What ontologies add to business data

In my work at Inferal, I use ontologies to describe what business data means and how different pieces fit together. A simple example helps explain why this matters.

Say you want to compare two advertising campaigns. Both reports show a cost per conversion. But one counts a purchase as a conversion, while the other counts someone filling in a form. Before comparing the numbers, you need to understand that difference.

Making business meaning explicit

People familiar with the business may already know this. Software needs those definitions to be explicit. An ontology is a way to describe them, along with the relationships between campaigns, customers, purchases, and other parts of the business.

Getting this right takes work. An API tells us which fields are available and often describes their types. We also need to understand what those fields represent, when two values can be compared, and what we can conclude from them.

This is why ontologies matter to us at Inferal. They give our rules and agents a shared understanding to work with. When you ask a question about your business, the answer should use the right definitions and data, and make it clear when something is missing.

A lot of this starts with information that already exists. API documentation, business policies, and the tools people use every day all contain useful knowledge. The difficulty is that each describes only part of the picture.

For example, an advertising platform can describe the campaigns it runs and the results it reports. Your store knows about orders and payments. Your inventory system knows which products are available. To answer a question across those systems, we need to establish how their records relate. We also need to keep the differences that matter. An order being placed and a payment being received are separate events, even if a report groups both under “sales.”

We built an ontology compiler to turn API descriptions into structured models that software can use. That makes the initial work repeatable. We still have to add the meaning needed to use those models in the business.

Agents help with that work. They can read documentation, gather supporting information, and propose definitions and relationships. Those proposals need review, and automated checks help catch inconsistencies. The useful result is a model whose assumptions we can inspect and whose definitions are supported by evidence.

Small distinctions change the answer

Some of the hardest decisions come from details that look small at first.

Take a missing value. If a report does not include a conversion count, treating it as zero could change which campaign an agent recommends pausing. We need to know whether the source is reporting no conversions, whether the figure is unavailable, or whether we simply have not received it yet. If we can’t tell, we need to say so.

Suppose a report gives a campaign’s total spend as $1,000. It also breaks that spend into $600 on mobile and $400 on desktop. Adding all three figures gives $2,000, even though every individual number is correct. The model needs to record which figure is the total and which figures are parts of it, so software can avoid counting the same spend twice.

Each decision affects what software can safely infer from the data. If we model the relationship incorrectly, every rule or agent using it can carry that mistake forward.

Shared meaning also needs to leave room for different ways of working. A sales team may use “customer” to mean an account it manages, while support needs to identify the person asking for help. Both are useful views. An ontology can describe each one and the relationship between them, so software can use the right view for the task.

Connecting data to useful questions

Once those relationships are clear, we can ask more useful questions.

Return to the advertising example. If you ask why cost per conversion went up, we first need comparable figures: the same kind of conversion, the relevant reporting periods, and the same measurement rules. Then we can examine spend and reported outcomes together. We can establish what changed in those figures and identify what still needs investigation.

The same approach helps when a question crosses into another part of the business. A campaign may be performing well while the product it promotes is running low on stock. Connecting the campaign to the product and its available inventory gives a rule or an agent the context needed to flag that situation. Vish discusses this kind of connection in his article on context-aware agents for ecommerce.

Connected business data

1. Advertising platform

   Campaign

   promotes

2. Store

   Product

   has available

3. Inventory system

   Inventory

For customers, this means being able to follow the information behind an answer. Which records were used? What does the measurement include? Which relationships connect the result to your business? Where is information missing? These are practical questions, especially when an answer may influence a decision.

At Inferal, ontologies provide the meaning that our operational models use alongside current data and business rules. This gives us a foundation for helping customers understand what is happening across their tools and decide what deserves attention.

The work starts with a question that matters to the business. If there is one you still answer by moving between reports, spreadsheets, and different teams, bring it to a conversation with us. We can explore the data, definitions, and relationships needed to answer it.