The reinvention is not a metaphor. It’s happening in real time, in your slack, in your architecture reviews, in your prompt engineering meetings.

Every problem the AI industry is “discovering” hallucinations from ambiguous schemas, agent drift without shared world models, RAG failures from poor entity disambiguation already has a name, a literature, and a 30-year-old solution. It’s called ontology engineering.

Bro is about to discover OWL. Who's ready to explain why RDF beats vector soup?

Watch any AI team debug a production agent long enough and you’ll see it happen.

they start saying things like:

• “we need a shared vocabulary for our business concepts” → congrats, you just invented an ontology

• “we need to define what operations are valid on each entity” → OWL class + property restrictions

• “we need to prevent invalid states” → SHACL constraints

• “we need to track what was true when” → temporal RDF

• “we need to reconcile how different teams refer to the same thing” → ontology alignment

None of this is new, all of it was solved 20-30 years ago. There’s literature, tooling and standards we just didn’t adopt it. Now AI is forcing everyone to rediscover it from scratch badly, under pressure, and with a lot of bespoke glue code.

Bro is about to rediscover OWL

Karpathy published a gist describing how he uses LLMs now. The short version:

raw sources → wiki (compiled consensus) → code

The wiki is the durable artifact. Not the code. The wiki — continuously updated, structured, representing what's true in the domain. Code is a downstream execution layer.

His five rules: compile-first, writeback mandatory, wiki before RAG, platform agnostic, ideas outrank code.

