One write. One transaction. Five layers.
Seal → index → audit → commit, together or not at all. Here is what one record looks like at rest, and how the seal is bound to the row it lives in.
Every record is sealed to its place in the file.
A payload is compressed, sealed with AES-256-GCM under a per-record key, and written as an immutable row whose plaintext columns are exactly the associated data of the seal. A keyed checksum covers both. Move the ciphertext anywhere else and it will not open. Click a layer.
Opaque JSON. Read only where you said to.
The engine reads exactly the top-level fields your schema declares for indexing — nothing else. Undeclared fields, nested structure, and values you encrypted yourself are stored byte-exact.
- payload
- compression
- seal
- checksum
- row
- content key
- audit row
Type anything. Seal it. Then try to move it.
Real AES-256-GCM in your browser, with the same associated-data binding the engine uses. Seal a payload, change one AAD field — the version, the status, the parent — and try to open it again.
The engine also compresses before sealing and stores the content key wrapped with AES-KW; both are omitted here. The AAD binding is exactly what you see.
One secret. Everything derived.
You supply key material; the engine derives its working set with HKDF-SHA256 — an index key, a checksum key, a wrap key, per-event audit keys, a key-check value — and mints one random master secret per store, wrapped with AES-KW. Every record gets its own random content key, wrapped under the wrap key. Rotating your key re-wraps one thing and re-encrypts nothing.
FIPS 140-3 at rest: the default build takes every primitive from aws-lc-rs pinned to the CMVP-validated AWS-LC-FIPS 2.0 module (#4816 static, #4759 dynamic), compiled and linked on Linux x86_64 and aarch64. Nothing hand-rolled, no second provider. Working keys are zeroized on drop; the one sanctioned panic in the engine is a failing random generator — predictable key material is worse than crashing. A host without the AWS-LC toolchain can pass --no-default-features for local work; that build is not a FIPS build.
Binary attachments, sealed under the record that owns them.
Files, imaging slices, exports — stored as objects on a record: sealed with that record's content key, bound by their own associated data (object id, owner, name, created), checksummed, audited, access-checked through the owner. Immutable: replacing one is a new object and a new revision. Shred the owner and every object dies with the shared key. The name is plaintext shape metadata, like a type — validated, and never a place for secrets.
The whole store is one file — and the file is always a complete backup.
Single writer, rollback-journal mode: between transactions the file on disk is the entire, consistent store — schema, index parameters, audit chain and all. Copy it, ship it, verify it anywhere. The storage layer is SQLite; you never see it, and stock tooling cannot read a single payload.
Replication is a per-table cursor over gapless sequence numbers. Reads are audited too: every export of record or object data seals an audit event before it is returned — fail-closed on a writable store.