WorldVM
Define a world. Give it goals. Let it run.
Software today is built around applications, databases, APIs, and workflows. But businesses consist of entities, relationships, obligations, capabilities, and desired outcomes.
Goal
Employee ready to work
Available action
Provision payroll account via PayrollConnector
An employee must be eligible to work. An invoice must be paid. A customer must be provisioned. A contract must be approved.
Each outcome depends on facts about the world. Those facts change. Some are unknown. Some are contradictory. Some require humans or external systems to act.
We build enormous amounts of software to coordinate these changes.
What if we could program the world directly?
Most business applications start with a database schema, then add APIs, forms, workflows, queues, and integrations.
Each layer creates another representation of the same underlying domain.
The database knows what happened. The workflow engine knows what should happen next. The UI knows what users can do. The rules engine knows what is allowed.
None of them has a complete model of the world.
WorldVM starts with a different set of primitives:
| Primitive | Question |
|---|---|
| Entities | What exists? |
| Facts | What do we know? |
| Rules | What must be true? |
| Goals | What do we want to become true? |
| Actions | What can change reality? |
| Evidence | Why do we believe something happened? |
Everything else is derived.
A form collects facts. A task requests an action. A workflow is a dependency graph. An application is a view into a running world.
WorldVM uses Forma, a typed Lisp for describing domain models as executable, composable programs.
Imagine defining an employee:
(entity Employee
(name String)
(email Email)
(start-date Date)
(employer (Ref Employer)))Now define what it means for an employee to be ready to work:
(goal ready-to-work
(for Employee)
(requires
identity-verified
employment-authorized
payroll-ready))This isn’t a workflow.
It doesn’t say which screen to display, which API to call, or which step comes first. It describes a desired state of the world.
WorldVM evaluates the goal against known facts and determines what remains to be done.
The examples illustrate a proposed Forma domain language, not syntax guaranteed to work in the current compiler.
The world is constantly changing.
An employee starts work. A document expires. A background check completes. An external system corrects a previously reported value.
WorldVM uses Triplex, a temporal fact database, to represent these changes.
[:employee/123 :employee/name "Alex"]
[:employee/123 :employee/employer :company/acme]
[:employee/123 :employee/status :active]Every fact can carry its source, history, and temporal context.
This allows WorldVM to answer three different questions:
That last distinction matters.
A business needs more than current state. It needs to explain decisions, reconstruct history, and understand how new information changes its understanding of the past.
Forma defines the world. Triplex remembers the world. WorldVM changes the world.
A complex business cannot be modeled as one enormous program.
It needs encapsulation.
WorldVM introduces Components: reusable, typed domain programs with their own state, goals, actions, and children.
A component exposes a public contract while hiding its internal implementation.
Consider a compliance system:
Acme Corporation
└── Federal Compliance
└── Form I-9
├── Section 1
├── Section 2
└── E-Verify
└── Case ResolutionEvery level is independently understandable.
The account cares whether its applicable compliance obligations are satisfied.
The federal compliance component coordinates those obligations.
The I-9 component manages employment eligibility verification.
The E-Verify component manages the lifecycle of an E-Verify case where applicable.
The parent doesn’t need to know how the child works. It only needs to understand the child’s public interface.
(component EVerify
(input employee EmployeeRef)
(input employer EmployerRef)
(output status CaseStatus)
(output resolved Bool)
(command submit-case)
(command close-case))An I-9 component can instantiate E-Verify conditionally:
(component I9
(input employee EmployeeRef)
(input employer EmployerRef)
(child verification
(of EVerify)
(when (everify-required? employer)))
(output complete
(and section-1-complete
section-2-complete)))I-9 completion and E-Verify resolution remain separate legal and operational obligations. A broader compliance component combines their outcomes when applicable.
Components provide the same fundamental benefits that component-based UI architectures brought to interfaces:
But instead of rendering pixels, WorldVM components reconcile reality.
A component definition is a versioned program.
A component instance is that program operating within a particular world.
Definitions
FederalCompliance@2
I9@3
EVerify@1
Instances
acme/federal
acme/employee-123/i9
acme/employee-123/i9/everifyThousands of instances can share the same definition.
Each instance has a stable identity, scoped facts, configuration, lifecycle, and execution history.
Instances can be nested without requiring a separate database or process for every component. Their boundaries are enforced through typed interfaces and capabilities.
A component can expose its status without exposing its internal facts. It can accept commands without allowing its parent to mutate private state.
A module is a reusable definition. An instance is a living part of the world.
Traditional workflow engines prescribe sequences. First A, then B, then C.
But reality is rarely that orderly.
Some work can happen in parallel. Some requirements are already satisfied. Some become irrelevant. Others emerge when facts change.
WorldVM defines goals and action contracts instead.
(action provision-payroll
(requires identity-verified)
(produces payroll-ready)
(via PayrollConnector))The runtime evaluates the world, identifies unmet goals, and determines which actions are eligible.
Goal: Employee ready to work
✓ Identity verified
○ Payroll ready
✓ Employment authorized
Available action:
Provision payroll accountAfter execution, WorldVM observes the result and evaluates again.
An action’s declared outcome is not automatically treated as a true fact. The runtime requires appropriate confirmation or evidence.
This is a continuous reconciliation loop:
There is no need to persist a giant workflow graph describing every possible path.
A workflow is simply the current projection of the work needed to satisfy a goal.
WorldVM doesn’t fundamentally distinguish between work performed by a person, an API, or an AI agent. All three interact with the world through typed capabilities.
Each action has preconditions, authorization requirements, effects, and observable outcomes.
(action collect-identity
(requires (not identity-complete))
(via (form IdentityForm)))
(action create-payroll-account
(requires identity-complete)
(via PayrollConnector))Agents can reason about goals and propose actions, but they cannot bypass the runtime’s constraints.
WorldVM remains the authority for what can be executed, by whom, and under which conditions.
This makes the domain model a shared interface between humans, traditional software, and autonomous agents.
WorldVM is built on three layers.
Language
A typed language for defining entities, components, contracts, goals, actions, and domain-specific abstractions.
Programs compile into versioned, inspectable artifacts.
Memory
A temporal fact database supporting queries, derivations, provenance, and historical reconstruction.
The world can be evaluated against different moments in time and different program versions.
Execution
A durable runtime for component instances, reconciliation, scheduling, authorization, and side effects.
Effect provides a natural implementation model for typed services, dependency injection, errors, concurrency, and resource management.
WorldVM adds the persistent execution semantics required for long-lived business operations.
Together, they form a programmable environment for operational software.
A WorldVM application is a collection of versioned components and configuration. Developers should be able to inspect changes before deploying them.
$ worldvm check
$ worldvm plan
$ worldvm applyA plan might report:
World: acme/production
Package changes:
federal-compliance 2.1 → 2.2
Affected instances:
1,248 employees
New requirements:
37
Actions requiring approval:
12
No changes applied.Because definitions are separate from facts, the runtime can evaluate a proposed configuration against existing reality before changing anything.
This opens the door to simulation, policy testing, historical replay, and safe migrations.
The goal is to bring the declarative development experience of infrastructure-as-code to business operations.
Traditional software tells you that something failed. WorldVM should tell you why.
$ worldvm explain acme/employee-123
Goal: Ready to work
Status: Blocked
Unsatisfied requirement:
Payroll account active
Because:
Identity verification incomplete
Source:
Federal onboarding package v2.1
Next eligible action:
Request identity verification
Responsible actor:
Employee
Evidence:
No verified identity record foundAn explanation isn’t merely a generated summary.
It is derived from the definitions, facts, dependencies, and execution evidence that produced the result.
The system should be able to answer:
These questions become native capabilities of the runtime.
WorldVM is not limited to workforce operations. The same primitives can describe many domains.
Employees, placements, onboarding, compliance, payroll, benefits, termination.
Invoices, approvals, payments, reconciliation, reporting.
Accounts, contracts, provisioning, entitlements, renewals.
Repositories, issues, branches, builds, deployments, agent tasks.
Each domain defines its own vocabulary using Forma. Each domain records its reality in Triplex. Each domain executes through the same WorldVM runtime.
The platform does not need to know what an employee, invoice, or deployment is.
It only needs to know how to evaluate facts, compose components, satisfy goals, and execute authorized actions.
The history of software is a progression toward higher-level descriptions of intent.
It treats a business as a living, programmable model rather than a collection of disconnected applications.
A model that can observe itself, explain itself, and act to satisfy its goals.
The result is not another workflow builder, rules engine, or application framework.
It’s a new abstraction for operational software.
This is the direction WorldVM is being built toward, not a description of a finished
product. Components, goal reconciliation, and the worldvm command line
are proposed designs. The demos below and the employee onboarding slice show what runs
today.
The frameworks
Forma and Triplex are two of the open frameworks WorldVM is built from. Each project handles one part of the problem and is useful on its own. Together they give the VMs facts to remember, rules to check, a language to write in, and a face to show. See the family portrait
Memory · Facts, time, provenance
The database that remembers why.
Every event a machine accepts becomes a fact with a time and a reason. Triplex keeps facts, history, versioned rules, and provenance in one store you can query with Datalog.
Rules · Schemas, predicates, workflows
Every app hides a second program.
Guards, contracts, and workflows as Effect Schema data. A process becomes something you can type-check and simulate before it goes live.
Language · Typed Lisp, macros
Watch a domain language compile.
Describe a process in a small language of your own. Forma type-checks it and elaborates it into the definitions the runtime understands.
Faces · Outliners, grids, forms, agents
Give the machinery a face.
A machine needs a human side. Outliners, data grids, forms, diagrams, and agent interfaces for Foldkit.
Vocabulary · Shared, typed entities
Every platform, checked as one program.
Typed definitions of the things processes touch, like people, vendors, and contracts, so machines in different systems agree on what they mean.
On top
Each one runs the frameworks for a different kind of work.
The VMs
Each VM is a different face on the same idea: actors send events, machines decide what’s allowed, and everything is on the record. These demos run in your browser.
Model your entities and the machines that move them. WorldVM generates the interface, whether that’s a table, a board, or an agent, and answers Datalog queries over the facts in Triplex.
ContextVM reads a corpus of documents, notes, or structured data and documents the ontology emerging from it. Explore concepts, fields, and relationships with evidence back to their sources. Service agreements are one example use case.
Stripe, Salesforce, and Okta config as typed source. OntologyVM plans each change against the live accounts, applies it in dependency order, and notices when someone edits a platform by hand. Each platform’s reconciler is an actor; each resource is a machine.
Threaded outline notes. Tag @scout, @writer, or
@critic on any note and an agent starts a subthread. When it’s done it
writes back into your outline, and you decide what stays.
A game engine for group chats. Each game is a machine, each player is an actor, and the chat is the table. Play a round of trivia with the Friday crew.
A runtime for living domain models
Create an employee, record their paperwork, and watch their readiness update. Employee onboarding is a working slice of WorldVM you can click through today.
Try the employee onboarding demo No signup. Your own private world in the browser. Please use made-up data.