Parquet & the manifest
Each job produces bounded Parquet objects and a manifest with integrity metadata.
Archive layout
Each job publishes Parquet batches and a manifest under its job UUID. Local files are staged, synced and published without overwriting existing targets. Remote destinations use durable local pending staging, create-only uploads and full SHA-256 readback; the completed manifest is published last. It records the policy, cutoff, schema, key bounds, counts, object sizes and hashes. Job byte counters exclude manifest bytes.
Type representation
PostgreSQL format 2 uses native Parquet integer, boolean and float columns, with exact numeric/date/UUID/JSON representations stored as UTF-8 plus type metadata. MySQL format 3 preserves native scalar representations as text, including unsigned integers, exact decimals and hex binary. MongoDB format 4 stores an ObjectId envelope and hex-encoded raw BSON, preserving types, field order and binary data rather than flattening documents. These archives are not interchangeable cross-engine tables.
Integrity and trust
verify checks the completed archive against its local journal. verify-directory checks a standalone manifest and its files. A consistent checksum proves consistency with those metadata, not historical source authenticity. Importing untrusted files cannot turn them into authenticated source evidence.
Export and deletion are separate records
The manifest is immutable and describes export. Its source_deleted: false field remains unchanged after source deletion. Use archive deletion-status for the local deletion checkpoint. Keep state backups as well as archive files; imported archives cannot authorize deletion.