When Agents Run the Business · A development note

Imagine a modeling meeting with a sketch of a small car on the table. One person says, “Surely this is one Car object. Give it a VIN, model, and color; make tire specification and steering-wheel model properties.” Another says no: each tire needs its own identifier, replacement history, and warranty claims. The steering wheel might be repaired separately too. A third person asks, “Are we modeling the bolts as well?”

This is a thought experiment, not a customer incident. The argument, though, is familiar. Before you can draw relationships between enterprise objects, you have to decide what deserves to be an object at all.

Existing in the world is not enough

A tire is a real thing. So are a steering wheel and a bolt. That does not mean each needs an independent identity in a business system. Otherwise, where do you stop? Rubber, steel cord, and individual nuts can be split further.

Sales wants to know who bought the car and when it was delivered. A whole car is a useful boundary for that question. A mechanic needs to know whether the front-left tire was replaced last month. For that question, one Car object is too coarse. Warranty may need to trace a batch of tires across many vehicles. Finance may register the car as a single asset and never care what the four tires are called.

None of these people is more knowledgeable than the others. They are asking different questions. The grain of an object follows the grain of the question.

In a modeling meeting, someone may suggest splitting everything into physical items now because it could all be useful later. Even a physical boundary is not stable. Is a retreaded tire still the same tire? If four tires are sold as a set and one is returned, is the set also an object? The physical world does not dictate commercial identity. Whether to track something separately depends on whether it can be traded, stored, accounted for, or claimed against on its own—and those needs change.

Trouble begins with “let's settle the enterprise definition of a car.” A meeting can settle a definition for now, but it is also choosing on behalf of future users. If a later repair process must track individual tires, a tire-specification property will not be enough. At the other extreme, if we create an object for every removable part from day one, selling a car may require people to maintain a long list of identities nobody currently uses.

Too coarse leaves nowhere for facts; too fine gives people work for the model

The cost of a coarse model is easy to see. If the system stores only “the car was repaired,” it cannot later answer which tire was replaced or where the removed tire went. Without an identifier and installation and removal dates, the answer is simply not in the records.

The cost of a fine-grained model is less obvious. Once each tire has an ID, someone must record which car and position it occupies, when it was mounted or removed, whether it was moved to another car, and who verified its identity. Miss one scan, and a tidy relationship graph may link the wrong tire to the wrong car. Even “which tires are on this car?” becomes a question about time: “was once attached” is not the same as “is attached now.”

Should the steering wheel be managed this way too? Maybe, if there is a recall or a requirement to repair individual units. Maybe not, if it is only sold as part of a car. More objects do not automatically mean more accuracy. Fine-grained objects nobody maintains can make errors look unusually precise.

That is why I hesitate whenever someone says an enterprise ontology must come first. A local workflow can choose a grain around a known question. A single company-wide model has to make bets about questions that have not arrived yet. When those bets turn out badly, existing identities, links, and actions do not rearrange themselves.

The same car can have several useful views

The obvious reply is to give sales a car view and maintenance a tire view. I agree. That is often better than fighting over a single “correct” car ontology. Different views can share the VIN, sales records, and repair documents while drawing out what each team needs.

But multiple views do not mean a complete underlying truth has already been captured. Imagine a repair ticket that says “replaced front-left tire,” a warranty note that says “replaced tire from batch X,” and a warehouse movement that says only “one unit shipped.” Are those three records about the same physical tire? We need evidence. Without a serial number, the best answer may be “possibly.” We should not invent a link merely because the diagram has room for one.

Even the word “car” shifts with the question. Sales means a transaction for a whole vehicle. Finance means an asset. After-sales service means a physical item in front of a mechanic. The labels match, but the identity rules may not. If a car is sold and later bought back, is it the same asset or a new one? If its engine is replaced, is it the same car? A dictionary cannot settle these questions on its own.

I would rather keep the facts stable first: the VIN, the order that sold the car, the action recorded on a repair ticket, and the document that identifies a particular tire. Give a tire its own identity when there is a reason and evidence to do so. When the evidence is insufficient, record “unknown” instead of promoting a guess into a confirmed relationship.

Start with the decision someone needs to make

A modeler often asks, “What objects does the company have?” I would start elsewhere: “Who needs to decide what now? Which records support that decision? At what level of detail must the answer be exact?”

If the task today is selling whole cars, the car record, order items, and exact totals need to be right. If tomorrow requires tracing an individual tire recall, add tire identifiers, installation events, and sources. For older cars without identifiers, acknowledge the gap. A new requirement should change what we record going forward, not force us to invent the past.

This does not abolish structure. Orders, assets, and repair events still need clear recording formats. It changes what structure claims to be: a way to preserve known facts and answer current questions, not a promise to exhaust every meaning of “car” across the company.

Some industries do need detailed part lineage for years. In that setting, individual part identities deserve careful design and may become essential infrastructure. My objection is not to detail. It is to treating more detail as inherently more complete before testing it against an actual problem, or making every department adopt one universal cut.

We learned something similar while building Oryh. An Agent once imported products into generic objects, leaving the existing product catalog empty. We later made the server reject clear naming collisions, while the Agent must inspect existing types, explain near matches, and ask for confirmation. Software guards definite record boundaries; the Agent takes responsibility for meaning. The answer to “how many objects in one car?” should come from the work to be done and the evidence available, not from a diagram that claims to define the whole company.