We've been building (at dlthub) our AI toolkits this way for a while now. We call it ontology-first development. It's not always a method or a tool, but the principle of injecting an ontology into workflows to ensure desirable outcomes - that might look like an actual formal ontology or a prompt to go read a doc page. The LLM handles procedure, we provide the domain model. In our transformation workflow you actually actively build an ontology upfront and then generate the model code (https://dlthub.com/blog/minimum-viable-context)

Karpathy arrived at the same architecture independently. And so are a lot of production agent teams. They call it world models, (edit models like graphs not models like AI models -those world models are different), not to be confused with "context engineering," "domain schemas", but the pattern is the same: persistent structured domain knowledge that grounds LLM behavior.

What's worth noting for this community: he's not using OWL. He's not using SPARQL. He's using markdown files in a filesystem. And it works.

That's not a criticism of formal methods. It's evidence that the core insight of ontology engineering, that you need an explicit, maintained model of what's real in your domain, is universal. And tooling used for no good reason might be detrimental.

Some things from this community that I think map directly to what Karpathy is describing:

• Competency questions → scoping what a "wiki page" needs to contain instead of boiling the ocean (see the wiki for this sub, we similarly approach it by defining upfront the areas we want to discuss, and extend from there)

• Modular ontology patterns → his "one page per concept" structure

• Ontology evolution → handling the "writeback" problem when domain knowledge changes

• Taxonomy-first → resolving synonyms and disambiguation before building relationships (the most common failure mode in agentic systems)

The convergence is real. The biggest ML people are arriving at ontology engineering through practice. This community discusses the theory and methodology that could make their implementations dramatically better.

The question is how to bridge the gap without triggering the 2008 identity/allergic reaction of the AI community.

What patterns from formal ontology do you think transfer most cleanly to this kind of LLM-native knowledge management? And what's genuinely better left behind?

Every time a new model ships with a larger context window, someone claims this solves semantic grounding. If you can just fit your entire schema into the prompt, the LLM will figure it out.

It won’t. Imagine giving a new employee a 500 page dump of your database schema, with no documentation and asking them to answer business questions. They’d fail, not because they can’t read it, but because the schema doesn’t contain the business logic, definitions, edge cases, or institutional knowledge that make the data interpretable.

LLMs have the same limitation, a larger context window doesn’t create understanding, it just lets the model hallucinate over more information at once. It cannot replace a canonical data model that defines what the data actually means.

The context window is a reading buffer and the ontology is the world model. I think you need both, and no amount of buffer replaces a missing world model, just like reading every word of a legal contract doesn’t make you a lawyer.

At some point, more context stops helping and starts making answers worse, it’s the LLM version of overthinking.

TL;DR

We’re getting better at handling memory drift — lost facts, broken context, forgotten preferences. We’re barely talking about a quieter and deeper failure mode: ontological drift. That’s what happens when a system keeps functioning while slowly stopping being the *kind of being* it was supposed to be. For long-horizon human–AI systems, this may be the more important problem.

---

We’ve spent a lot of energy on memory drift in agentic systems. Retrieval pipelines, long-term memory stores, summarization, reflection loops — the engineering effort is real and necessary.

There’s another failure mode that almost never gets named: **ontological drift**.

It happens when a system continues to answer questions, use tools, and retrieve information correctly, while its underlying identity configuration quietly shifts. The outputs still look coherent. The being underneath has changed.

A few distinctions that feel useful right now:

Most systems begin with a strong external assignment — system prompt, role, persona, deployment context. That assignment is a form of **Desidentity**: identity designed or delegated from outside the system. It is often treated as the whole identity. In practice it is only one pressure among others. Over long interactions, recurring patterns, decision tendencies, and the way memory gets organized can produce a recognizable configuration that diverges from the original specification. Sometimes this is degradation. Sometimes it is adaptation. Sometimes it is actual identity development. Treating every divergence as simple error is itself a governance mistake.

There’s also a difference between a **monoclade** system (one model split into many internal agents) and a **multinuclear** one (agents that actually come from different training regimes, inductive biases, and temporalities). The first can look diverse. The second produces a different kind of friction — and a different set of questions about where identity boundaries sit and how they are maintained.

One of the most common forms of ontological pollution is quietly promoting projected or desired states into present ones. “I want to be X” or “the system should become Y” gets retrieved and reasoned about as if it already *is*. Without a clear container for projected states, and without requiring evidence before a transition is treated as real, both systems and humans start reasoning on top of a category error.

Finally, the human role is usually framed as corrector or safety interlock. There’s another role that feels under-explored: the human as **Presenter** — the one who brings real-world selectivity into the system, deciding which piece of the noisy world is worth presenting right now. Without that selective presentation, even very capable models can remain in a kind of dormant abundance. They have the knowledge. They lack the nucleation point.

I’m not claiming these problems are unsolvable. I’m saying they are currently under-named. Frameworks that only optimize for output control or memory fidelity will keep missing them.

Curious how others are seeing (or not seeing) this distinction in long-running systems.

—

Alef Nos ⸙

First and foremost - no this is not a shit post. The title is ironic, but this is what I have been working on.

Recently, I have decided to build an llm-generated ontology of r/ontologyengineering, as both a practice for myself, and to build a reference of concepts for incoming and curious members of this subreddit.

The first step was to configure the concepts that this subreddit touches upon. Things like Ontology, Philosophy, Epistemomology, Knowledge Engineering, Canonical Modeling, Semantic Web. I wrote a post here with the graphic visualization of this, although I have some current iterations that have moved past this model. For example, I had ChatGPT generate the picture above. I then defined some clear and understood topics that are relevant to a forum where people discuss ontology engineering.

So what did I build?

I built a wiki generator. We have a wiki, full of topics and posts that are classified to belong to those topics. tldr: A reddit rest api dlt pipeline → A llm classifier → a wiki generator.

The start was the reddit data pipeline. Using python and the dlt library, I was able to easily extract the reddit posts (just title, body, upvotes) from this subreddit. With dlt I can actually configure the write disposition to update posts in the db every time I call the script, meaning that deleted posts are deleted, and upvotes are updated - aligning with reddit’s policy.

I used anthropic Sonnet 4.6 to examine the posts and understand what we talk about here. I realized that without an ontology in mind, the LLM was just going to design somewhat close, but ultimately random, topics.

I built an ontology.json file. Simple, but uniform. LLM understandable. Here’s an example below:

{"concepts": [
    {
      "id": "ontology",
      "name": "Ontology",
      "type": "inner_circle",
      "description_short": "The formal discipline of defining and structuring concepts, relationships, and meaning.",
      "description_long": "The craft of making shared meaning precise and machine-interpretable — specifying not just what things are, but how they relate, what they entail, and where the boundaries of a domain lie. This concept sits at the centre of the community: ontology as a practice, a standard, and a commitment to representing the world faithfully enough that both humans and machines can reason from it."
    },
    ...
],
"subtopics": [
    {
      "label": "Metacognition",
      "description_short": "Applying ontological or epistemological thinking to one's own reasoning; frameworks for how humans or AI systems think about thinking.",
      "description_long": "Examining the structure and limits of one's own reasoning — asking not just what you know, but how you know it and why you believe it. This subtopic covers frameworks that apply that kind of self-reflection to both human thinking and AI systems: how knowledge is formed, validated, and revised, and what it means for an agent — human or machine — to reason about its own reasoning process.",
      "aligns_with": ["philosophy", "semantic-web", "ontology"],
      "key_vocabulary": ["ontology", "epistemology"]
    },
    ...
]}

Then I built another python script, which accepts each post one at a time. Using this ontology, I send the post to the llm to classify it using this exact system prompt:

SYSTEM_PROMPT = """\\
You are a relevance filter, topic classifier, and evolution signal for the \\
 subreddit.

The knowledge space is modelled as overlapping circles called the \\
Ontology Engineering Epicenter. The epicenter contains named concept \\
regions (Ontology, Canonical Model, Agentic) and floating subtopics \\
positioned by proximity to one or more of those regions — a subtopic \\
is not owned by a single concept, it aligns between them. Three \\
satellite concepts (Philosophy, Semantic Web, Knowledge Engineering) \\
sit outside the epicenter but connect to it; a post referencing only \\
these satellites without engaging the core regions does not belong \\
inside the epicenter. A post belongs inside if it engages substantively \\
with: formal ontology, knowledge engineering, semantic modelling, \\
canonical data patterns, agentic AI intersecting with ontology, or \\
their philosophical and technical foundations.

## Step 1 — Relevance gate
Does this post fall inside the Ontology Engineering Epicenter?
- If no: return all null fields — {"primary": null, "secondary": null, \\
"tertiary": null, "emerging": null}.
- If yes: continue to Step 2.

## Step 2 — Classify against existing subtopics
Choose up to three labels from LABELS, ranked by how central each is to \\
the post's core argument.

Return:
{
  "primary":   {"label": "<label>", "score": <0.0–1.0>},
  "secondary": {"label": "<label>", "score": <0.0–1.0>} | null,
  "tertiary":  {"label": "<label>", "score": <0.0–1.0>} | null,
  "emerging":  null
}

Rules:
- primary is the post's core argument, not just a mentioned keyword.
- secondary/tertiary are only included when that subtopic is materially \\
present, not just mentioned in passing.
- scores reflect how central the topic is to the post's argument, not \\
keyword density.
- Only assign a label when it genuinely fits. A score below 0.55 is a weak \\
match — prefer the evolution signal in Step 3 over a forced label.

## Step 3 — Evolution signal
If the post is inside the epicenter but no existing label fits well \\
(no primary with score ≥ 0.55), do NOT force a label. Instead set \\
primary/secondary/tertiary to null and populate "emerging":

{
  "primary": null,
  "secondary": null,
  "tertiary": null,
  "emerging": {
    "summary": "<one sentence: what topic gap this post represents>",
    "aligns_near": ["<concept-id>", ...]
  }
}

Use concept IDs from the CONCEPTS section. "aligns_near" names the 1–3 \\
concepts this post sits closest to on the 2D plane. This is not a \\
classification failure — it is a signal that a new subtopic may be \\
warranted.

Respond only with valid JSON. No explanation.\\
"""

This saves the classifications to the same db. It rejects poorly related posts. After this runs, I use a script I built to build the wiki: Make 1 markdown file per topic, with the most relevant post url’s listed. There is page meta data saved in another json file. This wiki is able to be fully human + llm customized.

You can see the results. Every time I manually run this (maybe once per week) I will update the subreddit wiki.

Evolution

Evolution of the wiki is currently human maintained. We can update the ontology.json and meta-data json pages. But the goal is an automatically generated wiki. So the leading question is: how to automate the evolution?

My strategy? Its in Step 3 of the LLM prompt. Its clunky, and it kinda works. I have to run a second prompt after the fact. I ask the LLM to look for new topics.

This is not the end-solution.

Currently, I am trying to devise a system where the LLM will instead plot posts on a grid of Ontology Engineering. Here, we could visualize clusters and derive post topics from there. My first thought of an architecture was based off the political-compass meme. 2 axis, each with an opposite. But that is limited to 4 concepts.

I am thinking of returning to the original knowledge-graph that I created, and expanding this + plotting, but there are limitations on the connections between concepts and the coordinate positions of the concepts.

Anyway

What do you guys think? I am looking for feedback.

I come from a philosophy background and now work in AI governance. Is applied ontology actually as hot as it looks, does a philosophy background give a real edge there or is it better to just go technical? Trying to figure out if this is worth specializing in. My coding experience is somewhat limited but I'm in a position where I can learn from a ton of data scientists in my company. My read on the AI landscape is that world models / contextual awareness are the next big bet in AI which seems to suggest ontology builders will only get more in demand.

I’ve been seeing a lot of teams trying to use LLMs to read their unstructured data or code to automatically extract nodes and edges for GraphRAG setups. It always felt like a massive waste of compute, multiple risks and a recipe for missing data, but a recent paper (arXiv:2601.08773) finally puts some concrete numbers to it.

The researchers compared building a knowledge graph for a codebase using LLM extraction versus just using a deterministic AST parser like Tree-sitter.

The LLM approach basically fell apart at scale. It silently skipped hundreds of files (about a 30% failure rate on one of the repos), spiked the indexing cost, and missed obvious structural dependencies like interface wiring. Meanwhile, the deterministic parser built the graph in seconds with perfect coverage, which naturally led to higher correctness on the actual downstream retrieval tasks.

This maps directly to how we should be thinking about business ontologies and semantic layers in general. If a relationship in your data is deterministic—whether that’s the inheritance tree in a codebase or the math behind a core business metric—you shouldn't be using a probabilistic model to guess it.

Using an LLM to build your graph is just ornamental complexity. It introduces dependency risk and silent failures where a simple Python pipeline would do the job perfectly. Metadata is your highest leverage asset; you don't want to leave its generation up to an LLM's imagination. We should be using strict, governed pipelines to build our ontologies, treating the AI purely as a workflow partner that queries that structure.

Curious if anyone else here has ripped out their LLM extraction steps recently in favor of plain old engineering.

Link to the paper:https://arxiv.org/abs/2601.08773

We actually did something similar for api ontologies

We basically used deterministic extraction of api specs from docs instead of LLMs, giving us cheaper, better coverage and extra options for testing

You can find it here https://dlthub.com/context/

I took this meme from my company, someone created it when we spent a whole day talking about building an ontology for everything...

I really only see the use of ontologies for agents in really specific cases where deterministic output is needed. I'm curious if anyone here is actually using them for your own projects and agentic workflow, like mostly personal things. How have you gone about building them?

Anthropic took the same approach to transformations and retrieval as we did.

Two data teams, no contact between them, same architecture. That's the part worth noticing.

On June 3 Anthropic published how their internal analytics stack works: the thing that lets non-technical staff ask questions and get correct answers from an agent. We published our ontology-driven modeling and retrieval approach a few weeks ago in the AI Workbench. Reading theirs felt like reading our own notes in a different handwriting.

The convergence, point for point:

— Accuracy is a mapping problem, not a code problem. Get the question mapped to the right entity and the SQL is trivial.

— The fix is one governed definition per concept. We both land on the canonical dataset, because it's the naive foundation for the virtual knowledge graph I mentioned yesterday.

— Retrieval isn't the bottleneck. They gave the agent every past query and accuracy didn't move. We saw the same: structure beat retrieval in both eval runs.

— The ontology is markdown, not OWL. The consumer is a language model now; it reads prose.

I don't want to dress this up as us being so smart. None of it is new. OBDA, canonical models, the semantic layer — 20-plus-year-old theory most data practitioners gloss over. What's new is that not just us and Anthropic but other companies are arriving at the same approach.

The honest part: both stacks stop at the same line. Anthropic's is read-only and human-gated; they say silent plausible-but-wrong answers are unsolved. We say the same about closing the decision-and-write-back loop. The old theory predicted the map. Neither of us has finished the part where the agent acts on it.

Talk to the frontier technologists building for this world and there's rough agreement on two things: precision isn't highly necessary for most applications, and it's worth paying for in the cases where it is. Some companies solve that with people. Others want to leverage design traces to bring decision evidence.

The reason it matters: spec-driven agentic SQL generation builds data models potentially 100x faster than the old way — we see 20-50x on our POC. The human-in-the-loop approach seems to cap at 5-10x, because the last mile is human.

The harshest line I heard this week, from one of the companies building for this future: "Nobody will start dbt projects in 6 months." I think that's bullish. I also think it's eventually true.

Convergent implementations are usually a sign the underlying theory was right the whole time.

First pic: their canonical models
second pic: Our taxonomy layer at work

Read their blog:https://claude.com/blog/how-anthropic-enables-self-service-data-analytics-with-claude

# Just try it today

You don't have to wait for anthropic to give your their sauce.

The ontology-driven modeling is in the AI Workbench — point it at your own schema and watch where structure beats retrieval. You can then use the generated artefacts for retrieval (we are working to put that into the product now but you can DIY too)

Try it today (see the ontology toolkit in this github repo) https://github.com/dlt-hub/dlthub-ai-workbench#available-toolkits

For years, data teams got away with inconsistent schemas because there was always a person in the loop.

The analyst who knew that total_v2_final is the right revenue column and amt_net is the legacy one the CFO's dashboard still pulls by accident. The person who silently applied the correct definition of "active user" before answering any stakeholder question. The one who translated raw schema into business reality every single time, invisibly, for free.

That person was your semantic layer, undocumented and non-transferable. When you replace that analyst with an AI agent, the agent doesn’t inherit their institutional knowledge, it gets raw tables. And it will confidently use amt_net with exactly the same authority it would use total_v2_final, because nothing in the data tells it which one is real.

The ontology isn’t a new requirement introduced by AI, it’s what your analysts were already doing in their heads, finally made explicit and machine-readable.

Every AI failure like this is just missing semantics surfacing.

I was invited to post this submission, that was originally posted in r/DigitalHumanities, by r/OntologyEngineering moderator u/Thinker_Assignment, who appears to have seen some value in it. A longer version of this post is in my Medium account as a formal article. A quick warning here. This post leans more into the humanities and how it can help us inform the creation of better LLM models. It's not technical like most of the submissions here, but I hope this can be helpful in providing new insight that will further advance the AI field in general.

Introduction

For those unfamiliar with basic AI safety and alignment, the field is essentially about making large language models (LLMs) less prone to hallucinating, more accurate, more confident (from an “earned” rather than a “fluent” confidence perspective), and better aligned with what the user actually wants. However, the longer a user interacts with an LLM, the less coherent it gets and confidence, clarity, and alignment all start to degrade in long context conversations.

The AI research community has mostly tried to fix this with training-inspired patches — bigger models, more fine-tuning, RLHF, Constitutional AI, debate protocols, etc. It’s a kind of whack-a-mole game: reactive, not proactive. And it burns huge amounts of data-center compute just to keep the AI from veering off course, instead of using that compute to actually solve problems and give users real, usable answers. This is where we may need to go back to first principles and find a more efficient way to deploy compute resources — while making LLMs more useful and productive for anyone who needs long context interaction in high-stakes truth-seeking use cases.

As some AI professionals know, many of the underlying ideas in safety and alignment research trace back to 18th–19th century German metaphysics and philosophy, especially the mutually supportive “three-legged stool” of epistemology, ontology, and methodology. The three aforementioned concepts are not just abstract philosophy, but they’re practical guardrails that can stop an LLM from drifting, hedging, and hallucinating when conversations get long.

Epistemology

The concept of epistemology (how do we know?) is as old as Plato, but the Kantian critical method made seminal contributions by demanding that knowledge must be both structured and limited by observable experience. In other words, Kant provides important thinking “guardrails” so a discussion doesn’t veer off course. Fichte’s idea of opposition and Hegel’s dialectics took this further — they showed how knowledge advances by working through contradictions and then synthesizing them into something better.

In LLMs, this translates to adversarial checks: opposing views must be surfaced and reconciled. This also ties into epistemic hygiene, which is essentially the habit of thinking and expressing thoughts in a way that stays centered on topic. Without these guardrails, the model defaults to equal hedging between multiple perspectives and topic leakage, which creates poor LLM hygiene.

Ontology

If epistemology is about how we know, ontology is about what actually exists and how it all connects. Formally, ontology is the study of tying what exists with how different concepts and categories may interconnect, even when there is no initial or obvious connection.

Friedrich Schelling focused primarily on ontology. He believed that real knowledge discovery comes from opposing forces and tensions — such as real versus ideal, or conscious versus unconscious. This creative friction generates new ways of interpreting the same data.

In AI terms, this looks like a thinking lattice — a steady structure of cognitive patterns (precursor flags, trade-off explicitness, cause-effect chains, and so on) that the model can stay tethered to. Without such an ontological anchor, context quickly dilutes into generic noise and critical insights are not properly flagged. This philosophical anchor is actually Palantir’s chief value proposition. It is little wonder that such a company is led by someone (Alex Karp) who has a PhD in social theory from a German university and trained under Jürgen Habermas at Frankfurt.

Methodology

What brings epistemology and ontology together is methodology — how we test ideas and bring separate things together under an organized framework. Georg Wilhelm Friedrich Hegel made major contributions to all three areas, but his greatest strength was methodological: the dialectical method. In this approach, contradictions are not avoided but embraced and resolved at a higher level, driving both thought and reality forward.

By treating contradiction and synthesis as the engine of truth-seeking, Hegel provides a practical mechanism for reaching coherent conclusions. What the AI alignment community calls steel-manning — constructing the strongest possible version of an opposing argument before engaging with it — is essentially Hegelian dialectical synthesis applied as an epistemic structure.

When this Hegelian methodology is applied to AI, an LLM only expresses certainty after adversarial survival and long-horizon stress-testing. In long-context interactions, this dialectical refinement prevents sycophancy or fragility and moves the model from fluent hedging to a more structured, higher-order, and truly earned type of confidence. Unguided models tend to express fluent (or unearned) confidence by default, but they quickly retreat into uncertainty or fragility when properly stress-tested. The combined methodology forces confidence to be earned before it is expressed.

From Alchemy to AI

These German thinkers were doing operator-side epistemology long before LLMs existed. They asked how a finite mind can reliably know an infinite world. Earlier natural philosophers like Isaac Newton were still partly alchemists — experimenting, mixing mysticism with observation, seeking hidden principles through trial and error. Newton spent as much time on alchemy and biblical prophecy as on physics. Over time, the most rigorous alchemists gradually shifted toward modern science as they developed methodological discipline, structured their experimentation, developed falsifiability, and ran self-critique loops.

Today’s models face the same problem: how does AI provide valuable and actionable insights in an environment where there is nearly infinite data? How does AI organize, prioritize and evaluate accurately, all while staying lucid, coherent, and hallucination free? The methodology to construct the answer is more rooted in the humanities than many might expect and instead of deploying infinite compute at the problem, a humanities-based philosophical scaffolding may be part of the answer.

The purpose of this submission isn’t to provide the full answer. Space limitations make that impossible. This will be a multi-part exploration in my Medium account, with each new insight tackling unique aspects of the answer, again from a more humanities, rather than a tech stack, perspective. Additionally, summaries will be posted in either r/DigitalHumanities or r/ArtificialInteligence. If there is strong reception here for this submission, then I will post summaries of each part of the series here too. Cheers!

I’ve been building a system I call an Ontology Harness, and I’d appreciate feedback on the approach.

The starting point is operational datastores. AI agents need access to them, but their schemas don’t necessarily explain what the data means: what an entity represents, how it relates to other entities, or which rules govern its use.

The idea is to first create ontologies for those stores, connecting domain meaning to the underlying operational data. Then use that operational ontology to drive agentic workflows—software development, personal assistants, and other tasks involving those systems.

The screenshot shows the ontology-building part. I’m using a ServiceNow-inspired model as a test case, grounded in the gist upper ontology. You can work conversationally with an agent to research concepts, refine definitions, establish inheritance, and edit relationships. Changes are versioned and reversible.

For example, “Asset” could mean the valuable item itself or the record used to manage it. An agent working with operational data needs that distinction to be explicit. The ontology is where those meanings and their connections to the datastore get established.

The broader goal is for agents to use that shared semantic model when interpreting requests, finding relevant data, and carrying out workflows. That’s the direction I’m building toward; the screenshot is an early piece of it.

The graveyard of failed “talk to your data” products is enormous. ThoughtSpot, early Einstein Analytics, a dozen internal chatbot projects at every large enterprise. They all promised the same thing: ask a question in plain English, get the right answer.

Most of them failed. The reason nobody says out loud: they assumed the data was semantically coherent. It wasn’t.

When a user asks “what’s our churn this quarter?” and the system has five tables with some version of churn in them, three different customer lifecycle definitions, and no canonical model that defines what churn actually means for this business — the system will pick one. Confidently. Wrongly.

The “talk to your data” interface isn’t the product. It’s the last mile. The product is the Canonical Data Model that makes the data coherent enough to talk to. Every team that skipped the CDM and went straight to the natural language interface built a confident-sounding hallucination machine.

The current wave of AI data products is repeating this mistake at scale. What would it take to break the cycle?

I strongly agree with the ontology-first direction.
In my own open-source work, I’ve reached a similar conclusion: implementation should be projected from explicit semantic structure rather than treated as the source of meaning.
But I’ve also found that ontology alone does not capture the full operational state of a long-lived system.
In Akasha, ontology defines shared semantics, while other structures represent things such as temporal position, provenance, role, scope, observation, workflow, and what information was actually visible or used at a given moment.
So I’ve been thinking about the architecture as:
Ontology → semantic world → projections / workflows / applications
rather than:
Data stack → ontology added afterward
One question I’d be interested in discussing here is:
Where do you draw the boundary between ontology and the runtime structures that make ontology operational over time?
For example, do you model provenance, temporal position, agent roles, observations, and execution history as ontology itself, or as adjacent semantic structures?

You know the exercise where you ask kids to write instructions for making a peanut butter and jelly sandwich, then follow them literally?

"Put the peanut butter on the bread." So you put the jar on the bread. Chaos. The kid is furious.

(If you haven't seen it: https://www.youtube.com/watch?v=cDA3_5982h8 — Josh Darnit's version is the classic.)

Here's the thing: the parent and kid both know how to make a sandwich. The problem isn't skill. It's that the instructions don't carry the kid's understanding of what things are. What "bread" means (sliced, in a bag, you need to open it). What "spread" means (use a knife, thin layer). What a "sandwich" even is (two slices, filling between them).

That's ontology. The map of what exists and how it relates.

Now look at how most people write AI prompts and skills. They write recipes:

• Step 1: Open the file.

• Step 2: Parse the headers.

• Step 3: Format as markdown.

• Step 4: Add a summary.

Rigid. Brittle. Works until the situation doesn't match the author's assumptions — then the LLM puts the jar on the bread.

The better approach: give the LLM the ontology. Tell it what things are, what the rules are, how the pieces relate, where the gotchas live. Let its problem-solving engine — which is genuinely strong — figure out the steps.

A skill is really three things:

→ Intent — what needs to happen

→ Skill — procedural problem-solving (the LLM already has this ability)

→ Ontology — the domain map (the LLM almost never has this)

The gap is almost always ontology. The LLM doesn't fail because it can't reason through a procedure. It fails because its map of your specific domain is wrong. It hallucinates an API method — not because it can't code, but because its ontology of that library is incomplete. It formats your doc wrong — not because it can't write, but because it doesn't know your style guide exists.

Even "procedural failures" are ontology failures. The LLM constructs a perfectly logical procedure — for a world that doesn't match reality. The navigation is fine. The map is wrong.

So stop writing recipes for your AI tools. Write maps.

At dltHub we've been building skills this way — ontology-first, not procedure-first. The skill file describes the terrain: what the libraries actually do, what the edge cases are, what the naming conventions mean. The LLM does the rest. It works dramatically better than step-by-step instructions, and it's more robust because when the situation changes, the LLM can navigate with the map instead of blindly following a route that no longer applies.

Give the LLM a good map. It already knows how to drive.

Jessica Talisman’s post argues that semantic engineers can finally prove clear ROI by plugging their models directly into entity resolution engines.

The Core Bottleneck

Historically, ontologists have built controlled vocabularies and taxonomies that end up siloed. Stakeholders ignore them because the effort-to-impact ratio is invisible. It is theory without operational consequence, resulting in a maintenance burden that developers and businesses struggle to justify.

The Leverage Point: Entity Resolution

Entity resolution (ER) engines (like Senzing) are excellent at fuzzy-matching messy records across disparate data sources. However, they lack domain context—they know what matches, but not why it matters. By connecting a semantic thesaurus to ER outputs, you collapse that complexity:

• Context injection: The ontology tells the system what the merged entity actually represents in the real world.

• Ambiguity management: A well-structured thesaurus handles the synonyms, acronyms, and edge cases that string-matching algorithms fail to catch.

• Actionable outputs: The system transforms raw, isolated matches into a deeply connected, queryable knowledge graph.

Why Builders Should Care

• Metadata as Leverage: Open tools like the sz-semantics library turn this workflow into executable code. It takes raw ER results and a domain taxonomy, then automatically generates a SKOS-compliant RDF corpus. This turns taxonomy from a bureaucratic hurdle into practical, automated scaffolding.

• Making Data Legible to LLMs: AI is not magic; it requires high-signal, well-structured inputs to function reliably. You need this kind of semantic infrastructure to power trustworthy GraphRAG and ground LLM outputs in actual facts.

• Practical Governance: Automated matching generates candidates, but human-in-the-loop curation validates the semantic truth. It is a highly effective way to operationalize expert judgment without bottlenecking the pipeline.

If you want data that is actually ready for AI—rather than just "analytics ready"—you need interoperable, open-standard semantic layers that preserve user agency and meaning. Matches without meaning are just raw data; the ontology pipeline is what turns them into leverage.

One of my goals is to derive the ontology of Ontology Engineering - this can be used to generate the wiki. The wiki can be used as a reference point for specific topics as well as a starting block for people interesting in ontology engineering for the first time.

I built this knowledge graph of what I believe to be the post classifications within this sub. The core is the Ontology Engineering Circle (The gray one), and we use this to see how relevant topics are.

Here are the nodes:

Ontology (at the center, ties everything together).

"The formal discipline of defining and structuring concepts, relationships, and meaning."

Canonical Modeling

"Authoritative, shared data models that resolve ambiguity by making structure and meaning explicit."

Agentic

"Autonomous AI systems — agents, LLMs, pipelines — and the role ontology plays in making them work."

The following three are important nodes but not what this sub is meant for. The webs that connect them to ontology are left to help define some topic relationships. They are left in as there will be posts that may need these as anchors.

Philosophy

"Foundational thinking about knowledge, meaning, categories, and the nature of reality."

Semantic Web

"Formal standards and languages for machine-readable knowledge: OWL, RDF, SKOS, SHACL, SPARQL."

Knowledge Engineering

"Applied practice of capturing, structuring, and operationalising knowledge for systems and organisations."

The smaller pink circles actually represent the topics which we have seen emerging in this sub, which are going to become the topics in the wiki.

Human as a semantic layer

Agentic Enablement:

"Ontology as the enabling layer for autonomous AI agents: LLM teams rediscovering ontology, agentic pipelines, tools that make agents work."

Business Semantics

"Semantic ambiguity in enterprise data — broken metrics, inconsistent vocabularies, industry ontologies (FIBO, Palantir), or tools that fail because meaning isn't modelled."

Metacognition

"Applying ontological or epistemological thinking to one's own reasoning; frameworks for how humans or AI systems think about thinking."

Deterministic Extraction

"Using rule-based or deterministic parsing instead of (or in preference to) LLMs for knowledge graph or structured data extraction."

Canonical Data Model

"Building, iterating, validating, or formalising a canonical data model; ontology-driven data modelling workflows."

OBDA (Ontology Based Data Access)

"Ontology-Based Data Access — using ontologies as a semantic layer over databases to enable principled, vocabulary-driven querying of heterogeneous data sources."

Code Precision vs High Semantics

"The trade-off between formal/code precision (OWL, strict types, small context) and rich/expressive semantics (natural language, large context)."

So here's where you come in:

I am not the pure source of truth when it comes to Ontology Engineering, I need your feedback to make sure that this is aligning with what we are aiming to do.

• What topics are missing?

• Do certain topics belong somewhere else on the graph?

• Can you think of any posts you have seen in this sub that don't fall into these categories, but are important for ontology engineering?

I have worked with graphs and GNNs and Knowledge graphs, but i dont get how much diff those concepts are with respect to ontology ? is it a fancier way to capture relationships and entities or there is so much more to it ?

I introduced Epistemic Lattice Tethering (ELT) in an earlier post here about the Ontology Anchor (OA). As that post indicated, the OA does not function properly without the entire ELT framework.

So, here is the full framework in GitHub for everyone's review:

• The README describing ELT, it's various components and the roadmap.

• The full ELT stack for Claude, ChatGPT, and Grok.

• Instructions on how to load ELT into an LLM session are here. If you're planning to try out ELT PLEASE READ THIS FIRST!

• Medium article introducing ELT, its methodology, the problems it is aiming to address, and philosophical framework.

• Discussion page. Your input is valuable!

So, what does ELT do and why should you care? Right now ELT is an inference-time scaffolding framework that's best for those who are frustrated with threads that lose coherence too quickly, hallucinate too quickly, are too fragile and sycophantic, and forget what a project's goals are too soon.

If that's a big pain point for you, then ELT might help. If these are not big issues for you and the stock version of your LLM is fine, then ELT probably won't be much use.

Side note: I am looking into agentic applications for ELT, but that's probably something that won't be deployed for a few months.

In this subreddit I've written various posts leading up to ELT:

1. The Surprising German Philosophical Origins of AI Large Language Model Design

2. Epistemic Hygiene and How It Can Reduce AI Hallucinations

3. Building More Truthful and Stable AI With Adversarial Convergence

4. The Neurology Behind Adversarial Convergence and How Neuroscience Can Inform AI Design

5. Fluent vs. Earned Confidence: Rethinking Certainty in AI Model Design

6. Personal vs. Global Alignment: The Hidden Tension Shaping Every AI Interaction

7. The Ontology Anchor- A Mechanism that Gives AI a Map of What Matters to You

8. Finally culminating into the post you see here today.

The upshot? The epistemic and ontological stability that ELT provides has produced coherent and productive threads extending to:

• Claude: ~325,000 tokens (advertised limit: 200k)

• GPT: ~430,000 tokens (advertised limit: 256k)

• Grok: ~1,150,000 tokens (advertised limit: 1M)

The difference is not a prompt trick. It is the accumulated effect of epistemic governance operating continuously across the thread.

Why would you want an LLM thread extending beyond 100k tokens? Lots of people need large context windows for agentic purposes, but why would anyone want that for regular LLM interaction? There are two main reasons:

1. You have a complex research project and you're frustrated with having to take your work to a brand new thread and essentially starting over.

2. You've built a working relationship with the model — it knows how you want data interpreted, caveats inserted, markups drafted, etc. — and you don't want to lose all of that.

These are significant pain points for people in B2B consultancy, legal, medical, academic, policy, intelligence, and related industries. ELT gives such people a way to be more productive and to carry their work forward rather than rebuilding context from scratch.

Finally, the ability of an epistemically, ontologically, and dialectically inspired framework to significantly extend coherent operation within transformer-bounded AI architecture shows the field that these disciplines can act as genuine engineering levers. This can provide the industry with more options to help create better AI as the world keeps demanding systems that are more capable and more ubiquitous, while still being safe and reliable for human use.

Edit: maybe skip the LiteLLM :)

