The ZJX Brief.

Looking for ZJX Basic? The desktop and CLI package is available for Linux. Download Basic and read its installation instructions. This Brief documents the standalone ZJX 1.30.0 engine and its benchmark/support contracts.

A lossless archive system for structured data.

ZJX archives regular files and directory trees on Linux. Compact produces the smallest archives, fast takes less creation time while staying size-first, and ultrafast is built for the shortest wall time. Every objective restores the original bytes exactly. It is built for logs, telemetry, JSONL and NDJSON exports, and repeated engineering artifacts, where structure repeats. Data that is already compressed or encrypted gains little.

ZJX slots in beside your backup, access-control, retention, and disaster-recovery systems. A commercial evaluation measures it on your own data.

Installation and the package

ZJX 1.30.0 ships as one relocatable archive for x86-64 Linux with glibc, built for a portable baseline x86-64 target with the hardware digest implementation selected at run time. It contains two executables, a rootless installer and uninstaller, a checksum list for every packaged file, a build-provenance record, and the documentation set: README, installation guide, objectives guide, support matrix, offline restore guide, encryption notes, component list, license, and notice. Nothing in it needs a source checkout, a developer toolchain, or network access. The package and executables report the version literal 1.30.0: the qualified release build was promoted unchanged rather than rebuilt for publication.

Executables

zjx (create, list, test, inspect, restore, capabilities) and zjx-archive (an archive kept together with its checksum and validation records)

Runtime dependencies

glibc, liblzma.so.5, and libzstd.so.1, which supported distributions ship by default. The encryption component is linked statically.

External decoders

Some older archives depend on an external decoder; inspection reports each requirement, and whether it is available, before any extraction.

Installer

Verifies the checksum list, stages each executable beside its final path and renames it into place, copies the documents, and records exactly what it wrote. Upgrades replace executables atomically; removal deletes only the recorded files and never your archives.

Provenance

SHA-256 checksum files for every packaged file and every release asset, plus a build-provenance record.

Userspaces exercised

An empty home with a controlled path for 1.29.0; Ubuntu 24.04.4 base and an Arch bootstrap in clean containers for the 1.28.0 baseline. Supported platform: x86-64 Linux with glibc on local filesystems.

Release artifacts and checksums · Availability and access

Create an archive and choose a mode

Archive one path or many, with an explicit output and base directory, literal file lists, and include and exclude filters. Output inside an input directory is refused. Choose the metadata profile and one of three objectives; the objective changes how the archive is created, never what it restores.

Choose the mode per archive. In ZJX Basic that is zjx-basic create --mode smallest, --mode fast, or --mode ultrafast; smallest is the compact objective described here. In the 1.25.1 NIGHTMARKET qualification fast took about 63.6% less creation time than compact on its four corpora with no measured size penalty. Ultrafast requires the exact metadata profile, accepts --workers from 1 to 8 (four in the qualified speed configuration), and refuses larger requests with the real limit rather than clamping them. Its archive bytes do not depend on the worker count. The qualified ultrafast figures are in the 1.29 support contract.

A new archive is staged beside its final path and published with one atomic rename, so a failed run leaves no half-written result. Results report publication, cleanup, and durability state separately, and creation syncs both the staged file and its parent directory.

The recorded walkthrough on the Specs page shows one such run with the 1.28.0 package: 6 files, 1 symbolic link, 51,849 bytes in, a 5,164-byte archive out, publication committed. Handle the recorded archive

Inspect and verify

Inspection reports archive structure, decoder requirements and readiness, and manifest integrity without decoding the payload. Every archive written since 1.28 carries a manifest digest footer; archives written before 1.28 report their manifest integrity as unverified because no digest existed then. Testing verifies every payload digest without extracting; on ultrafast archives it runs a streaming parallel verifier with four workers in the qualified speed configuration. Listing enumerates members with type, size, permission bits, modification time, and link target, as a versioned record. A dry run of a restore checks the destination, decoder readiness, and the planned counts without writing.

Readiness is a dependency preflight and testing is an integrity check. Test an archive before you retire its source data.

Restore

