Prepared state engine
Atomic byte-record batches, branch heads, scoped receipts and allocation-free publication.
Status: Foundation. The pure prepared-state layer is implemented over the persistent map. It manages opaque byte records and performs no I/O, authentication, schema validation or graph execution.
Prepare before publishing
prepare validates the request and creates prospective data/receipt roots. Visible state does not change. The durable owner can then append and synchronize the exact intent before calling the allocation-free commit operation.
Preparation can be cancelled safely before logging. A stale, wrong-owner or already-consumed preparation is rejected at publication. If a durable owner encounters an unexpected rejection after synchronization, it must stop and recover rather than continue with an ordinary retry.
Branch heads and global sequence
The engine begins with main branch 1 at sequence/head 0. Every newly accepted command advances the global sequence. A data batch advances only its target branch's head; a version-control command advances global sequence without changing a data branch.
A fork checks an explicit source head and gives the new branch its creation sequence. Parent, child and grandchild can then evolve independently. Dropping a branch retains its identity tombstone and leaves surviving descendants' roots readable.
Atomic byte-record operations
| Mutation | Behavior |
|---|---|
| Put | Insert or replace the key's value. |
| Create | Require that the key is absent. |
| Delete | Require that the key is present. |
Mutations in a batch observe earlier mutations in that same batch. Any failure leaves the previously visible root and receipt set unchanged. The branch's expected head protects against stale writes.
Replay without repeating an effect
Receipts are keyed by branch scope and request identity. Matching intent returns the original receipt even if the old expected head is no longer current. Changed intent under the same scoped identity is a conflict.
Forks share record roots without copying parent replay identities. Current authorization and catalog versions are checked before historical receipt replay. Those counters detect stale context; the actual access decision belongs to the trusted application owner.
Typed commands have a deterministic, length-prefixed SHA-256 intent hash. Replay consumes explicit sequence, identity and version fields; it does not generate new IDs or timestamps.
Bounded foundation
Default admission limits include 1,000 mutations, 4,096 key bytes, 8 MiB values, 16 MiB canonical request bytes, 100,000 records per branch, 1,024 branch slots and 100,000 retained receipts. Tombstones and receipts are not silently evicted.
These bounds do not provide a process-wide memory ceiling. Historical-root lookup, merge-base retention, schemas and public authorization remain later layers. Architecture overview.