Alpha Ontology
The prebuilt operational ontology stack for Meta-Effects.
Meta-Effects has two main surfaces: Forma, the generic DSL-builder and runtime platform, and Alpha Ontology, the prebuilt operational ontology stack built with Forma. Alpha Ontology packages the forms, elaborations, runtime handlers, and services for things like define-entity, define-action, define-query, define-policy, and define-projection.
The purpose of Alpha Ontology is not to describe every business domain in advance. Its purpose is to provide a useful default DSL for operational software, while remaining extendable enough that a team can add its own domain forms or fork the language package entirely.
The Contract#
Alpha Ontology defines the core objects and default handlers that a Forma Runtime SDK can run against the Fact Store.
This makes Alpha Ontology different from a library of business objects. A staffing package may define Candidate, Placement, Client, and I-9 Case. Alpha defines what it means for those things to be entities, facts, actors, commands, events, policies, effects, and projections, and how those declarations materialize in a runtime.
What It Contains#
Alpha Ontology is the concrete ontology stack under the Meta-Effects project.
- Ontology DSL is the Forma-built language package: forms, elaborations, protocols, diagnostics, and editor metadata for operational ontologies.
- Ontology Runtime is the Alpha implementation of the Runtime SDK: handlers, services, policy hooks, command execution, effects, projections, and Fact Store materialization.
- Open Ontology is the open module layer: reusable Alpha packages for common operational patterns.
- ontology.run is the hosted deployment product: storage, generated interfaces, agent tools, operations, audit, and deployment workflows.
That keeps Forma reusable for other DSLs while giving ontology users a complete default system.
Default Language Set#
The default Alpha language set should stay deliberately small:
- Module names a compilation unit.
- Type names the shape of values.
- Entity names a semantic object.
- Fact records an assertion about an entity.
- Query derives information from facts.
- Policy gates authority.
- Actor owns state and receives messages.
- Command is the write boundary.
- Event records that something happened.
- Effect controls interaction with the world.
- Projection exposes an interface or derived representation.
Everything else should be treated as elaboration until proven otherwise.
Actors#
Entities describe what exists. Actors describe where mutable authority lives.
That is the important distinction. The ontology gives meaning. The actor gives jurisdiction. A runtime can lower an actor to a Durable Object, a local process, a queue-backed worker, or a native actor scheduler, but the semantic boundary remains the same.
Commands#
Commands are the only ordinary way to change the system.
This gives humans, services, and agents the same boundary. Before a command runs, the runtime can inspect who may invoke it, what it may affect, which actor owns execution, and which effects it is allowed to perform.
Facts and Events#
Facts are semantic memory. Events are historical occurrences.
An event says feedback was submitted. A fact says a candidate has a feedback record, a rating, a status, or a pending violation. Commands can produce both, and the distinction matters because organizations care about both current reality and accountable history.
Queries operate primarily over facts. Audit and replay operate primarily over events. The runtime should preserve both instead of collapsing them into one vague log.
Policies and Effects#
Alpha Ontology keeps pure and effectful semantics apart.
Queries are pure. Policies are queryable. Commands are effectful. Effects are declared capabilities.
This separation is what makes simulation, audit, replay, agent safety, and distributed execution possible. If everything can call HTTP or mutate state, the system becomes a scripting language. If effects are named and typed, the system remains an operational runtime.
Elaborated Forms#
Many useful concepts should not be primitive at first:
- workflow
- form
- dashboard
- violation
- task
- queue
- timer
- notification
- agent
A workflow is actor state plus commands, events, timers, and effects. A form is a projection bound to an input type and command. A violation is a fact produced by a failed constraint query. An agent is an effect handler operating inside policy and command boundaries.
Keeping these as elaborations protects the kernel from becoming a catalog of product features.
Extending Alpha#
Alpha is not a closed ontology. It is a language package. A team can add a form that fits its own domain:
That extension can elaborate into canonical IR, then use runtime handlers to install, update, remove, and expose it. The important part is that the extension stays inside the same toolchain: typed source, editor support, diagnostics, tests, generated services, and runtime behavior.
Why This Page Exists#
Meta-Effects needs a stable center. Forma syntax can evolve. Runtime SDKs can target different hosts. Domain libraries can grow. But the Canonical IR contract needs a small set of semantics that all of those layers preserve.
Alpha Ontology is that first default: an executable organization language you can adopt, extend, fork, or replace.
Read Forma for the DSL-builder and runtime platform, Canonical IR for the canonical representation, Fact Store for durable facts and history, Runtime SDK for the generic execution contract, and Open Ontology for the open module and standard library built on top of Alpha.