Restore everything or selected members, by literal name, file list, or include and exclude pattern. Selection never skips verification: the whole archive is verified before anything is published. A fresh destination is staged as a private sibling directory and published with one rename; extraction into an existing directory verifies the whole archive first and then replaces files one by one through temporaries. Output operations are anchored to directory descriptors opened without following links, so a link that appears in the destination during extraction is refused rather than written through.

Parent directories that a selected restore creates carry the restore time. Use the seconds or content metadata profile on a filesystem that cannot hold nanosecond timestamps or the recorded modes.

Resource limits and automation

Every operation accepts separate memory, temporary-disk, and entry-count ceilings, enforced by admission rather than discovered by crashing: an operation that cannot fit is refused before any large allocation is made. The defaults are 1 GiB of governed working memory and 64 GiB of planned temporary capacity. Limits are admission controls, not tuning hints. Ultrafast creation admits about 65 MiB with the default settings and four workers, and testing admits about 48 MiB with the default settings (96 MiB at the maximum setting); every admission is checked against the memory limit before work starts; an over-budget request is refused, never run with fewer workers.

For pipelines: JSON results and errors, a progress record stream on standard error, and cancellation by signal with exit codes 130 and 143 and inherited cleanup. Every handled failure, argument errors included, exits 1 and under JSON output delivers one failure object naming the error category and, where relevant, the offending selector or path. Error categories cover selection, destination, fidelity, links, decoders, format, integrity, resources, cancellation, and usage; the package's support matrix lists each error name with the action to take. Every creation result records the objective and the workers requested and used.

Fidelity contract and limits

Under the exact profile, 1.30.0 restores contents, the directory tree, permission bits including a literal 0000, nanosecond modification times (epoch zero is a value, not a default), and symbolic links whose targets are relative and stay inside the archive root. Dangling links and cycles are kept as links. File names are stored byte for byte as UTF-8; non-UTF-8 names are rejected at creation. The contract is the same on every objective.

Attributes ZJX cannot carry are refused rather than dropped. FAQ: what lossless means here

Compatibility

Compatibility is measured, not presumed: the 1.28 release qualification ran compatibility rows against retained archives from each earlier writer, and the 1.29 qualification ran the frozen 1.28.0 reader against every ultrafast archive. The commercial license sets the supported compatibility window, decoder retention, and support duration.

Offline use and restoring in ten years

Everything needed to restore is in the Linux package: no network, account, license server, source checkout, or developer toolchain. Bring the package, its checksum file, and the archive to the machine; verify the package; inspect the archive for decoder requirements; test it; dry-run the restore; then restore. The package's offline restore guide walks through exactly this and lists what each failure message means.

Retain the package, its checksums, and the archive's inspection record with your retention records. FAQ: future restoration

Password-protected archives

A password-protected archive is an ordinary ZJX archive wrapped in an authenticated-encryption envelope, so file names and metadata are encrypted with the contents (Argon2id key derivation, XChaCha20-Poly1305, libsodium 1.0.22 linked statically). Passwords travel by file descriptor or standard input, never on the command line. Locked inspection reveals only a bounded public header; testing reports envelope authentication and inner integrity separately; encrypted extraction always writes a new destination. A plain creation refuses to overwrite a protected archive, so protection is never silently removed. Inherited from 1.27 CIPHERGLASS.

Security notes

• A lost passphrase cannot be recovered.
• While unlocking, ZJX writes the decrypted inner archive to private temporary storage and removes it afterwards; removal is not secure erasure.
• Encryption protects the contents, internal file names and metadata; the encrypted file's overall size stays visible.
• The cryptographic review was internal; there is no external audit or certification (such as FIPS).
• Encryption is qualified on Linux.

The 1.29 support contract

ZJX 1.30.0 is the current engine release. Against 1.29.7 it writes smaller archives in every compact and fast measurement, packs 1.5x to 4.1x faster in those objectives, and restores fast and ultrafast archives faster on all five public corpora, with the same archive format as the 1.29 line. Against 1.29.7 on five public corpora and one laboratory host: smaller compact and fast archives in every measurement, 1.5x to 4.1x faster creation in those objectives, and faster fast and ultrafast restores on every corpus, each restore checked against the content digest.

