Introduction
Answers ready before you ask: one small language keeps counts, percentiles, candles, invoices and log dashboards current in a SQLite file as the data arrives.
Precomputing is a project to make answers cheap. A short policy names the streams of events you have and the answers you want ready, and says how long each level of detail should live. From then on every event updates those answers the moment it arrives, so a question becomes a lookup, and old detail fades on the schedule you set.
The code works today on simulated data, and four live demos run it in your browser. The next step is real traffic.

Why Keep Answers Ready
Most questions asked of a stream of events are known in advance: requests and p99 per endpoint, candles per symbol, tokens per customer this month, errors per service this minute. Answering them from raw events means keeping every event and scanning it again on each question. Keeping the answers ready pays off in four ways. Fast answers: reading a ready answer takes microseconds. Small files: summaries grow with time, while raw events grow with traffic. Exact where it matters: counts and sums are exact, and an exact stream counts every billable event once. Raw data where you want it: detail stays as long as you say, on your own machines, and the unusual events stay whole.

A policy is a few lines, and the rest follows from it. The compiler turns it into plain SQLite, which runs inside any application that already uses SQLite. The Engine runs the same policy in a Go binary, 12 to 17 times faster on Demo 2’s trades, and writes the very same file. How it works
What 0.1 Has Shown So Far
In the SQL demo, three hours of API traffic, 1,080,198 requests, fit in a file 7.9 times smaller than a plain table of the same requests, with every p99 within 0.65% of the exact value. In the Engine demo, a trading day of 4,048,210 trades becomes candles that match a recount exactly, even when the Engine is thrown away mid-write. Natively the Engine takes that day at 258,000 to 337,000 trades a second in our runs, and killed 100 times without warning it lost no acknowledged trade. In the Meter demo, a month of AI usage with retries, an outage and a stuck queue ends in invoices equal to a recount to the billionth of a dollar. In the Logs demo, a web shop’s dashboard goes upstream in 120 times fewer bytes than its log lines, and every point still matches a recount of the raw lines, the p95 values within 1%.
All of this was measured on simulated data, on a two-core cloud server and in Chromium. Nobody has run it on production traffic yet. That is what the pilots are for. The platform in detail
Where the Project Stands
Version 0.1 is done: the language, both runtimes, the Meter and Logs, with four demos and the tests behind them. 0.2 comes next: Logs sending its own batches upstream, an OpenTelemetry Collector plug-in, JSON log lines, smaller sketches, authentication and ready-made releases. Pilots with teams who try it on their own data run alongside, and 1.0 freezes the language and the file format. See the roadmap
Try It in Your Browser
The live demos run the real code inside your browser: the compiler, the Engine and the log reducer built for WebAssembly, writing into SQLite’s own WebAssembly build. Each one plays about a minute of simulated traffic, lets you break something along the way, and ends by checking every answer against a recount. Then ask the file anything in SQL. They are open to everyone, with no sign-up and nothing to install. Open the live demos
