A hosted runtime for ambient ontologies. Model a slice of your operations — entities, relationships, constraints, mutations, views — in code. Version control with git. Deploy with a terraform-style pipeline. The runtime keeps your operational model active in the background.
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.
Run·time /ˈrənˌtīm/ noun ──────────────────────────────────── 1. The period during which a program is executing. 2. A system that stores state, evaluates constraints, and advances time.
Ontology.run proper noun ──────────────────────────────────────────────────────── 1. A hosted runtime for an ambient ontology — evaluating constraints, surfacing violations, triggering processes, and maintaining a complete audit trail as facts. ──────────────────────────────────────────────────────── facts + constraints + processes = one living system
Business as Code
Your ontology lives in plain text files. Entity types, constraints, process definitions, form schemas, seed data — all expressed in .md documents that mix prose and code. Check them into git. Review them in pull requests. Deploy them like infrastructure.
Your business logic becomes a codebase, not a configuration screen.
ontology/
├── entities/ │ ├── employee.md │ ├── contract.md │ └── document.md ├── constraints/ │ ├── i9-compliance.md │ └── manager-approval.md ├── processes/ │ ├── onboarding.md │ └── expense-approval.md ├── documents/ │ └── i9-form.md ├── queries/ │ └── headcount-report.md └── README.md
entities/employee.md
(define-entity Employee (:field [employee/name String {:required true}]) (:field [employee/email String {:required true}]) (:field [employee/role String]) (:field [employee/start-date Date]) (:field [employee/manager (Ref Employee)]) (:field [employee/team (Ref Team)])) (define-constraint "email-required" (:entity Employee) (severity :error) (violation-query (find ?emp ?name) (where [?emp :name ?name] [not [?emp :email ?_]])))
Write your ontology as .md files — Markdown with embedded code blocks. Headings become section labels. Paragraphs become documentation. Fenced code blocks become executable ontology definitions. Your team reads the doc; the runtime reads the code.
# Employee Onboarding Every new hire must complete I-9 verification within 3 business days of their start date. ```ontology (define-entity Employee (:field [employee/name String {:required true}]) (:field [employee/start-date Date])) ``` ## Compliance Constraints The I-9 deadline is enforced automatically: ```ontology (define-constraint "i9-deadline" (:entity Employee) ```
Facts
Deploy Pipeline
Ontology changes go through a five-stage pipeline: author → typecheck → plan → apply → query. The system compiles your Lisp definitions, runs a Hindley-Milner type engine to catch errors without annotations, diffs the current state against the desired state, and applies changes atomically.
Write .md definitions or describe your domain — an AI agent generates the ontology.
Hindley-Milner inference validates types, relationships, and constraint queries. Zero annotations.
Diff current state vs desired. See exactly what will change before it does.
Atomically write changes as triples. Every deploy is a versioned snapshot.
Immediately queryable via Datalog. Constraints begin evaluating. Processes activate.
Constraints
Constraints are Datalog queries that define conditions that must hold. If a constraint query returns rows, those rows become violations. The system evaluates every constraint against every fact change. When the underlying data resolves, violations auto-close.
constraints/i9-compliance.md
(define-constraint "i9-missing" (:entity Employee) (severity :error) (:description "I-9 missing within deadline") (violation-query (find ?emp ?name ?start) (where [?emp :name ?name] [?emp :start-date ?start] [not [?emp :document/i9 ?_]])))
Constraints produce:
This is where compliance lives. Not in a spreadsheet. In the runtime.
The Loop
Facts change. Constraints evaluate. Violations surface. Processes trigger. Actions execute. New facts are asserted. The loop runs again. When a violation's underlying condition resolves, the violation auto-closes. The system heals itself.
The runtime never stops evaluating.
(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 conditions that must hold. If the query returns rows, those rows are violations.
Governed state transitions with preconditions and effects. Applied atomically with audit trail.
Multi-party data collection with section dependencies. Versioned templates that never disrupt in-flight documents.
DAGs that orchestrate actions, documents, queries, and human tasks into multi-step processes.
Version Control
Every ontology change is a commit. Branch to experiment with new entity types. Open a pull request to add a constraint. Merge to deploy. Rollback is git revert. Your business logic has the same rigor as your application code.
typical process
$ git checkout -b add-expense-policy $ vim constraints/expense-approval.md $ ontology typecheck ✓ 0 errors. 14 documents passed. $ ontology deploy plan + expense-limit (new constraint) ~ ExpenseReport (1 attr added) 2 to add, 1 to modify. $ git add . && git commit -m "expense policy" $ git push && gh pr create # after review + merge: $ ontology deploy apply ✓ Deploy complete. 24 facts.
Isolate ontology changes just like feature branches. Test new entity types or constraint modifications without affecting production.
Business stakeholders review ontology changes in plain Lisp. Compliance officers sign off on constraints. Everyone sees the diff.
ontology deploy apply writes all changes as a single transaction. If anything fails, nothing changes. Every deploy is a versioned checkpoint you can roll back to.
Git blame tells you who changed what and when. The triple store tells you what the runtime state was at any point in history. Two layers of time travel.
Minimal Core
entities → define-entity things with identity relationships → define-relation typed connections queries → define-query saved Datalog patterns mutations → define-mutation governed state transitions actions → define-action side effects and integrations processes → define-process multi-step workflows constraints → define-constraint continuously evaluated conditions views → define-view configured UI surfaces workspaces → define-workspace scoped environments
Nine primitives. Everything else composes from them.
Entities are bags of facts. Constraints are Datalog queries over facts. Processes are DAGs that produce new facts. The runtime is the evaluation loop.
That is the entire machine.
FAQ
Short version
a hosted runtime for ambient ontologies.
Define your workflow in code. Version control it. Deploy it like infrastructure. Facts, constraints, and processes keep running in the background.