fabio-rovai/open-ontologies

Worth a look if your team already runs an OWL/RDFS ontology in a knowledge graph or data catalog and needs an audit trail for schema changes; experiments are cheap, but adopting it as a gate means adding a Lean-based checker to your review process.

The problem

An ontology maintainer wants to add one property or move one class without silently breaking downstream data. The usual loop is to load the changed graph into a reasoner, look at a diff of inferred triples, and hope that reasoner's output is right. That makes the review depend on trusting the engine and on a second implementation agreeing with it. Open Ontologies changes the middle of that loop: you plan the change, get a blast-radius summary, and receive per-step derivations that a separate checker can verify. The outcome is a change package a reviewer can accept or refuse using a result they can re-check, not a verbal assurance.

What's different

The project's own example makes the point: a single domain axiom reports zero added or removed classes and a zero blast radius, yet the rule engine derives 901 new consequences. A shape-level diff alone would call that change harmless. The engine therefore reports conservativity against its rule table alongside the ordinary counts, so the gap between "the syntax barely moved" and "the meaning moved a lot" is visible before you apply anything. This is the most compelling part of the design and the reason the tool exists.

The second mechanism is the certificate. Inferences are written out as asserted triples plus derivation lines naming the rule, the conclusion and its premises. A checker built in Lean 4, without Mathlib, replays those files; the README shows a correct conclusion accepted and a single altered IRI rejected with a non-zero exit. That means the person checking does not have to trust the reasoner implementation, and can re-run the check months later on archived files. The README claims checking against the W3C SHACL suite rather than asserting conformance, and it offers a finite model for satisfiability questions and a refutation for inconsistency where certifiable. The honest limits are stated too: if inconsistency cannot be certified, you get the engine's opinion.

The main trade-off is conceptual weight. To get the audit property you need to keep the Lean checker available, keep certificates with the runs they belong to, and understand that a certificate covers the rules and premises it names. The README also positions this against ordinary reasoners: they can explain an answer or be cross-checked by a second implementation, but no verified checker accepts those explanations. That is a fair description of the difference, not proof that the engine is defect-free.

Who should try it

Good fit: a data or ontology team in a regulated setting whose graph feeds compliance, due-diligence or crosswalk decisions and where a reviewer must justify why an inferred conclusion holds. The blast-radius view is also useful for anyone who has been burned by a "trivial" schema edit. A poor fit is a single developer exploring an RDF toy graph who wants fast querying: the certificate workflow adds files and a separate toolchain for a benefit nobody is asking for.

There is a second, different audience: the comment on the March 2026 Hacker News thread describes the MCP server for LLM-driven ontology building, with validation in a triple store to counter hallucinated hierarchies. That path is documented separately from the proof workflow, so coding-agent users can start there without the Lean checker.

Requirements and limitations

The binary is the easy part: prebuilt macOS Apple Silicon and Linux x86_64 builds, a GHCR image, and a Rust 1.85+ source build. Native Windows and Intel macOS send you to the quickstart and Windows docs instead. Persistent storage is opt-in via an environment variable; in-memory is the default, so anyone expecting their graph to survive a restart must read the storage notes.

The ongoing cost is the verification loop: build the Lean checkers, keep the certificate with the run and the archived ontology, and remember that a pass covers the file and rule table it was checked against. CI review is only meaningful if that pairing is maintained. The MCP server speaks JSON-RPC over stdin/stdout, which looks like a hung process in a bare terminal; the README says to use CLI subcommands such as validate from a shell.

HotRepo's take

The dated HotRepo record is thin: 1,670 stars and +275 on the daily board on 2026-10-27, the only sampled day, plus a 3-point Hacker News thread from 2026-03-12. With one board snapshot, persistence of interest cannot be judged. Before relying on it, check the quickstart and Windows notes for your platform, then read the SHACL measurement and certificate fixtures in the project instructions to see whether the evidence depth matches your review standard.