Fact Store

The durable semantic memory underneath Meta-Effects.

The Meta-Effects Fact Store records assertions about the world as durable facts. It is the substrate shared by runtimes, agents, constraints, projections, and language packages. Alpha Ontology uses it by default, but the Fact Store is valuable outside Alpha: any system that needs inspectable facts, relationships, history, and provenance can use the same shape.

This is the part of Meta-Effects that says the model is not only source code and not only runtime behavior. It is also memory.

Why It Exists#

Operational systems need to remember more than current rows.

They need to know what was asserted, when it was asserted, what replaced it, which source or action produced it, and how it relates to the rest of the system. A workflow engine, form system, API service, analytics pipeline, and AI agent should not each receive a different partial account of reality.

The Fact Store gives them one queryable substrate:

facts for what is true or was true
relationships as first-class facts
history as ordinary data over time
provenance for source, action, actor, and transaction context
queries that can feed constraints, views, policies, agents, and generated APIs

Fact Shape#

The core representation is intentionally small.

text

entity       attribute          valueemployee:1  :employee/status   onboardingemployee:1  :employee/email    ada@example.comtask:9      :task/assignee     employee:1

Each assertion names an entity, an attribute, and a value. The runtime attaches transaction metadata: time, identity, source, and retraction state.

That shape is sometimes called a triple store, but the product-level idea is simpler: every meaningful assertion becomes an inspectable fact. The system can then derive current state, historical state, relationships, violations, projections, and agent context from the same memory.

Time Is Built In#

Current state is a view over facts. History is the same store observed at another time.

text

t1  employee:1 :employee/status candidatet2  employee:1 :employee/status onboardingt3  employee:1 :employee/status active

Instead of treating audit logs as a separate feature, the Fact Store keeps the audit trail close to the data. A policy can ask what is true now. A reviewer can ask what was true last week. A replay tool can reconstruct how the system moved from one state to another.

Queries Over Meaning#

Facts become useful when the system can ask questions over them.

lisp

(find ?employee ?email)(where  [?employee :_schema/type "Employee"]  [?employee :employee/status "active"]  [?employee :employee/email ?email])

Queries are not just reports. They are named boundaries that constraints, projections, actions, policies, generated APIs, and agents can share.

When an agent asks what it may inspect, what is incomplete, what action would fix a violation, or why a workflow is blocked, it should not reverse-engineer a set of screens. It should query the semantic memory directly through declared capabilities.

Outside Alpha#

Alpha Ontology is the default language package that emits facts, queries, policies, commands, and projections. But the Fact Store should not depend on Alpha.

A team could use it as:

a time-traveling graph database for operational facts
an audit substrate for an existing application
a Datalog query engine over entity-attribute-value assertions
a memory layer for agents that need provenance and relationships
a migration target for systems that cannot keep changing relational schemas
a local-first or edge-deployed semantic store behind a runtime adapter

That independence matters. Meta-Effects should have a complete integrated stack, but each layer should be useful enough to stand on its own.

Relationship To IR#

Canonical IR defines semantic structure. The Fact Store persists semantic assertions.

An IR entity definition can say which attributes exist, which references are meaningful, which policies govern commands, and which projections are available. The Fact Store then holds the actual assertions and history produced by running that model.

text

IR definition  -> what kinds of facts are meaningfulFact Store  -> which facts have been asserted over time

The boundary keeps source, semantics, and persistence separate without making them strangers. The IR gives facts names. The store gives those names memory.

Relationship To Runtime#

The Runtime SDK is the execution contract around the Fact Store.

It installs IR modules, checks policies, routes commands to actors, invokes effects, asserts and retracts facts, emits events, updates projections, and exposes services. The Fact Store is where the durable assertions land.

text

command  -> actor and policy checks  -> effects  -> fact assertions and retractions  -> query updates  -> projections, violations, agents, APIs

This is why the store should be top-level in the brand. Without it, Meta-Effects sounds like a language and runtime. With it, Meta-Effects has a durable memory model.

Not A Semantic Web Claim#

The Fact Store uses a fact shape that overlaps with older semantic-web and RDF systems, but Meta-Effects is not claiming that all meaning is solved by triples.

The claim is more operational: business software already has facts, relationships, history, rules, and interfaces. Putting those facts in one inspectable, queryable, time-aware substrate makes the rest of the system more coherent.

Promise#

A useful Meta-Effects Fact Store should preserve these properties:

facts are independent assertions
relationships are first-class
current state and history share one substrate
schema can evolve without migrations for every new attribute
Datalog-style queries can cross entity boundaries
provenance travels with assertions
humans, services, and agents can inspect the same memory under policy

Read Forma for authoring, Canonical IR for canonical semantics, Runtime SDK for execution, Alpha Ontology for the default language package, and Open Ontology for reusable modules that run on top of this substrate.