Practical answers

Before your first archive.

Availability, the three objectives, the qualified speed figures, the recorded walkthrough, the featured result, the evaluation, the license, the fidelity contract, and the path back to your files.

What is ZJX, and what files is it intended for?

ZJX is a Linux lossless archive system for regular files, directory trees, and safe symbolic links. On its compact and fast objectives it recognizes repeated record structure, tries several 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 files may show little gain. It complements backup, storage, and security systems rather than replacing them. Product overview

What can I use or download today, on which platforms?

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. Its Linux x86-64 package and checksums are listed in the public release record; the artifacts are held in the operator-controlled release and are requested from Greyforge Labs rather than downloaded anonymously. The package is the qualified candidate promoted unchanged and reports the version literal 1.29.0-rc3. ZJX 1.28.0 LOCKWIRE was the previous release with published assets. The local desktop wrapper is laboratory tooling, not a supported GUI download. Windows, macOS, and ARM are not claimed. Availability and access

Which objective should I choose: compact, fast, or ultrafast?

Compact when size matters: it is the default and searches several representations for the smallest complete archive. Fast when balance matters: a fixed reduced schedule that the NIGHTMARKET qualification measured at about 63.6% less creation time than compact on its four corpora with no measured size penalty. Ultrafast when wall time matters: one fixed compression attempt per unit, packed and verified in parallel with four workers by default, producing larger archives than compact or fast. Compact and fast are unchanged from 1.28.0 and write byte-identical archives on the qualification corpora. The objective changes how an archive is created, never what it restores. Create an archive and choose an objective

How fast is ultrafast, and what does that figure not mean?

Two qualified campaigns on a quiesced laboratory host measured verified creation (create, then independently verify) of the 1.29.0 default invocation against default tar | zstd -1, and they are reported separately: 1.247x on the sealed development cohort (95% [1.223, 1.267], Bonferroni-adjusted lower bound 1.221) and 1.1959x on a held-out cohort frozen before any measurement (95% [1.1867, 1.2043]). It is not a leadership claim: the same comparator with four threads is faster than the ZJX default on both cohorts, the preregistered held-out gate against it passed with a class-weighted point of 0.8236 and a 95% bootstrap lower bound of 0.8170 against a required 0.80, and ZJX was slower on 7 of 10 individual held-out cases. Ultrafast archives are larger than compact or fast archives, and the four-worker default costs about 1.19x the comparator's CPU and about 71 MB of peak memory. Both campaigns in full

What does the featured 38.1% result show, and what does it not?

It shows that on one real 342,409,609-byte service telemetry capture, ZJX on the compact objective (the same bytes in 1.28.0 and 1.29.0) wrote a complete archive of 4,412,984 bytes against 7,125,674 bytes for zpaq -m5, the strongest of the 14 comparator configurations tested at strong settings, and that every archive was restored and hash-matched. Compact and fast are unchanged in 1.29.0 (REDLINE gate P6: byte-identical archives), so the result is the current release's result; the archives were written by the 1.28.0 package on 2026-09-06. It does not show that ZJX wins on every workload, that your data will compress the same way, or that the indicative single-run laboratory timings in that campaign are performance evidence. Every configuration, exact bytes, and derivation

Is the archive walkthrough on the product page running ZJX?

No. It replays one recorded run of the released 1.28.0 package over a small synthetic project tree: the input members, the archive summary, the inspection results, and the source-versus-restored comparison were saved once and are displayed as saved. Nothing is uploaded and nothing is computed in the browser. Listing, testing, and comparing restored content are separate recorded facts. Interactive archive walkthrough

How does the commercial evaluation work?

Start with a description of what you retain and what you pay to keep it. We agree scope, data handling, and where the run happens, then you provide a representative sample of the real retention lane, sanitized if needed, plus the compressor and settings you use today. ZJX compact, fast, and ultrafast run against your current method and the same 14-configuration comparator set, in your environment or on a controlled Greyforge host. You receive complete archive bytes, creation and verification time, exact-restore evidence, memory and processing cost, and the limitations, in the same form as the published campaigns. Evaluations are scoped, paid engagements. Commercial evaluation

Where does an evaluation run, and what data must I share?

A description and reply address are enough to begin; data class, retained volume, growth rate, current compressor, and storage rate are useful context. Do not send confidential files until data handling has been agreed in writing: evaluation location, data access, sanitization, retention of samples, and deletion are all agreed before any file moves, and the run can happen inside your environment. Nothing here promises an NDA, zero telemetry, or a fixed retention period; those are terms of the written agreement. Evaluation contact

How is ZJX licensed, and what do evaluation and production cost?

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; the fee, license, packaging, support, and any compatibility commitment are agreed in writing before work starts. Public qualification does not establish a service-level agreement or production-support commitment on its own. The public evidence needed to assess the claims is readable without buying a Chronicle. License and terms

What does lossless mean, and which metadata is preserved?

Lossless means the original file contents are recovered exactly. Under the exact profile, 1.29 also restores the directory tree, permission bits including a literal 0000, nanosecond modification times, and symbolic links whose targets are relative and stay inside the archive root, on every objective. Attributes ZJX cannot carry are refused rather than dropped: setuid, setgid, and sticky bits, ACLs, capabilities, and other extended attributes make creation fail unless you consent to their loss. Hard links become independent files, sparseness is not preserved, and owners and groups are not stored. Fidelity contract

How will I restore archives in ten years?

Everything needed to restore is in the Linux package: no network, account, license server, source checkout, or developer toolchain. Inspection reports which decoders an archive needs and whether they are present before any extraction, and a dry run refuses to plan without them. A 1.29 reader restores plaintext archives from every release since 1.23 and encrypted archives from 1.27, and the 1.28.0 reader also restores every qualified 1.29 ultrafast archive. Keep the package, its checksums, and the archive's inspection record with your retention records, and agree the compatibility window and support duration in the commercial license. Offline use and restoring in ten years

How do resource limits and worker counts work?

Every operation accepts separate memory, temporary-disk, and entry-count ceilings, enforced by admission rather than discovered by crashing; too-small limits stop the operation before it starts. 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. Worker counts from 1 to 8 keep their exact meaning, requests above eight are refused with the real limit, and the archive bytes are the same at every worker count. Resource limits and automation

What changed across releases, and why were experiments rejected?

STREAMWALL bounded resource use; BLACKWIRE established the native product path; NIGHTMARKET added the Compact/Fast choice; RELICWIRE cut compact creation time on two measured datasets; CIPHERGLASS added password-protected archives; LOCKWIRE completed the workflow, fidelity contract, and package; REDLINE added the ultrafast objective with four workers by default and qualified it on two separately reported cohorts. Private 1.25 was withdrawn before public distribution. NULLSPOOL was rejected after performance regressions. GHOSTLANE's first run was invalid and its corrected campaign failed release qualification; neither shipped. Release history

Deeper detail: documentation, benchmarks, releases, public records, Greyforge product page.