Skip to content

All projects

Ontology AI Agent Research Platform

Consilience

The world's first general-purpose ontology OS — it builds a knowledge graph from markdown documents automatically, and an agent reasons over that graph

SWE-bench Verified resolve rate, all 500 tasks
78.80%
DP-Bench table TEDS-S — first on the official leaderboard
98.11
MuSiQue multi-hop evidence recall — graph 63.0% vs keyword 23.0%
+40pp
lines I wrote myself, across ~1,100 files
468,000
nodes under live physics at 18.3 ms/tick (WebGPU)
500k
dense retrieval seeding recall@10, at no added API cost
77.5 → 97.0

What it does

  • At save time the system extracts entities and relationships from the prose and loads them as W3C standard RDF.
  • The code structure graph lives in the same store, so a decision recorded in a document and its implementation in code resolve in one query.
  • Twenty-two file formats convert mechanically and deterministically, with no LLM summarisation.
  • Signed macOS and Windows releases, a seven-language UI, CRDT live collaboration, an admin dashboard and four subscription tiers all work.

The world’s first general-purpose ontology OS. You write markdown; the system builds a knowledge graph from what you wrote, and an agent reasons over that graph. It is a personal workspace that joins notes, documents, code, maps and design into a single graph, and since April 2026 I have built all of it alone: research, design, implementation, benchmarks, release and billing.

The name comes from E. O. Wilson’s book Consilience: The Unity of Knowledge, the idea that facts arriving from different fields, through different kinds of unstructured source, can be joined into one coherent system.

Public benchmark results

I measured every figure below myself, on the official harnesses. The conditions and limits of each row are written up separately in the research records.

Benchmark Result Conditions
DP-Bench (document parsing) TEDS-S 98.11 First on the official leaderboard for table structure, above Upstage enhanced 97.62, AWS 96.99 and LlamaParse 93.20. Achieved with a general-purpose VLM and a prompt I designed, not a fine-tuned parser
SWE-bench Verified 78.80% (394/500) All 500 tasks, no retries. This figure is the model and the scaffold added together and does not separate them. The next two rows do that
Selection-procedure A/B 54% → 76% Model and a 50-task set held fixed, adding only a procedure that cross-runs each candidate’s own reproduction command against the others
Code retrieval A/B +4.9pp File localisation accuracy (file@5, n=465) with the model, scaffold and prompt held fixed and only the search tools swapped. There is no slice in which the graph does worse
MuSiQue (multi-hop QA) 63.0% vs 23.0% Questions with every supporting paragraph retrieved. Paired per-question sign test p=2.5e-07. Of 17 four-hop questions, none succeeded without the graph
Real-vault retrieval A/B +31 to +39pp Paired exact McNemar: 90.7% against 60.0% (p=3.5e-13) and 76.0% against 37.3% (p=6.9e-18), measured on the question stratum most favourable to keyword retrieval
Dense retrieval seeding 77.5 → 97.0 recall@10. A failure mode reported in the public literature, diagnosed and fixed with a technique from another field. Keyword-only scores 85.2 on the same set, and dense seeding scoring below it was the symptom. No additional API cost

The implementation details are not published.

The ontology schema design, the retrieval seeding and ranking algorithms, the entity resolution strategy and the agent execution model are the product’s core assets, so they are not on this page. What follows covers only what was achieved and the criteria behind each decision.

What the system does

In existing notes apps, the user enters every link between documents by hand. An LLM assistant does not retain the structure it worked out once the conversation ends; ask the same question the next day and it reads the same vault from scratch. Consilience is a system that keeps what it has read after the session closes. The design draws on human cognition in four stages: education (bulk acquisition), experience (episodic memory), sleep (consolidation) and action (putting knowledge to use).

The graph is updated at save time. When you save a note, the system extracts its entities and relationships and loads them as W3C-standard RDF. The graph structure itself records which note is the source of which fact, and the graph can be regenerated from the markdown at any time. The original files always remain the user’s.

Documents and code go into the same store. The code structure graph is loaded into that same store, so “where in the current code is the decision from that meeting three months ago?” resolves in a single query. The academic comparators all index in offline batches and support a single language; this is a live index, updated incrementally on every edit.

Twenty-two file formats convert without loss. Spreadsheets, documents, presentations, PDF, Korean HWP and ebooks each have their own format-specific converter, and no LLM summarisation is used. Conversion is mechanical and deterministic.

The 3D graph view runs live physics on half a million nodes. I wrote its physics engine myself and reached 18.3 ms per tick at 500,000 nodes. At that scale an off-the-shelf library takes roughly an hour to settle; this implementation takes 4.2 seconds.

