The floor: a bare microcontroller
The smallest host the engine runs on: a part with no operating system, no filesystem, 8 MB of flash and 64 kB of working memory, where a record written before the reset is read back after it. Every host above it runs the same build.
What the board reported
| Over the RAM medium | Over the flash region | |
|---|---|---|
| Heap peak | 2,384 B | 1,648 B |
| Arena | 65,552 B | 65,552 B |
| Medium | The engine's own map in RAM | A 2 MiB partition at 0x130000 |
| Records | Two written and walked back in one boot | Three from three earlier boots, each reached by its coordinate after a reset |
| Application | 356,576 B in a 1 MiB slot | 447,968 B |
| Bootloader | Untouched | Untouched |
The flash run peaks lower than the RAM run because the region channel holds no map in memory. That is the same trade the host measurements show from the other side: the path that keeps nothing per record is the path that answers by reading the log.
The surface the firmware links
A part like this has a flash region, a write, and an erase. It has no key-value medium, so the C surface takes that shape rather than a layout: the region as a slice the engine can read, and two callbacks for the writes and the erases that the driver owns.
The region channel sits above it and carries the log, the segment index, the forward-only write rule, and the recovery of a torn tail. The firmware writes no format and keeps no index of its own, which is why the same application runs unchanged here and on the host.
What the board does not cover yet
Two cases are modelled against a slice and have not run on a part: a power cut in the middle of a write, and a region that has filled and retired its oldest segment. Until both run on the board, the durability claim covers the reopen that the run above performs, and does not cover those two.