Roadmap

Version 0.1 showed the idea working end to end on simulated data: one language, one file, two runtimes and two products, each with a live demo. 0.1.1 added what AI agents need, 0.2 made releases build and check themselves on five systems, and 0.3 closed the gaps that stood between Precomputing and a real deployment: OpenTelemetry in, HTTPS, a guard on billing clocks, and files whose policy can change. What comes next is real traffic, through pilots with teams who try it, before a 1.0 that freezes the language and the file.

Stage Status What it covers
0.1 Done The language, the SQL runtime, the Engine, the Meter and Logs, with six live demos
0.1.1 Done An MCP server for AI agents, read and write tokens for the HTTP server, and Traces for agent calls, with two more live demos. The first public release, open source under the Apache License 2.0
0.2 Done Releases that build and check themselves: binaries for Linux, macOS and Windows, each run before it goes out
0.3 Done OpenTelemetry logs and metrics over OTLP/HTTP, HTTPS in the server, ahead for billing streams, and precomputing migrate
Pilots Next Teams running Precomputing on their own data, with every result published only with their consent
1.0 Planned The policy language and the file format frozen, so files and policies from 1.0 on stay readable

What 0.2 and 0.3 Closed

Each item came from a limit written down in the 0.1 documentation.

  1. Builds for three systems. Every release now has binaries for Linux on x86-64 and 64-bit ARM, macOS on Apple silicon and Intel, and Windows, and each one the runners can execute runs Demo 2’s whole trading day before the release goes out.
  2. TLS for the HTTP server. precomputing serve --tls-cert --tls-key speaks HTTPS, and a renewed certificate is used without a restart.
  3. OpenTelemetry. 0.1 planned a Collector plug-in. 0.3 takes OTLP/HTTP in the server itself, which every OpenTelemetry SDK and Collector can already send, so no plug-in is needed: log records feed the streams from logs, and metrics feed streams of their own.
  4. Policies that grow. Planned for 1.0, done in 0.3: precomputing migrate adds streams, rollups, precomputes and quotas to a file that is already running, and refuses any change that would alter what it has counted.
  5. Clocks in billing streams. ahead refuses a report stamped too far past the meter’s own clock, so one gateway with a broken clock can no longer close a month early.

Still Open

  1. Logs sends its own batches. The batches meant for upstream are read from the file with SQL, as Demo 4 does. A forwarder would send them to an HTTP endpoint on a schedule, and retry until each batch is acknowledged, with the sequence numbers the Engine already uses.
  2. JSON log lines. A policy reads one text format and treats a JSON line as text. OTLP records come with their fields; JSON lines should too.
  3. Packed sketches. A sketch is stored as one row per bucket. In Demo 1 the sketch buckets are more than half of the file. Packing each window’s buckets into one value should make files with percentiles much smaller, with the same answers.
  4. Histogram buckets from OpenTelemetry. 0.3 keeps an OTLP histogram’s count, sum, minimum and maximum. Its buckets could feed a stream’s sketch, so percentiles survive too.

Pilots: Real Traffic

Simulated data proves the mechanics. Only real data shows where a policy is awkward to write and how files behave over months. The project would like to run pilots with teams in the areas the demos cover:

  • SQLite applications that keep counters, rollups or percentiles by hand today.
  • Services that need fast answers from a stream of events, such as an API sidecar or market data.
  • AI and API products that bill by usage and want the meter’s totals exact and in their own database.
  • Teams that pay by log volume and would rather send a dashboard’s answers than every line.
  • Teams that run AI agents and want every call kept, costed by run, repository and tool, and readable by the agents themselves over MCP.

A pilot runs on the pilot’s own machines, and its results are published only with the pilot’s consent. See Contact.

1.0: A Frozen Format

A first stable release should follow the pilots. Its promise is stability:

  • The file format frozen. Format 1 already changes only by adding tables and columns. From 1.0 that is a promise, so a file written by 1.0 stays readable by every later version.
  • The policy language frozen, with new features added only in ways that leave existing policies meaning the same.
  • Measured on named hardware. Every published figure measured again on stated machines, with the commands to reproduce it.

Later: Many Machines, One Answer

Every summary the language keeps merges. Two 30-second windows add up to exactly one 1-minute window, and sketches add bucket by bucket. The same rule lets files from many machines add up to one answer: one Engine per server or per region, and a merged file for the whole fleet, with the same accuracy as one Engine that saw everything. Merging files is the natural step after 1.0. So are more dashboard importers, starting with the dashboard exports of the popular log tools.

Open Questions

  • Where Logs should run. Beside the services, with OTLP sent straight to it, or behind a Collector that already gathers everything. Pilots should decide.
  • What the Meter should hand to billing systems. The meter’s totals are exact and in SQLite. Which billing tools to export them to, and in what form, depends on who uses it.