Your workflow has structure: things with identity, constraints those things must satisfy, and work that needs to happen when constraints are violated. Ontology Runtime makes that structure executable and keeps it present in the background.
You model a slice of your operations — entities, relationships, constraints, mutations, views — using a Lisp DSL. The runtime evaluates them continuously over a time-traveling triple store. When facts change, constraints re-evaluate. When violations arise, processes dispatch. The system is deterministic, auditable, and version-controlled.
The result is a closed-loop system where the gap between “what should be true” and “what is true” is continuously narrowed by the runtime itself. That is the ambient ontology: not a diagram of the business, but an operational model that keeps running.
Primitives
define-entityThings with stable identity and typed attributes
define-relationTyped, temporal connections between entities
define-querySaved Datalog patterns for reports and views
define-mutationGoverned state transitions with preconditions
define-actionSide effects triggered by events or processes
define-processMulti-step workflows that orchestrate resolution
define-constraintDatalog queries evaluated continuously over facts
define-viewConfigured UI surfaces for querying and editing
define-workspaceScoped environments grouping views and permissions
Entity-attribute-value triples with temporal semantics. Every assertion is timestamped and append-only. The triple store is time-addressable: you can query the state of any entity at any point in its history.
(define-entity Employee (:field [employee/name String {:required true}]) (:field [employee/email String {:unique true}]) (:field [employee/role String]) (:field [employee/start-date Datetime]))
Datalog queries evaluated continuously over the fact base. A constraint defines a condition that must hold. When facts violate a constraint, the runtime derives a violation fact. Constraints are not checked on write — they are derived continuously from the current state.
(define-constraint missing-certification (query (find [?emp ?role]) (where [[?emp :employee/role ?role] [?role :role/requires-cert ?cert] (not [?emp :employee/cert ?cert])])) (severity error))
Directed acyclic graphs of actions, mutations, and queries that orchestrate the resolution of constraint violations. When a violation is detected, the runtime dispatches the appropriate process. Processes produce new facts, which may resolve existing violations or trigger new constraint evaluations.
(define-process resolve-missing-cert (trigger missing-certification) (steps [(define-action notify-manager (type email) (to (query (find [?mgr]) (where [...])))) (form upload-certification (assignee ?emp) (fields [(:cert-file File) (:cert-date Datetime)])) (define-action record-certification (type assert) (facts [...]))]))
Execution Model
The runtime operates as a continuous evaluation loop. Facts enter the system through assertions — either from external data sources, user input, or process actions. The constraint engine evaluates all constraints against the current fact base, deriving violations where conditions are unmet.
Violations are themselves facts, queryable and time-stamped. When a violation matches a process trigger, the runtime dispatches the process. Process steps produce new facts, which re-enter the evaluation loop. The process continues until the system reaches a fixed point — a state where no new violations are derived.
The ontology is ambient because the loop does not wait for a person to remember it. It stays awake around the workflow, preserving facts, watching constraints, and turning drift into work.
This architecture ensures that every state transition is traceable. There are no implicit side effects. Every fact has a provenance: it was either asserted by an external source or produced by a named process step. The system is deterministic — given the same initial facts and ontology definition, the runtime will always derive the same violations and dispatch the same processes.
Knowledge Graph
All data in Ontology Runtime is stored as entity-attribute-value triples. There is no fixed schema — entity types and their attributes are defined in the ontology, but the underlying storage is schema-on-read. New attributes can be added to any entity at any time without migration.
Every triple is timestamped. The knowledge graph supports point-in-time queries: you can ask “what was the state of this entity at timestamp T?” and receive an exact answer. History is append-only. Retractions are recorded as new facts, not deletions. The complete lineage of every entity is preserved.
Entities across data sources are linked via identity resolution. When two systems describe the same real-world entity, a :_meta/same-as relationship unifies them. Queries traverse these links transparently.
{
"find": ["?name", "?role"],
"where": [
["?emp", ":employee/name", "?name"],
["?emp", ":employee/role", "?role"]
],
"as-of": "2024-01-15T00:00:00Z"
}Deploy Pipeline
Ontology definitions are compiled into an intermediate representation and diffed against the current deployed state. The deploy pipeline produces a plan — a precise enumeration of what will be added, modified, or removed. Nothing is applied until the plan is explicitly confirmed.
Deployments are atomic. Either all changes apply successfully, or none do. The pipeline handles schema changes (new entity types, modified attributes), data changes (seed data assertions), and behavioral changes (new constraints, updated processes) in a single transaction.
$ ontology deploy --plan Ontology: staffing-compliance Database: production Changes: + entity :contractor (3 fields) ~ entity :employee (add :clearance-level) + constraint :clearance-required + process :obtain-clearance 0 removals, 1 modification, 3 additions Run 'ontology deploy --apply' to apply.
Version Control
Ontology definitions are plain text files — Lisp S-expressions or TypeScript — that live in your repository alongside application code. Changes to your domain model go through the same review process as any other code change: branch, diff, review, merge.
The deploy pipeline integrates with CI/CD. A pull request that modifies an ontology definition can generate a deploy plan as part of the review, showing reviewers exactly what will change in the deployed knowledge graph. After merge, the pipeline applies the changes automatically.
Rollback is a deploy of a previous commit. Because ontology definitions are deterministic, reverting to an earlier version of the definition file and redeploying will reproduce the earlier schema state exactly.
Type System
Ontology definitions are statically analyzed before deployment. The type system infers attribute types, validates relationship cardinality, and checks that Datalog queries reference only declared attributes. Errors are caught at compile time, not at runtime.
Entity types compose. A :person type can be extended by :employee and :contractor, inheriting shared attributes while adding type-specific ones. Constraints can reference any attribute in the type hierarchy.
(define-entity Person (:field [person/name String {:required true}]) (:field [person/email String {:unique true}])) (define-entity Employee (:field [employee/department String]) (:field [employee/start-date Datetime {:required true}]) (:field [employee/manager (Ref Person)])) (define-entity Contractor (:field [contractor/agency String]) (:field [contractor/contract-end Datetime {:required true}]) (:field [contractor/hourly-rate Number]))
FAQ
Ontology Runtime is the execution substrate for ambient operational models. You model a slice of your operations — entities, relationships, constraints, mutations, views — using a Lisp DSL and deploy it as a self-correcting system. The runtime keeps your definitions active over a time-traveling triple store with Datalog queries.
A database stores data and answers queries. Ontology Runtime stores data, evaluates constraints continuously, and orchestrates resolution processes when violations are detected. The triple store is an implementation detail — the runtime is the product.
A triple store is a database that stores data as subject-predicate-object triples (entity-attribute-value in our terminology). This model is more flexible than relational tables: entities can have any attributes, relationships are first-class, and no schema migrations are needed to add new fields.
Datalog is a declarative query language based on first-order logic. It is similar to SQL but designed for recursive and graph-structured queries. In Ontology Runtime, Datalog defines the constraints that are evaluated continuously over the triple store.
Yes. Ontology Runtime includes connectors that sync data from external sources (SQL databases, APIs, CSV files) into the triple store as triples. Entity linking resolves identities across sources. Your existing systems remain the source of truth for their domains; the runtime provides a unified query layer.
Yes. Ontology Runtime is part of the Open Ontology project, released under an open source license.