The ZJX Brief.

A lossless archive system for structured data.

ZJX archives regular files and directory trees on Linux. On its compact and fast objectives it recognizes repeated record structure, generates several candidate representations, and keeps whichever produces the smallest complete archive; on the ultrafast objective it takes one fixed compression attempt per unit in parallel. Every objective restores the original bytes exactly. Logs, telemetry, JSONL and NDJSON exports, and repeated engineering artifacts are its target workloads. Already-compressed, encrypted, or low-redundancy inputs may show little gain.

ZJX is an archive tool. Your backup, access-control, retention, and disaster-recovery systems keep their jobs. Results on one dataset do not establish the outcome on another; the commercial evaluation exists to measure yours.

Installation and the package

ZJX 1.29 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.29.0-rc3: the qualified candidate 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 archives record a dependency on an external xz, brotli, or zstd executable; 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

The checksum files are the provenance mechanism of the release. They are not signatures, and no signature is claimed.

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. Windows, macOS, ARM, musl, network filesystems, and other filesystems' metadata semantics are not claimed.

Release artifacts and checksums · Availability and access

Create an archive and choose an objective

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.

Compact is the default. The NIGHTMARKET qualification measured fast at about 63.6% less creation time than compact on its four corpora with no measured size penalty; that is fast versus compact, not a competitor comparison. Ultrafast requires the exact metadata profile, accepts --workers from 1 to 8 (four by default), 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; atomic publication and power-loss durability are different claims, and only the stage and parent-directory sync of creation is promised.

The recorded walkthrough on the product 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 by default. 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.

None of these is the same as comparing restored files with the originals. Readiness is a dependency preflight, not an integrity result; test before trusting or replacing 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.

Solid archives decode in full for listing and selected extraction. 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 the large allocation or codec state is created. 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 at the default 4 MiB units and four workers, and testing admits about 48 MiB at 4 MiB chunks (96 MiB at the 8 MiB ceiling); 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 receipt records the objective, the recipe identity, and the workers requested and used.

Fidelity contract and limits

Under the exact profile, 1.29 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. Agree the supported compatibility window, decoder retention, and support duration in the commercial license; source availability under the noncommercial license is not a support commitment.

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. A lost password cannot be recovered. Inherited from 1.27 CIPHERGLASS and qualified on Linux only.

The 1.29 support contract

ZJX 1.29 REDLINE is the current release line. It adds the ultrafast objective beside compact and fast, with four workers by default; every REDLINE product gate passed on the frozen candidate and ZJX 1.29.0 was released on 2026-09-08. REDLINE is a speed release for one objective. Its qualified figures are verified-creation ratios against default tar | zstd -1 on a quiesced laboratory host, from two campaigns that are reported separately and never merged: 1.247x on the sealed development cohort and 1.1959x on a held-out cohort frozen before measurement. The same comparator with four threads is faster than the ZJX default; no benchmark leadership is claimed. Ultrafast archives are larger than compact or fast archives.

• Three creation objectives: compact (default), fast, and the new ultrafast, selected per archive
• Ultrafast: four workers by default on creation and on testing; --workers 1 to 8 keeps its exact meaning; requests above eight are refused with the real limit, never clamped
• Archive bytes independent of the worker count: 1, 2, 4, and 8 workers and the default produce identical archives on every qualified corpus
• Every integrity guarantee of the other objectives: per-chunk digests, manifest and archive digests, exact metadata, atomic publication
• Compact and fast archives byte-identical to 1.28.0's, with no measured slowdown; a 1.28.0 reader tests, inspects, and restores every 1.29 ultrafast archive
• Capabilities report the default and maximum worker counts and the fixed ultrafast recipe identity; every receipt records the workers requested and used
• A portable baseline x86-64 build with the hardware digest implementation selected at run time; the same relocatable Linux package layout, rootless installer, checksums, build provenance, and offline restore guide as 1.28.0
• Everything in the 1.28.0 workflow, fidelity contract, and boundaries carried forward unchanged

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 at its default invocation: --objective ultrafast, four workers, then an independent test. Host: Quiesced laboratory host under an exclusive lease, 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 default invocation 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) at 1.0005x the archive bytes and about 1.19x the CPU; Development cohort, not held out; the recipe was calibrated on these corpora. 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 default 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 and its margin. The preregistered gate compared the default invocation with the matched thread budget, tar | zstd -1 -T4, as a class-weighted geometric mean over ten declared classes: point 0.8236, 95% bootstrap interval on a single preregistered comparison; no familywise adjustment, lower bound 0.8170 against a required 0.80. It passed. ZJX was slower than that comparator on 7 of 10 individual cases and faster on the three large-record cases; the six held-out cases alone aggregate to 0.7917 [0.7832, 0.8004], which would not have met the lower bound. The verdict is the preregistered one; the margin is disclosed so the reader can weigh it. On the development cohort the same comparator was faster by the same order: ZJX kept 82.0% of its throughput (95% [0.807, 0.832]).