How it was designed and validated

What mattered more than the technology choices was the evidence on which each technique was adopted or rejected.

I built the vocabulary on W3C standards but deliberately excluded some standard facilities. Storing an irrevocable assertion in the graph creates a second source of truth that later extractions then silently contradict. Retractability was set as a first-class design requirement.

Inference does not overwrite what the user wrote. Judgements the system produces are recorded in a region structurally separated from the facts the user wrote. Provenance rather than truth is enforced by the data structure, not by convention.

I adopted techniques on the strength of the papers’ ablations, not their conclusions. The design builds on the research in HippoRAG, HippoRAG-2 and Microsoft GraphRAG. Rather than porting each technique as published, I selected among them on the evidence of the ablations those papers report themselves. Components worth less than 1pp were not adopted, given their cost, and metrics that proved to have no effect on this corpus were removed.

Failure modes were diagnosed from public research and fixed with a solution from another field. Dense retrieval crowding similar items at the top and pushing the correct document down was diagnosed using the distance-concentration result in a 2010 JMLR paper, and fixed by applying a correction from cross-lingual word embeddings to retrieval. I tried three intuitive alternatives before reaching that solution and rejected all three on the measurements.

An improvement that was not measured is not counted as one. Before each experiment the hypothesis, the rejection threshold and a “what would failure look like” entry go into a document, together with the commit hash at the time of registration, so that it can be verified afterwards that the criteria did not change once the result was in. And the mechanism is checked before the outcome: a metric that improves without an explanation of why is not adopted.

Failures to reproduce and rejected results are kept on the record. A gain confirmed on fixtures that did not reproduce at real-vault scale; a p-value that moved from 0.038 to 0.478 on a second independent run of the same design; a shipped commit reverted after being checked against an oracle. All of them are recorded. Rejected approaches go on a do-not-re-propose list so the same attempt is not repeated. Half of the research records below are records of that kind.

One criterion governs all of it: a result without a control arm is not used as evidence.

Scale and completeness

I wrote roughly 468,000 lines across some 1,100 files myself; with the 268 per-subsystem technical documents included, the total is about 520,000. Automated tests across Rust, vitest and Playwright number around 2,500.

Releases ship a notarised macOS universal build and a Windows x86_64 build signed with hardware-backed cloud code signing, both with an auto-updater. The UI supports seven languages: Korean, English, Japanese, Chinese, German, Spanish and French. A web build with feature parity to the desktop app, a headless server binary, CRDT-based live collaboration, an admin dashboard and four subscription tiers are all working.

Research through to commercial release was carried out by one person.

Measurements behind these claims

Stack

Rust TypeScript React Tauri Oxigraph RDF/SPARQL WebGPU three.js tree-sitter Next.js Supabase PostgreSQL

Skills demonstrated

  • AI Agent Systems

    Agent loops · tool contract design · MCP client and server (OAuth 2.1 · PKCE) · GraphRAG · Personalized PageRank · CSLS · Offline evaluation harnesses · Computer use · approval gates · threat modelling

  • Ontology & Knowledge Graphs

    RDF / W3C quads · named graphs · SPARQL 1.1 · Oxigraph · RocksDB · SKOS · Dublin Core · schema.org · PROV-O · GeoSPARQL · Entity resolution (union-find · embeddings · LLM adjudication) · Louvain / Leiden community detection

  • Product & Full-stack

    TypeScript · JavaScript · Python · C/C++ · C# · Java · Next.js · Nuxt.js · Vue.js · React · React Native · Expo · PostgreSQL · Supabase · AWS · GCP · Docker · UX design for ERP, CRM and LMS operational screens

  • Research Methodology & Benchmarking

    Pre-registered hypotheses, rejection thresholds and the commit hash at registration · Paired statistical tests implemented directly (McNemar · Fisher · Wilcoxon · Holm-Bonferroni) · Same-arm controls to establish the noise floor; pooled replicates to test whether significance reproduces · Blinded LLM judge panels, false-negative controls, and deterministic scoring with no judge · Adversarial refutation rounds; null results and failures to reproduce on the public record; do-not-re-propose lists · Public benchmarks measured first-hand: SWE-bench · MuSiQue · DP-Bench · OmniDocBench

  • Systems & Performance

    Rust (rayon · Barnes-Hut · int8 quantisation) · WebGPU / TSL compute shaders · tree-sitter code graphs · Tauri desktop · code signing · auto-update · Embedded · UART · MIDI

Press coverage