• Three creation objectives: compact, fast and ultrafast, selected per archive
• Compact and fast: smaller archives than 1.29.7 on all five public corpora measured, created 1.5x to 4.1x faster
• Faster restores: fast and ultrafast archives restore faster than on 1.29.7 on all five corpora
• The 1.29 archive format: 1.29.7 restored every 1.30.0 archive in the release measurements
• Every integrity guarantee: content, manifest and archive digests, exact metadata, atomic publication
• The same portable baseline x86-64 build, relocatable Linux package layout, rootless installer, checksums, build provenance, and offline restore guide as the 1.29 line
• Everything in the 1.28.0 workflow and fidelity contract carried forward

Qualified speed, two campaigns kept apart. Verified creation: archive creation plus an independent integrity check, 12 paired rounds per campaign, class-weighted geometric mean of per-round ratios, 95% bootstrap intervals. Subject: ZJX 1.29.0 ultrafast objective, four workers, then an independent test. Host: Dedicated, quiesced laboratory host, 8 logical CPUs; the measured executable is the one shipped in the released package. On the development cohort (Sealed development cohort: silesia, enwik8, and a synthetic deduplication case; 12 paired rounds, 468 of 468 cells usable), the qualified ultrafast configuration with four workers created and verified archives 1.247x faster than default tar | zstd -1 (95% [1.223, 1.267]; Bonferroni over the three preregistered primary comparisons, lower bound 1.221). On the held-out cohort (Four sealed members plus six privately held-out cases (about 1.86 GB, six workload classes) selected by a rule frozen before any measurement; ten classes, 12 paired rounds, 360 of 360 cells usable, run once), the same configuration measured 1.1959x default tar | zstd -1 (95% [1.1867, 1.2043]), with 6 of 6 held-out cases restored exactly before the timed rounds. The two figures come from different cohorts and are never combined.

The held-out gate. The preregistered held-out gate passed on the published package. Per-case results

Choosing ultrafast. Both headline figures compare ZJX ultrafast with four workers against default tar | zstd -1; the per-case results are on the benchmarks page. Ultrafast is the choice when wall time matters; compact and fast write the smallest archives for long-term storage. Against released 1.28.0 fast, ultrafast measured a creation ratio of 335x and a verified-creation ratio of 253x on that cohort at the diagnostic tier, four-member cohort including the service telemetry capture; 3 paired rounds.

Memory of the four-worker configuration. Creation admits about 65 MiB with the default settings and four workers and peak resident memory measured about 71 MB at four workers; testing admits about 48 MiB with the default settings (96 MiB at the maximum setting). Every admission is checked against the memory limit before work starts; an over-budget request is refused, never run with fewer workers. --workers 1 writes identical archive bytes.

Qualification status. Every REDLINE product gate passed on the frozen release build that became the published package: exact restoration at the qualified ultrafast configuration with four workers and at one and four workers on every qualified corpus, including six unseen held-out cases; the frozen 1.28.0 reader restoring every ultrafast archive; the predecessor speed gate; the held-out integration gate above; useful compression on the predesignated public corpora; compact and fast byte-identical to 1.28.0 with no measured slowdown; the bounds, cancellation, and progress suites; and the package alone, in an empty path, creating, testing, and restoring every qualified corpus. Two independent read-only reviews closed before the freeze.

Corpora. The qualified figures come from the named cohorts on the laboratory host. The public corpora are silesia and enwik8.

1.29.0 REDLINE public release record: artifacts, checksums, and verification · 1.29 REDLINE source note · 1.29 REDLINE Chronicle · Release entry · Both campaigns on the benchmarks page

The 1.28 baseline

ZJX 1.28 LOCKWIRE completed the supported Linux archive workflow; its release qualification passed every gate and ZJX 1.28.0 was released on 2026-09-06. It is the previous release with published assets. 1.29 carries the whole 1.28 workflow and fidelity contract forward; the list below is still the contract. LOCKWIRE completed the product: for input the earlier format could already represent, it writes the same archive bytes as the accepted 1.27 baseline plus a 16-byte manifest-integrity footer (144 of 144 byte-identity rows), and 1.29 compact and fast write the same bytes again.

• Create an archive from one or many inputs, with file lists and include/exclude filters
• List members without extracting; restore everything or selected members after whole-archive verification
• Preserve directory trees, contents, permission bits, nanosecond timestamps, and safe relative symbolic links; refuse silent metadata loss
• Password-protected archives inherited from 1.27
• Machine-readable results, progress records, and bounded cancellation for automation
• A relocatable Linux x86-64 package with a rootless installer, checksums, build provenance, and an offline restore guide
• Reads plaintext archives from every release since 1.23 BLACKWIRE and encrypted archives from 1.27

