In this piece
How to Validate Open Ontologies Derivation Certificates
One added triple left the structural risk at low in our Open Ontologies test, yet produced three new consequences. A later retrieval check exited successfully while explicitly saying its conclusion was unchecked.
Validate an Open Ontologies derivation certificate by preserving its asserted graph and rule scope, running the independent checker on the assertion and derivation files, and inspecting the structured result together with the process exit. Approve the exact graph and claims that passed. Unchecked results and checker failures remain unresolved.
Open Ontologies is an open-source engine for planning ontology changes and producing certificates for supported inferences. Its Terraform analogy describes a plan, review and apply workflow. If you are still deciding whether an agent needs a knowledge graph, start with our graph-engineering decision guide.
Test and research date: . We used checksum-verified Linux assets from v2.1.0, released on 23 October 2026. Source links pin the later 2 November commit c7fd75f. Independent acceptance remains unconfirmed: the checker failed at runtime on the unmodified certificate in our environment. The fixture tests behavior; it establishes no performance benchmark.
What does an Open Ontologies proof establish?
An accepted Open Ontologies derivation certificate establishes that its conclusions follow from its supplied assertions under the supported formal semantics. The assertion that a document is approved, accurate or current still needs its own evidence. A checker can validate the consequences of an incorrect premise without discovering that the premise is wrong.
The project’s assurance architecture separates checking a conclusion from establishing which graph the engine used.
| Question | Evidence to inspect | Limit |
|---|---|---|
| Does the derivation follow? | Independent checker result over the assertion and derivation files | Conditional on those assertions and supported rules |
| Is this the intended graph? | Graph revision, assertion digest and selected graph scope | A sound proof can describe the wrong snapshot |
| Are the assertions reliable? | Source evidence, extraction review and the responsible owner | Formal entailment does not verify the outside world |
| May the agent use the result? | Your application policy and access checks | The class name itself grants no permission |
Our LLM-as-a-Verifier analysis covers learned scores for ranking model outputs. Open Ontologies checks an explicit derivation against rules.
How do you check an Open Ontologies derivation certificate?
Generate the certificate, then run oo-cert against asserted.tsv and derivations.tsv. Preserve stdout, stderr and the exit code. Acceptance requires the checker to finish and return its documented successful result.
The certificate guide describes a separate Lean checker that re-checks the recorded inference steps. Its documented success contract is exit 0, ok: true and theorem OOCert.certificate_sound. A rejected step should identify its rule, conclusion and premises.
Download our Open Ontologies certificate test fixture and captured results, then change into the unpacked directory. The example assumes your verified engine and checker executables are on your PATH. The bundle includes source fixtures and an evidence collector; supply the binaries separately.
open-ontologies --no-connect --data-dir ./review-store batch - <<'OO'
load proposed.ttl
reason --profile rdfs --certificate ./certificate
OO
oo-cert ./certificate/asserted.tsv ./certificate/derivations.tsvThe batch keeps loading and reasoning in one process. Our proposed graph contained four asserted triples; rdfs reasoning produced three derivations. We then changed one conclusion to claim that note42 belonged to ApprovedForProduction, while leaving its premises unchanged.
| Input | Observed result | Review decision |
|---|---|---|
| Unmodified generated certificate | Exit 1, empty stdout, stderr: failed to locate application | Hold. No successful independent acceptance was emitted |
| Altered conclusion, unchanged premises | Exit 1, JSON ok: false, first_rejected: 2, rule rdfs9 | Reject the altered derivation. A specific rule check failed |
Both processes exited 1. Only the second produced a structured rule rejection; first_rejected: 2 identifies the third derivation record because the index starts at zero. The first run failed while locating the application. These are different failures, and the negative control cannot substitute for successful acceptance of the original certificate.
Why does a low-risk plan still need semantic review?
Open Ontologies reports structural risk and semantic consequences separately. A change that adds no named classes can still let existing rules derive new classifications. Inspect the conservativity block and its affected conclusions before deciding whether the change is intended.
Our starting graph used these three assertions. The Retrievable declaration deliberately puts that name in the original vocabulary:
@prefix ex: <https://example.com/knowledge/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
ex:note42 a ex:ProjectNote .
ex:ProjectNote rdfs:subClassOf ex:Document .
ex:Retrievable a rdfs:Class .The proposal adds one triple:
ex:Document rdfs:subClassOf ex:Retrievable .The conservativity documentation distinguishes this finite rule-table comparison from a general logical-conservativity guarantee. Our owl-rl plan reported one insertion, zero affected triples in the structural blast-radius field, risk_score: low, and not_conservative_under_rule_table.
| Triple, abbreviated | Why it appears |
|---|---|
| Document subclass of Retrievable | The new assertion itself |
| ProjectNote subclass of Retrievable | New derivation through the subclass chain |
| note42 type Retrievable | New derivation using that classification |
That is three new consequences, including one assertion and two new derivations. The reasoning certificate contains three derivations because it also includes note42 type Document, which already followed from the base graph.
The project’s published demonstration reports 901 new consequences in 0.04 seconds and a separate exercise with 259 certified derivations and one rejected forgery. We did not reproduce those counts or timings. As our example shows, a consequence count can include the added assertion.
Our batch process also exited 0 while its nested conservativity report contained exit_code: 1. That semantic finding may be an intended change. An approval job must inspect the report and record the decision; checking only the shell status misses it.
Can a smaller RAG context preserve the same conclusion?
Open Ontologies can evaluate whether a selected graph slice still supports designated positive ground triples under a chosen rule profile. You supply the claims. The tool does not extract and validate every statement in a generated answer, and preserving a percentage of nearby triples does not establish that the necessary premises survived.
For our fixture, the goal is note42 type Retrievable. The intact slice contains the three triples forming that derivation, leaving out the standalone class declaration. The truncated slice removes ProjectNote subClassOf Document. Both remain subsets of the proposed graph.
The projection-entailment guide gives checked, asserted and unchecked outcomes different names:
| Run | Per-goal result | Process exit | Meaning for approval |
|---|---|---|---|
| Intact slice, no checker configured | preserved_unchecked | 0 | The engine derives the goal; independent verification is absent |
| Truncated slice, no checker configured | lost_under_profile_unchecked | 1 | The selected profile no longer derives the goal from the slice |
| Intact slice, checker required | certificate_rejected, STOP_THE_LINE | 2 | Hold and inspect the raw checker error |
In the third row, the report carries the same failed to locate application runtime error. The wrapper’s rejection label does not establish that a rule was disproved. We did not obtain preserved_checked in this environment.
A lost-under-profile finding also has a boundary: it is the engine’s negative result within its supported rules, not a proof of non-entailment in every ontology logic. For a proof-required workflow, we would hold an unchecked positive result, restore a lost premise, and investigate a checker failure before allowing the agent to rely on the claim.
Entailment preservation also leaves authorization untouched. Our RAG permissions guide covers whether the user may retrieve those facts in the first place.
What belongs in the approval record?
An Open Ontologies approval record should identify the graph revision, selected assertions, rule profile, semantic change and exact checker result. When a retrieved slice is involved, add its per-goal verdicts. This is our proposed application policy, not a claim that the engine automatically approves business changes.
| Record | Acceptance question |
|---|---|
| Engine and checker identities | Which downloaded assets or builds ran, and do their hashes match the reviewed versions? |
| Graph revision and assertion bytes | Does the certificate describe the exact input approved for this run? |
| Selected scope and profile | Which graphs and rules were used, and were relevant constructs or goals refused? |
| Semantic-change report | Has a reviewer accepted the reported consequences and resolved undecided findings, independently of the structural risk label? |
| Checker stdout, stderr and exit | Did the intended checker emit a successful verification result? |
| Slice, explicit goals and verdicts | Does each required derived claim have the evidence your application demands? |
The trusted-computing-base document explains that the checker reads certificate files, not your intended application state. It does not inspect scope.tsv; the caller must review that selection. An assertion digest binds bytes. It does not establish their real-world truth, freshness or permission status.
For this experiment, the approval decision remains hold for independent verification. The forged-certificate rejection is useful evidence, but it cannot replace a successful check of the certificate you intend to use. Repeat the acceptance and rejection controls on your deployment host before wiring them into an agent.
How do you connect Open Ontologies to Claude Code?
Register Open Ontologies as a local stdio MCP server with an explicit executable and store path. Keep persistence intentional: the project’s default store is in memory, so restarting the process does not preserve the loaded graph. A running MCP connection alone also does not establish that a separate proof checker is installed.
The pinned storage and embedding configuration defines the memory default and persistent mode. Following the current Claude Code MCP instructions, this registration uses the local transport:
claude mcp add \
--env OPEN_ONTOLOGIES_STORAGE_MODE=persistent \
--transport stdio open-ontologies -- \
/absolute/path/open-ontologies \
--data-dir /absolute/path/oo-store serveReplace both absolute paths. Configure and verify the checker separately, then inspect the connection with /mcp. We verified the command structure against documentation; we did not run a live Claude Code session or test every MCP client. The command’s --data-dir is a CLI flag, not an environment variable.
Budget setup time for both executables and a successful proof check on your deployment host. Our test does not establish a one-minute verified setup.
When would we use Open Ontologies?
We would evaluate Open Ontologies when an agent relies on explicit, reviewable assertions and rules whose consequences matter. Start with one consequential claim, one proposed ontology change and a deliberately broken derivation. Expand once the deployment environment demonstrates both successful independent acceptance and the expected rejection.
If you need to connect this reasoning layer to an application, our AI product and agent development service is the relevant next step. Define the claims and the approval contract before expanding the graph.
Open Ontologies proof-verification questions
Is Open Ontologies a Terraform provider?
The project’s Terraform analogy describes planning, reviewing, applying and rolling back ontology changes. It does not establish compatibility with Terraform providers or HCL. Treat Open Ontologies as its own reasoning and change-management tool, and evaluate its actual commands and evidence formats before designing an integration around the analogy.
Does Open Ontologies prevent every agent hallucination?
No. A derivation checker covers specified formal conclusions from supplied assertions under supported rules. An agent can still extract an incorrect assertion, omit a necessary goal, describe a result inaccurately or make an unrelated claim. The application must connect the checked triples to the statements it releases and preserve the source evidence behind the assertions.
Can the same derivation certificate certify OWL DL reasoning?
The documented reason --certificate path supports rdfs, owl-rl and owl-rl-ext; owl-dl refuses that flag. The project has other verification mechanisms, but they must be assessed separately. Do not turn a successful check within a supported rule fragment into a claim that every OWL feature or every answer from the engine is certified.
Does a proof establish that custom Horn rules are correct?
A supplied-rule Horn certificate proves a conclusion relative to the supplied rules as well as the assertions. The rules remain assumptions. Preserve verdicts such as entailed_under_supplied_rules in full, and review the rule table and its digest. Shortening that result to a generic proven label would hide an assumption the reviewer needs to see.
Does local MCP execution keep every piece of data on my device?
Local reasoning does not by itself establish an entirely local AI workflow. Tool results are returned to the MCP client, whose model may run remotely. The pinned configuration also supports an OpenAI-compatible embedding API. The project’s quickstart documents model downloads for embedding initialization. Inspect the selected build, provider and client data flow before making a local-only claim.
Does derivations.tsv explain every possible justification?
No. The certificate guide records one derivation step per newly inferred triple, using the first derivation found. A conclusion may have other valid justifications that the file does not enumerate. Use the project’s dedicated justification and provenance mechanisms for that separate question, and assess their guarantees independently of whether this particular certificate checks.