# ZJX 1.29 REDLINE public source note

Published: 2026-09-08
Status: current ZJX release line; ZJX 1.29.0 released 2026-09-08 (tag v1.29.0); see the public release record for artifacts and checksums

## Claim boundary

ZJX 1.29 REDLINE is a speed release for one objective. It adds `ultrafast` beside the unchanged `compact` and `fast`, runs it with four workers by default, and qualifies it with two verified-creation campaigns against default `tar | zstd -1` on a quiesced laboratory host. The two campaigns measured different cohorts and are reported separately in this note and everywhere else; they are never combined into one statistic.

What the release claims: on the sealed development cohort, the 1.29.0 default invocation created and verified archives 1.247x faster than default `tar | zstd -1` (95% [1.223, 1.267]; Bonferroni-adjusted lower bound 1.221); on a held-out cohort frozen before any measurement, 1.1959x (95% [1.1867, 1.2043]). What it does not claim: benchmark leadership. The same comparator with four threads is faster than the ZJX default on both cohorts, and the preregistered held-out gate against it passed by a thin margin that this note discloses in full. `BENCHMARK_LEADERSHIP_QUALIFIED = NO`.

Compact and fast are unchanged: on the qualification corpora their archives are byte-identical to 1.28.0's, with no measured slowdown. The featured archive-size result on the public site was measured with the 1.28.0 package and stays attributed to it.