Qualification status. Every 1.28 LOCKWIRE gate passed on the frozen 1.28.0 release build: fidelity, publication, selection, listing, progress, and cancellation suites; compatibility rows against retained archives from the 1.23, 1.25.1, 1.26, and 1.27 writers; installed-package runs of the published package in two clean userspaces; scale floors including a file above 4 GiB and trees of 1,000, 10,000, and 100,000 entries; nine bounded defensive parser families with zero defects; a measured cancellation budget; 144 of 144 byte-identity rows; and paired performance rows against the 1.27 baseline on a quiesced laboratory host with no regression threshold crossed.

Operating notes. Archives written before 1.28 predate the manifest digest, so rewrite long-lived ones with 1.28 or later to gain it. Cancellation cleans up everything the operation started. Builds reproduce byte for byte.

1.28.0 LOCKWIRE public release record · 1.28 LOCKWIRE source note: the full support contract · Release entry

Results

Public benchmark. ZJX Basic 1.0.3 wrote the smallest archive of all 15 settings measured on the public http_logs-181998 corpus (363,512,754 bytes of real web-server access logs from the public Elastic Rally http_logs corpus, one JSON record per line): 12,158,244 bytes, 18.6% smaller than xz -9e, and its fast mode compressed 2.4x faster than xz -9e. Every archive was restored and checked byte-for-byte by SHA-256. The build, corpus, commands and raw results are public: reproduce it from GreyforgeLabs/zjx-benchmarks.

Release-note history. ZJX 1.29.0 compact result, unchanged from 1.28.0. Measured 2026-09-06 with the ZJX 1.28.0 LOCKWIRE executable (executable SHA-256 prefix 10ee0d9e, the executable shipped in the 1.28.0 Linux package) on one real service telemetry JSONL capture: 342,409,609 bytes. ZJX compact wrote 4,412,984 bytes; the strongest of the 14 comparator configurations, zpaq -m5, wrote 7,125,674 bytes: 38.1% smaller. Every archive was restored and matched against the source hash. ZJX speed is qualified in the 1.29 support contract. The 1.29.0 release gate confirmed byte-identical compact and fast archives against 1.28.0, so this result, written by the 1.28.0 LOCKWIRE executable on 2026-09-06, is the 1.29.0 result.

The full table, derivation, verification scope, and historical records moved to the benchmarks page, which also carries both REDLINE speed campaigns. Source note: commands, tool versions, hashes, per-run observations

Availability and license

ZJX 1.30.0 is the current engine release. Against 1.29.7 it writes smaller archives in every compact and fast measurement, packs 1.5x to 4.1x faster in those objectives, and restores fast and ultrafast archives faster on all five public corpora, with the same archive format as the 1.29 line. The Linux x86-64 package and its checksums are listed in the public release record. ZJX 1.29.6.6 (2026-10-12) was the previous release with published checksums, and 1.29.7 (2026-10-19, lighter restores) was qualified and first distributed inside 1.30.0; 1.29.0 REDLINE (2026-09-08) began the 1.29 line, and ZJX 1.28.0 LOCKWIRE preceded it; ZJX 1.27 CIPHERGLASS was qualified on the same lineage and first shipped inside 1.28.0. ZJX is a command-line product for x86-64 Linux.

The standalone engine is licensed under the PolyForm Noncommercial License 1.0.0. Commercial evaluation, deployment, embedding, resale, hosted use, managed archival services, and internal business use require a separate written commercial license from Greyforge Labs. Evaluations are scoped, paid engagements. Package access, licensing, and the evaluation route are on Get ZJX.

Moved sections

Earlier Brief sections keep their anchors here and continue at their new home.

• 1.26 RELICWIRE, less creation time: releases page
• 1.25.1 NIGHTMARKET, choose your priority: releases page
• 1.23 BLACKWIRE, one native product path: releases page
• 1.21 STREAMWALL, explicit resource limits: releases page
• How to read a measurement: benchmarks page
• Evidence links: research index