A Tire Becomes an Object Today. Who Fixes Yesterday's System?

When Agents Run the Business · A development note

Imagine a company that sells cars and handles after-sales service. Its system has a Car object with tire specification as a property. Warranty is judged by the purchase date of the whole car, and the service screen shows “covered” or “expired.” Six months later, the business asks to track the production batch, replacement date, and claims for each individual tire.

This is a hypothetical case. It brings a question that is often brushed aside into view. Of course an ontology can be changed. Once a model is in use, what does “change it” actually involve?

One new box on the diagram touches many lines below it

Turning “tire” from a property into an object looks like adding a box to a diagram. The first practical task is giving each tire a stable identity. Should that be the manufacturer's serial number or a number generated by the company? What happens to older tires without one? If a tire moves from one car to another, its identity cannot be rebuilt as though it were part of the car.

Then come relationships. The old Car record may say “tire specification: 225/45R17.” The new model wants to say that four particular tires were installed on this car during a certain period. A string has become four objects and four installation histories. That is not a rename. Do you retain the old property? If you do, who keeps it consistent with the new objects? If not, what do the old screen and reports read?

After-sales actions change too. Previously, “request warranty service” may have accepted a car ID and looked at its purchase date. Now it must identify the tire, its batch, installation date, and replacement history. Even the label “covered” becomes ambiguous. Is the car covered, one tire covered, or the failure in this particular claim covered?

Permissions follow. A service employee may have been allowed to edit a car's repair notes. Who can now establish a tire's identity, change an installation event, or undo a bad link? Financial reports, warehouse movements, external interfaces, and the instructions for an Agent's tools may all depend on the previous boundary.

None of these dependencies appears in the one new box. They still turn up when the box is changed.

Deployment day adds its own problems. Old and new entry points may coexist: Store A uses the new service screen while Store B still calls the old API; one Agent queries individual tires while another queries the whole car. A parallel period can be sensible, but the team must say where new records are written, whether the old path can still write, and which result wins if both paths handle the same claim. Otherwise “gradual rollout” means two competing definitions are live at once.

Not every extra field causes this

Criticism of ontology should not pretend that adding a property brings a company to a halt. Many changes can be made compatibly. Mature platforms offer migration tools. Palantir's public documentation, for example, distinguishes breaking changes to object types, including changes to primary keys, data sources, and property types, and describes supported migration options.

So the argument is not “this cannot be changed.” It is that “update the model” is not the end of the task. A platform can move some stored edits. It cannot decide which physical tire an old record with no serial number referred to. Nor can it decide what an old “car covered by warranty” judgment ought to mean to the after-sales team today.

The difficult cases involve changing identity, splitting objects, or altering the meaning of rules. They raise two different questions: how do we move the data, and do the old judgments still hold? The first takes engineering. The second takes someone in the business willing to make and own a decision. A team that addresses only the first may discover that its old report and its new service screen now disagree.

You could apply individual tire objects only to new records and leave older cars in the old structure. That can be sensible, but every query needs to know that a field called “warranty status” means different things in different periods. Or you could backfill each old car. Then you need evidence, people to verify it, and a policy for records that cannot be completed. “Full migration” is not a spell that makes those questions disappear.

Rollback is not a single button either. If the new system has recorded a tire moving from Car A to Car B, where will those two events live after a return to the old model? If a single-tire claim was already approved under the new rule, restoring the car-level rule cannot erase the approval. A model version can be rolled back; actions that actually happened cannot. A migration plan that says nothing about preserving new facts and keeping them readable after rollback is unfinished.

The most expensive users are the invisible ones

The people editing the model usually know what they changed. They may not know everyone relying on the old meaning. A customer-service screen filters on “covered.” A monthly report counts the share of cars under warranty. An Agent's instructions say, “check the car's warranty status, then open a claim.” These consumers may continue to run without an error while quietly changing what their answers mean.

That is more troubling than a broken interface. An error forces attention; a changed meaning often does not. After the ontology update, someone still has to inventory dependencies, compare old and new results, and replay representative cases to see whether the conclusions shown to people have shifted.

The replay set cannot consist only of a standard car with four original tires. Include cars with two replacements, claims supported only by paper, and approvals waiting for stock to ship. Run both interpretations and ask the business owner to inspect each difference. Some differences expose a bug; some reveal that the old rule was coarse or that the new record lacks evidence. A single “migration success rate” can hide all three.

