An ontology is a dependency like any other
I've spent the last few years watching agents and LLM tooling get dramatically better at doing things and barely better at remembering them. Every engagement starts by re-explaining the same context. Every new hire rebuilds the same mental model from scratch.
A maintained, versioned, verifiable ontology is one answer to that. It's harder and less glamorous than a bigger context window, and I think it's the one that compounds.
But look at how ontologies get treated once somebody has written one.
Other work depends on it
Other ontologies import it. Datasets are validated against it. Applications build on it and, increasingly, so do language models. By any honest definition, an ontology is a dependency.
So when it changes, the people downstream need to know three things:
- Are its conclusions still right?
- Does it still answer the questions it was built to answer?
- What, exactly, changed?
Today, that knowledge is spread across file histories, test scripts, release notes and the maintainers' memory. Little of it travels with the release.
We already solved a version of this
Software has had this problem for decades, and we built habits around it. You pin an exact version. A lockfile records what you got. A package is identified by its contents, so you can tell whether the bytes you hold are the bytes that were published. None of that is exciting, which is the point. You stop thinking about it and get on with your work.
Ontologies deserve the same release discipline. They also need something code packages rarely get: conclusions a machine can check. An ontology entails things its authors never wrote down. A release should be able to tell you what those conclusions are and show that they hold.
So I started building it
That project is called Erden. The idea is to treat an ontology as a package, with a canonical identity, a version history, explicit dependencies and a validation report.
I began on the machine in front of me, because a registry is only worth building if publishing to it is a small step from work people already do. As of this week, a local command-line tool can check a project and install its dependencies from pinned versions.
The harder half comes next: a place to publish to, where each release gets checked the same way every time and the results stay attached to it.