The archive that is the write path
A point-of-sale, pharmacy, or gaming terminal streams events one transaction at a time. Each is appended to the file tail and hash-chained in real time (O(1)per record — prior bytes are never rewritten). Every N records a sealcheckpoint is fsync’d as a durability barrier. Lose power mid-write and the torn tail is detected and recovered to the last seal; alter, delete, reorder, or insert any past transaction and it is pinpointed to the exact record.
- O(1)
- per record: append to the tail, hash-chained in real time — never a rewrite
- per-record
- tamper pinpoint — the exact transaction, not the batch
- 0 loss
- torn-tail crash recovery to the last fsync'd seal, no sealed record lost
- anchor
- an out-of-band seal receipt catches even a full in-place re-forge
Stream it, prove it, survive a crash
# the till streams events — O(1) append, sealed every 1000, fsync durable at1 worm append lane7.journal --events shift.csv --seal-every 1000 --fsync # created lane7.journal — appended 10,000 records (seq 0..9999); # 10000 sealed; seal receipt 3f9a1c07...; 1,284,113 bytes [fsync durable] at1 worm verify lane7.journal # WORM INTACT — 10,000 records, 10 seals, head 3f9a1c07... # power was cut mid-write — recover the torn tail, lose nothing sealed at1 worm recover lane7.journal # RECOVERED: torn tail at byte 1283990 discarded; kept 9,983 records # (9 seals, durable to seal @ 9000). Recovered prefix re-verifies: YES. # publish the seal head out-of-band — defeats a full re-forge at1 worm anchor lane7.journal --publish lane7.receipt.json at1 worm verify lane7.journal --anchor lane7.receipt.json # WORM INTACT ... anchor receipt: MATCH
Streaming write path
Each transaction is one O(1) append to the tail, hash-chained in real time. No nightly reconstruction, no whole-file rewrite — the journal is the live record as sales happen.
Exact-record pinpoint
Alter, delete, reorder, or insert any past transaction — even repairing the per-frame checksum — and the chain diverges at the exact sequence number. It tells you which record.
Crash-safe + anchored
A torn mid-write is detected and recovered to the last fsync’d seal with zero sealed-record loss. An out-of-band seal receipt catches a full in-place re-forge that a naive verifier would accept.
Honest scope — how this differs from the shipped Ledger
Hash-chained, append-only, tamper-evident storage already ships as the AT-1 Ledger, and the idea is prior art (Certificate Transparency, AWS QLDB, blockchains) — we ship it, we don’t patent it. The genuinely new delta here is the write model: the Ledger re-encodes and rewrites its trailer on every batch append and pinpoints to a frame; WORM appends each record in O(1), pinpoints to the exact record, seals at fsync’d checkpoints, and recovers a torn mid-write. WORM is the hot streaming front-end; at1 worm rollover folds sealed segments into the Ledger as the queryable, aggregatable, GDPR-erasable cold store.
Two honest limits.(1) “WORM” by protocol (append-only bytes + hash chain) is tamper-evident, not tamper-proof, against root on the box; the --fsync durability mode plus OS object-lock (S3 Object Lock / chattr +a) and the external anchor receipt are what enforce immutability. (2) Fiscal / electronic-journal regimes (Germany KassenSichV/TSE, France NF525, 21 CFR Part 11) require a certifiedsecure element — certification is out of scope until an accredited lab signs off. We sell the immutable journal + proof primitive, not a certified TSE.
Speed is stated as the per-record append cost (O(1), no rewrite); “secure” means integrity + crash-safety + tamper-evidence, not confidentiality.