Beyond Facts: Formal AI Hypothesis About the Ontology Itself

Important business concepts rarely live in a single definition. “Declined payment,” “active customer,” or “urgent ticket” can show up in documentation, code, metrics, filters, and operational decisions. The same name can hide different criteria; equivalent definitions can circulate under distinct names. That is why building a canonical representation of a business concept remains a hard problem inside an organization: the definition everyone applies usually isn’t written down anywhere — instead, it is repeated in every query that uses it.

An experimental application built on the framework described in this article examined usage of a data platform and found traces of that fragmentation: the same three-condition filter reappeared across 1,600 executions, spread over six different SQL forms, without any artifact declaring it as the definition of a concept.

Dashboard titles named business concepts; filter expressions in queries established the criteria used to recognize them; the execution history connected the two. The application identified that this combination was not merely a collection of correlated metadata. It formed a recurring pattern linking a named concept, an operational definition, and its usage, capable of supporting a hypothesis about a canonical representation.

Recognizing a pattern like this expands the role of AI systems based on large language models (LLMs). Instead of receiving a free-form description and returning another free-form description, they can compare what we already know, identify regularities, and formulate new hypotheses in a controlled way. When the same path of reasoning reappears, it can be turned into a formal, verifiable, and reusable rule. It is this step — reasoning also about the language in which conclusions are formulated — that the article sets out to ground.

This is the first article in a series. It establishes the formal foundation: what can be formulated and why the conclusion belongs to another level. The questions deliberately left out will get articles of their own in the series — why we should believe a hypothesis like this, and how it can change a versioned ontology.

Note: the data platform is the domain of this example, not the boundary of the framework. The same reasoning structure can be specialized for other fields of knowledge.

Ontology: the choices that come before facts

Ontology investigates what exists and which distinctions we use to understand reality. In the Categories, Aristotle already distinguished categories such as substance, quantity, quality, relation, place, and time.

Consider the statement “Ana works at Acme.” Ana is a person, Acme is an organization, and working at is a relation between the two. Ontology makes these elementary differences explicit: which entity types exist and which relations can connect them.

Formally, we will call the ontology Ω, its signature Σ, and its theory Γ. The relation among the three elements will be represented by:

Ω = ⟨Σ,Γ⟩

Σ is the signature, that is, the available vocabulary. It declares type names, such as Person and Organization, and relation names, such as WORKS_AT and MANAGES. Γ is the theory: it gathers the definitions and rules that say how that vocabulary can be used. The signature provides the terms; the theory establishes the commitments assumed when combining them.

For example, using p and o as variables that can stand for different entities, Γ could declare:

WORKS_AT(p,o)
  → Person(p) ∧ Organization(o)

MANAGES(p,o)
  → Person(p) ∧ Organization(o)

The expressions determine the types of the participants in both relations: p is a person and o, an organization. The symbols belong to Σ; the rules belong to Γ.

We can therefore think of the ontology as the vocabulary and the grammar of a knowledge language. Before producing statements with it, however, we need to establish what its symbols mean.

Formal semantics: how symbols acquire meaning

The signature declares symbols; the theory declares definitions and rules. Formal semantics establishes what those expressions mean and under which conditions they can be considered satisfied. Without that layer, a formula can be syntactically correct and still lack a precise interpretation.

An interpretation, represented by I, is defined over a domain Δ: the set of things the symbols can refer to. Each type comes to denote a subset of that domain, and each relation, a set of tuples of elements from that domain:

Personᴵ ⊆ Δ
Organizationᴵ ⊆ Δ

WORKS_ATᴵ ⊆ Δ × Δ
MANAGESᴵ ⊆ Δ × Δ

The superscript I means “in the interpretation I.” So saying that something is a person means that this element belongs to Personᴵ. Saying that a person works at an organization means that the pair formed by the two belongs to WORKS_ATᴵ.

The interpretation must respect the definitions and rules of Γ. For the rule presented earlier, this requires that, whenever the pair (p,o) belongs to WORKS_ATᴵ, p belongs to Personᴵ and o belongs to Organizationᴵ. When an interpretation satisfies every expression of Γ, it is a model of the theory:

I ⊨ Γ

The formula can be read as “I satisfies Γ.” Logical consequence is then expressed as:

Γ ⊨_L φ

This means that φ is satisfied in every model of Γ. The subscript L identifies the logical consequence of the theory.

Formal semantics does not prove that the ontology correctly describes reality; it only makes explicit what follows from the adopted interpretation. The reasons for accepting that interpretation belong to epistemology and will be examined in the next articles of this series.

With the ontology and its semantics established, we can distinguish the language from the statements built with it.

