Além dos fatos: hipóteses formais da IA sobre a própria ontologia

Conceitos importantes de negócio raramente vivem em uma única definição. “Pagamento recusado”, “cliente ativo” ou “chamado urgente” podem aparecer em documentação, código, métricas, filtros e decisões operacionais. O mesmo nome pode esconder critérios diferentes; definições equivalentes podem circular com nomes distintos. Por isso, construir uma representação canônica de um conceito de negócio continua sendo um problema difícil dentro de uma organização: a definição que todos aplicam costuma não estar escrita em lugar nenhum — ela existe repetida dentro de cada query que a usa.

Uma aplicação experimental construída sobre o framework descrito neste artigo examinou o uso de uma Plataforma de Dados e encontrou os rastros dessa fragmentação: um mesmo filtro de três condições reaparecia em 1.600 execuções, distribuídas por seis formas diferentes de SQL, sem que nenhum artefato o declarasse como a definição de um conceito.

Títulos de dashboards nomeavam conceitos de negócio; expressões de filtro nas queries estabeleciam os critérios usados para reconhecê-los; o histórico de execução conectava as duas coisas. A aplicação identificou que essa combinação não era apenas uma coleção de metadados correlacionados. Ela formava um padrão recorrente entre conceito nomeado, definição operacional e uso, capaz de sustentar uma hipótese de representação canônica.

Reconhecer um padrão como esse amplia o papel da IA baseada em LLMs. Em vez de receber uma descrição livre e devolver outra descrição livre, ela pode comparar o que já sabemos, identificar regularidades e formular novas hipóteses de maneira controlada. Quando um mesmo caminho de raciocínio reaparece, pode transformá-lo em uma regra formal, verificável e reutilizável. É esse passo — raciocinar também sobre a linguagem em que as conclusões são formuladas — que o artigo procura fundamentar.

Este é o primeiro artigo de uma série. Ele estabelece a base formal: o que pode ser formulado e por que a conclusão pertence a outro nível. As perguntas que ficam deliberadamente de fora terão artigos próprios na série — por que acreditar em uma hipótese dessas, e como ela pode alterar uma ontologia versionada.

Nota: a Plataforma de Dados é o domínio deste exemplo, não o limite do framework. A mesma estrutura de raciocínio pode ser especializada para outros campos do conhecimento.

Ontologia: as escolhas que vêm antes dos fatos

Ontologia investiga o que existe e quais distinções usamos para compreender a realidade. Nas Categorias, Aristóteles já diferenciava categorias como substância, quantidade, qualidade, relação, lugar e tempo.

Considere a afirmação “Ana trabalha na Acme”. Ana é uma pessoa, Acme é uma organização e trabalhar em é uma relação entre as duas. A ontologia torna explícitas essas diferenças elementares: que tipos de entidade existem e quais relações podem conectá-las.

Formalmente, chamaremos a ontologia de Ω, sua assinatura de Σ e sua teoria de Γ. A relação entre os três elementos será representada por:

Ω = ⟨Σ,Γ⟩

Σ é a assinatura, isto é, o vocabulário disponível. Ela declara nomes de tipos, como Pessoa e Organização, e nomes de relações, como TRABALHA_EM e GERENCIA. Γ é a teoria: reúne as definições e regras que dizem como esse vocabulário pode ser usado. A assinatura oferece os termos; a teoria estabelece os compromissos assumidos ao combiná-los.

Por exemplo, usando p e o como variáveis que podem representar diferentes entidades, Γ poderia declarar:

TRABALHA_EM(p,o)
  → Pessoa(p) ∧ Organização(o)

GERENCIA(p,o)
  → Pessoa(p) ∧ Organização(o)

As expressões determinam os tipos dos participantes das duas relações: p é uma pessoa e o, uma organização. Os símbolos pertencem a Σ; as regras pertencem a Γ.

Podemos, portanto, pensar na ontologia como o vocabulário e a gramática de uma linguagem de conhecimento. Antes de produzir enunciados com ela, porém, é preciso estabelecer o que seus símbolos significam.

Semântica formal: como os símbolos adquirem significado

A assinatura declara símbolos; a teoria declara definições e regras. A semântica formal estabelece o que essas expressões significam e em que condições podem ser consideradas satisfeitas. Sem essa camada, uma fórmula pode estar sintaticamente correta e ainda não possuir uma interpretação precisa.

Uma interpretação, representada por I, começa por um domínio Δ: o conjunto de coisas às quais os símbolos podem se referir. Cada tipo passa a denotar um subconjunto desse domínio, e cada relação, um conjunto de combinações entre seus elementos:

Pessoaᴵ ⊆ Δ
Organizaçãoᴵ ⊆ Δ

TRABALHA_EMᴵ ⊆ Δ × Δ
GERENCIAᴵ ⊆ Δ × Δ

