A time-traveling knowledge graph database and system of action. Entities, relationships, facts, and time — all queryable. No migrations. No JOINs. No lost history.
On·tol·o·gy/änˈtäləjē/noun
1.The branch of metaphysics dealing with the nature of being.
2.A set of concepts and categories in a domain that shows their properties and the relations between them.
The Database
Relational databases store rows. Rows change. History disappears. UPDATE erases the past to store the present.
Ontology-DB stores facts. Facts never change. History is built in.
// the atom of data
[entity, attribute, value, timestamp]Add attributes to any entity, anytime. No migrations, ever.
Every fact is timestamped. Query any point in history.
First-class edges between entities. Not foreign keys.
Declarative pattern-matching queries that compile to SQL.
Key Features
System of Action
Most databases store data and wait. Ontology-DB creates a closed loop of detection and resolution. Rules query for problems. Violations track them. Actions fix them. Forms collect what's needed. Processes orchestrate the whole thing.
When the underlying data changes, violations auto-resolve. The system heals itself.
(define-constraint i9-required
(where
[?emp :employee/status "onboarding"]
[?emp :employee/name ?name]
(not [?form :form/entity ?emp]
[?form :form/template "i9"]
[?form :form/status "completed"])))Datalog queries that define bad states. If the query returns rows, those rows are violations. Evaluated continuously.
Governed state transitions with preconditions and effects. Can require approval. Applied atomically with full audit trail.
Multi-party data collection with section dependencies. Versioned templates so in-flight documents are never disrupted.
DAGs that orchestrate actions, documents, queries, and human tasks into multi-step processes. Each step feeds the next.
Compare & Review
For Developers
Lisp for AI generation and REPL-driven development. TypeScript for IDE autocomplete and compile-time safety. Both compile to the same intermediate representation with perfect round-trip fidelity. A Hindley-Milner type engine powers inference across the entire ontology.
Canonical source. Shared intermediate representation. Executable runtime metadata.
compile(lisp) → OntologyIR → deployable payload
┌──────────────┐ │ Lisp DSL │ │ (.lisp) │ └──────┬───────┘ compile │ V ┌──────────────┐ │ OntologyIR │ │ (shared) │ └──────┬───────┘ emit │ V ┌──────────────┐ │ Runtime data │ │ payload │ └──────┬───────┘ validate │ V ┌─────────────────────────────────────────────────────┐ │ ✓ verified ─── payload matches compiled IR │ │ deployable data keeps source semantics │ └─────────────────────────────────────────────────────┘
waiting...waiting for IR...waiting for emit...Homoiconic. Token-efficient. Built for AI generation and REPL-driven development. No build step.
The intermediate representation where source declarations become schema-flexible, compiler-checked runtime intent.
Deployable entity types, relationships, queries, rules, views, and workflow metadata.
A Hindley-Milner type engine powers the entire Lisp DSL experience — inference, diagnostics, CEL validation, and autocomplete. No annotations required.
Algorithm W + row polymorphism + CEL bridge
|Algorithm W with row polymorphism infers every type — entity attributes, action bindings, do-block expressions, even Datalog query result shapes. No annotations needed.
CEL expressions inside Lisp documents are type-checked against the entity schema. Variables like $entity, $input, $now are typed from context.
Open record types let functions accept any record with the required fields — extra fields pass through. The type {:name String | r} means "has name, maybe more."
FAQ
Unify your systems into a single queryable ontology. Every fact timestamped. Every relationship first-class. Every query can see the past.