From facts to ontological meta-inference

An individual is a particular entity of the domain. ana and acme, for example, are individuals; Person and Organization are the types that classify them. When the terms of the ontology are applied to individuals, we obtain statements such as “Ana works at Acme.”

We will call N the knowledge population: the set of particular statements accepted up to a given point. The ontology and its population play different roles:

Ω = available language
N = statements built with that language

The object level: conclusions about individuals

An inference applies a rule already present in Γ to statements present in N to obtain another statement. From WORKS_AT(ana,acme), the rule already declared in Γ allows us to conclude Person(ana) and Organization(acme). The language has not changed; we simply derived more knowledge using it. Ω₀ identifies the ontology in use, N₀ represents the population before the inference, and N₁, the population after it:

Ω₀ stays fixed
N₀ → N₁

This is the object level: the conclusion speaks about individuals. It is possible to add thousands of facts to N and keep using exactly the same types, relations, and rules.

The meta level: conclusions about the language

Now suppose the existing statements reveal a recurring pattern: whoever manages an organization stands, in practice, above whoever works at it. Both facts are already in N, each on its own — one person manages Acme, others work at Acme. What does not exist is a term linking those two people directly: every relation in Σ connects a person to an organization, none connects a person to another person.

The available conclusion is no longer a fact about Ana or Acme but a proposal of vocabulary — introducing SUPERVISES, a relation between two people, and declaring in Γ where it comes from. A rule like this, linking one observed configuration to another while preserving the participants involved, will be called a constraint:

MANAGES(p₁,o) ∧ WORKS_AT(p₂,o)
  → SUPERVISES(p₁,p₂)

Note that p₁, p₂, and o are the same on both sides: it is not enough that someone who manages and someone who works exist, they have to be the same people and the same organization. And because it is empirical, the constraint neither asserts causality nor guarantees that every future case will follow the pattern.

The movement is the reverse of the previous one. There, the ontology stayed fixed while the population grew. Here, no new fact is asserted about Ana or Acme, and it is the language that would change: Σ would gain a symbol that did not exist before — and with it, a kind of link the ontology could not express — while Γ would gain the rule that says where that symbol comes from.

evidence in N, interpreted under Ω₀
              ↓
N stays fixed
Ω₀ → Ω₁ (proposed, not yet adopted)

difference between Ω₀ and Ω₁:
  Σ gains the symbol SUPERVISES
  Γ gains the rule that produces it

We call this transition ontological meta-inference. “Meta” identifies the target of the conclusion: the language used to build knowledge has become the object of the reasoning.

Ω₁ is a proposal, not a done deal: formulating it does not replace Ω₀, which remains the ontology in use. In one of the next articles of this series, we will address the conditions under which a proposal can be accepted and give rise to a new version of the ontology.

The rule in use: back to the object level

Suppose the proposal is accepted and Ω₁ becomes the ontology in use. From then on, the rule does not have to be rediscovered case by case: it applies like any other rule of Γ. All it takes is for N to contain what we already knew about Ana plus a new statement about who manages Acme:

MANAGES(bruno,acme)
WORKS_AT(ana,acme)

for the rule to produce a statement nobody had to observe:

SUPERVISES(bruno,ana)

This is the object level again: the conclusion speaks about individuals, Ω₁ stays fixed, and N grows. The difference is that there is now vocabulary to express it. Every person Acme hires will allow the same rule to derive another statement, with no further discovery — and the same holds for any other organization, because the constraint speaks about the form of the cases, not about the individuals that gave rise to it. The meta-inference happened once; the application repeats.

The role of AI within the formal space

Learning ontological structures from data did not start with LLMs. Text2Onto, for example, already represented extracted results in an intermediate model at the meta level and handled data-driven change discovery (Cimiano and Völker, 2005). What language models add is flexibility to relate heterogeneous signals, formulate abstractions, compare explanations, and produce structured hypotheses.

That capability does not remove the need for the framework. Recent results on ontology and schema generation with LLMs show both the possibility of producing formal structures and the variation and errors that demand explicit evaluation (Lippolis et al., 2025; Zhang et al., 2025). A syntactically organized output can still use incompatible relations, swap roles, or propose a generalization the evidence does not support.

The role assigned to AI is broader than filling in an ontology and narrower than governing it. It can relate signals, formulate types, propose constraints, uncover candidate canonical representations, explain their structure, and look for formal incompatibilities. It cannot silently create a parallel vocabulary, turn recurrence into causality, or turn well-formedness into truth or adoption.

The meta-inference produced by the application

So far, the language has been built with people, organizations, and immediately recognizable relations. Now it can be applied to the domain in which the meta-inference was produced.