O sobrescrito I significa “na interpretação I”. Assim, dizer que algo é uma pessoa significa que esse elemento pertence a Pessoaᴵ. Dizer que uma pessoa trabalha em uma organização significa que o par formado pelas duas pertence a TRABALHA_EMᴵ.

A interpretação precisa respeitar as definições e regras de Γ. Para a regra apresentada anteriormente, isso exige que, sempre que o par (p,o) pertencer a TRABALHA_EMᴵ, p pertença a Pessoaᴵ e o pertença a Organizaçãoᴵ. Quando uma interpretação satisfaz todas as expressões de Γ, ela é um modelo da teoria:

I ⊨ Γ

A fórmula pode ser lida como “I satisfaz Γ”. A partir daí, uma consequência lógica é expressa por:

Γ ⊨_L φ

Isso significa que φ é satisfeita em todo modelo de Γ. O subscrito L identifica a consequência lógica da teoria.

A semântica formal não prova que a ontologia descreve corretamente a realidade; ela apenas explicita o que decorre da interpretação adotada. As razões para aceitar essa interpretação pertencem à epistemologia e serão examinadas nos próximos artigos desta série.

Com a ontologia e sua semântica estabelecidas, podemos distinguir a linguagem dos enunciados construídos com ela.

Dos fatos à meta-inferência ontológica

Um indivíduo é uma entidade particular do domínio. ana e acme, por exemplo, são indivíduos; Pessoa e Organização são os tipos que os classificam. Quando os termos da ontologia são aplicados a indivíduos, obtemos enunciados como “Ana trabalha na Acme”.

Chamaremos de N a população de conhecimento: o conjunto de enunciados particulares admitidos até um dado momento. A ontologia e sua população cumprem papéis diferentes:

Ω = linguagem disponível
N = enunciados construídos com essa linguagem

O nível-objeto: conclusões sobre indivíduos

Uma inferência aplica uma regra já existente em Γ a enunciados presentes em N para obter outro enunciado. A partir de TRABALHA_EM(ana,acme), a regra já declarada em Γ permite concluir Pessoa(ana) e Organização(acme). A linguagem não mudou; apenas passamos a saber mais com ela. Ω₀ identifica a ontologia em uso, N₀ representa a população antes da inferência e N₁, a população depois dela:

Ω₀ permanece fixa
N₀ → N₁

Esse é o nível-objeto: a conclusão fala sobre indivíduos. É possível acrescentar milhares de fatos a N e continuar usando exatamente os mesmos tipos, relações e regras.

O nível-meta: conclusões sobre a linguagem

Agora suponha que os enunciados existentes revelem um padrão recorrente: quem gerencia uma organização está, na prática, acima de quem trabalha nela. Os dois fatos já estão em N, cada um por sua conta — uma pessoa gerencia a Acme, outras trabalham na Acme. O que não existe é um termo que ligue essas duas pessoas diretamente: todas as relações de Σ conectam uma pessoa a uma organização, nenhuma conecta uma pessoa a outra.

A conclusão possível deixa de ser um fato sobre Ana ou Acme e passa a ser uma proposta de vocabulário — introduzir SUPERVISIONA, uma relação entre duas pessoas, e declarar em Γ de onde ela decorre. Uma regra assim, que liga uma configuração observada a outra preservando os participantes envolvidos, será chamada de constraint:

GERENCIA(p₁,o) ∧ TRABALHA_EM(p₂,o)
  → SUPERVISIONA(p₁,p₂)

Repare que p₁, p₂ e o são os mesmos dos dois lados: não basta existir alguém que gerencia e alguém que trabalha, precisam ser as mesmas pessoas e a mesma organização. E, por ser empírica, a constraint não afirma causalidade nem garante que todo caso futuro seguirá o padrão.

O movimento é o inverso do anterior. Lá, a ontologia permanecia fixa enquanto a população crescia. Aqui, nenhum fato novo é afirmado sobre Ana ou Acme e é a linguagem que mudaria: Σ ganharia um símbolo que antes não existia — e, com ele, um tipo de ligação que a ontologia não sabia expressar — enquanto Γ ganharia a regra que diz de onde esse símbolo decorre.

evidências em N, interpretadas sob Ω₀
              ↓
N permanece fixa
Ω₀ → Ω₁ (proposta, ainda não adotada)

diferença entre Ω₀ e Ω₁:
  Σ ganha o símbolo SUPERVISIONA
  Γ ganha a regra que o produz

Essa passagem será chamada de meta-inferência ontológica. “Meta” identifica o alvo da conclusão: a linguagem usada para construir conhecimento tornou-se objeto do raciocínio.

