The useful output is a checkable certificate, not another screenshot
Open Ontologies addresses a narrow failure in ontology review. A text diff can show one changed triple without showing the new facts a reasoner will derive from it. This tool plans the change, reports its semantic consequences, and can write a derivation certificate. A separate Lean 4 checker replays supported rules against the recorded premises. The reviewer gets files and an exit code instead of having to trust the engine's explanation.
That promise sits inside a large repository. commit 9b2dfc2 had 2,823 files, roughly 197,500 lines of source, and a 249.3 MB checkout. The Rust binary covers RDF and OWL loading, SPARQL, SHACL, reasoning, data ingestion, mappings, lifecycle operations, and MCP. The repository also contains Lean checkers, a Tauri studio, a Python engine, documentation, fixtures, and ontology data. Adopting it means choosing which layer you trust and operate.
The distinction between result types is unusually important here. Built-in Horn-style reasoning can produce a certificate with a soundness theorem. User-supplied rules produce a different verdict because those rules remain assumptions. Some inconsistency findings can be certified; other tableau answers are explicitly presented without that guarantee. Locality modules cite an external theorem and report a measurement rather than claiming this repository checked the theorem.
Release binaries avoid the source build that exceeded 15 minutes
Our Cargo install step completed in 67 seconds and resolved 364 packages. The project publishes binaries for Apple Silicon and x86-64 Linux, plus a container image, so many users do not need to compile the repository. The README says a source build requires Rust 1.85 or newer. Its recommended release command enables embeddings, plugins, and SQL features, which pulls in more code than the default feature set.
The default Cargo features are empty. PostgreSQL, DuckDB, embeddings, the WASM plugin host, and a quantized vector index are separate choices. The README says the published binaries and container use the default set, leaving 8 tools unavailable because they need embeddings, plugins, or database features. That is a sensible way to keep the standard binary smaller, but the tool list shown in the documentation is broader than any one default installation.
Running the core CLI also has a storage trap. The default store is in memory. If you run load and then start a separate reason process without persistent mode, the second process sees an empty store. The tool warns about this, but the README admits the warning is easy to miss. Persistent work needs OPEN_ONTOLOGIES_STORAGE_MODE=persistent and the same --data-dir on related commands.
What happened when we ran it
Our unprivileged Rust sandbox used 3 CPUs and 12 GB of RAM. Installing commit 9b2dfc2 succeeded in 67 seconds with 364 packages resolved. The repository build did not finish within the 900-second limit. We have no supplied tail that identifies the crate or stage where that build command was working, so the only defensible result is a timeout.
The test command also timed out at 900 seconds. Its final output still showed dependencies compiling, including unicode-width, quick-error, proptest, and wat. No test summary appeared, which means we cannot claim that any test passed or failed. The lab scan did find a tests directory, 6 CI workflow files, a Dockerfile, and a Compose file. Those project signals do not turn our incomplete local run into a green check.
A cold Rust build can improve with a shared cache or a larger runner, but we did not measure either. The 900-second result matters for a team deciding how quickly a clean environment can verify a patch. Pinning a release binary is the easier evaluation path. Contributors should reproduce the full build and test workflow on their own CI class before assuming the repository's 6 workflows will fit their time budget.
MCP access is useful only with the proof boundary intact
The serve command exposes ontology operations to Claude Code, Claude Desktop, Cursor, and other MCP clients over standard input and output. Version 2.0.1 fixed a handshake case where a request arriving before initialize could end the server. The quickstart is short: configure the binary as an MCP server, restart the client, and the onto_* tools become available. The server appearing idle in a terminal is expected while it waits for a client.
The tested checkout has 2,823 files because the project goes far beyond that handshake. An AI client can load data, run queries, validate shapes, plan changes, and ask for reasoning. The model's involvement does not make its output trustworthy. The certificate path matters precisely because the engine or client can be wrong. Keep the asserted input, derivations, digest, checker version, and verdict together if the result must survive an audit.
Version 2.0.1 is active, while source verification remains expensive
GitHub showed 873 stars and 20 combined issues and pull requests on October 7, 2026. The repository was pushed on October 1, and release v2.0.1 arrived September 28. The open queue had active fixes for Parquet, XML, XLSX, mappings, graph contexts, and CI. Those dates show current maintenance across the many input paths, while the breadth of fixes also warns that format edge cases are still moving.
Open Ontologies is worth adopting when an ontology change needs an artifact another person can verify later. Start with the release binary, a small production-shaped ontology, persistent storage, and one certificate checked outside the engine. Do not begin by enabling every optional feature. Our two 900-second timeouts show the source path needs real CI capacity, and the project's own wording shows that only some answers cross the line from an engine opinion to a checked proof.