SNAPSHOT ARCHIVE

Every night, one file, AS OF any date

Point AT-1 at a folder of nightly CSV table snapshots(export your FoxPro HSTs / SQL dumps to CSV) — each ~95% identical to yesterday. It keeps one base plus a hash-chained sequence of row-level deltas. Reconstruct any night row-exactfor querying — or byte-identical to the original file with --exact— run SELECT … AS OF ‘2026-05-14’ across years without a restore, and detect tampering on any single night. A stable row-key + per-night schema stamp means a column added or dropped mid-chain still rebuilds.

2–12×
smaller than the backup folder you run today — grows with chain length & overlap
AS OF
any date materialized without restoring a single backup
--exact
reconstruct the original file byte-for-byte (checksum-against-original works)
hash-chained
one flipped byte in any night breaks the chain and is caught

Chain the nights, then query any date

at1 snapshot build 2026-05-*.csv -o ledger.at1snap --pk id --exact
#   30 nights, pk=id, row-exact + byte-exact recipe
#   vs sum-of-independent-gzip (your backup folder): 2-12x (grows with overlap)
at1 snapshot asof ledger.at1snap 2026-05-14 --where status=OPEN
#   AS OF 2026-05-14 -> day 13: 5,033 rows, 1,204 where status=OPEN (row-exact)
at1 snapshot asof ledger.at1snap 2026-05-14 -o night.csv --exact
#   wrote night.csv — byte-identical to the original (sha256 matches)
at1 snapshot verify ledger.at1snap
#   OK: 31 nights verified, hash chain intact, 31 byte-exact

AS-OF without restore

Resolve a date to its night and materialize just that day from base + deltas — a few hundred KB of I/O, not a full-backup restore. That is the query a solid archive of the same backups cannot answer.

Per-night tamper-evidence

Each night stores the SHA of its delta and the SHA of the snapshot it must reconstruct to, chained to the night before. Flip one byte anywhere and the chain breaks — reconstruction refuses.

Schema drift, solved

Rows are keyed by a stable primary key, by name; each night carries its own schema stamp. A column added, dropped, or reordered across years still reconstructs — and doesn’t blow up the nightly delta.

Honest about the numbers

The compact chain is typically 2–3× smaller than gzipping each night and grows toward ~12×over hundreds of high-overlap nights — and about 12× vs uncompressed nightly copies. A single solidxz over the concatenation is a touch smaller on pure bytes — but it cannot answer AS OFwithout unpacking everything, has no per-night tamper-evidence, and no O(checkpoint) day addressing. We pitch the query and the proof, never “smallest on disk.” The --exactrecipe adds a little per night (it stores each night’s original row order) so byte-for-byte reconstruction is guaranteed.

By default a reconstructed night is row-exact: same rows and cells as the original, in a canonical order (sorted by primary key, normalized line endings) — ideal for querying. Add --exact and AT-1 also reproduces the original file byte-for-byte(verified against its SHA-256, with a raw fallback so it is guaranteed). “Secure” here means integrity + reproducibility (tamper-evidence), not confidentiality.