Ω₁ é uma proposta, não um fato consumado: formulá-la não substitui Ω₀, que continua sendo a ontologia em uso. Em um dos próximos artigos desta série, trataremos das condições sob as quais uma proposta pode ser aceita e dar origem a uma nova versão da ontologia.

A regra em uso: de volta ao nível-objeto

Suponha que a proposta seja aceita e Ω₁ passe a ser a ontologia em uso. A partir daí, a regra não precisa ser redescoberta a cada caso: ela se aplica como qualquer outra regra de Γ. Basta que N contenha o que já sabíamos sobre Ana e um enunciado novo sobre quem gerencia a Acme:

GERENCIA(bruno,acme)
TRABALHA_EM(ana,acme)

para que a regra produza um enunciado que ninguém precisou observar:

SUPERVISIONA(bruno,ana)

Isso é nível-objeto outra vez: a conclusão fala sobre indivíduos, Ω₁ permanece fixa e N cresce. A diferença é que agora existe vocabulário para expressá-la. Cada pessoa que a Acme contratar produzirá outro enunciado pela mesma regra, sem nenhuma descoberta adicional — e o mesmo vale para qualquer outra organização, porque a constraint fala da forma dos casos, não dos indivíduos que a originaram. A meta-inferência aconteceu uma vez; a aplicação se repete.

O papel da IA dentro do espaço formal

Aprender estruturas ontológicas a partir de dados não começou com LLMs. O Text2Onto, por exemplo, já representava resultados extraídos em um modelo intermediário em nível meta e tratava da descoberta de mudanças orientada por dados (Cimiano e Völker, 2005). O que modelos de linguagem acrescentam é flexibilidade para relacionar sinais heterogêneos, formular abstrações, comparar explicações e produzir hipóteses estruturadas.

Essa capacidade não elimina a necessidade do framework. Resultados recentes de geração de ontologias e schemas com LLMs mostram tanto a possibilidade de produzir estruturas formais quanto variação e erros que exigem avaliação explícita (Lippolis et al., 2025; Zhang et al., 2025). Uma saída sintaticamente organizada ainda pode usar relações incompatíveis, trocar papéis ou propor uma generalização que as evidências não sustentam.

O papel reservado à IA é mais amplo do que preencher uma ontologia e mais restrito do que governá-la. Ela pode relacionar sinais, formular tipos, propor constraints, revelar hipóteses de representação canônica, explicar sua estrutura e procurar incompatibilidades formais. Não pode criar silenciosamente um vocabulário paralelo, converter recorrência em causalidade nem transformar boa formação em verdade ou adoção.

A meta-inferência produzida pela aplicação

Até aqui, a linguagem foi construída com pessoas, organizações e relações imediatamente reconhecíveis. Agora é possível aplicá-la ao domínio em que a meta-inferência foi produzida.

A aplicação é uma implementação executável do framework apresentado neste artigo. As distinções teóricas não foram usadas apenas para interpretar sua saída posteriormente: elas determinam como a aplicação representa as observações, abstrai estruturas recorrentes e formula uma hipótese.

O cenário observado

A aplicação recebeu o registro de uso de uma Plataforma de Dados entre 6 de janeiro e 5 de julho de 2026. O material combina o catálogo de 12 tabelas do schema commerce, um inventário com 19 dashboards e 5.755 registros de execução. Esses registros correspondiam a 84 formas distintas de SQL: 3.665 execuções vieram de dashboards, 1.780 eram consultas avulsas e 310 pertenciam a pipelines.

Os 5.755 registros estavam distribuídos desta forma:

