Runtime SDK

The SDK for turning a language package into a running system.

Meta-Effects source does not merely generate documentation, schemas, or UI. A language package elaborates source into Canonical IR. A runtime is the SDK contract that defines what it means to run that IR: how declarations are installed, updated, removed, fingerprinted, stored, exposed as services, and connected to effects in the world.

The runtime is where an abstract IR graph becomes an operational system.

Runtime Shape#

The stack is intentionally layered.

text

Forma source  -> language package, often Alpha Ontology  -> canonical IR  -> runtime handlers  -> runtime services  -> fact store  -> host adapters  -> stores, actors, effects, projections

Canonical IR is the abstract target. The runtime SDK binds that target to execution semantics and writes durable assertions through the Fact Store. It may run on Effect TS, Rust, Cloudflare Durable Objects, SQLite, Postgres, or a hybrid of those targets. The semantics should survive the host.

Runtime SDK Contract#

A runtime SDK should make execution explicit enough that a new host or language package can conform to it:

load and validate canonical IR modules
bind IR definitions to handlers for install, update, remove, and fingerprint
expose services generated from the language package
define policy, capability, and audit hooks
expose typed APIs for humans, services, and agents
provide simulation, replay, and conformance fixtures
report source and IR provenance when execution fails

That makes "runtime" less a single server and more a contract for running a language wherever the system needs to live. Alpha Ontology's Ontology Runtime uses this contract for operational ontologies, but another team could use the same SDK shape to run a different DSL.

Language, Handlers, Services#

The clean split is:

text

language  -> forms and elaboration into IRhandlers  -> how emitted declarations become runtime stateservices  -> the API surface exposed by the runtime instance

The language answers "what can I say?" Handlers answer "what happens when that declaration is installed, updated, removed, or compared?" Services answer "what can the rest of the application call?"

This is the boundary that lets a team extend Alpha without editing the host runtime, or build a different runtime language without rewriting the surrounding SDK. Most users should never write custom handlers. They matter because they give advanced teams a place to define how their own language materializes.

typescript

const runtime = defineRuntime({  id: "company.alpha",  language: alphaLanguage,  handlers: alphaHandlers,  services: alphaServices,});const app = runtime.instantiate(project);await app.services.actions.run("activate-employee", input);

Durable Facts#

The runtime stores assertions through the Fact Store. Current state is a view over facts; history is the same substrate observed over time.

text

entity       attribute          valuecandidate:1 :candidate/status  interviewingcandidate:1 :candidate/email   ada@example.comfeedback:9  :feedback/rating   4

That shape keeps the system inspectable. A query, a constraint, a dashboard, and an agent can all operate over the same semantic memory instead of each receiving a different application-specific model.

Actor Execution#

Actors are the runtime primitive for locality and ordering.

lisp

(define-actor PlacementActor  (:key-by placement/id)  (:owns Placement Employee Client)  (:commands StartOnboarding SubmitDocument ApprovePlacement)  (:effects assert-fact emit-event schedule-command call-http))

An actor instance owns a slice of reality. It receives commands, checks policy, updates local state, asserts facts, emits events, schedules future work, and invokes declared effects. This gives the runtime a place to put workflows, queues, timers, locks, and agent boundaries without inventing a separate primitive for each.

Commands#

Commands are the write boundary.

When a command enters the runtime, the runtime should be able to answer:

Which actor owns this command?
What input type must be validated?
Which policy authorizes it?
Which preconditions must hold?
Which effects may it perform?
Which facts or events may result?

That makes commands suitable for humans clicking buttons, services calling APIs, workflows advancing, and agents taking action under the same rules.

Effects#

Effects are typed capabilities, not ambient power.

text

assert-factretract-factemit-eventsend-commandschedule-commandcall-httpsend-notificationinvoke-agentwrite-blob

The runtime can log effects, simulate them, deny them, retry them, or bind them to environment-specific adapters. This is especially important for AI. An agent should not receive a vague API key and a prompt. It should receive declared capabilities inside an actor, command, policy, and audit boundary.

Workflows as Actors#

Workflow does not need to be a separate foundation.

A workflow is actor state plus commands, events, timers, and effects.

text

collect document  -> verify document  -> wait for system result  -> approve placement  -> notify parties

The runtime can represent that as fields on an actor, scheduled commands, emitted events, and projections for operators. If a step fails, the failure becomes facts and violations inside the same model.

Projections#

Interfaces are runtime projections.

A form is a projection over an input type and command. A table is a projection over a query. A dashboard is a projection over queries and facts. An agent console is a projection over capabilities, policy, and context.

lisp

(define-view CandidatePipeline  (:query ActiveCandidates)  (:mode table)  (:actions SubmitFeedback AdvanceCandidate))

The UI can still be designed and refined, but it does not have to invent a second version of the organization.

Target Implementations#

The first runtime SDK can be Effect TS because the model maps naturally to typed schemas, services, layers, effects, and HTTP handlers.

Rust can become the portable systems kernel: IR validation, query execution, fact storage, actor scheduling, deterministic replay, and WASM embedding.

Cloudflare Durable Objects are a natural actor target: one addressable object, single-threaded execution, durable local storage, alarms, and message entrypoints.

The important point is that none of these targets is the source of truth by itself. The source of truth is the Canonical IR produced through Alpha Ontology, the durable assertions in the Fact Store, and the runtime SDK contract that says how that IR behaves.

Runtime Promise#

A Meta-Effects runtime should preserve these semantics:

facts are durable and queryable
queries are pure
policies are explicit
commands are the write boundary
actors own ordered mutation
effects are declared capabilities
events preserve history
projections are replaceable interfaces

That is the difference between an app with generated pieces and a structured system that keeps running.

Read Forma for authoring, Canonical IR for the canonical representation, Fact Store for durable facts and history, Alpha Ontology for the default operational language package, and Open Ontology for reusable modules that compile into this runtime contract.