Roadmap

The Alpha proves the design in simulation. What comes next takes the same engine onto real chips, then toward a first release, and later adds a learned layer that lets each device adapt to its situation. Durations are estimates, and hardware surprises could stretch them.

The Beta: Real Chips

The Beta has two goals. The first is the same engine, unchanged, running and tested on real boards from five microcontroller families, with every number from the Alpha measured again on the chips themselves. The five are the four already compiled for the Alpha plus Xtensa, the ESP32 cores that the Alpha’s compiler could not target.

Prices as listed by the maker or a retailer in September 2026.

Work Packages

1. Flash drivers. One small driver per family (read, write, erase), built on the vendor’s own flash functions: the Pico SDK, the STM32 libraries and ESP-IDF partitions. They plug into the same four-function interface the Alpha already uses.
2. Tests on the chips. The existing test suites, trimmed to fit, run on every board. They also run in emulators (QEMU for Arm Cortex-M and RISC-V) on every change to the code.
3. A power-cut rig. A relay or transistor switch, driven by a spare Pico, cuts each board’s power at random moments while it writes. The target is 10,000 real cuts per board, checked against the same model as in the simulation.
4. Measurements. Whole-firmware size, RAM and stack, time per operation, flash wear, and energy per reading with a power profiler.
5. Engine changes the chips ask for. A faster checksum (a table, or the chip’s hardware CRC unit), an optional single-precision build, locking hooks for firmware with threads, and whatever else the hardware turns up.

The Demo, for Real

The second goal is the demo on real hardware. Three devices, one per industry, each on a different chip family, with real sensors and radios, all report to one gateway and run for a week.

The gateway is a Linux machine, a Raspberry Pi or a PC, running the full build with SQL over all three. A cool box stands in for the truck, and a Wi-Fi access point switched on and off stands in for mobile coverage. A cellular modem can replace it later without touching the engine.

From a Set-Up File to a Build

In the Alpha each device’s set-up is written by hand in the demo’s C code. In the Beta each device gets a short set-up file: flash area and sector size, write alignment, memory, series layouts, the parameters of the rule on the device, what to send, and how large a message may be. A small generator turns the file into build settings and start-up code for that device. Success is measured in time: a new sensor, or a new industry, set up and running on a board in days.

Timeline: About 16 Weeks

Weeks	Work
1 to 3	Drivers for the Pico and the ESP32-C6. Emulator tests on every change. Whole-firmware size measured
4 to 7	The Pico 2 (Arm and RISC-V), the STM32WL and the ESP32-S3. The power-cut rig: 10,000 cuts per board. Timing and energy measured
8 to 11	The three industry devices with sensors and radios. The set-up generator. The gateway
12 to 14	The 7-day run of all three devices, and the fixes it calls for
15 to 16	Beta release: the on-flash format and API frozen for Beta users, documentation, and a Beta report with every figure measured again

The Beta needs two to three people: a lead engineer who also writes the drivers, one embedded engineer full time, and part-time help with the test rig and the tools. Hardware costs little. Two of each board, the sensors, the LoRaWAN gateway, a power profiler and the power-cut rig come to well under $1,000.

When the Beta Is Done

1. The engine’s test suites pass on all five chip families, on the boards and in emulators.
2. At least 10,000 real power cuts per board, with no acknowledged write lost and no database that fails to open.
3. Whole-firmware size, RAM, stack, time per operation and energy per reading measured on every board and published.
4. The engine’s own code size on each board within 10% of the Alpha’s figures.
5. The three industry devices run for 7 days, each deciding by itself and syncing to one gateway, with no data lost.
6. Each device built from its set-up file, with the time to set up a new one recorded.
7. Coverage-guided fuzzing runs every night with no open crash.

Out of scope for the Beta: a graphical set-up tool, a cloud service, certification and new SQL features. Sync security gets a design during the Beta and code after it.

After the Beta: Toward v1.0

A first production release should follow about 6 to 9 months after the Beta (estimate). Most of the work is what turns a tested engine into something a product can depend on:

• Secure sync. Authentication and encryption, so a gateway accepts records only from its own devices.
• One position per gateway. Today a device remembers only the most advanced gateway’s position, so with several gateways a lagging one can miss a delete. Each gateway gets its own.
• Firmware with threads. Locking hooks for devices where several tasks use the database.
• More chips and flash parts, with drivers proven on the power-cut rig.
• Documentation and tooling. A full API reference, a written sync protocol specification, and automatic testing on every change.
• Pilots in the field, on devices that belong to someone else.
• A frozen format. From v1.0 on, the on-flash format and the API stay stable, so records written by one version stay readable by the next.

Advanced Beta: The Learned Query Optimizer

After the Beta comes an optional learned layer, the Learned Query Optimizer. It lets the engine take its situation into account (battery, link, storage, events and the data itself) when it decides what to keep, what to send and how to answer. The gateway learns, each device decides, and the application sets the limits. It comes in four phases, and the work can stop after any of them:

The first phase changes storage and sync, so it is planned to land before the v1.0 format freeze. The layer is designed to add no code at all when it is compiled out.

Later: More Industries

The three demo industries share a pattern: a device that keeps data, decides for itself and talks over a limited link. The same pattern shows up in energy metering, smart buildings, water networks, retail refrigeration, vehicle fleets, drones, healthcare devices and consumer electronics. None of them is tested yet. The post on next verticals looks at what each would need.

Open Questions

• The license. It will be chosen before the first public release. The plan is a proprietary engine, with an open-source branch under consideration: perhaps a free key-value core, a dual license, or source code open to read and test.
• Pilots. The Beta’s devices are built by the project itself. Pilots on other people’s devices come after it, and the project would like to hear from device makers who want to take part. See Contact.