The release itself, its artifacts, and their checksums are in the [public release record](https://greyforge.tech/research/zjx-1-29-redline-release-record-2026-09-08.md). The published package (`zjx-1.29.0-rc3-linux-x86_64.tar.gz`, SHA-256 `ce48b6923fecac2e68cd463d863b0b361d9ab239c74c4ced6d28e88b3e72d23d`) and its executables are the qualified third release candidate promoted unchanged; they report the version literal `1.29.0-rc3`, and nothing was rebuilt for publication. ZJX 1.28.0 LOCKWIRE was the previous release with published assets; its [source note](https://greyforge.tech/research/zjx-1-28-lockwire-source-note-2026-09-05.md) remains the full statement of the workflow, fidelity, and compatibility contract that 1.29 carries forward unchanged.

Product page: <https://greyforge.tech/products/zjx>
Product site: <https://zjx.greyforge.tech/>
Free release Chronicle (1.29 REDLINE): <https://greyforge.tech/chronicles/zjx-1-29-redline>
The 1.29 support contract in the Brief: <https://zjx.greyforge.tech/docs.html#redline>

## The ultrafast objective

- Selected per archive with `--objective ultrafast`; `compact` (the default) and `fast` are unchanged.
- One Zstandard level-1 attempt per 4 MiB unit with pass-through as the fallback when compression does not pay. No candidate search, no solid encoding, no dictionary training.
- A deterministic parallel packer for creation and a streaming parallel verifier for testing, four workers by default on both (prospective specification Amendment A1). `--workers` from 1 to 8 keeps its exact meaning; `--workers 1` restores the single-buffer profile; 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 on every qualified corpus, byte-identical to both earlier release candidates.
- Every integrity guarantee of the other objectives is kept: per-unit SHA-256, manifest and archive digests, exact metadata, atomic publication.
- Requires the exact metadata profile.
- The capabilities report publishes the default and maximum worker counts and the fixed recipe identity (`ultrafast.v1`, Zstandard level 1, 4 MiB units, digest prefix `897b2375`); every receipt records the objective, the recipe identity, and the workers requested and used.
- Memory admission at the four-worker default: about 65 MiB for creation (a ring of two units per worker with input and output buffers, one codec context per worker and one for the writer) and about 48 MiB for testing at 4 MiB chunks (96 MiB at the 8 MiB ceiling). Peak RSS measured about 71 MB at four workers against about 12 MB at one. Every admission is checked against the memory limit before work starts; an over-budget request is refused, never run with fewer workers.

## Measurement method

- Subject: ZJX 1.29.0 at its default invocation (`--objective ultrafast`, four workers, then an independent test), the executable shipped in the published package (SHA-256 prefix `636af810`).
- Metric: verified creation, archive creation plus an independent integrity verification, wall time.
- Comparators: `tar | zstd -1` at its default (one admitted thread), verified by `zstd -t`; and `tar | zstd -1 -T4`, the matched thread budget. zstd 1.5.5.
- Design: two warmup plus twelve measured paired rounds per campaign, randomized order within each round, stopping count fixed in advance; paired per-round ratios (comparator time over ZJX time, so a value above 1 means ZJX faster); class-weighted geometric mean over declared workload classes; 95% bootstrap intervals over rounds (10,000 resamples, fixed seed). Bonferroni adjustment over the three preregistered primary comparisons on the development campaign; the held-out gate is a single preregistered comparison and carries no familywise adjustment.
- Host: a quiesced Linux x86-64 laboratory host with 8 logical CPUs under an exclusive qualification lease; the same host built the package once, and the measured binary is the shipped binary. Absolute seconds are not published; ratios and intervals are.
- Both campaigns were preregistered before the candidate was packaged; every measured cell was usable and none was excluded.

## Campaign 1: sealed development cohort

Cohort: silesia (public), enwik8 (public), and a deterministic synthetic deduplication case; 12 paired rounds; 468 of 468 cells usable. This is the cohort the ultrafast recipe was calibrated on, which is why it is not the only evidence.

| Comparison | Ratio | 95% bootstrap | Reading |
|---|---:|---|---|
| ZJX default vs `tar \| zstd -1` (default) | 1.247x | [1.223, 1.267] | primary; Bonferroni-adjusted lower bound 1.221; ZJX faster |
| ZJX default vs `tar \| zstd -1 -T2` | 0.964x | [0.947, 0.980] | exploratory; ZJX slower |
| ZJX default vs `tar \| zstd -1 -T4` | 0.820x | [0.807, 0.832] | exploratory; ZJX slower |
| ZJX default vs `tar \| zstd -1 -T0` | 0.820x | [0.806, 0.836] | exploratory; ZJX slower |

Worker sweep against default `tar | zstd -1` (exploratory): `--workers 1` 0.548x [0.539, 0.555]; `--workers 2` 1.062x [1.046, 1.077]; default (four workers) 1.247x [1.223, 1.267]; `--workers 4` explicit 1.261x [1.242, 1.282]; `--workers 8` 0.976x [0.962, 0.987]. The default is statistically indistinguishable from an explicit `--workers 4` (0.989x [0.967, 1.012]). Archive bytes across the cohort were 1.0005x the comparator's. CPU: about 1.19x the default comparator's.

Negative results kept: eight workers is slower than four and slower than the default comparator; the four-worker default trails the comparator at two, four, and all threads; the final figure, 1.247x, came in below the interval an earlier candidate had recorded on this host ([1.273, 1.310]), and the earlier number is not quoted as current.

## Campaign 2: held-out cohort, one shot

The holdout was built to remove the author's hand from the selection. An eligibility rule was written and digested before anything was enumerated: six workload classes (production telemetry captures, event-stream ticks, application logs, agent session traces, database snapshots, repository working trees), real data that already existed for ordinary operational reasons, between 64 MiB and 1 GiB per case, disjoint by digest and by origin from every sealed corpus, never used to calibrate any REDLINE recipe or default. Within each class the eligible candidates were ordered by a hash seeded with the package digest and the first was selected. No compressor ran on any candidate during enumeration, selection, or snapshot (`HOLDOUT_SELECTION = PROSPECTIVE`; performance unseen at the freeze). The selection was snapshotted with a manifest, shipped to the laboratory host, digest-verified there, and measured exactly once against the unchanged package. Identities and digests are recorded in the retained evidence; the bytes are private and are not published.

The six held-out cases total about 1.86 GB: a production telemetry capture from a later day than the sealed one (821,029,763 bytes), an event-stream tick log (90,770,011), an application log (195,392,109), an agent session trace (84,846,090), a database snapshot (95,162,368), and a repository working tree of 24,997 files (575,334,250). They were measured alongside the four sealed members (the 2026-06-03 telemetry capture, enwik8, silesia, the synthetic deduplication case): ten cases, ten declared classes, 12 paired rounds, 360 of 360 cells usable, every held-out case restored exactly at the default invocation before the timed rounds (6 of 6).

| Case | Status | Class | vs `tar \| zstd -1` | vs `tar \| zstd -1 -T4` | ZJX bytes / comparator bytes |
|---|---|---|---:|---:|---:|
| Production telemetry capture, later day | held out | structured records | 1.820x faster | 1.281x faster | 1.0015 |
| Event-stream ticks | held out | event stream | 0.859x slower | 0.638x slower | 1.0012 |
| Application log | held out | application logs | 1.402x faster | 0.926x slower | 0.9936 |
| Agent session trace | held out | agent traces | 1.139x faster | 0.712x slower | 1.0014 |
| Database snapshot | held out | database snapshot | 0.783x slower | 0.686x slower | 1.0046 |
| Repository working tree, 24,997 files | held out | mixed repository | 1.052x faster | 0.666x slower | 1.0812 |
| Service telemetry capture, 2026-06-03 | sealed | structured telemetry | 1.564x faster | 1.086x faster | 1.0014 |
| enwik8 | sealed | bulk text | 1.785x faster | 0.921x slower | 1.0006 |
| silesia | sealed | public mixed | 1.972x faster | 1.090x faster | 1.0005 |
| Synthetic deduplication case | sealed | synthetic dedup | 0.529x slower | 0.535x slower | 1.1034 |

Reported lane, against default `tar | zstd -1`: class-weighted point **1.1959x**, 95% [1.1867, 1.2043].

The preregistered gate (P4) was the matched-thread-budget lane, `tar | zstd -1 -T4`, as a class-weighted geometric mean over the ten declared classes, requiring a 95% lower bound of at least 0.80:

| Reading | Point | 95% bootstrap | Against 0.80 |
|---|---:|---|---|
| Preregistered rule: ten declared classes | 0.8236 | [0.8170, 0.8307] | PASS, margin 0.0170 on the lower bound |
| The two telemetry captures counted as one class (nine classes; exploratory) | 0.7913 | [0.7843, 0.7989] | would not pass |
| The six held-out cases alone (six classes; exploratory) | 0.7917 | [0.7832, 0.8004] | would not pass on the lower bound |

The 0.8170 bound is a 95% bootstrap lower bound on a single preregistered comparison; no familywise adjustment applies to it. ZJX was slower than the four-thread comparator on 7 of 10 individual cases and faster on the three large-record cases. The verdict is the preregistered one: changing the class structure after seeing the numbers would be the reinterpretation the rules forbid, in either direction. The margin is disclosed so that the release decision, and any reader's decision, is made with it in view. CPU on the held-out cases: the candidate used less CPU than `-T4` on the large-record cases and more on the small-archive and many-file cases. Archives were within 0.5% of the comparator's on eight cases, 8.1% larger on the 24,997-file tree, and 10% larger on the small synthetic case.

## Predecessor gate (within-product)

Against released ZJX 1.28.0 `fast`, rebuilt with the same toolchain and processor policy, on the four-member cohort (the three development corpora plus the sealed 2026-06-03 telemetry capture), diagnostic tier, 3 paired rounds: a creation ratio of 335x (95% lower bound 330x against a required 5x) and a verified-creation ratio of 253x (lower bound 250x against a required 3x), producing archives 27% to 1,000% larger than fast's. This compares two ZJX objectives with different goals; it is not a competitor result and does not appear on the homepage.

## Compatibility and correctness

- Exact restoration of every qualified corpus at the default invocation and at one and four workers, including the six held-out cases.
- Deterministic archive output across all tested worker counts and both earlier release candidates.
- The frozen 1.28.0 reader tests, inspects, and restores every 1.29 ultrafast archive.
- Compact and fast archives are byte-identical to 1.28.0's on the qualification corpora, with no measured slowdown (worst paired timing ratio 1.0000).
- The package alone, in an empty `PATH`, created, tested, and restored every qualified corpus at the default invocation.
- The fidelity contract, the compatibility table, the package layout, and every documented limitation of 1.28.0 carry forward unchanged; see the [1.28 LOCKWIRE source note](https://greyforge.tech/research/zjx-1-28-lockwire-source-note-2026-09-05.md).

## The defect found during qualification

In the shipped `ReleaseSafe` build mode, the parallel verifier's helper threads were allocating and freeing their buffers through the governed allocator off the coordinator thread, so concurrent updates to the resource governor's memory account could be lost and the release-mode assertion on release fired: a panic in about one verification in a hundred of a small archive at four or eight workers. It surfaced in the full test suite during qualification of the second release candidate, after that candidate had been packaged and measured. The package and its campaigns were voided. The fix moves every governed allocation for the verifier onto the coordinator, which allocates each helper's buffers before spawning and frees them after joining; a regression test runs 600 rounds at eight workers and asserts the governor's account ends exactly where the owner left it (it failed before the fix and passed 300 of 300 after). The third candidate was frozen, packaged once on the laboratory host, and requalified in full, with a second independent read-only review. The fix costs about ten milliseconds per multi-worker test because the coordinator now touches those buffers serially before any helper starts; it is why the third candidate verifies about 4% slower than the second at four workers, and it was accepted as the price of the invariant. It is the only code change between the second and third candidates.

## What is not claimed

Benchmark leadership or any unscoped superlative; general superiority to zstd; any LZ4 result; 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); any prediction for another machine or workload; Windows, macOS, ARM, musl, network filesystems; an externally audited product. The private telemetry capture and the six held-out cases are not redistributed; public corpora are silesia and enwik8.

## Qualification status

Every REDLINE product gate passed on the frozen third candidate, which is the published package: exact restoration (P1), frozen-1.28.0-reader compatibility (P2), predecessor speed gain (P3, diagnostic tier), held-out integration overhead (P4, one shot, as disclosed above), useful compression on the predesignated public corpora (P5), legacy regression with byte-identical compact and fast (P6), bounds, cancellation, and progress suites at the freeze revision (P7), and the clean-userland package (P8). Two independent read-only reviews closed before the freeze. `ULTRAFAST_PRODUCT_QUALIFIED = YES`; `BENCHMARK_LEADERSHIP_QUALIFIED = NO`. The [public release record](https://greyforge.tech/research/zjx-1-29-redline-release-record-2026-09-08.md) controls the artifacts, checksums, post-publication verification, and remaining limitations.

## License

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.