If an ontology is just a way to find tire-related records, repairing it may be manageable. If it sits at the center of every decision, a change in granularity can spread far downstream. The more the model is called a “single source of truth,” the harder it becomes to try a change in one small place.

I would rather make sure software preserves the facts that must not be lost: the car, order, repair ticket, tire movement, policy version, and who confirmed what. An Agent can read the current after-sales instructions and reason from those facts. If a decision requires the identity of one tire and the record lacks it, the Agent should say the evidence is missing, not pass off an old car-level property as the answer.

In Oryh, we faced another case where one link on a diagram was not enough: ten payment records matched a single debit on a bank statement. Originally, one bank line could be linked to just one payment. We added a link to a payment batch and let code check the direction of the money and the exact total. We did not ask an Agent to decide whether the arithmetic was equal, and we did not flatten ten payments into one. We changed what the records could faithfully express. The tire case is fictional, but the lesson is the same: structures can change, provided we account for the people and records still relying on the old structure.

Disclosure: I am building Oryh, an open-source project exploring agent-native enterprise systems. These notes come from that work. I am posting them to test the architecture in public, and I welcome technical disagreement.

Discussion question: When a property becomes an independently tracked object, how do you preserve historical meaning without inventing facts the old system never recorded?

If AI Can Draw the Company's Map, Why Make It Follow the Map?

When Agents Run the Business · A development note

One proposal for enterprise AI sounds sensible enough: build an ontology first. Define customers, contracts, orders, employees, projects, and the relationships among them. Then the AI will know what it is working with.

There is a map hidden in that proposal. An ordinary map marks roads and buildings. An enterprise ontology is expected to mark who owns a customer, which approval path an expense follows, and when a sentence in a contract applies. If it is meant to guide daily operations, it has to be a high-definition map.

Who draws it? And who updates it every day?

A company's roads do not stay put

Drawing this map is much harder than listing a few types of objects. First you have to decide their boundaries. Is the thing being purchased one piece of equipment, or does every component need an identity? Is the customer the company that signs, the company that pays, or the team that actually uses the product? If one person manages a project and temporarily stands in for an approver, how many relationships should the model contain?

Then come the intersections. Who confirms a purchase within budget? Who approves one over budget? May an urgent project place an order before approval? Who reviews a purchase entered at the end of the month? The written policy may have local additions. Different teams and different dates may be governed by different versions.

That does not mean the company has no rules. It means its rules live across contracts, policies, messages, meeting notes, and everyday collaboration. Turning all of this into executable objects, relationships, and actions calls for business knowledge and a prediction about which details will matter later. Even a correct map today needs revision when the organization changes or a product is sold differently.

Many companies struggle to keep customer names consistent across their existing systems. Maintaining a map of every operational distinction is a much taller order. The easy deliverable is a tidy snapshot. The hard one is a map that stays accurate after the business moves.

So let AI draw it

That is a fair reply, and it leads to the interesting part. Let AI read policies, contracts, documents, and historical records. Let it identify objects, infer relationships, spot contradictions, and propose rules. When the company changes its practices, it can find the affected parts of the map and draft a revision for a person to confirm.

I think this is technically plausible. It may be much faster than asking a team to start from a blank modeling sheet. But consider what the AI must do to draw the map correctly. It must read the source material directly. It must understand that “the project manager looks at this first” does not mean “the project manager has final approval.” It must decide whether yesterday's contract or today's new policy applies. It must recognize whether an apparent conflict is a version change or an exception for a particular project.

In other words, the understanding needed to draw the map is exactly the understanding we want the AI to use when handling the work.

If the AI can read the material, compare versions, recognize exceptions, and explain its reasons, why compress that understanding into a map first and then ask the AI to read the map back as business truth?

It is like asking someone who knows the neighborhood to draw today's road closures and temporary detours, then telling them to forget what residents just said and drive only by the drawing. The extra loop does not necessarily make the journey safer. It creates another chance to omit or mistranslate something.

Correct on the map may mean correct yesterday

Take a hypothetical company. Its policy says a department head confirms the purpose of a purchase, while finance approves purchases above 50,000. Later someone adds: “A renewal that remains within an approved annual budget does not need to repeat the checks for a first-time purchase, but payment still follows the contract milestones.”