Tabela	Execuções	Tabela	Execuções
`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

O material recebido não declarava nenhum conceito de negócio: nada nele nomeava “Pedidos Confirmados”, “Pagamento Aprovado” ou “Chamado Aberto”.

O caso de Pedidos Confirmados

O caso mais expressivo estava em commerce.orders. Das 1.875 consultas à tabela, 1.600 — pouco mais de 85% — aplicavam a mesma expressão normalizada:

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

A normalização é importante porque essas condições apareciam em ordens e formas de SQL diferentes. A expressão não era uma query específica: era o mesmo critério operacional presente em seis formas de consulta.

Forma de uso	Origem	Execuções
pedidos confirmados por dia	dashboard “Vendas — Valid Order por dia”	900
pedidos confirmados agrupados por status	dashboard “Vendas — Valid Order por dia”	180
receita confirmada por dia	dashboard “Receita confirmada por dia”	260
contagem total de pedidos confirmados	consulta avulsa	90
pedidos confirmados por cliente	consulta avulsa	90
carga de pedidos confirmados em `analytics.daily_orders`	pipeline	80

A primeira query ligada a um dashboard contava pedidos por dia:

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

Essa forma e as 180 execuções que agrupavam pedidos por status totalizaram 1.080 queries do painel “Vendas — Valid Order por dia”.

O segundo dashboard usava o mesmo critério para calcular receita:

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

Essa forma foi executada 260 vezes a partir do dashboard “Receita confirmada por dia”.

O padrão inferido pela IA

Antes da hipótese, Ω₀ só era capaz de sustentar a estrutura observável: uma expressão lê uma tabela, é executada a partir de um dashboard e o título desse dashboard contém um termo de negócio.

%%{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["Expressão Y"] -->|READS_FROM| T["Tabela T"]
    E -->|EXECUTED_FROM| D["Dashboard Z"]
    D -->|TITLE_HAS_TERM| L["Termo X"]

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

Nada nesse grafo afirma que existe um conceito, e nada em Ω₀ permitiria afirmá-lo: não existe símbolo para dizer que algo define um conceito, nem que algo o representa.

Na execução apresentada neste artigo, quem formulou a hipótese foi o DeepSeek V4 Pro. Ele recebeu essas informações já representadas pelo framework e reparou em duas coisas ao mesmo tempo. Um mesmo filtro se repetia em muitas queries sobre a mesma tabela — não um recorte qualquer, mas condições que expressam um critério de negócio. E essas queries vinham de dashboards cujos títulos nomeavam justamente o que o filtro seleciona.

A hipótese liga as duas observações. Se o filtro decide o que entra e o título diz como aquilo se chama, então o filtro pode estar funcionando como a definição operacional de um conceito, e o dashboard, como o lugar onde esse conceito aparece com nome.

%%{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["Expressão Y"] -->|READS_FROM| T["Tabela T"]
    E -->|EXECUTED_FROM| D["Dashboard Z"]
    D -->|TITLE_HAS_TERM| L["Termo X"]
    C["Conceito C"] ==>|DEFINED_BY| E
    C ==>|REPRESENTED_BY| L

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

Esse segundo grafo é Ω₁. As setas contínuas continuam representando a estrutura observada; as reforçadas são o que a hipótese acrescenta, e o Conceito C é o que elas ligam:

diferença entre Ω₀ e Ω₁:
  Σ ganha os símbolos DEFINED_BY e REPRESENTED_BY
  Γ ganha a constraint que os produz

No caso principal, Dashboard Z corresponde a “Vendas — Valid Order por dia”, Expressão Y ao filtro sobre pedidos confirmados e Tabela T a commerce.orders. O termo “Order” aproximava o título da tabela, enquanto “Valid” e “confirmada” ofereciam uma leitura de negócio para as condições status = 'confirmed', is_test = false e cancelled_at IS NULL. A hipótese preenche Conceito C com Pedidos Confirmados.

O salto meta-inferencial ocorreu quando a aplicação deixou de descrever apenas esse caso e formulou uma regularidade entre filtros que definem conceitos, dashboards que os representam e queries executadas a partir desses dashboards. Na saída gerada, a recorrência também foi ilustrada por dois outros casos:

35 execuções de uma expressão associada a DeclinedPayment, a partir do dashboard “Pagamentos recusados”;
40 execuções de uma expressão associada a UrgentTicket, a partir do dashboard “Chamados urgentes”.

O que o experimento demonstra

Uma inferência no nível-objeto poderia encerrar o caso em um julgamento particular: o conceito Pedidos Confirmados é expresso operacionalmente pelo filtro que combina status = 'confirmed', is_test = false e cancelled_at IS NULL. Seria uma conclusão útil, e teria acrescentado um enunciado a N sem tocar na ontologia.

A aplicação foi além. Ao comparar nomes presentes em dashboards, expressões usadas nas queries e o histórico de execução que os conectava, formulou uma regularidade sobre a estrutura comum a esses elementos — uma constraint, e com ela os símbolos necessários para expressá-la.

É por isso que a hipótese não se limita a Pedidos Confirmados. Ela também recobre Pagamento Recusado e Chamado Urgente, e pode ser testada sempre que novos conceitos apresentarem a mesma forma.

O alcance da base formal

É nessa passagem do conceito particular para uma estrutura reutilizável que está o resultado central. Usar IA além da inferência sobre fatos não significa retirar limites, mas operar em uma linguagem formal em que a teoria e as hipóteses sobre ela possam ser inspecionadas e criticadas. Com ontologia e semântica formal, a saída da LLM deixa de ser apenas texto: seus tipos, relações e condições podem ser verificados e processados programaticamente. A incerteza permanece na formulação e na aceitação da hipótese; uma vez admitida, sua aplicação pode ser determinística e reprodutível.

A base formal apresentada neste artigo responde o que é uma ontologia e como representá-la formalmente. Restam duas perguntas: por que acreditar nessa hipótese e como ela poderia participar de uma nova versão da ontologia. A primeira será abordada no artigo sobre epistemologia; a segunda, no artigo sobre evolução ontológica.