What is not claimed. ZJX 1.29 is not the fastest archiver or compressor and is not generally superior to zstd. tar | zstd -1 with four or all threads is about 1.22x faster than the ZJX default on the development cohort and faster on 7 of 10 held-out cases. No leadership claim is made. Ultrafast archives are larger than compact or fast archives of the same input (ultrafast archives were 27% to 1,000% larger than fast's on those corpora on the four-member cohort); choose compact or fast for long-term storage where size matters. 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 real telemetry capture; 3 paired rounds: a within-product comparison of two objectives with different goals, not a competitor result.

Resource cost of the four-worker default. Creation admits about 65 MiB at the default 4 MiB units and four workers and peak resident memory measured about 71 MB at four workers against about 12 MB at one; testing admits about 48 MiB at 4 MiB chunks (96 MiB at the 8 MiB ceiling). Every admission is checked against the memory limit before work starts; an over-budget request is refused, never run with fewer workers. --workers 1 restores the single-buffer profile with identical archive bytes.

Qualification status. Every REDLINE product gate passed on the frozen candidate that became the published package: exact restoration at the default invocation 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; bounds, cancellation, and progress suites at the freeze revision; and the package alone, in an empty path, creating, testing, and restoring every qualified corpus. Two independent read-only reviews closed before the freeze. A resource-governor defect in the parallel verifier (helper threads updating the memory account off the coordinator thread, a rare panic on small archives at four or eight workers) was found during qualification, fixed with a regression test, and requalified in full; it is the only code change between the second and third release candidates.

Documented limitations. The qualified figures are laboratory-host results on the named cohorts under the named comparators; they do not predict another machine or workload. The held-out gate passed by a thin margin that depends on its preregistered class structure. The private telemetry capture and the six held-out cases are not redistributed; public corpora are silesia and enwik8. Everything under the 1.28.0 documented limitations remains in force.

1.29.0 REDLINE public release record: artifacts, checksums, and verification · 1.29 REDLINE source note: the qualified figures and what is not claimed · Release Chronicle, including what REDLINE did not achieve · 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, fidelity contract, and boundaries forward unchanged; the list below is still the contract. LOCKWIRE was a product-completion release, not a compression release: 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 LOCKWIRE gate passed on the frozen 1.28.0 candidate: 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. This Brief quotes no LOCKWIRE speed or size figure; none was qualified as a marketing claim.

Documented limitations carried into 1.29. Archives written before 1.28 carry no manifest digest, so a relabelled member name in such an archive is not detectable. Defensive testing is bounded evidence under a declared budget, not a proof of immunity. Cancellation reaps the operation's owned decoder child; the supported decoders are single processes. Reproducibility is established under the fixed build-path recipe only.

1.28.0 LOCKWIRE public release record · 1.28 LOCKWIRE source note: full support contract and what is not claimed · Release entry

Results

ZJX 1.29.0 compact result, unchanged from 1.28.0 (REDLINE gate P6: byte-identical archives). Measured 2026-09-06 with the ZJX 1.28.0 LOCKWIRE executable (source revision 30307f19, 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. Timing is indicative only. The ZJX rows carry the current version, 1.29.0, because compact and fast are unchanged from 1.28.0: REDLINE gate P6 confirmed byte-identical compact and fast archives against 1.28.0, so the same software writes the same bytes and the campaign was not rerun. The archives themselves were written by the 1.28.0 LOCKWIRE executable on 2026-09-06.

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.29 REDLINE is the current release line. It adds the ultrafast objective beside compact and fast, with four workers by default; every REDLINE product gate passed on the frozen candidate and ZJX 1.29.0 was released on 2026-09-08. The Linux x86-64 package and its checksums are listed in the public release record. ZJX 1.28.0 LOCKWIRE (2026-09-06) was the previous release with published assets; ZJX 1.27 CIPHERGLASS was qualified on the same lineage and was distributed for the first time inside 1.28.0. The local desktop wrapper is laboratory tooling, not a supported GUI download. No Windows or macOS release is announced.

ZJX 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
• Research experiments: 1.22 NULLSPOOL and 1.24 GHOSTLANE
• How to read a measurement: benchmarks page
• Evidence links: research index