# ZJX 1.29.0 REDLINE public release record Published: 2026-09-08 Status: released Release: ZJX 1.29.0 REDLINE Tag: `v1.29.0` This is the scrubbed public proof record derived from the canonical release record and the authenticated release metadata. It excludes private repository paths, host details, credentials, and internal evidence directories. ## Release identity - Release publication time: `2026-09-08T14:53:42Z` - Draft: no - Prerelease: no - Target: Linux x86-64 (glibc), unprivileged user operation - Build mode: `ReleaseSafe`, portable baseline x86-64 processor target with the hardware SHA-256 implementation selected at run time (the 1.28.0 package was tuned to its build host; this one is not) - Compiler version: Zig 0.16.0 (pinned) - Static component: libsodium 1.0.22 - Embedded product revision: `0115105b` (the frozen third release candidate; the annotated tag dereferences to the same revision) - Reported identity: `zjx 1.29.0-rc3 (0115105b..., ReleaseSafe)` - Specification: REDLINE Revision 0.1 (SHA-256 prefix `c8d0fffe`) with the prospective Amendment A1 (four workers by default; SHA-256 prefix `cb582f64`) The published package and executables are the qualified third release candidate **promoted unchanged**. They carry the version literal `1.29.0-rc3` because they are byte for byte the artifacts every gate below was measured on. Nothing was rebuilt, repackaged, or edited for publication: REDLINE rule RL-033 requires publication to use the tested artifact and verify its hash, never to replace it. The earlier candidates `1.29.0-rc1` and `1.29.0-rc2` were frozen evidence only and were never published. ## Release artifacts | Asset | Bytes | Release-asset SHA-256 | |---|---:|---| | `zjx-1.29.0-rc3-linux-x86_64.tar.gz` | 4,847,589 | `ce48b6923fecac2e68cd463d863b0b361d9ab239c74c4ced6d28e88b3e72d23d` | | `zjx-1.29.0-rc3-linux-x86_64.tar.gz.sha256` | 101 | `402b730056eefcd26a20a132c8820647d3525bcae02185ac96fc2ab7a41437f5` | | `zjx-1.29.0-source.tar.gz` | 283,242 | `3865057c9417692afeafc8987a873db38055c0ea36d4b4776cd35a31677bb789` | | `zjx-1.29.0-source.tar.gz.sha256` | 91 | `ca7432bb27c2bb0e114bf5e9072b7e8ed7e8a08a96eb8d28b06dfef1a389e020` | The package contains `bin/zjx` (SHA-256 `636af810b567098a1ee65201a9e408284585f2abcaf0dac1abacb43abe69796d`), `bin/zjx-archive` (SHA-256 `0ba769161b11f33c5b161b9760cf6672cf0cb73b0043565f5c2ba8dec7ecc1f8`), a rootless `install.sh`, `INSTALL.md`, `SHA256SUMS`, `PROVENANCE.json`, and the user documentation (`OBJECTIVES.md`, `SUPPORT_MATRIX.md`, `OFFLINE_RESTORE.md`, `COMPONENTS.md`, `ENCRYPTION.md`, `ENCRYPTION_FORMAT.md`, README, LICENSE, NOTICE). The source archive is the public native product surface of the frozen revision produced by the repository's release recipe; research infrastructure and retained qualification material are excluded. The checksum files are the provenance mechanism of the release; they are not signatures. All four artifacts were retrieved from the operator-controlled release through two authenticated paths and revalidated. The package hashed to the frozen candidate identity on both paths and was byte-identical to the retained laboratory-built file; both digest sidecars verified; the source archive hashed to its generated identity. The downloaded package verified its own `SHA256SUMS` (15 of 15), reported the identity above, and carried a `PROVENANCE.json` naming version `1.29.0-rc3`, source `0115105b`, the baseline processor target, and `ReleaseSafe`. Its capabilities report lists four default workers, eight maximum effective workers, and the fixed ultrafast recipe identity (SHA-256 prefix `897b2375`). In an empty home with a controlled `PATH`, the package installed rootless into a prefix containing a space, created an archive of a tree containing a symbolic link on the ultrafast objective with a receipt recording four requested and four effective workers, inspected it, tested it, listed its 15 members, restored it byte for byte with the exact link target, and uninstalled leaving the user's data in place. ## Distribution The repository that holds the release is private. Its release assets are not reachable anonymously, and the public site does not present a download link for them. Package access is requested from Greyforge Labs: . Anyone who receives the package should verify it against the checksums above before installing. ## What 1.29.0 delivers A third creation objective, `ultrafast`, beside the unchanged `compact` (default) and `fast`. Ultrafast makes one Zstandard level-1 attempt per unit with pass-through as the fallback, runs no candidate search, no solid encoding, and no dictionary training, and keeps every integrity guarantee of the other objectives: per-unit SHA-256, manifest and archive digests, exact metadata, atomic publication. It ships with a deterministic parallel packer and a streaming parallel verifier that use four workers by default on creation and on testing (prospective Amendment A1) and accept `--workers` from 1 to 8 with its exact meaning; requests above eight are refused with the real limit, never clamped. Archive bytes do not depend on the worker count: the default, 1, 2, 4, and 8 workers produce identical archives, byte-identical to both earlier release candidates, on every qualified corpus. The recipe identity is unchanged from the candidates (`ultrafast.v1`, Zstandard level 1, 4 MiB units, digest prefix `897b2375`) and is published by the capabilities report and recorded in every receipt. Compact and fast archives are byte-identical to 1.28.0's on the qualification corpora, with no measured slowdown. ## Qualified performance Measured on the qualification host (8 logical CPUs, quiesced under an exclusive lease), with the executable shipped in the package above. Verified creation is archive creation plus an independent verification; paired rounds; class-weighted geometric means of per-round ratios; 95% bootstrap intervals over rounds. A ratio is comparator time over ZJX time, so a value above 1 means ZJX was faster. Two campaigns measured two cohorts; their figures are never combined. - Development cohort (silesia, enwik8, a synthetic deduplication case; 12 paired rounds; 468 of 468 cells usable): the default invocation is **1.247x** the verified-creation speed of default `tar | zstd -1` (95% [1.223, 1.267], Bonferroni-adjusted lower bound 1.221 over the three preregistered primary comparisons) at 1.0005x the archive bytes and about 1.19x the CPU. This cohort is the one the recipe was calibrated on. - Held-out cohort (four sealed members plus six privately held-out cases selected by a rule frozen before any measurement; ten classes; 12 paired rounds; 360 of 360 cells usable; run once): **1.1959x** the default `tar | zstd -1` lane (95% [1.1867, 1.2043]). - Against released 1.28.0 `fast` on the four-member cohort (diagnostic tier, 3 paired rounds): a creation ratio of 335x and a verified-creation ratio of 253x, producing archives 27% to 1,000% larger (the objective's tradeoff). `BENCHMARK_LEADERSHIP_QUALIFIED = NO`. ZJX 1.29 is not the fastest archiver or compressor, is not generally superior to zstd, and is slower than `tar | zstd -1 -T4` and `-T0` (about 1.22x on the development cohort: ZJX kept 82.0% of the four-thread comparator's throughput, 95% [0.807, 0.832]). The competitor field a leadership claim would require (including LZ4 and snappy at multithreaded settings) was never assembled, so no leadership claim is eligible. No leadership claim is made. ## Held-out P4 disclosure The competitive-integration-overhead gate P4 was run once against a private holdout frozen by a selection rule fixed before any enumeration. The rule named six workload classes (production telemetry, event-stream ticks, application logs, agent session traces, database snapshots, and repository working trees), required real pre-existing operational data between 64 MiB and 1 GiB per case disjoint from every sealed corpus, and selected one case per class by a hash seeded with the package digest; no compressor ran on any candidate during enumeration, selection, or snapshot. The six cases total about 1.86 GB; their identities and digests are recorded in the retained evidence and are not published. Every held-out case restored exactly at the default invocation before the timed rounds (6 of 6). The gate passed its prospectively frozen acceptance rule, and the margin was thin: - gate lane: matched-backend control `tar | zstd -1 -T4`, class-weighted geometric mean of paired verified-creation ratios over ten declared classes, point estimate **0.8236**; - 95% bootstrap lower bound **0.8170** against a required lower bound of **0.80** (a single preregistered comparison; no familywise adjustment was needed); - ZJX was slower than the `-T4` 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**, 95% [0.7832, 0.8004], which would not have met the lower bound; with the two telemetry captures counted as one class, the ten-case reading is 0.7913; - the preregistered class-weighted gate nevertheless passed, and that verdict is the one recorded. This is disclosed as engineering transparency, not as a marketing figure. ## Resource tradeoff of the four-worker default - CPU: about 1.19x the CPU of default `tar | zstd -1` on the development cohort; less CPU than `-T4` on the large-record held-out cases and more on the small-archive and many-file cases. - Memory: creation admits a ring of two units per worker with input and output buffers plus one codec context per worker and one for the writer, about 65 MiB at the default 4 MiB units and four workers; peak RSS measured about 71 MB at four workers against about 12 MB at one. Testing self-contained archives 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. ## Qualification summary Every REDLINE product gate passed on the package above: P1 exact restoration at the default invocation and at one and four workers on every qualified corpus, including the six unseen held-out cases; P2 frozen-1.28.0-reader compatibility (the 1.28.0 binary tests, inspects, and restores every ultrafast archive); P3 predecessor speed gain (diagnostic tier, as stated above); P4 held-out integration overhead (as disclosed above); P5 useful compression on the predesignated public corpora; P6 legacy regression (compact and fast byte-identical to 1.28.0 with no measured slowdown); P7 bounds, cancellation, and progress suites at the freeze revision, including the new regression test for the verifier; P8 clean-userland package (the package alone, in an empty `PATH`, created, tested, and restored every qualified corpus at the default invocation). Two independent read-only reviews closed before the freeze. `ULTRAFAST_PRODUCT_QUALIFIED = YES`; `BENCHMARK_LEADERSHIP_QUALIFIED = NO`. A `ReleaseSafe` resource-governor defect in the parallel verifier (helper threads updating the governor's memory account off the coordinator thread; a panic in about one verification in a hundred of a small archive at four or eight workers) was found during qualification of the second candidate. The package built from that candidate and its campaigns were voided. The fix moves every governed allocation for the verifier onto the coordinator thread and carries a regression test; the third candidate was frozen, packaged once, and requalified in full, with a second independent review. It is the only code change between the second and third release candidates, and it costs about ten milliseconds per multi-worker test. ## 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 six held-out cases alone would not have met the lower bound. - Ultrafast archives are larger than compact or fast archives of the same input; compact and fast remain the choice for long-term storage. - Ultrafast requires the exact metadata profile; worker requests above eight are refused with the real limit. - The private telemetry capture and the six held-out cases are not redistributed. Public corpora: silesia, enwik8. - A rebuild at the tagged revision would report `1.29.0`, not `1.29.0-rc3`; the shipped package's `PROVENANCE.json` is the truth for the published bytes. - Everything under the [1.28.0 LOCKWIRE documented limitations](https://greyforge.tech/research/zjx-1-28-lockwire-release-record-2026-09-06.md) remains in force; 1.29 changes none of them. ## Public claim boundary The release adds one objective and qualifies it. It does not claim benchmark leadership, general superiority to zstd, any result for LZ4, any result at a one-worker default (the product default is four), equal-ratio superiority (ultrafast archives are 0.05% to 10% larger than `tar | zstd -1` archives on the qualified cohorts and larger than compact or fast archives), a cross-platform release, or an externally audited product. Windows, macOS, ARM, musl, and network filesystems are not claimed. The local desktop wrapper is laboratory tooling and is not part of the package. ## Version ordering 1.28.0 LOCKWIRE (tag `v1.28.0`, 2026-09-06) was the previous release with published assets; 1.29.0 REDLINE follows it directly. The `1.29.0-rc1` and `1.29.0-rc2` candidates were frozen evidence only and were never published. Qualified figures, method, and what is not claimed: [1.29 REDLINE public source note](https://greyforge.tech/research/zjx-1-29-redline-source-note-2026-09-08.md). Release Chronicle (free): . Product page: . Product site: .