Counterfactual Store: A Database That Stores Alternatives, Not Just Facts
One direction that feels genuinely different from the earlier list of 20 primitives is a Counterfactual Store. Adjacent ideas certainly exist. Provenance databases, event sourcing, probabilistic databases, simulation systems and version control all touch pieces of it. But as a deliberately tiny infrastructure primitive, there’s no established category built around this exact abstraction.
Normal databases answer “what is true?” Temporal databases, and Temporal KV, add “what was true?” A Counterfactual Store adds a third basic question: what would be true if X were different?
Instead of just storing price = 100, the application keeps dependencies between values. Say revenue = price × units, profit = revenue - costs, and cash = previous_cash + profit. The application asks what happens if price becomes 90. The store evaluates the affected state without touching the real state. Picture a tiny interface along the lines of SET price 100, DERIVE revenue FROM price, units, then WHATIF price=90. The result isn’t another permanent database version. It’s a throwaway alternate reality calculated from the current state.
Branching state as the primitive
So the interesting primitive isn’t SQL, analytics or simulation. It’s branching state. The system has one canonical reality plus cheap hypothetical branches. An application creates a branch, changes three values, inspects everything affected downstream, and throws the branch away, or commits it and makes that reality the new state. Git branches files. This branches live application state and its consequences.
That opens up some fascinating uses. A configuration system checks what a setting change would do before applying it. A scheduler tests moving a job. An inventory system reserves hypothetical stock before committing an order. A financial app asks what a payment does to liquidity. An infrastructure controller simulates removing a node. An AI agent tests an action against application state before actually running it.
That last one may matter most. Agents increasingly need a clear line between “calculate what happens if I do this” and “do this.”
The plain-language explanation passes the four-question screen’s technology test unusually well: your application has a real state, and Counterfactual Store lets it change that state temporarily, see everything that would follow, then either discard the experiment or make it real.
The money question is less proven, so this isn’t a company to build right away. There is a plausible eventual buyer, though: developers building automation, planning systems, infrastructure controllers and AI agents where wrong actions have measurable costs. The commercial version could become a safe-execution layer for autonomous software. Before an agent performs an operation, run it against a counterfactual state, evaluate invariants, then permit or reject the real operation.
ForkDB: forking as the data model
There’s a stranger extension I like even more. Call it ForkDB. Every state can be forked almost instantly. A new fork costs next to nothing because it references the parent’s unchanged values; only differences take storage. Forks can fork again, merge, expire or become canonical.
Unlike Git, the contents aren’t files. Unlike database transactions, branches can live for hours or days. Unlike snapshots, they’re writable. And unlike conventional databases, branching isn’t an admin feature. It’s the data model itself.
That gives a very clean loop: state, fork, mutate, inspect, then discard or commit.
It deserves the full four-question screen, because it has something most of the earlier primitive ideas lacked. It’s hard to describe as “a smaller X.” It’s closer to a new basic operation for application state.
Those are the primitive ideas worth hunting for.