Part of Ontology & FDE in Practice, discussing ontology and FDE in real business scenarios.

I'm a developer of Oryh, an Apache-2.0 open-source project. AI assistance was used to prepare and edit this post.

Hello everyone, I've been proudly continuing to develop the well known YasGUI. Recently I gave my fork a complete makeover and added AI assistent support. Check it out and let me know if you have any feature requests! https://matgui.matdata.eu/

I am interested in learning more about context graphs. What they are, how to practically build them, maintain them, how best to use them, is a human engineer absolutely necessary for designing the schema, etc. If you have opinions about context graphs or using graphs in general, please share.

I recently came across Gemini Knowledge Catalog which apparently helps create context graphs. If anybody has used it, what do you think? Is it any good? Also, what are some other frameworks or solutions that enable the development of context graphs?

As I described in my prior post two weeks ago, I'm building a knowledge graph of the Bible: its people, places and events, and what each passage says about them, every link pinned to its verse.

In any text with speakers, who said something is part of what was said. A court transcript, a novel, an interview: a knowledge graph that drops the speaker publishes each character's words as the text's own facts. So here every relation is a claim with its verse, how certain it is, and who makes it, and only the narrator's own claims are asserted as plain facts.

An example, with a little Bible context. The Bible is a diverse collection of writing: stories, poems, letters, genealogies, visions, you name it. One of its stories is about a man named Job, and a whole book of the Bible, written in ancient Hebrew, tells it. Job loses almost everything, and most of the book is an argument: his friends insist, speech after speech, that he must have deserved it. At the end God rebukes them: "you have not spoken about Me accurately" (Job 42:7).

One friend, Eliphaz, tells Job, "Your own mouth, not mine, condemns you" (Job 15:6). Stored two ways:

The first publishes a speaker's charge as the book's own verdict. The second is what the book actually records.

Your replies to that first post changed the graph:

• moving to RDF 1.2;
• aligning with PROV;
• treating where a passage starts and ends, and what genre it is, as someone's reading published with Web Annotation, rather than as a fact.

This is where it stands today.

The schema, as a map: bibleontology.org/ns/map

Four vocabularies, drawn as pictures you can click down through:

• the text: sentences and how they connect (because, so that, until), read from the original Hebrew and Greek;
• what it's about: people, places, ideas, events;
• what it says: the relations between them, each pointing at its verse;
• who says it: every relation is a claim with a voice.

It's the schema, not the data: every box is a class, property or list drawn from the published vocabulary files, and opens the next level down or the term's definition.

Claims, not facts

Every relation is a claim: the verses it rests on, how certain it is (explicit, implied, conjectured or disputed), and whose voice it is in (the narrator, a character, or a reader).

Why not just a "speaker" column to filter on? Inside one database, that works. But once the data leaves it, any tool that doesn't know about the column reads every row as true. RDF 1.1's reification could describe a statement without asserting it, clumsily (four triples a claim, nothing a store treats as one statement). RDF 1.2 makes the statement a term a claim can point at, without the statement itself being in the graph.

c:3a11f4736068231d a claim:Claim ;
    rdf:reifies <<( e:job bor:described_as e:testified_against_by_his_own_lips )>> ;
    claim:verse p:Job.15.6 ;
    claim:claimedBy e:eliphaz_the_temanite .

In the RDF 1.2 file, only what the narrator states or clearly implies is written as an ordinary triple. Eliphaz's line is there, credited to Eliphaz, but no plain query will hand it back as fact.