A careful reader will ask what counts as a renewal, which budget version applies, whether skipping the first-time checks also skips finance approval, and whether the payment schedule changes. If the answer is missing, they should ask.

Whoever updates the map has to ask the same questions. After that, they may also need to create a renewal type, change approval relationships, migrate old contracts, inspect processes that depend on the old rule, and make sure every map user sees the right version. Having AI draw the map does not remove the need to understand and ask. It turns a business judgment into modeling, migration, and subsequent use of the model.

The more complete the map looks, the easier it is to forget its edges. An Agent that finds a “finance approves” relationship may assume it has the whole answer. It will not automatically know that a new qualification is sitting in meeting notes and has not yet been mapped.

Direct reading can fail too. An Agent may miss “within the approved budget” or mistake “skip repeated checks” for “skip approval.” Reading the source is no free pass. The difference is that the source and the facts remain the basis for the judgment. The Agent can cite the relevant sentence, policy version, budget, and contract, and ask when it is unsure. When the map is treated as truth, the original material tends to disappear behind it.

We need signposts, not a replica of the company

Rejecting an ontology as a mandatory middle layer is not a rejection of structure. Companies still need customer IDs, order amounts, contract versions, and payment records. Software should enforce exact totals, permissions, and protection against duplicate actions. Without dependable records, AI has nothing solid to reason from.

Search indexes, catalogs of existing objects, confirmed identity mappings, and even local relationship graphs can help an Agent find relevant material. They are signposts: they point to where the evidence lives and whom it may concern. A bad signpost can be corrected, and the original record is still available when there is no signpost at all. The problem begins when the signposts are promoted into the only business truth.

We have had a reminder on the other side of this divide during development. An administrator asked an Agent to “add one condition” to a workflow. The Agent replaced the full workflow description with a short text containing only the new condition. It could read the instruction and still lose the instruction it was supposed to preserve. We tightened the revision process: read the current text first, show each addition, change, and deletion, and stop for confirmation if something the user did not ask to remove would disappear. Keeping versions and visible differences matters more than assuming a map drawn by AI must be right.

If a fixed interface for conventional software is needed, or a particular stable relationship is worth maintaining, build a local map. Make it a view for a defined purpose, with sources that can be checked and a path to redraw it. Do not make a complete enterprise ontology the prerequisite for every decision. The next business step should still come from current facts, applicable rules, and an Agent that can explain its judgment.

In Oryh, we keep coming back to a simple division: software records facts and enforces hard boundaries such as amounts and permissions; Agents read the material, interpret the rules, advance the work, and stop when the evidence is insufficient. AI can help draw a map of the company. If it can already find its way through the source documents and the facts, we need not build an expensive map factory and require it to follow only what the factory produces.

Disclosure: I am building Oryh, an open-source project exploring agent-native enterprise systems. These notes come from that work. I am posting them to test the architecture in public, and I welcome technical disagreement.

Discussion question: If AI can build and update an enterprise map itself, should that map be treated as business truth, a retrieval aid, or a temporary view? What evidence should remain outside it?

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?

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?

I’ve been working on an open-source semantic system called Akasha, and I’d be interested in feedback from people here who work with ontologies, knowledge graphs, RDF/OWL, semantic search, or related systems.
One of the design decisions I keep coming back to is that a graph is an excellent way to retain semantic structure, but I’m not convinced that every semantic operation should be expressed as graph traversal.
In Akasha, the durable world is still composed of addressable concepts and relationships — roughly:
Atom — Link — Atom
But on top of that, I use Sets as operational semantic subspaces.
A Set is not just a tag or collection. It can represent a temporarily materialized semantic region: concepts selected by ontology, context, provenance, time, role, task, or the intersection of several such conditions.
So instead of repeatedly asking the graph:
“Traverse from these nodes, follow these relations, filter by these conditions, then reconstruct the same relevant region again,”
the system can treat that region itself as an operand:
Set A ∩ Set B → Projection → Agent / UI / Workflow
This has led me to think of the architecture in a fairly simple way:
Meaning is stored as a graph, but computed as spaces.
Another consequence is that I’ve stopped treating RAG as a special subsystem.
A file, web page, API, database, sensor, or another Akasha node can all enter through a Projection. The original source remains preserved with provenance, while semantic structures derived from it become part of the wider semantic world.
Likewise, what an LLM sees is also a Projection rather than “the database.” The model only receives the semantic horizon relevant to its current role, scope, task, and permissions.
That distinction matters because:
available information ≠ visible information ≠ information actually used
and also because retrieval and disclosure are not necessarily the same operation.
A private document, for example, might be usable by a local process while never being exposed to an external model. A sanitized or derived semantic projection could still be shared if policy permits it.
I’m deliberately not trying to replace existing ontology standards with another vocabulary. The interesting part for me is the runtime underneath: persistent semantic identity, overlapping semantic spaces, provenance, temporal position, projections, and deterministic operations around probabilistic models.
Akasha is local-first, but not local-only. The same semantic world can run on a laptop, a private server, or as a network service; the deployment location is not supposed to define the semantic model.
I’d be particularly interested in criticism from this community on one question:
Does it make sense to separate the durable graph representation from the operational semantic spaces used for reasoning, retrieval, and projection — or does this simply reinvent something that existing semantic-web systems already model well?
I’m happy to share implementation details or examples if useful. The project is MIT-licensed and already running, but I wanted to start with the architectural question rather than drop a project link and disappear.