The application is an executable implementation of the framework presented in this article. The theoretical distinctions were not used merely to interpret its output afterwards: they determine how the application represents the observations, abstracts recurring structures, and formulates a hypothesis.

The observed scenario

The application received usage records from a data platform covering the period from January 6 to July 5, 2026. The dataset combined the catalog of 12 tables in the commerce schema, an inventory of 19 dashboards, and 5,755 execution records. Those records corresponded to 84 distinct SQL forms: 3,665 executions came from dashboards, 1,780 were ad-hoc queries, and 310 belonged to pipelines.

The 5,755 records were distributed as follows:

Table	Executions	Table	Executions
`commerce.customers`	45	`commerce.orders`	1,875
`commerce.products`	315	`commerce.order_items`	590
`commerce.payments`	470	`commerce.support_tickets`	430
`commerce.shipments`	360	`commerce.subscriptions`	585
`commerce.reviews`	260	`commerce.carts`	365
`commerce.refunds`	275	`commerce.campaigns`	185

The material received contained no declared business concepts: nothing in it named “Confirmed Orders,” “Approved Payment,” or “Open Ticket.”

The Confirmed Orders case

The most illustrative case was in commerce.orders. Of the 1,875 queries against the table, 1,600 — a little over 85% — applied the same normalized expression:

cancelled_at IS NULL
AND is_test = FALSE
AND status = 'confirmed'

Normalization matters because these conditions appeared in different orders and SQL forms. The expression was not a specific query: it was the same operational criterion present in six query forms.

Usage form	Origin	Executions
confirmed orders per day	dashboard “Sales — Valid Order per day”	900
confirmed orders grouped by status	dashboard “Sales — Valid Order per day”	180
confirmed revenue per day	dashboard “Confirmed Revenue per day”	260
total count of confirmed orders	ad-hoc query	90
confirmed orders per customer	ad-hoc query	90
load of confirmed orders into `analytics.daily_orders`	pipeline	80

The first query tied to a dashboard counted orders per day:

SELECT date_trunc('day', created_at) AS day,
       count(*) AS orders
FROM commerce.orders
WHERE status = 'confirmed'
  AND is_test = false
  AND cancelled_at IS NULL
GROUP BY 1
ORDER BY 1

This form and the 180 executions that grouped orders by status totaled 1,080 queries from the “Sales — Valid Order per day” dashboard.

The second dashboard used the same criterion to compute revenue:

SELECT date_trunc('day', created_at) AS day,
       sum(total_amount) AS revenue
FROM commerce.orders
WHERE status = 'confirmed'
  AND is_test = false
  AND cancelled_at IS NULL
GROUP BY 1
ORDER BY 1

This form was executed 260 times from the “Confirmed Revenue per day” dashboard.

The pattern inferred by the AI

Before the hypothesis, Ω₀ could only sustain the observable structure: an expression reads a table, is executed from a dashboard, and that dashboard’s title contains a business term.

%%{init: {
  "theme": "base",
  "themeVariables": {
    "background": "#F8FAFC",
    "primaryColor": "#FFFFFF",
    "primaryTextColor": "#0F172A",
    "primaryBorderColor": "#E2E8F0",
    "secondaryColor": "#F1F5F9",
    "tertiaryColor": "#FFE0F0",
    "lineColor": "#5A6B7D",
    "titleColor": "#0F172A",
    "clusterBkg": "#F1F5F9",
    "clusterBorder": "#E2E8F0",
    "fontFamily": "Inter, Segoe UI, Helvetica Neue, Arial, sans-serif",
    "fontSize": "15px"
  },
  "flowchart": {
    "curve": "basis",
    "nodeSpacing": 28,
    "rankSpacing": 36,
    "padding": 8
  }
}}%%
flowchart LR
    classDef active fill:#FFE0F0,stroke:#D6006F,color:#0F172A,stroke-width:2px;
    classDef muted fill:#FFFFFF,stroke:#E2E8F0,color:#5A6B7D,stroke-width:1px;
    classDef support fill:#E3F6F9,stroke:#007C91,color:#0F172A,stroke-width:1.5px,stroke-dasharray:4 2;
    classDef warning fill:#FFF4D6,stroke:#9A5B00,color:#0F172A,stroke-width:2px;

    E["Expression Y"] -->|READS_FROM| T["Table T"]
    E -->|EXECUTED_FROM| D["Dashboard Z"]
    D -->|TITLE_HAS_TERM| L["Term X"]

    class T,L muted;
    class D,E support;

Nothing in this graph states that a concept exists, and nothing in Ω₀ would allow stating it: there is no symbol for saying that something defines a concept, or that something represents one.