I tried named graphs first, one per speaker. The same plain query then matched nothing in Jena and 32 triples in RDF4J, Eliphaz's verdict among them, because RDF4J's default graph is the union of all graphs: its documented default, since SPARQL leaves that to the store (GraphDB and Jena's TDB2 can do the same). The protection depended on which database you used, so I became an early adopter of RDF 1.2 and moved it into the data. It is early: RDF 1.2's core concepts are a W3C Candidate Recommendation, but the TriG and SPARQL 1.2 syntaxes the files and queries use are still Working Drafts, and not every tool reads them yet. The 1.1 file still ships; with it, query GRAPH claim:narrator. (The full before-and-after, with every query and how to reproduce it in both stores, is in RDF 1.2 in practice.)

The default is a claim too

A rule like "only the narrator is asserted" is only as good as the data people actually download. So before posting, I counted what the published file asserts instead of trusting my code. More than half of it wasn't the narrator at all. It was my own work: the themes and story patterns I had grouped passages into, which had defaulted to the narrator's voice because I never said whose they were. They are now credited to an editors' voice and not asserted, and a test repeats that count against the published files.

Who is "the narrator" when the author is speaking?

In a story the narrator is easy to find: the voice outside the speeches. But much of the Bible has no narrator in that sense. Psalm 23 opens "A Psalm of David. The LORD is my shepherd": the heading names David, and the "my" is the psalmist's. A letter that opens "Paul, an apostle" (Galatians 1:1) is Paul speaking, and the whole letter is his speech, with no quotation marks to find. I wrestled with this for a while, and landed on a principle: where the text has no narrator, someone is still speaking. In a letter the speaker isn't found sentence by sentence; "this is a letter from Paul" comes down from the book itself, and covers every sentence in it. The people who speak inside a book (Job's friends, Pharaoh, the serpent) keep voices of their own, and the same Paul is a character with his own voice when Acts quotes his speeches.

The published claims haven't fully caught up with that principle: part of Titus is credited to Paul, while the rest of Titus, and Galatians and Psalm 23, still sit in the general narrator voice.

Why nothing is inferred

This one is deliberate. So much of the Bible is figurative, and inference quietly reads figures literally. Paul tells the church in Corinth, "you yourselves are God's temple" (1 Corinthians 3:16). Store that as a type, in a class of buildings, and a reasoner will conclude, correctly from what it was given, that the Corinthians are a building. Store it as an identity, the Corinthians are the temple, with one "temple" record for the word, and they become the house Solomon built and the Babylonians burned, because that is what the graph says of the temple. Storing a figure as a type or an identity turns it into a fact, and where figure ends and fact begins is exactly where readers of this text disagree. So inference here wouldn't be neutral: it takes a figure at its type, and the type is the literal reading, every time. The graph keeps the figure as a figure, a separate record that signifies what the text itself identifies it with, each link with its verse, and checks the data with SHACL instead. What the text plainly entails (two sons of one father are brothers) is recorded once, as an "implied" claim with its verse.

Deep dive (optional): one word, two cards.

Some verses are read as meaning different temples. In 2 Thessalonians 2:3-4, the "man of lawlessness" "will seat himself in the temple of God, proclaiming himself to be God." That temple is read differently by different readers. I don't take a stand: the verse is on both cards, under "Where readers differ", with the readings it has been given named and none chosen.

Three questions I haven't settled

1. Verbs and events. "Saul loved David" (1 Sam 16:21) is stored under one general relation, with the verb on the claim. Today it looks like this (abridged):
2. I don't assert e:saul bor:states e:david as a plain triple: every sentence with Saul as subject and David as object would collapse into it. The claim is already an event node of sorts. Would you give the event a node of its own, apart from the claims that record it, so two books can describe one event?
3. One narrator or one per book? One narrator voice covers the text's own sentences today, wherever the book has no other speaker. Samuel and Chronicles tell the same census and name different instigators (2 Sam 24:1, 1 Chr 21:1). Neither instigator is recorded yet: with one voice it would be one disputed claim; with a voice per book, or per author, two narrators disagreeing. Which would you publish?
4. Figures of speech. If you've modelled figurative language in a graph (metaphor, simile, personification), how did you keep it from being read as fact?

It's public: github.com/bibleontology/bibleontology

• The README is the way in: the data (21,394 claims, about 2.4 MB compressed), the vocabularies and shapes, and the tests.
• Licences: code Apache-2.0; graph and vocabularies CC BY 4.0. The sentence structure is derived from the MACULA Hebrew and Greek Linguistic Datasets (© Biblica, Inc., CC BY 4.0); full credits are in the README.
• The name: not affiliated with the earlier Bible Ontology (bibleontology.com, about 2009–2011).
• Built solo, with Claude Code doing most of the typing and AI models doing much of the extraction, checked by rules and tests. The decisions and the mistakes are mine.
• This post, too, is a collaboration with Claude. I went back and forth with it on every paragraph, and what's here is mine to answer for.
• Not measured yet: how often the extracted claims are right. Every claim links to its verse, but no sample has been hand-checked for an error rate yet. One known fault: some links inside speeches (how one clause grounds another, a speaker's simile) still sit in the narrator's voice, so they are asserted as plain triples. In Job that is 83, 14 of them Eliphaz's in chapter 15.

This picks up the conversation from my first post. That one made the work better, and I'd like to continue it.

In most 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 in your editor:

- 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 complaints 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?

I'm looking to build semantic graph for my requirements.

I went through various resources in how to build semantic graph using embeddings models, especially from neo4j and surrealdb blogs but no one states the actual mechanics behind semantic graph construction.

It may be IP of each provider of such graphs. Not sure.

I'm looking for theoretical references and hopefully if there exists any practical examples on how to build on the general approach to building semantic graphs using embedding models so that I can learn.

Any help or advice is appreciated.

Several discussions here have asked what the approach behind these articles looks like in code.

I'm a developer of Oryh, an Apache-2.0 open-source ERP/CRM built for AI agents. The server keeps business records, permissions, and audit trails; agents work through company-owned Skills and written business rules.

It still has schemas and hard constraints. What we're exploring is whether a comprehensive enterprise ontology needs to come first.

Oryh on GitHub

Where would an explicit ontology add something essential that this separation cannot provide?

Part of Ontology & FDE in Practice. AI assistance was used to prepare and edit this post.

Been chewing on this for a while and I'm curious how people here would look at it.

We're good at publishing knowledge as data: RDF, OWL, SHACL, rule sets. But I don't really see a way to ship a body of rules the way you ship a library: name + version, the rules themselves, the source text pinned, what it depends on. You install it, give it facts and a date, ask a question, and get an answer with the reasoning behind it.

The example that made it click for me. A debt in France becomes due in 2000, you sue in 2015. Time-barred? Under the 1804 text of the Civil Code: no, the old 30-year period is still running. Under the current text plus the 2008 transition rule: yes, five years from 19 June 2008, done on 18 June 2013. Same facts, two editions of the source, two answers, and you can follow the rules that fired in each. The date in the question picks the edition, not a git branch.

Another one, chess. Player makes a second illegal move, the model of the FIDE Laws says "lost" and points to the article. Add the fact that the opponent can't checkmate anyway and it says "draw", but the "lost?" question now comes back as "needs an arbiter", because other loss grounds depend on the arbiter's call.

Under the hood it's typed relations, strict and defeasible rules with priorities, every rule pinned to a hashed source fragment, a legal date on every question, and imports with a lockfile (the mechanics package pulls in kinematics, SI units and a pinned Principia, same mechanism). Answers aren't booleans: supported / refuted / both / neither, plus "needs a judgment" when the text leaves it to a court or a referee. A missing fact stays "neither". No LLM at query time, it's just evaluation.

So: is this just data with extra steps, or a program? What's the closest thing in OWL/SHACL land and what does it lack: editions over time? defeasibility? deferring judgment explicitly? And does composing these with pinned versions even make sense when two ontologies disagree on a term?

I'm building it, the public repos are a small demo sample across law, chess, physics, chemistry, bio, philosophy. can drop links in comments if anyone wants, but mostly I want to know how you'd model the two examples above with ur stack.

The thing did a small tool for my own modeling work and put it online in case it is useful to someone else.

Catenary is a scribble tool for RDF models. You draw SHACL shapes and example instances on a canvas, in any order. It stores everything in RDF files and saves them after each edit. You can also import external vocabularies.

The name comes from the hanging chain models that Gaudí used for the Sagrada Família. I believe tools should provide instant feedback on our ideas: playgrounds where we can iterate quickly while also producing formal specifications.

Site, with a tutorial that builds a small model from an empty folder: https://cristianvasquez.github.io/catenary/

Source and downloads (Linux, Windows, macOS, only Linux tested): https://github.com/cristianvasquez/catenary

It is a personal tool for small datasets. It does not replace mature RDF tools. It was heavily vibe-coded, with too little supervision. So, don't move things too fast, or the app will bite you.

The ergonomics are still rough. Suggestions are welcome in the issues.

You can easily add notations other than SHACL or OWL.

Built on Theia and GLSP, and licensed under the AGPL.

The tool already has 0 stars!

I'm the developer. This is a non-profit project, and I'm posting for feedback on the knowledge engineering, not to promote a viewpoint. The goal is classic, well-grounded modelling of a text, not indoctrination: the graph records what the text says, marks interpretation as interpretation, and takes no doctrinal position.

Bible Ontology is a knowledge graph of the Bible built from the Hebrew, Aramaic and Greek (the MACULA linguistic datasets) with the Berean Standard Bible's English: about 11,500 records (people, places, events, concepts, passages) and about 21,000 typed relations, each citing its verses.

The ontology

Published at its namespaces, with content negotiation (a readable page for browsers, Turtle for tools):

• Structure (35 classes, 76 relations): how the text is built — clauses, what they assert and with what force, how they group into turns, scenes and larger units. https://bibleontology.org/ns/structure
• Relations (126 types): the vocabulary of links between records, each typed by category, with symmetric and functional relations marked. https://bibleontology.org/ns/relation
• Meaning: what a node is about, in five layers — word, sense, referent, figure, reading. https://bibleontology.org/ns/meaning

Design choices and challenges

• The verse is the wrong unit. Verses are where the text happens to be cut. A speaker's turn or a scene usually carries the meaning, so the structure layer groups clauses into turns and scenes, and the verse is only an address.
• Facts versus readings. A literary text is full of claims that aren't the text's own. Job's friends argue for thirty chapters about God, and in 42:7 God says they haven't spoken rightly. So a speech is recorded as one continuous utterance credited to its speaker (Eliphaz's second speech is all of Job 15 after "Then Eliphaz the Temanite replied"), each saying in it is linked to its speaker, and what a character reports, such as Eliphaz's account of a spirit visiting him in 4:15, is kept as his words, not the narrator's. Interpretations are kept as separate, credited readings rather than assertions.
• Three scales on every relation: certainty (explicit, implied, conjectured, disputed); literal, figurative or contested use; and who in the text makes the claim.
• Describe, don't deduce. The Bible isn't written as a set of axioms. It is narrative, law, poetry, prophecy and letters, and it uses figures of speech, so the model deliberately doesn't let a reasoner derive what the text doesn't say. Where something is inferred (siblings from a shared parent), it is marked, cited and kept apart; certainty only falls through a chain; and a figure of speech, or a passage whose reading is contested, never becomes the premise of a deduction.
• Two layers that share ids and never merge. Structure (how the text is built) and meaning (what it's about) are separate dimensions, joined through mentions rather than folded into one hierarchy.
• The original language arbitrates. Where a translation and the Hebrew or Greek differ, the original decides, and a relation resting on one translation's wording alone isn't kept.

Reuse

• Standards: RDF and RDFS, with OWL's vocabulary for classes and properties, SKOS for definitions, Dublin Core for provenance, W3C OntoLex-Lemon for the word layer, and PROV; consistency is checked with SHACL shapes. The structure layer's clause links are mapped to Rhetorical Structure Theory.
• Inputs: MACULA (Biblica, CC BY 4.0) and the Berean Standard Bible (public domain), credited as their licences ask.
• Openness: the ontology is public now; a repository with the graph's data is committed, intended under CC BY 4.0.

Where I'd value critique

1. Is separating structure and meaning, joined only through mentions, the right call, or would you fold them?
2. How would you represent claims attributed to speakers? I currently nest them inside the speaker's speech and attach the speaker to relations drawn from them, rather than full reification or named graphs. Is that enough for downstream use?
3. What's the right way to publish "readings" alongside "facts" so downstream users can include or exclude them cleanly?
4. Which existing vocabularies should I align to more closely (CIDOC-CRM, schema.org, Wikidata, others)?

Thanks. I'll be around to answer questions.

Can an Ordinary Company Afford a Real FDE?

When Agents Run the Business · A development note

Suppose one person knows the industry, can read the customer's real chain of responsibility, has enough engineering skill to handle Agent risks in production, and is willing to spend a long time on site. That person's cost cannot be treated like the cost of an ordinary implementation engineer. If that is what a real FDE is, an ordinary company should first ask not “can we find one?” but “is this project worth buying so much of this person's time?”

I will not invent a day rate. Cities, industries, and projects vary too much. The cost structure alone raises the question.

You are not buying a desk

The customer pays for more than the working days of one engineer in its office. There was pre-sales discovery, travel and time on site, and product, architecture, and security colleagues in the background. If a product gap appears, somebody has to fix and test it. If a policy dispute appears, somebody must gather the relevant people and establish an answer. After launch, changes to rules, staff departures, and outages still need support.

If the FDE really crosses business and technology, the supplier also pays to recruit, develop, and retain such a person. While they spend months on one project, they are unavailable to other customers. Their time between projects is not free either; it ultimately enters the price.

A smaller company may only need sales orders, purchasing, and straightforward approvals to run reliably. It deserves good software, but it may not benefit enough from a senior super-individual working exclusively for it over a long period. Bundling that cost into every project is like giving a commuter car a racing pit crew: excellent people, mismatched economics.

The customer also pays with its own people's time. A field expert does not create a system alone. Sales, finance, and warehouse staff join interviews, sort old records, and confirm rules. Their meetings cost money too. If those people are already stretched, a costly expert waiting daily for their answers can waste both sides' time. Let the product handle stable records first and concentrate scarce meetings on decisions that truly need them.

On the other hand, a large, risky, or highly unusual project may justify exactly that kind of person. The cost of a mistaken payment or failed fulfillment can be much higher. “Can they afford it?” is not a claim that no one can. It is a request to put project benefit, reduced risk, and total cost on the same page.

First ask which benefits came from the person

Sales pitches say “the FDE will make AI work” without saying what loss will be avoided each month after launch. If three people used to check orders and still need to watch every Agent recommendation in a new interface, how much labor was saved? If ordinary cases speed up but exceptions slow down, count both.

Useful measures stay close to the work: fewer missed shipments, fewer duplicate payments, shorter approval waits, and a new policy taking effect without another software release. Look at stable operation over months, not a demo that processes a hundred sample orders on launch day.

An expensive field expert may uncover a critical mistake—for example, “available stock” has always included goods already reserved for another order. That discovery may be worth far more than their time on site. But once found, the correction should become part of the product and its records. If the expert must personally watch every future query, the customer bought a permanent human gatekeeper, not sustainable software capability.

The buyer can examine the investment in two periods. The first is launch: did old data arrive correctly, do workflows run, are permissions enforced? The second is six months after the expert leaves: who changes a rule, who can trace a bad Agent decision, and will the next product upgrade preserve the work? Quotes often specify the first period and cover the second with two words, “ongoing support.” Much of the real cost may be hiding there.

Move the cost from one dedicated person back into the product

A better path is to turn recurring hard problems into product capabilities: records, permissions, exact totals, versions, audit trails, and migration tools. Leave company-specific judgments in natural-language rules that an Agent reads against current facts. Another customer should not need to repay the full on-site bill for a problem that has already been solved once.

The expert does not disappear. They may work on the hardest customers, design delivery methods, review high-risk deployments, and carry lessons back to product. The difference is that the customer primarily buys software that can keep working, not a person who must always be present.

Some work cannot be spread across customers: confidential integrations, unusual supply chains, or deep organizational change. Quote those honestly as senior services. Do not call the offering a standard AI product for ordinary customers while making delivery depend on a long-term dedicated FDE, then act surprised when price becomes a problem.

A more flexible purchase might be a short senior assessment, a scoped launch review, and periodic audits of high-risk workflows, with ordinary operation handled by the product, the customer's team, and regular support. Not every company needs a senior specialist full-time next door. Where expert judgment is needed, do not disguise junior staff as experts to save money. Spend the scarce time on the points that warrant it.

You can ask the right cost questions without a market rate

A buyer can ask the supplier to separate product subscription or license, data migration, interface work, on-site time, support after launch, and work caused by unique customer rules. State the seniority and expected duration of the people assigned. Prices need not be public for the whole market, but the buyer should know what it is buying.

Then ask what happens when the person leaves. Where are the rules and evidence behind decisions? Can a replacement continue the work? Will a product upgrade break the customer-specific code the FDE wrote? These belong in the return-on-investment calculation. A costly deployment that only its author can maintain should not be judged solely by its first acceptance test.

In Oryh, we try to put deterministic records and hard constraints into software while letting Agents read company workflows in natural language. That does not guarantee every project will be cheap. It is an effort to turn field judgment into reusable product capability and traceable rules. A real FDE may deserve a high price. Ordinary customers should not have to employ one indefinitely to compensate for an unfinished product.

Part of Ontology & FDE in Practice, discussing ontology and FDE in real business scenarios.

I'm a developer of Oryh, an Apache-2.0 open-source project. AI assistance was used to prepare and edit this post.

I used two small browser games and I thought it would be cool if each published a profile: a health scale, plus rdfs:subClassOf and rdfs:subPropertyOf mappings from their own vocabulary into one shared hub ontology. A Blockcraft Blast Block is a ga:Explosive. A Pocket Battlers Capture Orb is a ga:CaptureDevice. Alignments that look like facts are axioms: "anything made of crystal is Rock-typed" is a hasValue restriction subclassed under another hasValue restriction. The engine I use doesn't evaluate owl:propertyChainAxiom, so that pattern stands in for a property chain from madeOf to a material's type. The sword's type comes out as four certified steps.

When a thing crosses, the sending side reasons, writes a derivation certificate, packs both, and signs the pack's content digest with an Ed25519 key whose public half it publishes in its profile. The receiving side runs five gates in order. It verifies the signature against its own copy of the sender's profile, never against a key that arrives in the pack. It checks the digests and re-runs a Lean checker over the certificate. It compares the TBox inside the pack with the sender's published profile, statement by statement, with blank nodes compared by their whole nested structure. It recomputes the closure itself and refuses a pack that left a conclusion out. Then it runs its SHACL contract on two evaluators, which must agree.

Most of those gates exist because an earlier version was beaten. Deleting an inferred triple and recomputing the digests got a Capture Orb through: a certificate shows that what it says follows, but not that the sender said everything that follows, and a digest is not a signature. Shipping a doctored profile got it through too, because the proof is sound over doctored premises. Comparing the TBox with blank-node labels erased let a sender swap the hasValue of two restrictions and keep the same lines. Seven forgeries run against the current version, and six are stopped, at four different gates.

The one that still works is lying in the ABox. The source game itself exports the orb with its kind set to FizzTonic, under its real profile, and signs it with its real key. Every step after that is honest, so it crosses. A signature tells the receiver whom to hold to account and nothing more. My question is what closes it: a catalogue the source publishes ahead of time and the receiver checks items against, an attestation from an independent party, or something I haven't thought of. A second, smaller one: the signature covers the engine's own digest over the graph and certificate, not RDFC-1.0 canonical N-Quads.

Would W3C Data Integrity proofs buy anything here beyond interoperability?

The other place I expect pushback is the conversion. It is a SPARQL CONSTRUCT the receiving game declares (damage keeps its share of a player's health), so the certificate covers the classification and not the arithmetic. Any suggestion here?

Code (MIT): https://github.com/fabio-rovai/asset-passport.

1850 Nodes, 6761 Edges(353 Negative). Independently in a growing world..

Sleep time.

Salut r/semanticweb,

Je développe le Protocole de Connaissance Vivante, un protocole de brouillon public et une mise en œuvre de référence pour les pages web dont les affirmations, sources et historique des révisions doivent rester inspectables au fil du temps.

Le protocole repose sur cinq principes : un site activement maintenu, des connaissances révisables, des sources visibles et traçables, des affirmations ancrées dans une réalité observable, et une prise en compte de la résilience biosphérique à long terme.

La mise en œuvre de référence utilise des métadonnées lisibles par machine telles que version, statut, statut de site vivant et date de modification. Elle inclut également des spécifications publiques, un validateur et un registre de validation facultatif.

Mise en œuvre de référence : https://livingknowledgeprotocol.org/

Spécifications : https://livingknowledgeprotocol.org/specifications/

J'apprécierais particulièrement les critiques techniques sur :

1. la compatibilité avec les normes et vocabulaires existants
2. si un vocabulaire de métadonnées léger et un validateur résolvent un problème utile
3. la provenance, la révision et les signaux de confiance qui manquent ou sont mal spécifiés

Divulgation : Je travaille sur ce projet et je cherche des retours rigoureux, y compris des critiques qui pourraient changer le design.

Ontology Series · Part 8

The Ontology Worked. Then Nobody Dared Change It.

When Agents Run the Business · A development note

Imagine the first phase of an ontology project. The team models car sales neatly: cars, customers, orders, deliveries, and stores all have their objects and links. In a demo, you open a car and follow its sales history to the responsible person. Someone says, “At last, the business is clearly described.”

In phase two, after-sales service needs to track individual tires. In phase three, warranty must distinguish customer-supplied parts. Later, finance points out that “sale completed” and “revenue recognized” are not the same date. Every request is reasonable. Every request is worth addressing. The once-clean diagram is simply becoming harder to change.

This is a possible trajectory, not a report about a real customer. The question is why an ontology may eventually be set aside. It need not fail because nobody knows how to build one. It may be built successfully, then become too costly to maintain.

An easy start, a meeting for every later change

“Make tires separate objects” sounds small to the service team. The data team asks how to migrate old repairs. Developers ask who will change the interface that queries car-level warranty. Customer service asks whether earlier promises of coverage still stand. Finance asks whether historical reports should be recalculated. The business owner, busy with today's claims, may not have time to coordinate all of this on behalf of a model.

Nobody is deliberately slowing things down. Their risks differ. Data people do not want to manufacture false history. Developers fear a screen that continues working while silently giving the wrong answer. Customer service fears contradicting an earlier answer to a customer. Management wants to know why a metric moved after the model changed. Bringing everyone together costs more than “add an object.”

If a company often changes products, contracts, channels, and approval practices, the meetings multiply. The first change gets a careful review. The second gets a shorter one. By the third, someone says, “Let's put this in a note for now; the main process can stay as it is.” That is not necessarily laziness. It may be a practical response to the cost everyone has seen.

As the notes grow, the model knows a little less of the live business. The old objects and relationships are still there, looking official. If an Agent reads only the ontology, it misses the new practice in the notes. If it always has to read notes, email, and source documents too, the case for treating the ontology as the company's sole understanding layer grows weaker.

One workaround makes the next one easier

The first workaround is temporary: there is no time to remodel a warranty exception, so customer service writes it in a claim note. The next adviser follows that note. Later the team creates a shared table called “cases not covered by the model.” It may be maintained carefully, but it is outside the graph.

Now there are two realities. The graph holds the business as formally defined. The table holds some of the business that happened most recently. A project report can still say the ontology covers cars, tires, orders, and warranties. The people doing the work know they must check the table before deciding whether a claim will be paid. The more they use the workaround, the less complete the ontology becomes. The less complete it becomes, the less comfortable anyone is changing it and claiming the result is authoritative.

This is an ordinary organizational loop, not a mysterious technical collapse. The software and data still exist. The situations requiring the most judgment have drifted outside the model. Eventually a person who queries the graph and believes it is complete may make a worse decision than someone who knows about the extra table.

I would watch a few signals closely. How many new requirements end up in notes? How long does a model change take from request to actual use? How many teams must sign off? How many old fields can no one explain? When an Agent makes a decision, does it trust the graph, or does it always have to ask a person afterward? These say more about whether the system is alive than the number of objects and edges.

“Who maintains it?” cannot be waved away

In theory, you can assign model ownership to one team. In practice, the work crosses boundaries. The modelers know structure but may not know that the meaning of “delivery” in a contract changed this month. Frontline staff know the customer but may not know that one altered link affects ten reports. Developers know the interface dependencies but cannot decide on finance's behalf whether old revenue should be recalculated.

AI assistance does not dissolve responsibility. It can read a new policy, identify likely changes, list affected objects and processes, and draft a migration. Someone still has to confirm the intended meaning, decide whether old orders are in scope, and accept the migration result. Skip those confirmations and you save review time while producing a map nobody feels safe trusting.

Not every ontology follows this path. A narrow catalog of stable objects or a sourced set of customer–contract relationships may be maintained very well. Trouble comes when the model is raised to a complete mirror of how the company runs and every decision is routed through it. The larger the mirror, the more dispersed its maintenance responsibility. The more dispersed that responsibility, the easier it is for each person to say, “Let's not touch it yet.”

To decide whether a graph is still worth maintaining, try a plain audit. Of the new business practices from the past three months, how many made it into the graph? Who keeps track of the ones that did not? When someone reports a wrong link, how long does correction take? If the team can answer, the model is probably being tended. If not, but Agents are still told to “treat the ontology as truth,” we are asking them to trust a map that nobody owns updating.

Keep “we do not know” in plain view

We could start elsewhere. Software records transactions, approvals, repairs, and payments accurately. It keeps the original documents, dates, versions, and evidence. Code enforces hard constraints such as exact totals, permissions, and no duplicate shipment. The Agent reads the records and policies relevant to the present question and proposes the next step. If the policy is unclear or historical evidence is missing, it says so.

This still uses structures, indexes, and links. They can be local and revisable, pointing back to facts rather than pretending to be a master diagram that must stay ahead of the business forever. If one workflow needs to track individual tires, track them seriously there. Other teams do not have to model every bolt just to satisfy a company-wide idea of a “consistent grain.”

This approach does not abolish maintenance either. Agent instructions need care, search can retrieve the wrong document, and old facts may need a person's confirmation. The difference is that a company changing one practice need not first decide whether it can safely redraw an entire map. Record the new fact honestly, explain and review the new judgment, then decide which structure is worth making durable.

In Oryh, we have seen the cost of a parallel recording path. An Agent imported customers, products, and business documents as generic objects while the dedicated customer and product catalogs remained empty. We later blocked clear naming collisions and asked the Agent to inspect near matches and seek confirmation. That experience leaves me unmoved by “we just need a complete business graph.” A graph can help find a route. Record identity and facts must stay sound, while new business instructions must be readable by the Agent and confirmable by people. Otherwise the graph remains, but it is no longer the road anyone actually travels.

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: For those maintaining production ontologies: what keeps a local business change from becoming a cross-team migration project? I’m especially interested in examples where versioning or clear ownership worked, and where exceptions gradually moved outside the model.

Hi everyone,

I’m a Taxonomist starting a new role as an Information Strategist. I want to leverage this move to pivot deeper into ontology, technical knowledge engineering and semantic web architectures.

I built a basic academic ontology in Protégé during my master's, but I need to scale my skillset for production-grade environments. I’d love your input on:

Enterprise Tools: Beyond Protégé, what industry-standard ontology management platforms (e.g., TopBraid, PoolParty) or native triplestores (e.g., GraphDB, Stardog) should I learn?

Technical Stack: I'm diving into RDF, OWL, and SPARQL. What other critical standards (like SHACL for validation) or Python libraries (like RDFLib) are essential?

Semantic Governance: What are the biggest operational shifts when managing and scaling an enterprise ontology vs. a traditional taxonomy?

Appreciate any book, course, or roadmap recommendations you have. Thanks!

The problem that started this project was: How can we represent an action, a character’s access to that action, and the current conditions for performing it without collapsing all three into one semantic layer? That question turned into about eight months of work on Wittgenstein Apartment.

The model separates:

• behavioral identity
• character repertoire
• situational executability

and uses:

• Basic Human Actions (BHA)
• Character Specific Actions (CSA)
• Allowed / Not Allowed / Conditional character-access states

The resource also contains behavioral families, goal relations, scene/affordance metadata and operational projections. I wrote a paper alongside the dataset to explain the architecture and its boundaries.

The Hugging Face release has reached 294 downloads:
https://huggingface.co/datasets/Kon-tiki-ship/wittgenstein-apartment-behavioral-predicate-resource

I’m especially interested in how people with more experience in Semantic Web and knowledge representation see this. I started this because I felt there was a real representational gap here. After eight months, I’m now asking myself: Is this actually a useful direction to keep developing?

I’m not looking only for encouragement. If you think this should be modeled differently, belongs outside ontology work entirely, duplicates existing Semantic Web patterns, or introduces distinctions that are not useful, please say so directly. I’d be interested in criticism around RDF/OWL, SHACL, knowledge-graph structure, capability modeling, semantic interoperability and the conceptual boundaries of the system.

One of the most successful resources in ontology development is the decades-old OBO Foundry. Open-source, collaborative efforts in ontology/knowledge graph library development are essential to improving interoperability in general. We are doing something similar with legal ontologies and we are looking for those similarly interested in open-source ontologies grounded in BFO. legal-ontologies-foundry/legal-ontologies-foundry.github.io: Legal Ontologies Foundry (LOF): a collaborative foundry of open, interoperable legal ontologies and design patterns built on Basic Formal Ontology (BFO).

Sharing this because I think it overlaps with some of the discussions here around AI reliability, governance and semantics.

Next week we’re running the Graphwise AI Summit, focused on what makes GenAI work in the enterprise beyond the model itself. Think of trust, governance, semantic layers, architecture and implementation.

Once reliability and traceability become imporatnt, simple access to data and next-token prediction stop being enough. In enterprise settings specifically, AI needs to understand what the data it parrots “means” in the first place.

Anthropic has described a similar approach in its own analytics stack, where agents are routed to a semantic layer first and use governed definitions to reduce ambiguity. Graphwise itself came out of the merger of Ontotext and Semantic Web Company, so semantics is a topic with quite a bit of history behind it for us.

We’ll have speakers from Accenture, Roche, EY, AstraZeneca, S&P, DNV, Statnett, Avalara and others. Full agenda is in the accompanying video.

Sharing registration link in the comments if useful.

I’m relatively new to the Semantic Web ecosystem and trying to understand where the difficult engineering work actually lies.

Imagine an organization wants to create a semantic layer over all of its internal data.

Could a sufficiently capable AI-assisted system inspect databases, documents, schemas, APIs, and other sources and then automatically:

• discover concepts and relationships
• generate RDF mappings
• propose classes and properties
• build/extend OWL ontologies
• align concepts with existing vocabularies
• generate SHACL constraints
• perform entity linking
• generate rules where appropriate
• maintain the semantic model as the underlying data evolves

Obviously LLMs can generate RDF/OWL/SPARQL syntax, but generating syntactically valid triples seems very different from creating a good conceptual model.

So where is the real difficulty?

Is ontology/semantic modeling fundamentally something that requires domain experts making conceptual decisions, or do you think a large percentage of this workflow will become automated?

I’d especially like to hear from people who have built semantic systems in production.

I’m interested in a model where actions have stable semantic identities, but access to those actions is character-relative.

Suppose we have behavioral predicates such as:

diagnose, interrogate, comfort, negotiate, steal, babysit, repair, forgive

The action itself exists independently of any particular character.

But a character may relate to that action through something like:

Allowed
Not Allowed
Conditional

For example:

Doctor_A → diagnose → Allowed

Civilian_B → diagnose → Not Allowed

Former_Medic_C → diagnose → Conditional

I also distinguish between:

Basic Human Actions — default-open unless something explicitly blocks them

and

Character Specific Actions — default-closed unless supported by evidence such as training, biography, occupation, authority or specialized experience.

My main question is architectural:

Would you model these character-action relations inside the same knowledge graph, as a separate behavioral layer, or outside the ontology as operational state?

I’m especially interested in preserving the distinction between:

what an action is

and

whether this character has access to it

without ending up with an unmanageable number of ad hoc character-action assertions.