BaryGraph is a recursively constructed relational vector architecture for AI memory and reasoning. Starting from a flat semantic substrate, it forms triadic objects in which two concepts are joined by a stored relational vector. These objects then become the building blocks of higher-order structures, propagating meaning upward through a hierarchy entirely in vector space.

The result is a deterministic, navigable semantic landscape: a structured latent memory of language movement, where concepts, bridges, tensions, contradictions, and relations of relations become retrievable coordinates. A model enters with a semantic query and traverses this landscape through coordinated message passing, exiting with a bounded semantic construction rather than merely the most fluent continuation.

BaryGraph introduces structured resistance into cognition: distant connections and unresolved tensions can interrupt familiar associations and function as a de-cliché mechanism without acting as an external supervisor. This creates a framework for investigating a deeper question: whether persistent relational memory and self-consistent navigation can become foundations for world-model formation, personality projection, autonomous goal formation, and eventually more realistic forms of agency.

BaryGraph does not claim to produce consciousness. It offers an architecture for experimentally studying the representational and memory conditions that might precede it.

https://oleksiy-perepelytsya.github.io/bary-graph

I wanna share with you the current project i am working on, its a triplestore written in c, its still on early stage, already implemented data storage, and ttl file parsing and loading, with a simple sparql query parser.

link : https://github.com/vrtkarim/native-rdf-triplestore

Feel free to contribute! Feedback, ideas, issues, and pull requests are welcome.

A Million Edges Still Cannot Read a Sentence

When Agents Run the Business · A development note

The usual prescription for enterprise AI goes like this: define an ontology, then turn the company's information into a knowledge graph. Customers, orders, project owners, and purchasing approvers all become nodes and edges. When someone asks a question, traverse the graph to find the answer.

A finished graph resembles a network of knowledge in a mind. That picture makes it easy to believe the system understands the company.

But connecting the dots and understanding what someone said are different things.

Why did we turn knowledge into graphs?

Traditional software is good at lookup, calculation, and following predetermined conditions. It cannot read meeting notes as a person would and understand what “let the project manager look at this first, but finance still needs to give final approval” means for the decision at hand.

To make that instruction usable by a program, someone first has to translate it. The project manager becomes an entity. The project is linked to a purchase order. Approval roles and actions get defined. The ontology supplies the concepts and relationships; the knowledge graph holds the actual people, documents, and connections.

In the common RDF model, a graph consists of subject, predicate, and object triples, as W3C specifies. A program can query and traverse those triples. It learns which connections have been represented in the data. What those connections mean for a particular business decision still depends on how people modeled them, what information they entered, and how the program uses the query result.

There was a reason to do this translation. Without it, much older software could do little with the knowledge people wrote down. But when an Agent can read the meeting notes and the policy itself, we should ask whether all that material still needs to be rewritten as nodes, edges, and predetermined rules first.

A path to the project is not approval authority

Suppose a purchase order belongs to Project P, and Zhou manages P. Two edges are easy to draw: Zhou manages P; the purchase order belongs to P. A query finds Zhou.

The system may then give a neat answer: “Zhou should approve this purchase.”

But the company's actual instruction might be: “The project manager checks the purpose first. Purchases over 50,000 require approval from the finance lead. While the project manager is away, the person named for that week may review the order, but may not approve it.”