In the run presented in this article, the model that formulated the hypothesis was DeepSeek V4 Pro. It received this information already represented by the framework and noticed two things at once. The same filter recurred across many queries over the same table — not just any slice, but conditions expressing a business criterion. And those queries came from dashboards whose titles named precisely what the filter selects.

The hypothesis links the two observations. If the filter decides what gets in and the title says what that is called, then the filter may be working as the operational definition of a concept, and the dashboard as the place where that concept appears with a name.

%%{init: {
  "theme": "base",
  "themeVariables": {
    "background": "#F8FAFC",
    "primaryColor": "#FFFFFF",
    "primaryTextColor": "#0F172A",
    "primaryBorderColor": "#E2E8F0",
    "secondaryColor": "#F1F5F9",
    "tertiaryColor": "#FFE0F0",
    "lineColor": "#5A6B7D",
    "titleColor": "#0F172A",
    "clusterBkg": "#F1F5F9",
    "clusterBorder": "#E2E8F0",
    "fontFamily": "Inter, Segoe UI, Helvetica Neue, Arial, sans-serif",
    "fontSize": "15px"
  },
  "flowchart": {
    "curve": "basis",
    "nodeSpacing": 28,
    "rankSpacing": 36,
    "padding": 8
  }
}}%%
flowchart LR
    classDef active fill:#FFE0F0,stroke:#D6006F,color:#0F172A,stroke-width:2px;
    classDef muted fill:#FFFFFF,stroke:#E2E8F0,color:#5A6B7D,stroke-width:1px;
    classDef support fill:#E3F6F9,stroke:#007C91,color:#0F172A,stroke-width:1.5px,stroke-dasharray:4 2;
    classDef warning fill:#FFF4D6,stroke:#9A5B00,color:#0F172A,stroke-width:2px;

    E["Expression Y"] -->|READS_FROM| T["Table T"]
    E -->|EXECUTED_FROM| D["Dashboard Z"]
    D -->|TITLE_HAS_TERM| L["Term X"]
    C["Concept C"] ==>|DEFINED_BY| E
    C ==>|REPRESENTED_BY| L

    class T,L muted;
    class D,E support;
    class C active;

This second graph is Ω₁. The solid arrows still represent the observed structure; the bold ones are what the hypothesis adds, and Concept C is what they link:

difference between Ω₀ and Ω₁:
  Σ gains the symbols DEFINED_BY and REPRESENTED_BY
  Γ gains the constraint that produces them

In the main case, Dashboard Z corresponds to “Sales — Valid Order per day,” Expression Y to the filter over confirmed orders, and Table T to commerce.orders. The term “Order” semantically linked the dashboard title to the table, while “Valid” and “Confirmed” provided a business interpretation of the conditions status = 'confirmed', is_test = false, and cancelled_at IS NULL. The hypothesis instantiates Concept C as Confirmed Orders.

The meta-inferential leap occurred when the application moved beyond describing that particular case and formulated a regularity among filters that define concepts, dashboards that represent them, and queries executed from those dashboards. In the generated output, the recurrence was also illustrated by two other cases:

35 executions of an expression associated with DeclinedPayment, from the “Declined payments” dashboard;
40 executions of an expression associated with UrgentTicket, from the “Urgent tickets” dashboard.

What the experiment demonstrates

An inference at the object level could stop at a particular conclusion: the concept Confirmed Orders is operationally expressed by the filter that combines status = 'confirmed', is_test = false, and cancelled_at IS NULL. That would be a useful conclusion, and it would have added a statement to N without touching the ontology.

The application went further. By comparing names present in dashboards, expressions used in queries, and the execution history connecting them, it formulated a regularity about the structure common to those elements — a constraint, and with it the symbols needed to express it.

That is why the hypothesis is not limited to Confirmed Orders. It also covers Declined Payment and Urgent Ticket, and it can be tested whenever new concepts present the same form.

The reach of the formal foundation

The central result lies in this transition from a particular concept to a reusable structure. Using AI beyond fact-level inference does not mean removing limits, but operating in a formal language in which the theory and the hypotheses about it can be inspected and criticized. With ontology and formal semantics, the LLM’s output stops being just text: its types, relations, and conditions can be verified and processed programmatically. Uncertainty remains in the formulation and the acceptance of the hypothesis; once accepted, its application can be deterministic and reproducible.

The formal foundation presented in this article answers what an ontology is and how to represent it formally. Two questions remain: why we should believe this hypothesis, and how it could be incorporated into a new version of the ontology. The first will be addressed in the article on epistemology; the second, in the article on ontological evolution.