Exocortex
A semantic knowledge management system built on RDF, SPARQL, and ontology-driven architecture. Runs as an Obsidian plugin, CLI tool, or TypeScript library.
---
Why Exocortex
Most tools separate data from configuration: you write content in one place and configure UI, workflows, and schemas in another. Exocortex takes a different approach — Everything as Knowledge.
Your entities, their properties, UI layouts, workflows, and commands are all described as semantic data in the same Markdown files, in the same vault. Create a new entity type — and the UI adapts automatically. Define a workflow transition — and buttons appear. No code changes, no server, no vendor lock-in.
This is an evolution of the "as Code" paradigm (Infrastructure as Code, Docs as Code):
| As Code | As Knowledge (Exocortex) | | ---------------------------------------- | ---------------------------------------------------------------------------------------------- | | Workflow as Code — CI/CD pipelines | Workflow as Knowledge — status transitions as RDF data, UI buttons generated automatically | | Layout as Code — JSON/CSS config | Layout as Knowledge — columns, filters, sorting described semantically | | Schema as Code — JSON Schema, Prisma | Schema as Knowledge — OWL classes and properties as files in your vault |
"As Code" describes desired system state. "As Knowledge" describes what things mean and how they relate.
Compared to existing tools:
| | Exocortex | Notion | Jira | Semantic MediaWiki | Protégé | | ------------------------- | :-------: | :----: | :--: | :----------------: | :-----: | | RDF/Semantic | ✅ | — | — | ✅ | ✅ | | File-based (git-friendly) | ✅ | — | — | — | ✅ | | UI from ontology | ✅ | ✅ | ~ | ~ | ✅ | | Offline-first | ✅ | ~ | — | — | ✅ | | For knowledge workers | ✅ | ✅ | ✅ | ~ | — | | Action layer (commands) | ✅ | ~ | ✅ | — | — |
---
What It Does
- Semantic knowledge graph — every piece of knowledge is an Asset with UUID, class, properties, and relationships stored as RDF triples
- SPARQL queries — ask complex questions across your entire knowledge base
- Modular ontologies (AssetSpaces) — the engine itself is domain-agnostic; every domain vocabulary ships as a separate, versioned, independently-shareable package you mount on demand. See Exo-as-SDK topology.
- Everything as Knowledge — commands, workflows, property schemas, layouts, and even plugin settings (exoSetting assets — see docs/explanation/settings-homoiconization.md) defined as vault assets, not hardcoded
- Installable ontology packages — extend the graph by mounting an AssetSpace from any public or private GitHub repo (assetspace-add in the CLI, Add a knowledge pack in the plugin) — no engine change required
- Profile (production-ready) — vault-declared homoiconic profiles that drive on-disk AssetSpace materialization via a single Apply profile operation (mount-state strict replace). One vault, multiple contexts, selective sync. See docs/explanation/profile.md.
- ExoSync — GitHub-backed vault sync via the Exocortex: Sync command: pull → merge → push over the GitHub REST API, with structured 3-way merge and quarantine for unresolvable conflicts (a SHACL merge-gate ships in core but is not yet wired into the plugin). Works on mobile (no git binary required). See docs/how-to/exosync.md.
- UI/CLI Parity — every capability is reachable from the Obsidian plugin and the CLI; neither client holds exclusive features. The complement of homoiconicity: it keeps the invocation layer open just as homoiconicity keeps the data layer open. See VISION.md.
- Desktop / Mobile parity — every plugin command works on both desktop and mobile; none is gated desktop-only (a desktop-only dependency such as the git binary is bridged through a cross-platform path — vault.adapter / GitHub REST). The third member of the no-lock-in triad. See VISION.md.
- Local-first — all data stays on your device, no cloud required
---