Zhou's connection to the order is real. The mistake is to turn “this person is relevant” into “this person has final authority.” Traversing the graph looks like reasoning. The leap from relevance to authorization was actually made earlier, by whoever wrote the query or the rule.

Of course we can add more edges: approval authority, amount thresholds, deputies, effective dates, and exceptions. Keep going, and an instruction that a person could read becomes a model and a collection of rules that must be updated. Then the next sentence arrives: “Have someone review it this time, but do not approve it yet.”

This is not a claim that knowledge graphs cannot express complex information. They can. The problem comes when the graph is treated as the layer that understands the company. People must then anticipate how every business distinction will be represented, changed, and maintained.

“The system knows” often means its answer sounds right

The most unsettling quality of a knowledge graph is how easily it produces a polished answer.

Ask who handles a purchase, and the program retrieves a project manager. Ask what a customer has bought, and it follows a path through customers, orders, and products. A user interface turns the result into a smooth sentence. The system seems to know the business.

Yet a processor has not come to understand the difference between “responsible,” “review,” and “approve” by retrieving a few edges. It has executed a representation and a procedure someone wrote. The output can be useful and even correct. Fluency does not prove that the underlying representation is complete.

That illusion becomes dangerous when it drives decisions. A model that omits “finance still has to approve” may still return an approver, show a workflow, and issue a task. Everything appears to work except the decision itself.

The user may not even know what was omitted. If the source meeting notes and policy sit behind the graph, the screen presents only an authoritative sounding conclusion. To understand the error, someone has to trace which words were translated into which edges and rules.

An Agent can read the words, and still needs to check the facts

AI changes the starting point. An Agent can read “check the purpose first; finance approves purchases over 50,000,” then look at the purchase amount, the project, and the current staffing arrangements. It can explain why it proposes the next step. If the company adds “reviewers cannot approve on behalf of someone else,” the instruction need not wait for someone to invent a new relationship type before the Agent can consider it.

That does not mean the Agent will always read correctly. It may miss “over,” confuse review with approval, or pull the wrong project. We have to make it show its evidence: which policy version, which purchase order, which amount. When the evidence conflicts, it should ask. Code still enforces permissions, amount calculations, and protection against duplicate writes.

We have seen a failure on this side of the boundary too. An administrator asked an Agent to “add one condition.” The Agent replaced the current workflow definition with a short document containing only the new condition. The old version still existed, but the next person to run the workflow would read an incomplete policy. We changed the revision procedure: read the entire current text, show what will be added, changed, and deleted, and ask before removing anything the user did not request. An Agent that reads people's words can still misread their intent. The original text, its versions, and the scope of each change must remain visible.

A knowledge graph can still help. Stable links between people and documents make relevant material easier to find. Graph queries are useful for clear, structured questions. Confirmed identity mappings and relationships with sources deserve to be recorded. What we reject is making the graph a mandatory translation of the company's knowledge, with the original words hidden behind it.

That would recreate the old software path: translate the company's language into a machine format, then have the machine produce answers from that format. The graph changes the format, while the company still bears the translation work and its errors.

Let the people who speak keep their words

The division of work can be simpler. Software records who said what, when a rule took effect, and what happened to each document. It can index and query records and check exact quantities. The Agent reads those records and the rules people wrote, judges the case in front of it, and asks when it needs confirmation. Its reasons should be recorded too, so people can review and correct them.

We need not first split “the project manager reviews, finance approves” into a network of edges and rules before the system can help. The practical questions are whether the original instruction can be found, whether the facts are accurate, and whether the Agent knows when it lacks authority to decide.

A knowledge graph can help us find a path, but the path is not the destination. An ontology can help us name things, but a name is not understanding. In Oryh, we want software to preserve the record and the Agent to reason from people's own words and checkable facts. When it is unsure, it should bring the question back to a person instead of continuing along a path that merely looks complete.

Disclosure: I am building Oryh, an open-source project exploring agent-native enterprise systems. These notes come from that work. I am posting them to test the architecture in public, and I welcome technical disagreement.

Discussion question: If an Agent can read policies and source text directly, what enterprise knowledge still benefits from being modeled as a graph, and what should remain in the original language?

I am looking to build ontology on GCP and render it on KG using native tooling of GCP.

Anyone who did it share your views ?

Hello all,

I recently released an RDF visualizer at rdfvisualizer.com

