The record answers on its own.

One engine from a data center to a two-dollar drone.

Ktema is a multi-dimensional query engine for products and services that have to answer for what they did. It answers across several axes in a service, beside the database you already run, or on hardware that cannot run one, with no operating system under the engine, no storage work at boot, and no index to maintain.

A software agent, a robot, a drive, or a medical monitor asks which readings moved together before the failure, or what happened in the last seconds. Ktema answers from the record it keeps, with or without a server, a network, or a cloud round trip.

Talk to us

database with an index

the same query

device with no database

The same three fields are the axes in both panels, and they are an example: a deployment declares its own. On the left they are held in an index, and a leaf of it costs about 134 KB on a 32-bit target for two small records. On the right they are the coordinate itself, so a reader computes the address instead of looking it up. The single index leaf is a pilot engine measurement on a 32-bit target, reproduced from the build.

Why

The system has to answer for what it did.

Three failures end a deployment. The record answers all three from the machine that made it.

The incident

Why it acted, what it saw, and what limited it, read from the machine's own record rather than from a log someone has to reconstruct.

The link drop

The record is made on the machine, so the question is answered there, with or without a server, a network, or a cloud in the path.

The audit

For medical, automotive, industrial, and energy products, the record is the evidence a regulator asks for. The CRA reporting duty already applies, and the AI Act asks for logging over the life of a high-risk system.

Engine

A record written under its own address.

Ktema stores the record where the question will look for it. A reader computes the address from the fields instead of walking an index.

The address: A record's fields are its coordinates. The engine computes the address from the record, so a writer and a reader arrive at the same place without a lookup.
The record: Three kinds of entry: a fact, an intent, and a hint. Each is written once, under its own coordinate.
The question: A question is a region on the same axes, such as one origin over a time window. The answer is the set of records whose coordinates fall inside it. No index, and no scan from the start of the log.
The medium: The engine asks the medium for a region, a write, and an erase. On a part that is a region of flash; in a service it is the storage the process already has. The record is append-only; a segment is the unit of recovery, and the memory the engine holds is bounded by one segment, not by the record count.
The edge: A Rust library with a C ABI, including read and query, at the application edge. It links into the build you already ship, or the service you already run: no operating system, no file system, and no database under the engine.
The limit: A question that needs a join across separate systems, or a record that may leave the process or the device, is a database's job. The engine is for the question answered where the record was made.

Proof

What the engine costs, on the machine and over the log.

Four numbers: what it takes to fit, what it costs to grow, what a question returns, and what a database needs for the same question.

01the footprint
1,648B
The engine never holds more than 1,648 bytes of working memory on the board: a fortieth of the 64 KB arena it is given.
An ESP32-S3 with 8 MB of flash, the records on the flash and the read path included.
1,648 B at the peak2.5% of a 64 KB budget
The records sit on the flash. This is what the engine holds while it works, and it does not grow with them.
02the growth
1.67µs
A record read from the middle of ten thousand: 1.67 µs, against 1.04 µs at a thousand.
Ten times the history adds two thirds of a microsecond, because a read does not walk the log from its start.
1,000 records1.04 µs
10,000 records1.67 µs
+0.63 µs, for ten times the records.
Bars scaled to 1.67 µs.
03the question
2.96ms
A question that returns 1,001 records from ten thousand stored takes 2.96 ms.
At a thousand records the same question returns 101, in 148 µs.
1,000 stored · 101 returned148 µs
10,000 stored · 1,001 returned2.96 ms
+2.81 ms, and 900 more records returned.
Bars scaled to 2.96 ms.
04the alternative
100KB
A minimum SQLite build needs an operating system and about 100 KB of heap for its B-tree.
It also rebuilds on boot: it replays its write-ahead log, while LittleFS walks its directory and NVS reads its page index into RAM.
Ktema · 1,648 B1,648 B
SQLite · 100 KB100 KB
Bars scaled to 100 KB. The engine figure is measured on the board; the database figure is its published minimum.

01/ 04

Scroll

The footprint is the ESP32-S3 run on the board. The read and the question are host figures: release build, median of 51 samples. The database figure is its published minimum.

Device

Two megabytes of flash history, 1,648 bytes of working memory.

On an ESP32-S3, a chip with 8 MB of flash, a run wrote a record and read it back after four restarts. A boot does no storage work to find it: the address is computed from the fields, so there is no index to rebuild, and the memory it needs does not grow with the history.

An ESP32-S3-WROOM-1 module on a flight-controller board, with its battery and USB bridge attached. — An ESP32-S3-WROOM-1 with 8 MB of flash, running from its own lithium cell.

Working memory, bytes

First start2,384

Starts after1,648

The first start prepares the storage. Later starts hold 1,648 bytes. What bounds it is one segment, and a segment's size is fixed.

Storage it occupies

Region of the 8 MB flash2 MB

ESP32-S3 build in its 1 MiB slot447,968 B

The image carries the engine and the Delta client. A quarter of the flash and less than half its slot.

It asks the hardware for three things: a region of flash, a write, and an erase. One partition line. The bootloader untouched. Everything above that line is Ktema.

Measured on the board over four starts.

Product

Runs inside the product you already ship

Your team adds Ktema to the build it already has, and the product can answer multi-dimensional questions from its own record.

Shipped as: A component your team adds to the build it already ships, with a C interface at its edge. There is nothing to port and no platform to stand up.
Self-contained: One component carries the record, how it is stored, and how it answers multi-dimensional questions.
Answers: Multi-dimensional questions about what happened and why, on the device, from the record it keeps.
Travels: A record written on one machine reads on another, with no conversion step and no export.
Reaches: One codebase spans your product line, from the smallest target to the largest, so the record format does not change with the hardware.
The boundary: The record format and the research are public, so a second implementation can recompute an address. The commercial layer is the conformance program, the engine, and the device kernels.

The record is also the evidence a regulated product needs. The CRA reporting duty has applied since 11 September 2026, and its main obligations arrive in December 2027. The EU AI Act asks for logging over the life of a high-risk system.

Contact

Put the engine inside your product

If your device has to answer multi-dimensional questions on the spot, we should talk.

Ktema links into the product you already ship. It leaves the server, the network, and the database you already run where they are, and it fits the memory a small device carries. Tell us what your machine has to answer, and we will show you what that query looks like on the device.

Write to us