Most dashboards ask the same few questions repeatedly: requests per endpoint, month-to-date usage, error rates by status. The usual approach recalculates answers on every refresh, which is fine until your data grows. Then every refresh becomes slow, or you ship all your data to a hosted service and pay per gigabyte.
Precomputing does the calculation once, as the data comes in. You write a short policy that names the answers you want and says how long each level of detail should live. It compiles to plain SQLite triggers, so every INSERT keeps those answers current, and reading an answer is a lookup.
The technical innovation is materialization without a separate system. Your triggers run invisibly as data arrives. Your dashboard queries views. It’s still just SQLite—any SQLite tool opens the file and the answers are plain views with nothing running beside them. When triggers get too slow, you swap in a Go engine that runs the same policy and writes the same file, byte for byte. Your dashboard code doesn’t change.
The same policy language drives other systems. A usage meter for billing where a retried request counts once and a closed month stays locked. A log reducer that keeps every line locally but sends upstream only what a dashboard needs. An AI agent can ask the precomputed file over MCP instead of reading raw rows.
Precomputing is version 0.1, checked hard on simulated data and not yet deployed to production. The platform page covers the full architecture. The Policy Language walks through a policy line by line. The SQL demo puts three hours of simulated API traffic through a compiled policy in SQLite’s WebAssembly build, right in your browser.
The technical appeal is elegance. You don’t add a separate analytics system. You don’t invoke a service on every query. Answers sit in the same SQLite file as your data, kept current by the same transaction that writes the data. The innovation is showing that dashboard speed doesn’t require a separate service—it requires calculating the right things at the right time.