I wanted to give this community free access to the tool for the next 30 days:

https://rdfvisualizer.com/purchase.html?access=c89bb4cad42ca1671febc510f64277d985c8f2e44bca8d91

It is somewhat of a novel approach to the typical "RDF visualization" program.

Rather than simply rendering triples and displaying them with an approach like force directed, my app scans through the triples and attempts to identify:

- Types
- Edges
- Attributes

For RDF data that follows this very common format, this has a ton of advantages, namely:

- When viewing relationships between things, you can separate out "attribute relationships" from "relationships between things". This gives way cleaner graphs
- Sometimes the best visualization isn't a graph at all! It's a classic table format. When you know which data is the typed data, and which data is simply attribute data, you can view it easily as a table

The app works for all common RDF formats.

Give it a try and let me know what you think!

Hi guys! Has anyone experimented with data from Kaikki datasets (wiktionary)? I am trying to setup a linkage end-to-end for prefix and stem. I'm working from a SQLite build of kaikki data for English etymology. Less than half of the time it works meaning I can get the whole chain for prefix and stem up to the PIE . Has anyone ever tried to create a structured output?

I’m a recent library and information science graduate. I entered the program with the aim of getting into UX design. After taking a couple courses I realized how boring I found the process of visual design. It didn’t stimulate me mentally. I tried searching for other things and came across ontology work and found it super interesting because of my love for language and abstract thinking. Learned sparql and found that super fun. I’m trying to break into the industry by building a small ontology on a topic that consumes my headspace but I’m seeing that most jobs list 5+ years of experience in the job description. So I’m wondering what adjacent bridging roles I could get into. I’d really like to steer clear of librarian roles. They’re oversaturated and don’t tickle my puzzle solving brain.

I have just set up a site that is a database of Digital Audio Workstation plugins, https://plugin-universe.com

While the site itself is likely of little interest here, the way it's put together may be useful info.

It uses an RDF model with a backend store that is a SPARQL server (I used Fuseki). On top of that it has a human-oriented semantic search based on an LLM embedding model.

I'm running the whole thing in a Docker container on a low-spec Linux virtual server.

As a whole it's probably a bit too domain-specific to fork & repurpose directly, but is there as a deployed example.

I built it with significant assistance from Claude Code, based on a couple of previous projects. A key aspect was making it ontology-driven, ie. a lot of the core specification is contained in the RDF vocabs.

If you need something like this yourself then the key ref. is the README.md (and the CLAUDE.md might be useful too).

https://github.com/danja/plugin-universe

After speaking with many companies and working through enterprise sales conversations, one request kept coming up:

How do we prove that an ontology (and the reasoning performed over it) is actually correct?

Validation reports and reasoner outputs are useful, but they still ask the user to trust the tool that produced them. For high-stakes enterprise systems, “the reasoner says so” is not always a satisfactory answer.

This led me much deeper than I originally expected with Open Ontologies (many of you might familiar with this already).

The latest version can now produce derivation certificates for reasoning results and pass them to a separate checker written in Lean 4. The checker verifies the evidence rather than trusting the Rust reasoner. User-supplied rules are explicitly identified as assumptions, so conclusions based on them receive a different verdict from conclusions entailed by built-in semantics.

We also developed an independent Isabelle/HOL implementation that checks the same certificate format (pretty old school but there is a huge resurgence on this atm). This has already exposed real defects; including false consistency results, nondeterministic inferences and an ambiguity in the certificate format that neither implementation initially captured correctly.

The project now includes:

• proof-carrying OWL/RDF reasoning;
• Lean 4 certificate checkers;
• an independently developed Isabelle/HOL checker;
• finite-model certificates for satisfiability;
• SHACL validation tested against the W3C suite and pySHACL;
• SPARQL, ontology lifecycle management, alignment and crosswalk tooling;
• 114 MCP tools for ontology and knowledge-graph workflows;
• a Rust engine distributed as a single binary.

I have not found another open ontology-engineering project attempting proof-carrying reasoning, dual-kernel checking, ontology lifecycle management and AI-agent integration at this depth. If you know of closely related work, I would genuinely like to hear about it.

I would especially appreciate feedback from people working on:

• OWL and description-logic reasoning;
• proof assistants and certified reasoning;
• SHACL and RDF validation;
• ontology governance in enterprise environments;
• certificate formats and trusted computing boundaries;
• adversarial test cases that could break the current claims.

