Wavetable

Concepts

Five ideas explain almost everything about how Wavetable behaves.

Facts are claims, not rows

In a normal database, a fact is a cell in a row. Someone or something wrote it there, and you cannot tell who, when, or why. In Wavetable, every fact is a claim: a statement about an entity that carries its source events, who or what asserted it, a confidence, and a status (proposed, accepted, superseded, or redacted).

Connectors and programs never write directly into your tables. They propose claims. An adjudication loop, serialized per tenant, decides what becomes accepted truth. The tables you query (called projections) are caches built from accepted claims, and they can always be rebuilt from scratch.

This is why every answer in Wavetable can show a receipt. The provenance is not a log bolted on afterward. It is the write path itself.

The event log is evidence, not state

Everything that happens (an email arrives, an invoice is paid, a human approves a merge, an agent calls a tool) is an append-only event. Events are the evidence claims cite. State lives in claims and projections, so deletion works: payloads are envelope-encrypted per subject, and erasure shreds the keys (see security).

Identity is resolved with precision, softly

The same customer shows up as an email address in Gmail, a customer id in Stripe, and a device id on your site. Wavetable links these identities in two passes: deterministic keys merge automatically, and probabilistic matches only ever produce merge proposals for your Inbox. Merges are soft and reversible, because a wrong merge is the most expensive mistake a system of record can make.

Memory is narrative with citations

Each entity carries a written narrative maintained by a model. Every sentence maps to the claims and events that support it, and the UI shows those citations on hover. A sentence the generator cannot cite does not ship; it fails closed. When a cited claim is superseded, the dependent sentences are flagged stale and regenerated. Memory exists for humans; automations and reports read claims and projections, never prose.

Configuration is versioned artifacts

Your schema, views, workflows, and policies are not settings in a dashboard. They are compiled, versioned artifacts with git-like history: diffable, approvable, reversible. AI authors them at design time; humans approve them; the runtime executes them deterministically. Before a workflow goes live it is replayed against your real history in shadow mode, and you see the counterfactual report first.

The result is a system of record you can interrogate: what does it believe, why does it believe it, who approved the rules, and what would this change have done.