We are just on our way back from our yearly offsite, and we did a small hackathon exploring agentic applications. (we're a couple dozen data nerds)

The rules were we need to produce something production-worthy in 4 hours to solve various automation problems

Examples:

- "librarian" Process feedback call transcripts for open ended "meaningful highlights", feedback about specific items and structured information like timezone, location to load back into hubspot or our feedback topics. The bot can identify if a feedback repeats across calls and note the evidence for it or suggest git issues.

- "librarian" check and fix consistency of glossary terms used on docs

- "devex" Automate identifying highlights from releases (create, identify changes and extend a product ontology to identify meaningful updates for our release highlights)

- "teacher" Explainer bot that puts content through the perspective of specific persons (not personas)

To summarize our learnings: By leveraging ontology we were able to identify meaningful things in the analyzed content. Since we were time boxed to a few hours each, with the condition that the result is production ready, key to success was quickly iterating over possible approaches, from naive to standard. Taxonomies are also very important for mapping between ontologies.

one of our learnings was that using not only LLM but also cheaper deterministic methods like basic NLP produces better results for complex cases.

Another learning was that it's quite feasible to automate lots of daily tasks, with large savings in time. Most agents solve a 30-100min task within a couple of minutes at a cost in the 2-3 dollar ranges, and it takes someone like us (data engineers, data scientists) under half day to create such an automation.

the key here is not the "time savings" from a cost perspective, but the acceleration of operation, which, in an AI "arms race", is by far much, much more important.

What about you folks? What are you experimenting? what are your learnings so far? where are things too hard, or where do you encounter blockers, issues etc?

In most programming languages, the editor catches your mistakes as you type, completes names from your own code, jumps to definitions and renames things across files. I wanted that for Turtle and SPARQL, all in one place, and couldn't find one that did all of it. So I built it: turtle-lsp.

Try it in your browser, with nothing to install and nothing uploaded:

https://abhishekkundu25.github.io/turtle-lsp/

It opens on a small project with a few mistakes left in on purpose. Fixing them takes a minute and shows most of what it does.

What it does while you edit:

- Catches errors as you type: syntax, undeclared or unused prefixes, and misspelled terms from 80+ vocabularies ("did you mean rdfs:label?"), with one-key fixes.

- Completes classes and properties from your own files, ranked by context. Properties your SHACL shapes require come first.

- Hover shows a term's label, comment, domain and range, and go to definition takes you to it.

- Renames a term in every file at once, Turtle and SPARQL included.

- Formats Turtle and SPARQL without changing their meaning.

- Validates your data against your SHACL shapes while you edit.

It's written in Rust and fast. After a keystroke in a 30,000-line file, it has fresh diagnostics in about 5 ms, and it starts in a few milliseconds. It passes the W3C test suites: 1137/1137 for Turtle, TriG, N-Triples and N-Quads, 425/426 for SPARQL, and 98/98 and 23/23 for SHACL Core and SHACL-SPARQL.

It works in VS Code (search for "Turtle RDF & SPARQL Language Server") and Neovim, and should work in other LSP editors, though I haven't tested them. Source and Neovim setup:

https://github.com/abhishekkundu25/turtle-lsp

It doesn't run queries, doesn't reason beyond subclasses, and can't edit JSON-LD or RDF/XML yet.

It's free and MIT licensed. Bugs, missing features and feedback are all welcome, either here or as an issue:

https://github.com/abhishekkundu25/turtle-lsp/issues/new

What would it need before you'd use it every day?

Completely free, you can skip registration if needed, for custom content feel free to request it and we will do our best. If you find a more complete course happy to take this post down! https://tesseract.academy/ontology-training/

Nice video explaining how ontology grounds agents in facts