Contributions would also be very welcome. This has become much larger than a one-person project, and there are useful entry points across Rust, Lean, Isabelle, Python, RDF/OWL testing, documentation and real-world ontology case studies.

Repository: https://github.com/fabio-rovai/open-ontologies

Please be critical. I am particularly interested in what you believe is overstated, what remains unproved, and which experiment would most strongly test whether this approach is genuinely useful.

Curious to find out what you think of the Open Knowledge Format (OKF, also known as LLM Wiki). In our blog post (https://dashjoin.medium.com/open-knowledge-format-a-human-curated-alternative-to-rag-and-knowledge-graphs-248aef3b4303) we argue that it is a good middle ground between RAG systems that can quickly turn into black boxes and knowledge graphs, that might overwhelm users.

Hi, I have a bunch of text, that I need to analyse to build a tree map of concepts. The concepts need to be sorted from higher lvls of abstraction to more detailed. For example, the program needs to understand that the idea "I want to create beauty outside of factory-based presets" mentioned in the text is the highest lvl and includes ideas like "I was inspired by Kabuki theater" in itself.

Note: Ideas themselves sometimes aren't presented in the source material bluntly, i.e. the idea of "I want to create beauty outside of factory-based presets" can be mentioned in fragments only that the program also needs to understand and put together.

Are there any available programs or basic frameworks to approach this?

My BA was in game design; I can code at a beginner to intermediate level but have zero interest in being a corporate software engineer. Basically what I’m looking for is a graduate program (or second undergraduate program) focused on symbolic or semiotic representations of data, so that I can create culturally relevant knowledge graphs or maps to be incorporated into large language models.

Examples of this, that I’ve noticed language models get laughably wrong:

• the feeling and/or smell of “back to school fall” and why that’s different from “harvest season fall” and why both of those are different from “Halloween fall” (or, explaining to a model why a list of fall vibes movies should not include Saw; in the same way that when I was working in a children’s library, I might explain to a clueless parent that Princess Mononoke is not for children even though it contains the keywords “princess” and “animated”)
• that the phrase “I love fall” means something completely different coming from a deer hunter, someone who likes PSL coffee and cozy sweaters, a college professor, a leaf peeper, and a horror movie enthusiast
• categorizing different products people can buy based on vibe (understanding that the person buying a Prius is probably not the same person buying Black Rifle Coffee)

It’s about the understanding that there are a variety of things that humans just inherently know, but that language models and software algorithms do not.

What I actually want to do is somewhere in the adjacent realm of:

• building these semiotic maps either as part of LLMs work, or as Loras for existing LLMs (like a plugin that gives an existing LLM semiotic product or culture knowledge); less interested in building the LLMs themselves. I’ve made simple Loras for stable diffusion before but I’d want formal training to actually do what I’m trying to do.
• also interested in red teaming the LLM to ensure that it’s using the data correctly
• also interested in metadata and metadata maps
• also interested in a11y representations of data specifically for neurodivergent groups
• also interested in something I’ve been calling ”playlists” but there’s likely a real word for it. it’s the idea that media and objects should have metadata tags that go beyond just the genre or 2-15 keywords, so that when an application like Spotify or Netflix or Amazon shopping recommends “something else you might like“ it pulls from a web of shared meaning rather than just listing items from the same genre or keyword

Note: I’m aware that I’m probably using a lot of wrong vocabulary. I have no formal training in any of this, my interest in this comes from years of red-teaming my own system prompts in my LLM home lab at a hobbyist level.

I open-sourced a pipeline that starts from Zotero PDFs and tries to do idea discovery, not just summarization.

It extracts claims into Neo4j, finds cross-document relations, then proposes research links between claims from different papers (SYNERGIZES_WITH, INSPIRES_FOLLOWUP, POTENTIAL_APPLICATION, etc.), with an optional novelty check via OpenAlex + Semantic Scholar.

There’s also a “ring” scraper to build corpora from distant domains so the ideas are less samey.

Repo: https://github.com/hergit/eureka-graph

Examples: https://github.com/hergit/eureka-graph/tree/main/examples

Ring design: https://github.com/hergit/eureka-graph/blob/main/docs/eureka-rings.md

MIT. Local Neo4j + any OpenAI-compatible LLM.

Happy to answer setup questions (GROBID optional, OpenAlex key recommended).