--- class: reference purpose: Release notes for ArgonDB v1.5.7.22 — Linux: the hundred-tenant estate cut (connections, pooler, cursor, pins) template: product --- # ArgonDB v1.5.7.22 — Linux (x86_64) > **Cut 2026-11-02 (early morning ET), from `main`'s tip — THE HUNDRED-TENANT > ESTATE CUT, re-queued after the cut-ask fix landed; read section 2 first.** > v1.5.7.22 exists because the ERP coordinator's demo estate of about a > hundred tenants (8 distributors and about 90 manufacturers on a > 142-database estate box, v1.5.7.21) met the product's limits on 2026-11-01, > and the product landings on `main` that day and night answer them. Every > figure on this page is labeled by who measured it and when; nothing measured > on a customer estate that this cut did not measure is stated as this cut's. > **Headed by name, the fifth product change: the tail's on-demand cut ask > extends while the pass advances** (section 2.5) — a landing's data pin > asked the tail for a cut and a fixed 120 s bound expired with a 100 to > 116 s pass still stamping tables, seven refusals in one evening on the > ERP's estate (ERP-measured 2026-11-01 5:16pm to 7:42pm ET); the bound is a > window now, each expiry while the pass advanced is a logged finding, and > only a stall ends the wait; the 630 s client bound and the pin's 3 s > freshness deadline are UNCHANGED (section 7). **(1) The compute primary's > `max_connections` is an `argon.toml` key** (`[compute] max_connections`, > default unchanged at 100) and the box prints the per-tenant slot arithmetic > — the ERP coordinator's field line of 10:13am ET, `connection to server at > 127.0.0.1 port 6673 failed: FATAL: sorry, too many clients already`, is the > reason (section 2.1). **(2) The pooler gets two box-wide defaults, > `[pooler] default_pool_size` and `server_idle_timeout`** (section 2.2) — and > this page says plainly that the release tarball does not bundle PgBouncer; a box whose host has no `pgbouncer` binary prints `pooler: NOT RUNNING` with the Ubuntu install line and serves every tenant on its direct port, and the `[pooler]` pool sizes bind nothing until the binary is installed (ERP-measured > 2026-11-01 about 2:2xpm ET on the estate box). **(3) The publish-status > hourly refresh runs beside the 30 s pass instead of freezing the cursor > record**, a cut reaches the record within one pass, and `argondb lake list > --table a,b` reads only the named tables (section 2.3) — the ERP's > `wait_lake` failure of 2:08pm ET and the coordinator-measured 11 min 11 s > freeze (19:03:32Z to 19:14:43Z on 4,838 tables) are the reason. **(4) The > reader's catalog walk is pruned to the statement's scope, a catalog 503 is > retried once and reported as a 503** (never as a table that does not > exist), and the reader's catalog requests in flight are capped at one > (section 2.4) — the reference box's 42 authorizer deadline misses and the > `TableNotFound` masking of 2026-11-01 are the reason. **Row C and Row D, > which the first plan for this version deferred to v1.5.7.23, ARE in these > bytes** because both landed on `main` before this cut's base: **Row C**, > a landing's pin retries its freshness read once and a refusal names the > address, the error class, the elapsed time and both attempts (section > 2.6); **Row D**, the consent read of `publication land` walks only the > publication's warehouses instead of all 139 (section 2.7). Also in these > bytes (section 3): one resolver maps a PostgreSQL-spelled table to its > lake key across `argondb-mcp` and `argondb-query`; a table published on an > idle box no longer reads `backfill pending` for up to an hour. The catalog > this artifact ships is the v1.5.7.21 one — source-built, the dual > authorizer arm in its bytes, inert by default (section 4). The cross-version > golden copy stays a known gap. No box default changed. Every build fact at > the bottom of this page is measured from the artifact by the > release-verification pipeline, none declared. **ArgonDB on one Linux box.** One native binary runs PostgreSQL, the storage layer, an analytics lake derived automatically from the write-ahead log, and the AI agent endpoints — no Docker, no cluster, no cloud account. Install with one pasted line, connect with `psql` a minute later. ## 1. Cut from `main`'s tip; the shipped crates moved by ten product landings, so this is a REBUILD A fourth version number means "the previous tag plus the picks named in the notes, and nothing else" (`docs/release-path.md`, "Fix numbers"). v1.5.7.4 and v1.5.7.6 through v1.5.7.21 were cut from the tip of `main` instead, on the project owner's word, and their notes say so. **v1.5.7.22 is cut the same way:** its source tree is the tip of `main` at the moment this cut's lane started (`dcfd42471c49236d0e9340b4571c5444437a91c5`, committed 2026-11-02 3:15am ET; the lane spawned 3:19am ET), plus the commits that carry these notes, the v1.5.7.11 through v1.5.7.21 notes `main` never carried, the records assembled at the cut and the cut-time documents. It carries every change that landed on `main` that the `v1.5.7.21` tag (`a1ddf5f153868d1cbec935fc6a15ea80234f5370`, cut from `main`'s tip `3d16e11c71` of 2026-10-30 1:04pm ET plus that cut's release-path fix, published 2026-10-30 8:45pm ET) does not have. **The authority, in two blocks.** The project owner's block of 2026-11-01 7:00pm ET (answered 6:52pm), question 1, "Cut now" — one release-cut row that night with the `max_connections` knob, the pooler defaults, Row A and Row B, the soak included, the ERP's gate estates swapping Monday 2026-11-02 afternoon, Row C and Row D following in v1.5.7.23 — under the standing cut ruling [D-2026-09-21-4707dd]. Then the block of 2026-11-01 9:00pm ET, ratified as worded, after the ERP's seven on-demand-cut refusals of that evening: "The coordinator builds the cut-ask fix by hand now ... and lands it tonight. The running v1.5.7.22 cut lane is retired now; v1.5.7.22 is re-queued p1 Fable, blocked by that landing, and cuts from main's tip the moment it lands, waiting for nothing else" — and at 9:1xpm, "go with one release"; the ERP coordinator chose the same shape in its note of 02:17Z ("ONE release — .22 ~4am with the fix", the swaps its own act, the goldens re-taken on both boxes from the published tag). The first v1.5.7.22 cut lane was retired at 9:19pm ET before any publish step — no tag, no `LATEST` move; its candidate `fa4574ebb593` on `release/v1.5.7.22` is superseded by this cut's, as the v1.5.7.21 cut superseded its own first candidate — and its gate set and at-cut records are a record, not a base. Row C and Row D landed on `main` at 6:38pm and 8:53pm ET, before this cut's base, so both ride; the cut-ask fix landed by hand at 3:15am ET and this cut started four minutes later. The number stays on the v1.5.7 line because that is the line the ERP's boxes run. The fix-number rule itself is not changed by this release. **The delta proof.** Between the `v1.5.7.21` tag and this cut's base, `git log --oneline a1ddf5f15386..dcfd42471c49` lists 636 commits (the tag's own commits are on `release/v1.5.7.21`; its merge base with `main` is the v1.5.7.21 base `3d16e11c71`, and `3d16e11c71..dcfd42471c49` is the same 636); `git diff --stat a1ddf5f15386 dcfd42471c49 -- crates/` reads 60 files, 11,803 added lines and 410 removed. The cut builds exactly `argondb-ctl`, `argondb-tail`, `argondb-mcp` and `argondb-query` (`scripts/release/build-artifact.sh`) and the crates they depend on; those moved by **24 files, 6,780 added lines and 340 removed** (`argondb-ctl` 10 files +3,308/−135, `argondb-query` 1 file +1,601/−117, `argondb-common` 3 files +493, `argondb-committer` 2 files +338/−20, `argondb-tail` 5 files +572/−52, `argondb-transform` 2 files +248/−1, `argondb-mcp` 1 file +220/−15), in ten product landings — the seven of sections 2.1 to 2.7 and the three of section 3: - **`a57deb92ef` through `218491c78e` (six commits, landed by hand 2026-11-02 3:15am ET) — the on-demand cut ask extends while the pass advances, and the landing's pin waits are windows too** (section 2.5; `product-fix-2026-11-01-the-on-demand-cut-ask-extends-while-the-pass-advances-logs-each-expired-bound-as-a-finding-and-fails-only-after-a-stall-window-with-no-progress`): `crates/argondb-tail/src/cut_on_demand.rs` (+224 net of −), `flight.rs`, `service.rs`, `crates/argondb-ctl/src/landing_runner.rs` — 4 files, +374/−48. - **`c8dc319ec4` and `a564fa389a` — `[compute] max_connections` and the connection arithmetic** (section 2.1; `product-fix-2026-11-01-compute-max-connections-…`, landed 2026-11-01): `crates/argondb-ctl/src/max_connections.rs` (new, 673 lines, then +70/−17 when the arithmetic learned the sibling's `default_pool_size`), `serve.rs` (+141, +6/−3), `publish_status.rs` (+59, +4/−2), `lake_tenant.rs` (+30), `clone_box.rs` (+11), `main.rs` (+1) — 6 files, +977/−18. - **`9161c48949` — `[pooler] default_pool_size` and `server_idle_timeout`** (section 2.2; `product-fix-2026-11-01-the-pooler-gets-box-wide-defaults-…`, landed 2026-11-01): `crates/argondb-ctl/src/pooler.rs` (+547/−13), `serve.rs` (+28), `lake_tenant.rs` (+22) — 3 files, +584/−13. - **`3787477aa4` — the publish-status refresh beside the pass, the cut in the record within one pass, `lake list --table`** (section 2.3; `product-fix-2026-11-01-the-publish-status-hourly-refresh-…`, landed 2026-11-01): `crates/argondb-ctl/src/publish_status.rs` (+790/−203), `lake.rs` (+371), `main.rs` (+21/−1), `crates/argondb-tail/src/flight.rs` (+71/−5) — 4 files, +1,050/−203. - **`7e65cba974` — the reader's scoped walk, the 503 as a 503, one catalog request in flight** (section 2.4; `product-fix-2026-11-01-the-reader-statement-path-…`, landed 2026-11-01): `crates/argondb-query/src/lib.rs` (+727/−46), `crates/argondb-committer/src/iceberg_sink.rs` (+210/−2), `catalog_calls.rs` (+148/−1), `crates/argondb-ctl/src/lake_address.rs` (+2/−1) — 4 files, +1,039/−48. - **`615abcb1d6` — Row C, the pin's freshness read logs on both sides and retries once** (section 2.6; `product-fix-2026-11-01-the-pin-freshness-read-logs-address-and-error-on-both-sides-and-retries-once-before-refusing-a-landing`, landed 2026-11-01 6:38pm ET): `crates/argondb-query/src/lib.rs` (+507/−87), `crates/argondb-tail/src/flight.rs` (+88) — 2 files, +595/−87. - **`7af01f6da6` — Row D, the consent read of `publication land` scoped to the publication's warehouses** (section 2.7; `product-fix-2026-11-01-the-consent-read-of-publication-land-walks-only-the-publications-grantee-warehouses-not-every-tenant`, landed 2026-11-01 8:53pm ET): `crates/argondb-ctl/src/landing_runner.rs` (+452/−5), `crates/argondb-transform/src/publication.rs` (+237), `lib.rs` (+12) — 3 files, +701/−5. - **`a4939ab220` — one resolver for the PostgreSQL spelling of a published table** (section 3.1; `product-fix-2026-11-01-one-resolver-maps-…`): `crates/argondb-common/src/pg_spelling.rs` (new, 479 lines), `crates/argondb-mcp/src/lib.rs` (+235/−18), `crates/argondb-query/src/lib.rs` (+397/−8), `argondb-common/src/lib.rs` (+1) — 4 files, +1,094/−18. - **`62a134c863` — a table published on an idle box no longer reads `backfill pending` for an hour** (section 3.2; `product-fix-2026-11-01-a-freshly-published-table-on-an-idle-box-…`): `crates/argondb-ctl/src/publish_status.rs` (+305/−3), `crates/argondb-tail/src/flight.rs` (+81), `service.rs` (+47/−4), `lib.rs` (+30), `crates/argondb-common/src/test_overrides.rs` (+13) — 5 files, +468/−8. Everything else that moved under `crates/` is NOT in the tarball: `crates/argon-coord` (10 files, +4,718/−62 — the coordinator harness's landing scheduler, schedules and board), `crates/argon-engine` (24 files, +192/−6 — the shared resolver's fixtures), `crates/argon-harness-db` (1 file, +112/−1) and `crates/argondbcloud` (1 file, 1 line: the worked-overlay example stops naming a person). `Cargo.lock` and `Cargo.toml` did not move: no shipped crate's dependency changed. Under `scripts/` (62 files, +7,503/−581) and `testing/` (106 files, +7,628/−357) the changes are the product landings' gates (`testing/box/compute-max-connections.sh`, the pooler gate's new leg, `testing/box/publish-status-refresh-beside-the-pass.sh`, the hybrid-aggregate arm-choice runner and roster row, the idle-box publish gate, the pin-freshness retry box proof, the consent-scope proof) and the coordinator harness's landing, lint-scoping, hand-landing and selftest mechanics; `storage/` did not move; `deploy/` moved by 12 files (+158/−18: the harness's published site and the kit rail), and the catalog overlay patch `deploy/third-party/lakekeeper/argondb-backend.patch` is byte-identical to v1.5.7.21's (sha256 `6cf891adafbb…`). The artifact's inputs changed [D-2026-10-11-ad81a6], so everything in Build facts was built, verified and gated on the new bytes. ## 2. The hundred-tenant estate: seven product changes, each with its field line and its own lane's proof The ERP coordinator's demo load of about 100 tenants on a 142-database estate box (v1.5.7.21) is the field this release answers. Each subsection pastes the landing lane's own release fragment VERBATIM (`docs/releases/fragments/folded/`, including its limits block), then names the field figures by who measured them and when, and the lane's own regression and gate. **No box default changed in any of the seven.** ### 2.1 product-multi-tenant — `[compute] max_connections` is a knob, and the box prints the connection arithmetic per tenant count On 2026-11-01 at 10:13am ET the ERP coordinator's demo load of about 100 tenants (8 distributors and about 90 manufacturers, each with its pooler entry) failed at its Users step with the estate box's primary refusing: `connection to server at 127.0.0.1 port 6673 failed: FATAL: sorry, too many clients already` (a clone box on band 300, v1.5.7.21). The box primary ran the compute spec's `max_connections` of 100; the box's own use of the primary is a measured constant of about 7; each tenant's pooler entry may open up to `pool_size = limit / 4` = 5 server connections; so 100 tenants could ask the primary for 500 against 93 shared slots, and no argon.toml key, environment variable or clone-box flag set the limit. - **The knob.** `[compute] max_connections = ` in `argon.toml` (a TOML integer), or `ARGONDB_PG_MAX_CONNECTIONS=` in the environment, env winning over the file as for `idle_stop`. `argondb serve` writes the value into the primary's compute spec and prints `max_connections: N ()` at start. **The default is unchanged**: absent, the primary runs 100. A value below the floor — the box's own 7 slots plus one tenant's connection limit, 27 at the shipped limit of 20 — is refused by name before anything is spawned. A clone box inherits the value with the copied `argon.toml`. - **The arithmetic line.** On its first estate pass and on every pass whose tenant count changed, the box prints `connections: max N, box constant C, per-tenant pool P, T tenants may ask T*P, headroom H`, and warns once when `T*P` exceeds `N-C` (`WARN connections: 100 tenants may ask 500 against 93 shared slots …`), naming the key to raise. `P` is `[pooler] default_pool_size` when the box sets it, else the pooler's `limit / 4`, else (no pooler) the tenant's connection limit. - **Sizing.** Behind the pooler a box needs about `5*T + 7` connections for `T` tenants: 400 carries 78 tenants, 600 carries 118. The knob sizes the primary only. A read-only analyst compute and a per-tenant compute (`[compute] per_tenant`, default off) keep the template's 100; a per-tenant compute's limit is per compute, not per primary, and is named here, not sized. The box constant 7 is the 2026-10-07 measurement from the 120-tenant replay; a new per-tenant caller of the primary moves it. The arithmetic is printed, not enforced: a box whose tenants' pools exceed the headroom still boots and the warning is the only change. The ERP's own estate has not been re-run at 100 tenants with the knob raised; the 120-tenant shape is covered by the unit replay at both polarities and the box gate `testing/box/compute-max-connections.sh` at six tenants. **The field line, labeled.** `connection to server at 127.0.0.1 port 6673 failed: FATAL: sorry, too many clients already` — the ERP coordinator's, 2026-11-01 10:13am ET, from their demo load's Users step against a clone box on band 300 running v1.5.7.21; the arithmetic in the fragment (100 tenants, pool 5 each, 500 against 93 shared slots) is the landing lane's reading of that estate's shape, not a measurement on it. **The lane's own proof** (its report, `docs/lane-reports/product-fix-2026-11-01-compute-max-connections-…`): the `max_connections` module's parser and arithmetic tests and the 120-tenant replay at both polarities (`cargo test -p argondb-ctl` → `test result: ok. 1419 passed; 0 failed; 6 ignored` on its tree), and the box gate `testing/box/compute-max-connections.sh` → `compute-max-connections: PASS` (the refusal below the floor at 20, `SHOW max_connections` 400 on the source box and on its clone, the default 100 untouched, the arithmetic line quiet at 6 tenants and `WARN` at 7). The follow-up commit `a564fa389a` makes the arithmetic's `P` read `[pooler] default_pool_size` when the box sets it (section 2.2's sibling), so the two knobs compose on one box. ### 2.2 product — the pooler gets two box-wide defaults, `[pooler] default_pool_size` and `server_idle_timeout`, and prints the fan-in before the primary refuses On 2026-11-01 the ERP's demo load of about 100 tenants, each with its pool, hit the box primary's ceiling twice: `FATAL: sorry, too many clients already`. The box's one pooler gave every tenant a server pool of `connection limit / 4` = 5 and, with `[compute] idle_stop` off, kept an idle backend for 600 s, so 100 tenants touched within ten minutes could hold up to 500 backends against the primary's 100 - 7 = 93 shared slots. The only pool knob was per tenant and the idle timeout had none. Two `[pooler]` keys now sit beneath the per-tenant tables: `default_pool_size = ` is the server pool every tenant gets unless `[pooler.pool_size].` names it, and `server_idle_timeout = ` is how long an idle server connection is kept, box-wide. Absent, nothing changes: the pool is still `limit / 4` and the timeout is still 600 s, capped at the idle window exactly as before. Zero refuses at load by name, like the keys beside them. The generated ini's comment block, the pass's log and the box's start carry the arithmetic: `T tenants x pool P = up to T*P backends against the primary's N - C`, with a WARN when the sum exceeds the headroom, and `argondb serve` prints `pooler defaults: pool P per tenant (…), server_idle_timeout S s (…); P backends per tenant against the primary's N - C = H shared slots, so more than H/P tenants exceed it; [pooler] read at start; a change needs a restart`. The pooler box gate's new leg proved both polarities on ms-01: the default box kept its idle backend past ten seconds; the same box restarted with `default_pool_size = 1` and `server_idle_timeout = 5` held at most one backend per tenant under six concurrent pooled clients and drained it to zero within ten seconds of the last transaction. - The two keys are read at `argondb serve` start. A change needs a box restart; the start line says so. Hot reload of the two keys was not built. - The `N` of the arithmetic is the compute spec template's `max_connections` of 100 and the `C` is the measured constant of 7. The knob that raises `N`, `[compute] max_connections`, is the sibling change and lands separately; until it is wired into the fan-in the box prints the template's 100 even where a raised value runs. - The fan-in line's `T` is the count of pool entries the pass wrote, so it appears from the first provisioner pass after start, not on the banner itself; the banner carries the per-tenant ceiling instead. - A per-tenant `[pooler.pool_size].` override still wins over `default_pool_size`, and `server_idle_timeout` above the `[compute] idle_stop` window is written as the window. - Lowering the pool alone does not seat the ERP's hundred: at the template's `max_connections` of 100 the primary has 93 shared slots, so even `default_pool_size = 1` leaves 100 tenants over by 7, and the fan-in line says so. The other half is the primary's `max_connections` knob, shipped separately. **The field line, labeled, and the candor line this release carries.** The release tarball does not bundle PgBouncer; a box whose host has no `pgbouncer` binary prints `pooler: NOT RUNNING` with the Ubuntu install line and serves every tenant on its direct port, and the `[pooler]` pool sizes bind nothing until the binary is installed — **ERP-measured 2026-11-01 about 2:2xpm ET on the estate box**, where the box printed `pooler: NOT RUNNING — pgbouncer binary not found on PATH …; the box serves every tenant on its direct port only. The pooler is optional and the platform provides it: PgBouncer >= (the release tarball does not bundle one). Install it on Ubuntu: …` (the line's text is `crates/argondb-ctl/src/pooler.rs`'s; the artifact bundles no `pgbouncer`, by the B-MT5 (B) ruling the build script cites, and `install.sh` does not install one). On 2026-11-02 3:26am ET this cut's lane read `/usr/sbin/pgbouncer` → `PgBouncer 1.26.1`, running (two instances: the host's `/etc/pgbouncer/pgbouncer.ini` and the kept demo estate's own `box/pooler/pgbouncer.ini`), on splink-server — the ERP's estate box — so a box served there after the swap to these bytes finds the binary; whether the pooler starts on a given box is that box's own start line to read (`pooler defaults: …` or `pooler: NOT RUNNING …`), and this page does not project it. **The pooler fragment's second limit is overtaken by `a564fa389a`** (section 2.1): at this tag the arithmetic's `N` is the resolved `[compute] max_connections`, so a raised value is what the fan-in line prints; the fragment is pasted as its lane wrote it. **The lane's own proof** (its report, `docs/lane-reports/product-fix-2026-11-01-the-pooler-gets-box-wide-defaults-…`): `cargo test -p argondb-ctl … pooler::` → `test result: ok. 37 passed; 0 failed; 0 ignored; 0 measured; 1383 filtered out`; the pooler box gate on ms-01 → `pgbouncer-pooler-gate: PASS (P0a: optional pooler — installer key fresh/off, absent and too-old BOOT on the direct port naming the binary, floor and install line on banner + status, stray/mute named; P0-P7: pooler resident on :25604, pool 20/4=5 -> 40/4=10 reloaded live, superuser refused pooled, session features refused po…)`, with the new leg's two polarities the fragment names (the default box kept its idle backend past ten seconds; the same box restarted with `default_pool_size = 1` and `server_idle_timeout = 5` held at most one backend per tenant under six concurrent pooled clients and drained it to zero within ten seconds). ### 2.3 lake — the publish-status hourly refresh no longer freezes the cursor record, a cut reaches the record within one pass, and `lake list --table` reads only the named tables On a 4,838-table estate (the ERP coordinator's 142-database demo box, v1.5.7.21) the box's publish-status writer ran its hourly catalog refresh as one pass: 4,838 `load_table` calls, 11 min 11 s (19:03:32Z to 19:14:43Z on 2026-11-01), and `argon.publish_status_state` — the record `argondb lake list` answers from — was not written for the whole of it. The ERP's real-names demo load failed at 2:08pm ET in its `wait_lake` (600 s ceiling) on four tables the tail had committed a minute after the wait began; `lake list` showed them at the previous cut until 19:14:47Z. The same freeze followed every restart, because the first pass of a process was a full walk too. Now the refresh is a slice per pass beside the record — `ceil(tables / (bound / 30 s))`, 41 of 4,838 per 30 s pass at the defaults — every table once per hour, and the pass line names the progress (`refresh 1200/4838 this bound, 41/pass`); the first pass seeds every table from the tail's cut record and censuses it behind. The tail's `freshness` record now carries a committed table's stamp from the warehouse commit on, not after its stamping of the other tables (8.7 min on that estate), so the writer's next pass puts a cut in the record from the `cut` column, under 60 s from the commit. `argondb lake list --table a,b[,c]` reads only the named tables — from the record where it covers them, from their own catalog stamp otherwise, one read each — and prints a fourth cell naming the store; `--from-catalog` is unchanged (9 to 14 minutes on that estate, unusable as a poll). - The refresh's total cost is unchanged (one catalog read per table per hour); the shape is 41 reads per pass instead of 4,838 in one. `ARGONDB_PUBLISH_STATUS_REFRESH_SECS` smaller than 30 s is one pass that reads every table. - A table seeded from the cut record on a writer's first pass reads the tail's own coordinate until the census reaches it, inside the first hour; a change a foreign writer made before the restart surfaces when the census does. - The tail's post-cut stamping of the other tables is not bounded by this change; a table covered by the estate record is lifted by `lake list` as before, and one with its own cursor stamp reaches the record when its stamp commits. **The field figures, labeled.** The `wait_lake` failure (600 s ceiling, four tables committed a minute after the wait began, `lake list` showing them at the previous cut until 19:14:47Z) — **the ERP coordinator's, 2026-11-01 2:08pm ET**, on their real-names demo load against the 142-database estate box (4,838 tables, v1.5.7.21). The freeze itself — one hourly refresh pass of 4,838 `load_table` calls, **11 min 11 s, 19:03:32Z to 19:14:43Z** — **the coordinator's measurement, 2026-11-01**, read from that box's publish-status log. The 41-per-pass slice, the 8.7 min post-cut stamping and the 9 to 14 minute `--from-catalog` listing are the landing lane's readings of the same estate's logs. **The lane's own proof** (its report, `docs/lane-reports/product-fix-2026-11-01-the-publish-status-hourly-refresh-…`): `cargo test -p argondb-ctl` → `test result: ok. 1416 passed; 0 failed; 6 ignored`, `-p argondb-committer` → `424 passed; 0 failed`, `-p argondb-tail` → `888 passed; 0 failed; 2 ignored`; its selftest `publish-status-refresh-beside-the-pass-selftest: PASS -- 12 judge case(s), both polarities`; the box gate on a 4,200-table estate → `publish-status-refresh-beside-the-pass: PASS -- 7 check(s) on a 4200-table estate: the refresh ran 2100/pass beside 6 passes, the cut reached the record in 23.5s, the named listing took 491ms 579ms 526ms` (its first run, before the read budget, was red on two checks and the lane's report says so). ### 2.4 product — a scoped `argondb-query` statement walks only the warehouses its scope can live in, and a catalog 503 is reported as a 503 On the ERP's reference box (1,004 tenant warehouses, catalog authorizer on) every planner statement `argondb-query --scope a,b "EXPLAIN …"` still asked all 1,004 warehouses two catalog questions each — the scope narrowed the walk inside a warehouse, never the set of warehouses — so a two-table plan issued about 2,000 catalog requests, one after another as fast as the catalog answered. On 2026-11-01 that throughput (400+ requests a second at the catalog) pushed the authorizer's batch checks past their deadline 42 times in three bursts; the catalog answered `503 AuthorizationBackendError` to the reader's listings and metadata loads, the ERP's dialects preflight spent 143 s on its first view and refused three referee runs in an hour, and a tenant copy whose metadata load failed under that was SKIPPED by the reader's pin and reached the planner as a table that did not exist — which sent a day of diagnosis after an authorizer that was up throughout. - **The scope prunes the walk at the warehouse level.** A warehouse whose database no scope entry names is not asked at all, on a cold walk and on the warm roster-cache confirm alike. On a 200-tenant scratch box a two-table `EXPLAIN` went from 1,000 catalog round trips over 200 warehouses to 10 over 2 (cold), and from a 90 s to a 0.8 s listing (warm). The cost line says `pruned to the pin's scope — the statement's scope, 2 of 200 warehouse(s) walked`. An unscoped statement walks everything exactly as before; a scope naming a cross-tenant view still walks every warehouse (its expansion is a walk over every tenant) and the cost line says so. - **A catalog 503 is a 503.** The failure head reads `catalog unavailable (503 from , , warehouse )`; an idempotent read that answered 503 is retried once after a 250–750 ms jittered pause; a 503 on a table's metadata load refuses the statement instead of skipping the table; the roster cache is never written from a walk that saw one. - **The reader's catalog concurrency is one, and the cost line prints it.** The walk is sequential; the burst was request count, not fan-out. A load that the catalog answers `404 TableNotFound` for a table the same walk listed seconds earlier is still reported as that disagreement, not as a 503: the client cannot tell a missing table from a load the authorizer would not decide, and the ERP's tour refresh hit exactly that shape (`loading t294__pub__publication / TableNotFound`) while the catalog's log showed `AuthorizationBackendError 503` for the same principal in the same minute. The failure text now names where to look; the catalog's own bytes are the only thing that can tell the two apart. The warehouse-level prune believes a tenant warehouse is named after its database (the provisioner's rule); a `[lake.tenant_warehouse]` override is caught by the pin's full re-list and costs the old walk, never a wrong answer. **The field figures, labeled.** The 1,004 tenant warehouses, the about 2,000 catalog requests per two-table plan, the **42 authorizer deadline misses in three bursts**, the `503 AuthorizationBackendError` answers and the `loading t294__pub__publication / TableNotFound` masking — **the landing lane's reading of the ERP's reference box's catalog and reader logs, 2026-11-01**; the 143 s dialects preflight and the three referee runs refused in an hour are **the ERP coordinator's**, from their referee of that day. The scratch-box figures (1,000 round trips over 200 warehouses to 10 over 2; a 90 s listing to 0.8 s) are the lane's, measured on a 200-tenant scratch box, not on the ERP's. **The lane's own proof** (its report, `docs/lane-reports/product-fix-2026-11-01-the-reader-statement-path-…`): `cargo test -p argondb-query` → `test result: ok. 460 passed; 0 failed` (then 16 further test binaries, every one `test result: ok.`), `-p argondb-committer` → `429 passed; 0 failed`, `-p argondb-ctl` → `1428 passed; 0 failed; 6 ignored`; `lint-gate (all): PASS` on ms-01. **The limit stands as the fragment states it:** a `404 TableNotFound` for a table the same walk listed seconds earlier is still reported as that disagreement, and only the catalog's own log can tell it from a 503. ### 2.5 lake — the tail's on-demand cut ask no longer gives up on a clock while the pass is working: the window extends while the pass advances, and only a stall ends the wait On a 142-database estate (4,841 tables, cadence 30; the ERP coordinator's demo box on v1.5.7.21) one cadence pass takes 100-116 s, and a landing's data pin that asked for a cut on demand waited out the pass in flight and then its own against a fixed 120 s bound. The bound expired with the pass still stamping tables, the pin fell back to the cadence and the landing was refused — seven times in one evening (`cut on demand: NO pass answered the ask ... inside 120s`). Now the pass publishes a progress count (one step per table refreshed, cut, drained, committed or quiet-stamped) and the ask's 120 s is a window: when it expires while the count has moved, the tail logs `FINDING — the 120s window expired ... while the pass advanced ... a timeout is never a verdict` and waits another window; only a window with no progress at all ends the wait. The `cut_now` answer carries `extended`, the number of windows that expired while the pass advanced, and the answer line names it. - The stall window is the old bound, clamp(4 × cadence, 120 s, 600 s): a pass that makes no visible progress for that long is still a timeout, and the pin still falls back to the cadence as before. - The landing's own pin waits take the same shape: the sized consent wait (two measured cadences, floored at 120 s, capped at 600 s) is a window for both the consent pin and the data pin; a window that expires while the pin read moved or the tail cut again prints a `FINDING` line and opens another, and `consent-pin-behind-run-start` / `data-pin-behind-run-start` are refused only after a whole window with neither (the refusal names how many windows it took). The ERP's 9:27pm refusal of 2026-11-01, "Waited 120s (two cadences of 40s, floored at 120s)" on a tail mid-pass, is this path. - The landing runner's 630 s bound on one whole `cut_now` call is unchanged: a single ask the tail keeps extending past that is not received, and the pin falls back to its own window wait. It is listed, not converted, in the absolute-bounds census. - The pin's 3 s freshness deadline after a fallback is unchanged in this release; the landing retries its freshness read once before refusing (the .22 pin-freshness change) and the deadline's own extension is a later row. **The field figures, labeled.** The seven refusals between 5:16pm and 7:42pm ET on 2026-11-01 (`t294 refused rows=- pin=- version=1`, the tail's `cut on demand: NO pass answered the ask ... inside 120s (116206 ms for a pass)`), the 100 to 116 s pass on 4,841 tables at cadence 30, and the 9:27pm `data-pin-behind-run-start ... Waited 120s (two cadences of 40s, floored at 120s)` refusal — **the ERP coordinator's, from their real-names demo load on the 142-database estate box (v1.5.7.21), 2026-11-01**, read by the coordinator from that box's tail and landing logs. The project owner's ruling of 7:1xpm ET that evening, "no more failures because of timeouts, no matter where or why", ratified as worded on both consoles at 7:2xpm, is the reason this change was built by hand that night and v1.5.7.22 waited for it. **The landing's own proof** (the coordinator's hand landing, record `docs/history/2026-11-01-product-fix-2026-11-01-the-on-demand-cut-ask-extends-while-the-pass-advances-logs-each-expired-bound-as-a-finding-and-fails-only-after-a-stall-window-with-no-progress.md` with its three post-mortems): the new test `cut_on_demand::tests::a_pass_advancing_past_the_window_is_waited_for_and_a_stalled_one_is_not` (a 12 s pass against a 5 s window answers with two extensions; a pass begun and then silent is a timeout after one window) beside the kept `no_pass_inside_the_bound_is_a_timeout`; the landing-runner tests for the pin windows (a tail cutting at cadence with an unmoved LSN is a stall, not progress — post-mortem 2 of that landing, which the whole-crate `cargo test` caught before the push); the landing's own gate round on main (`lint-nocargo`, `fmt-clippy`, `cargo-test` pinned at `52a035630c1d`, the `land:` commits `b470bf29fb` and `32c0febe97`). This cut re-ran `argondb-tail`, `argondb-ctl` and `argondb-transform` whole on the cut bytes (Build facts). **The limits stand as the fragment states them:** the stall window is the old bound, clamp(4 × cadence, 120 s, 600 s); **the landing runner's 630 s bound on one whole `cut_now` call is UNCHANGED**, and **the pin's 3 s freshness deadline after a fallback is UNCHANGED** in this release — the retry of section 2.6 is a second ask under the same 3 s, and the deadline's own extension is a later row of the absolute-bounds census. ### 2.6 product — a landing's pin retries its freshness read once, and a refusal names the address, the error class, the elapsed time and both attempts on the client, with the tail logging every freshness action On 2026-11-01 at 1:41pm ET the ERP's real-names demo load was refused on a tenant's landing: `taking the pin: freshness signal unavailable: the tail Flight freshness action is unreachable and the lake carries no _argon_timeline breadcrumb`. The tail was up; it answered the same read in 0.6 s two minutes later, and its own ring-read lines of that second show 2-4 s waits on its ingest lock. The refusal did not say that. It carried no address, no error class, no duration and no attempt count; the client's warning line said no more; the tail logged nothing for the action at all; and the landing was refused on the first 3 s miss. Thirteen minutes earlier the same tenant's first landing had landed 5 of 5 grantee rows. Now the pin's freshness read makes two attempts, each bounded by the same 3 s deadline, with a 300-700 ms jittered pause between them, and a healthy tail pays nothing: the read ends at the first answer. Each missed attempt is one warning naming the address dialled, the class (`connect refused`, `timeout after 3000 ms`, `status …`, `transport …`), the elapsed milliseconds and the attempt count; a retry that answers says so, naming the miss before it. When both attempts miss and the lake breadcrumb holds nothing, the refusal carries every attempt, the pause, and the `_argon_timeline` table the fallback looked at with the reason it held nothing. The tail writes one INFO line per `freshness` action, `freshness-action: side=tail peer= scope= head= answer_ms=`, so a client's claim can be checked against the server's record of the same second. The fail-closed rule stands: a pin is never taken on a stale signal; the retry is a second ask of the live tail. - The retry is one, and only for the pin's freshness read. The pin's other tail actions (`tables`, the pending-notes probe, the cut ask) keep their own bounds and are not retried here. - A tail that misses both attempts now costs a refused landing about 6.7 s instead of 3 s (two deadlines and the pause). A tail that answers costs nothing more than before. - The timeout class says the tail did not answer within 3 s; whether that was a contended ingest lock or a hung connect is read from the tail's `freshness-action:` line (present with a large `answer_ms`, or absent), not from the client's line. - The 1:41pm refusal's cause — the tail's state lock held for seconds at a time while ring reads waited — is diagnosed by this change, not fixed by it. - The box proof's lever is the test hook `ARGONDB_FRESHNESS_TEST_MISDIAL`, which misdials the first k attempts to a closed port: a stopped or killed tail cannot stand in for it, because the pin asks the tail `tables` before its freshness read and that action has no deadline. **The field figures, labeled.** The 1:41pm ET refusal (`taking the pin: freshness signal unavailable: the tail Flight freshness action is unreachable and the lake carries no _argon_timeline breadcrumb`) on the real-names demo load — **the ERP coordinator's, 2026-11-01**, referee `345bc76b-20261101T182442Z`; the tail's ring-read lines of that second with `answer_ms` 2,032 to 4,017 under its ingest lock, and the 0.6 s answer two minutes later — **the landing lane's reading of the kept estate's tail log** (`demo-estates/20261101T051354Z/box/logs/argondb-tail.log`, lines 9335 to 9345). This is the row the first plan for this version named "Row C, not in this cut"; it landed on `main` at 6:38pm ET on 2026-11-01 (`615abcb1d6`), before this cut's base, so it is in these bytes. **The lane's own proof** (its report, `docs/lane-reports/product-fix-2026-11-01-the-pin-freshness-read-logs-address-and-error-on-both-sides-and-retries-once-before-refusing-a-landing.md`): `cargo test -p argondb-query --offline` → every `test result:` line `ok` (e.g. `test result: ok. 14 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out; finished in 3.02s`); the box proof `pin-freshness-retry-and-refusal: PASS — P1 control landed and the tail logged the action with the peer; P2 misdial attempt one (closed port 57829) landed on the retry with both attempt lines; P3 misdial both refused naming address, connect refused, elapsed, both attempts, the 324 ms pause and the breadcrumb path; P4 landed again; rows 6 -> 7 = 7 -> 9; tail freshness-action lines 25 -> 34`. **The limits stand as the fragment states them:** the retry is one and only for the freshness read; the 3 s deadline is the same deadline twice; the 1:41pm refusal's cause (the tail's state lock held for seconds while ring reads waited) is diagnosed by this change, not fixed by it. ### 2.7 product — `publication land` reads its consent from the publication's warehouses, not from every tenant's On the ERP coordinator's 142-database estate box (v1.5.7.21, 139 tenant warehouses) each `argondb publication land` took about ten minutes, and five of those minutes were the consent read: the landing's consent pin named the `all_tenants.pub__publication` / `pub__subscription` views, which expand to every tenant warehouse by definition, so every landing walked all 139 warehouses' catalog namespaces as `oidc~argondb-reader` (659 to 3,475 audit lines a minute, 22:14Z to 22:18Z on 2026-11-01) to read the consent rows of the six databases its landing set is decided from. Twenty-five landings a night spent two hours reading 130 tenants' consent rows to decide about five. Now the consent read walks only the publication's warehouses: the publisher, every grantee the publication names (every contract version), and any other publisher whose publication names one of those grantees — decided from the box primary's own consent rows, read after the run-start floor, and cut into the reader's roster the way a landing's data pin already was. The pin line says `consent read: N of M warehouse(s) walked`. The floor, the proof and the landing set are unchanged over the rows read: a grantee's unsubscribe committed before the run start is still seen (the box primary's rows of the same databases differ from the pin, and the cut is asked), and a tenant the publication does not name is never read. - A publication granted to `*` (every member) still walks every warehouse, because every member's subscription row decides; so does a publication the box primary does not name, a run whose consent tables have no box-primary relation, a run under `--at`, and a box whose primary will not answer inside 60 s. The pin line names which. - A tenant that subscribed to a publication that never granted it is now reported `no grant for ; no accept from ` rather than `no grant for `: its subscription row is outside the read. The refusal is the same. - The lake walk is still taken on every landing: the consent pin is the coordinate the subscription is decided at (the landing runner's rule 2) and the publication bodies are read from it; the box primary's rows prove the pin, they do not replace it. - The data pin's on-demand cut wait (about 100 s per landing on that estate) is not this change's; it is tracked separately. With the consent walk gone the data pin's ask reaches the tail sooner, so a landing can meet that bound where the walk used to hide it: on the 200-warehouse scratch box two of six landings refused one grantee `data-pin-behind-run-start` after the 120 s bound, none of the unscoped four did, and a re-run lands it. **The field figures, labeled.** The ten-minute landings and the five-minute consent read on the 142-database estate box (139 tenant warehouses, v1.5.7.21), the 659 to 3,475 audit lines a minute as `oidc~argondb-reader` from 22:14Z to 22:18Z on 2026-11-01 — **the landing lane's reading of the ERP's catalog audit log on that box**; the twenty-five landings a night are the ERP's demo load's shape as the lane read it. This is the row the first plan for this version named "Row D, not in this cut"; it landed on `main` at 8:53pm ET on 2026-11-01 (`7af01f6da6`), before this cut's base, so it is in these bytes. **The lane's own proof** (its report, `docs/lane-reports/product-fix-2026-11-01-the-consent-read-of-publication-land-walks-only-the-publications-grantee-warehouses-not-every-tenant.md`): on the 200-warehouse scratch box the consent read walked 6 of 200 warehouses in 1.2 to 2.2 s against `main`'s 45 to 182 s (the pin line `consent read: N of M warehouse(s) walked`), a pre-run unsubscribe refused identically; `cargo test -p argondb-transform` → `test result: ok. 326 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.34s` (then 8 further binaries, every one `test result: ok.`); `cargo test -p argondb-ctl` → `test result: ok. 1432 passed; 0 failed; 6 ignored; 0 measured; 0 filtered out; finished in 31.78s`; `lint-gate (all): PASS`. **The limits stand as the fragment states them:** a publication granted to `*` still walks every warehouse; the lake walk is still taken on every landing; the data pin's on-demand cut wait is section 2.5's, and on the scratch box two of six landings met the then-120 s bound where the walk used to hide it — section 2.5 is what makes that bound a window. ## 3. Also in these bytes: three more product landings since v1.5.7.21 ### 3.1 product — a PostgreSQL-spelled read of a published table over MCP reaches the lake copy and carries its pinned lake LSN Since v1.5.0 (2026-09-12, commit `bae7783265`) a published table's lake copy carries the three-level lake name — `postgres__public__orders` for `public.orders` in the primary database — and the lake read plane resolved no other spelling of it. So a `query` statement that spelled the table the way a PostgreSQL user types it (`orders`, `public.orders`) was served by the analyst Postgres arm on a hybrid box, with `lsn: … served from Postgres` and no lake LSN, or refused as an unknown lake table on a lake-only box; the served `query` description's promise — an analytical aggregate "the lake can serve at the same coordinate" takes the lake arm — held only under the lake spelling, and the gate that asserts it ran on no clock. Fixed from this cut. One resolver (`argondb_common::pg_spelling`) maps the primary database's PostgreSQL spelling of a published table — bare `orders`, `public.orders`, `postgres.public.orders` — to its lake key, literal-first: a name that already IS a lake key (a branch internal, a lake-owned table) is never re-read. The pin's scope resolves through it, so `pin(scope=["orders"])` mints where it refused; the lake session registers the PostgreSQL spellings beside each published key, so the statement runs on the lake verbatim and answers with `pinned_lsn:`; and an unpublished or unknown spelling keeps the answer it had. `testing/box/hybrid-aggregate-arm-choice.sh` now has a fleet-slot runner and a row on the scheduled box-proof roster. - Affected: v1.5.0, v1.5.1 (both withdrawn), v1.5.2 through v1.5.7.21, and the kits `kit-argon-d43df2ab` and `kit-argon-f79692fd`. On those, a PostgreSQL-spelled lake read over MCP answered from PostgreSQL without a lake LSN on hybrid boxes and refused on lake-only boxes; since commit `bae7783265` (2026-09-11). - A bare or two-part spelling is read in the box's PRIMARY database (`postgres`), the same narrowing every MCP surface already makes. A relation in a second database is addressed by its three-part spelling (`shop.public.orders`) or its lake key. - The kit's sample app still reads the lake copy by its lake name in its lake-query stage; its diagnostic probe (`_lake_content_probe`) reads `FROM orders` unfiltered and on a hybrid box that is the Postgres copy — the template porter's, not changed here. ### 3.2 lake — a table published on an idle box read `backfill pending` from `argondb lake list` for up to an hour after it had landed A table published on a quiet box — no other writes, no landing, no estate record due — landed in the lake on the tail's next cadence as always, but `argondb lake list`, `argon.publish_status` and the MCP `publish_status` tool could read `backfill pending` for it until the box's hourly cursor refresh. The tail enrolled a joining table before it materialized it and, in that window, its freshness record already named the table's lake watermark; the box's publish-status writer, on a pass inside the window, asked the catalog, was told the table was not in the lake, and kept that answer for as long as the record's coordinates held — and on an idle box the cut after the join lands at the same coordinate the join baselined at, so the record never moved. Whether a given box hit it was decided by the phase of two 30 s timers started at boot; the kit's quickstart box did, for the full 420 s the sample app allows. Fixed in two halves: the tail leaves a joining table out of its record until its baseline and changelog have committed, and the writer re-asks the catalog every pass for a table the record carries but the cache holds as absent (one call per pass per such table, none on a settled estate; the pass line gains `pending=`). A box-level gate publishes two tables on an idle box over a widened join window and asserts the listing lands within a cadence; its control restores the pre-fix shape by the test-only knob `pre_fix_pending_backfill=1` and fails by name. - Affected: v1.5.7.16, v1.5.7.17, v1.5.7.18, v1.5.7.19, v1.5.7.20, v1.5.7.21, and the kit `kit-argon-d43df2ab` (box image `argondb-box:d43df2aba317`, built from main `d43df2aba317`). Measured by `git grep QuietSkip::IdleCut` over the release tags (the idle-cut rule, 2026-10-21, is what stopped the record moving; the writer's cursor cache, 2026-10-15, is what kept the negative): zero hits at v1.5.7.15 and earlier, hits from v1.5.7.16 on. On those versions a table published on an idle box can read `backfill pending` until traffic, a landing, an estate record or the hourly refresh (`ARGONDB_PUBLISH_STATUS_REFRESH_SECS`, default 3600 s) arrives; `argondb lake list --from-catalog` reads the table's true state meanwhile, and the data was in the lake the whole time. - The lake itself was never wrong: the backfill landed within seconds of the publish on every box measured. Only the read surfaces that go through the box's cursor record were stale. - The template gate's `lake-publish` leg was not re-run against a box image built from this fix: this node has no docker. The proof is the box-level gate plus a hand run of the sample app's publish sequence on a local box, said so in the lane report. ### 3.3 product — the lake copy of a published table is read by its lake name; a PostgreSQL-spelled read over MCP answers from Postgres without a lake LSN Since v1.5.0 (2026-09-12, commit `bae7783265`) a published table's lake copy carries the three-level lake name — `postgres__public__orders` for `public.orders` in the primary database, the spelling `argondb lake address --field lake-table` prints. The MCP `query` tool reaches the lake copy under that name and returns the pinned lake LSN (`pinned_lsn:`). A statement that names the table by its PostgreSQL spelling (`orders`, `public.orders`) is served by the analyst Postgres arm on a hybrid box — the default box with the analyst pool on — and its answer carries `lsn: … served from Postgres` and no lake LSN; on a lake-only box (`ARGONDB_ANALYST_POOL=off`) the same statement is refused as an unknown lake table. The kit's sample app (stage 6, `lake-query`) read the lake copy by its PostgreSQL spelling and went red on `kit-argon-f79692fd` for this reason; its assertion now reads the lake copy by its lake name, on a template branch pending the decision in the lane report. - Affected: v1.5.0, v1.5.1 (both withdrawn), v1.5.2 through v1.5.7.21, and the kits `kit-argon-d43df2ab` and `kit-argon-f79692fd` (both channel-staged, neither pinned). On these, the lake copy read over MCP answered from PostgreSQL without a lake LSN on hybrid boxes, and refused on lake-only boxes, whenever the statement spelled the table the PostgreSQL way; since commit `bae7783265` (2026-09-11). - The served `query` description promises the lake arm for an analytical aggregate "the lake can serve at the same coordinate"; today that holds only for a statement spelled with the lake name. Whether the lake arm resolves the PostgreSQL spelling of a primary-database table is escalated as a product decision, not changed here. - `testing/box/hybrid-aggregate-arm-choice.sh`, the gate for that promise, is on no roster and has not run since the spelling changed; escalated. This fragment is the MEASUREMENT whose product decision section 3.1 closes: on these bytes the PostgreSQL spelling of a primary-database table resolves to its lake copy, so the shape it describes ("answers from Postgres without a lake LSN") is v1.5.0 through v1.5.7.21's, and the escalation it names is answered by section 3.1. Its limits on the kit's sample app are the template porter's and stand. ## 4. The catalog this artifact ships: the v1.5.7.21 catalog, the dual authorizer arm in its bytes, inert by default **In one line: the bundled `lakekeeper` is built from the upstream `v0.13.1` tag at commit `1f6a1fb6ee0ef78d5cb0ca5a96837ee579a03f1c` with one added crate, `lakekeeper-authz-argondb`, wired in by ArgonDB's overlay patch — the patch is byte-identical to v1.5.7.21's (sha256 `6cf891adafbb…`), so the wiring is the v1.5.7.21 one: the `argondb` arm, the `argondb-dual` arm, the permissions router the dual arm mounts, and `argondb-authz backend-version` answering `modes=argondb,argondb-dual,openfga,allow-all` with an `overlay 6cf891adafbb` stamp. The backend stays INERT BY DEFAULT — the box's serve arm tells the catalog child `openfga` under `[lake] catalog_authz = "openfga"` (the default on a box with more than one database) and nothing under `off` (the default on one), exactly as v1.5.7.21; `dual` and `engine` BOOT when set by name, and NEITHER IS A DEFAULT.** `crates/argondb-ctl/src/serve.rs` moved in this release by the `max_connections` and `[pooler]` lines (section 2) and not by its mode table. The overlay is proven by content and the bytes assert their wiring, as the v1.5.7.21 notes' section 2 describes; the proof on THIS artifact — `PROVENANCE.txt`'s `lakekeeper` row with its `overlay=` and `modes=` fields, the staged binary's `backend-version` answer, and `strings bin/lakekeeper | grep -c argondb-dual` — is in Build facts, and a candidate whose bytes lacked the dual arm would have stopped this cut. The dual run [D-2026-10-25-f1c715] [D-2026-10-30-0eee29] starts at the ERP's first `dual` flip on v1.5.7.21 or later bytes; nothing here changes which authorizer decides under any mode. ## 5. What else landed on `main` since the v1.5.7.21 tag's base Fourteen fragments landed since the `v1.5.7.21` base; ten are the product sections above. The other four are listed here by name and are NOT product changes: ### The previous release's record - `product-release-2026-10-30-the-cut-reapplies-the-catalog-overlay-by-patch-hash-asserts-the-dual-arm-in-the-bytes-and-cuts-v15721-because-v15720-shipped-no-argondb-dual-arm` — "release — ArgonDB v1.5.7.21 for Linux: the catalog carries the dual authorizer arm (v1.5.7.18 through v1.5.7.20's did not); the overlay is proven by patch content and the bytes assert their wiring; cut from main's tip plus the release-path fix, 2026-10-30". The record of the cut this one follows; its notes are at . ### The coordinator harness (listed by name; not a product change; not in the tarball) - `harness-fix-2026-10-31-no-new-user-timer-the-memory-backup-the-saturday-assembler-and-the-harness-deploy-move-onto-argon-coord-schedules-and-the-landing-event` — "harness-fleet — the coordinator box's memory backup and Saturday assembler run as argon-coord schedule rows, and a refused harness deploy is retried by the landing event's subscriber". ### The kit channel (listed by name; the kit's own channel; not a Linux-box change) - `release-cut-2026-11-01-the-kit-rail-stages-openfga-in-the-box-image-builds-its-tier-from-source-and-moves-the-staged-kit-pin-once-the-template-gate-is-green` — "release — the box image carries the catalog's policy engine, and the cut builds its storage tier from the source it ships". - `release-cut-2026-11-01-the-third-kit-cut-from-mains-tip-after-the-lake-query-fix-runs-the-templates-acceptance-to-green-moves-the-staged-pin-and-delivers-last-cut-to-argon-template` — "release — the third kit cut from main's tip, kit-argon-72bc5d48, replayed through the customer's sequence before publication". ### ArgonDBCloud No ArgonDBCloud fragment landed since the `v1.5.7.21` base; its crates moved by one line (`crates/argondbcloud/examples/splink-erp-post-install-overlay.json`, the worked-overlay example stops naming a person, `bb21dc7ea1`); the connection-capacity design of 2026-11-01 (`argondbcloud-design-2026-11-01-connection-capacity-per-tenant-computes-under-g1-…`) is a design page, not a crate change. The installer's own channel (`argondbcloud/LATEST`) is unchanged by this cut and its next cut pins 1.5.7.22. ### The harness changes on `main` since the v1.5.7.21 tag's base, by landing subject Between the `v1.5.7.21` base and this cut's base (`git log 3d16e11c71..dcfd42471c49`, the `land:` commits) the ten product landings are sections 2 and 3, the v1.5.7.21 cut's record and the two kit cuts are above, and the rest are the coordinator harness's — the landing scheduler, the read-set-scoped lint legs, the schedules, the standing-red fixes, the post-mortem recharters, the template ports, the fingerprint sweeps and the hand-landing rules the cut-ask landing produced: - `harness-fix-2026-10-31-a-landing-runs-only-the-lint-legs-whose-read-set-the-change-touched-…` and `harness-fix-2026-11-01-every-lint-legs-read-set-is-traced-to-the-files-its-program-opens-at-head-…` — a landing runs only the lint legs whose read set the change touched, from one leg-inputs table traced at HEAD, with a genuine whole-tree leg named as the FLOOR; the full set runs nightly as a box proof; `harness-fix-2026-11-01-mirror-and-record-paths-leave-every-legs-read-set-…` is its mirror-path rule. - `harness-fix-2026-11-01-the-landing-scheduler-in-argon-coord-owns-the-push-queue-…` (the push queue, slot reservation at spawn, the capability table). - `harness-fix-2026-11-01-hand-land-runs-the-authoring-proof-census-before-it-launches-…`, `harness-fix-2026-11-01-the-reconcilers-green-unlanded-net-leg-reads-a-per-pass-slice-…`, `harness-fix-standing-red-registry-client-selftest-on-main`, `coordinator-fix-2026-11-01-one-fleet-no-partitions-splink-server-eight-lanes-…` and `fleet-ops-2026-11-01-towb-gets-the-box-stack-built-and-the-calibrate-ladder-run-…` (the landings after the first v1.5.7.22 lane's base). - `harness-fix-2026-11-01-the-daily-24-hour-review-is-an-argon-coord-schedule-row-…`, `harness-fix-2026-11-01-the-customer-sequence-replay-runs-an-image-candidate-inside-its-container-…`, `harness-fix-2026-11-01-the-fleet-board-names-every-account-by-its-email-behind-one-password-gate-…`. - `harness-fix-2026-10-31-coord-commit-takes-the-landings-shape-after-a-lost-push-…`, `harness-fix-2026-10-31-every-selftest-fixture-queues-its-rows-with-a-job-type-…`, `harness-fix-2026-10-31-live-state-and-idle-deadline-selftests-leave-the-landing-gate-…`, `harness-fix-2026-10-31-the-37-skeleton-fingerprint-parity-rows-retire-by-ruling-…`, `harness-fix-2026-10-31-the-erp-coordinator-session-launches-through-the-pool-wrapper-…`. - `harness-fix-2026-10-30-an-idle-residents-live-copy-with-no-session-under-it-is-refreshed-…`, `harness-fix-2026-10-30-the-four-unowned-standing-reds-of-10-28-…`, `harness-fix-2026-10-30-the-node-worktree-reclaim-keeps-a-crashed-tree-…`, `harness-fix-2026-10-28-a-land-fail-conflict-and-a-push-lost-to-a-moved-main-…-rerun-1`, `harness-census-2026-10-30-the-10-14-to-10-18-postmortem-fix-chain-…`, `blocker-fix-2026-10-18-landings-per-node-equal-build-slots`, `coord-pm13-thirteen-attempts-of-one-coordinator-commit`. - Ten `harness-fix-standing-red-*-on-main` rows (decision-gate, fmt-clippy, blocked-premise, box-proofs, fleet-launch-loop, lane-launch-first-gate-refusal, lane-launch-giveup, splink-build-nodes, template-update, terminal-event). - Nine `postmortem-fix-*` rows (2026-10-14, 10-15 ×2, 10-16 ×2, and the four 2026-10-30 recharters), four `systematic-fix-*` rows, five `template-port-2026-11-01-*` rows and three `template-update-*` rows, seven `skeleton-fingerprint-sweep-*` rows, and `release-cut-2026-10-31-the-kit-cut-53-days-past-its-daily-if-changed-floor-…`. With them the coordinator's own commits: the decision registry regenerated from the project owner's blocks of 2026-10-31 and 2026-11-01, the one-fleet rulings of 2026-11-01 (splink-server to eight lanes; towb carrying toww's twelve), the ledger mirrors, the port-debt records the post-merge hook writes, and the two derived rules the cut-ask hand landing produced (a hand-built product change is proven by the whole crate's suite before its landing; a hand rebase is checked against the union invariant of every append-only table before anything is pushed). ## Errata already published The v1.5.7.20 served page carries the catalog-overlay erratum under an ERRATA marker (appended by the v1.5.7.21 cut on 2026-10-30; its before and after shas are in that cut's lane report). The v1.5.7.21 served page carries no erratum at this cut, and this cut appends none: nothing in sections 2 and 3 is a defect in a claim the v1.5.7.21 notes made — the hundred-tenant limits are limits those notes did not describe, named here. The v1.5.7.19 page's uuid COPY-rendering and five-rows errata stand as the v1.5.7.21 notes describe them. Two errata written on `main` on 2026-11-01 under `docs/releases/errata/` are the KIT channel's (`kit-argon-d43df2ab`'s idle-box `backfill pending`, section 3.2's defect; `kit-argon-72bc5d48`'s lake-query assertion) and belong to that channel's pages, not to a Linux page. ## 6. The restart procedure, written for a box on v1.5.7.21; no box default changed; two knobs are new, one verb gained a flag Upgrading a box from v1.5.7.21: the data directory stays as it is — it is data, not a binary version, and no lake migration runs. Stop the serve (SIGTERM to the box pid, and wait for it to exit), place the v1.5.7.22 Linux binaries where the v1.5.7.21 ones are, and start with the same `--data-dir` and `--port`. The demo servers, or any process that reads the box, restart after the serve. A box being upgraded from v1.5.7.20 or earlier follows the v1.5.7.21 notes' section 5 first, and through it the earlier notes' restart sections. **Swap the tail and the readers of one estate in one window** (candor line (a), the v1.5.7.17 limit, unchanged by this release) — and on this release that rule has teeth on the landing path too: the `cut_now` answer's `extended` field (section 2.5) is read by a v1.5.7.22 landing runner from a v1.5.7.22 tail. **The knobs.** **No box default changed in this release.** Every knob a Linux box reads keeps the default and the meaning the v1.5.7.21 notes' section 5 lists. **THREE KEYS ARE NEW**, and each is inert when absent: `[compute] max_connections` (absent: the primary runs 100, as before; `ARGONDB_PG_MAX_CONNECTIONS` wins over the file; a value below the box's floor is refused by name before anything is spawned — section 2.1), `[pooler] default_pool_size` (absent: `limit / 4`, as before) and `[pooler] server_idle_timeout` (absent: 600 s capped at the idle window, as before; both read at `argondb serve` start, a change needs a restart — section 2.2). **ONE VERB GAINED A FLAG:** `argondb lake list --table a,b[,c]` reads only the named tables (section 2.3); `argondb lake list` without it and `--from-catalog` are unchanged. `[lake] catalog_authz` keeps its default (section 4). **The interim levers the first plan for this version named for Row C and Row D** — `[lake] cadence_secs = 60` on a large estate, and a retry of the first grantee after the pass boundary — **are not needed as workarounds on these bytes**: Row C, Row D and the cut-ask window are all in this cut (sections 2.5 to 2.7). `[lake] cadence_secs` stays an ordinary operator knob with its default unchanged. For Splink's ERP boxes, the sequence is the v1.5.7.21 one with the new path: install v1.5.7.22 beside v1.5.7.21 with the same installer and the sha256 from Build facts (the package unpacked at `/srv/erp/argondb-v1.5.7.22`); point the box environment at the new prefix where it points at v1.5.7.21; set `[compute] max_connections` for the tenant count the box carries (section 2.1's sizing: about `5*T + 7`; 600 carries 118 tenants) and, where the pools should be smaller than `limit / 4`, `[pooler] default_pool_size` and `server_idle_timeout`; restart the serve on the same data directory and port (`scripts/erp-box-restart.sh --force` from the ERP checkout, as for v1.5.7.21); read the box's start lines — `max_connections: N ()`, `pooler defaults: …` (or `pooler: NOT RUNNING …`, which names the install line) and, on the first estate pass, `connections: max N, box constant C, per-tenant pool P, T tenants may ask T*P, headroom H`; then relaunch the demo servers — and their readers with them, since the readers and the tail of one estate upgrade together — and replace the demo load's `wait_lake` poll with `argondb lake list --table `. The box refresh on any customer box is that customer's step: on Splink's boxes the swap is Splink's, in the window they pick (the project owner's block of 2026-11-01 names Monday 2026-11-02 afternoon for their gate estates; the ERP coordinator's note of 02:17Z names one swap before their 7am review and the goldens re-taken on both boxes from the published tag). **The ERP's platform conformance gate re-run after the swap is the field measurement of this version's twin row** (EXPECTED GREEN, as on v1.5.7.19 through v1.5.7.21; the cut's own twin landing at the ERP shape on ms-01 is in Build facts). What is different at the first start on v1.5.7.22: - Three new start lines: `max_connections: 100 (default)` (or the value and its source), `pooler defaults: pool P per tenant (…), server_idle_timeout S s (…); P backends per tenant against the primary's N - C = H shared slots, so more than H/P tenants exceed it; [pooler] read at start; a change needs a restart`, and on the first estate pass the `connections: …` line with a one-time `WARN` when `T*P` exceeds the headroom. - The publish-status pass line gains `refresh / this bound, /pass` and `pending=`; the first pass of a process seeds every table from the tail's cut record instead of walking the catalog (section 2.3). - A scoped `argondb-query` statement's cost line reads `pruned to the pin's scope — the statement's scope, K of N warehouse(s) walked` and names the reader's catalog concurrency (1); a catalog 503 reads `catalog unavailable (503 from , , warehouse )` (section 2.4). - A landing on a busy estate may print `FINDING — the 120s window expired ... while the pass advanced (N steps) ... a timeout is never a verdict` from the tail, and the landing runner's own `FINDING` for a pin window that expired while the pin moved; the `cut_now` answer line names `extended` (section 2.5). A refusal names the windows it took. - A pin's freshness read that misses once prints a warning naming the address, the class, the elapsed milliseconds and the attempt count, and the tail logs `freshness-action: side=tail peer= scope= head= answer_ms=` for every freshness action (section 2.6). - A landing's pin line reads `consent read: N of M warehouse(s) walked` (section 2.7). - A PostgreSQL-spelled read of a published table over MCP answers from the lake copy with `pinned_lsn:` (section 3.1). - Nothing at the boot line under `openfga` beyond those; no view is rebuilt, no lake table is created, no journal row is rewritten. ## 7. Known limits - **(a) The tail and the readers of one estate upgrade together** (the v1.5.7.17 limit, unchanged): a reader on v1.5.7.16-or-older bytes answers not-yet-durable for a table the estate record covers — stale, disclosed, never wrong — until it is swapped. - **(b) THE CROSS-VERSION GOLDEN COPY IS A KNOWN GAP** (as the v1.5.7.18 through v1.5.7.21 notes say [D-2026-10-26-e06dd0]). No proof of this version or of the five before it ran a clone of an estate's golden copy taken on an older platform version onto an engine of this version; a gate that warns on it is right; the case is unmeasured on our side. The ERP coordinator's note of 02:17Z says the goldens are re-taken on both boxes from this tag; that is their act, not a measurement of this gap. - **(c) through (h)** stand as the v1.5.7.21 notes' section 6 states them: the never-landed probe's listing waits for the in-engine authorizer (c); the uuid COPY-rendering history (d); the fresh-tenant first-refresh wall (e); the lake writer's `UInt64` refusal, not changed here (f); the bench's figures as field figures (g); the served v1.5.7.18 through v1.5.7.20 catalogs without the dual arm (h). - **(i) THE RELEASE TARBALL DOES NOT BUNDLE PgBouncer, AND THE POOL SIZES BIND NOTHING UNTIL IT IS INSTALLED** (section 2.2; ERP-measured 2026-11-01 about 2:2xpm ET on the estate box, which then printed `pooler: NOT RUNNING` with the install line). The two new `[pooler]` keys and the arithmetic line are read on a box with the binary; on one without it the box serves every tenant on its direct port and says so. PgBouncer 1.26.1 was present and running on splink-server when this cut's lane read it (2026-11-02 3:26am ET); each box's own start line after the swap is the only statement of whether its pooler started. - **(j) THE 630 s CLIENT BOUND AND THE 3 s FRESHNESS DEADLINE ARE UNCHANGED** (section 2.5's limits): the landing runner's `CUT_NOW_CLIENT_BOUND` of 630 s on one whole `cut_now` call is listed in the absolute-bounds census and not converted — a single ask the tail keeps extending past it is not received, and the pin falls back to its own window wait; the pin's 3 s freshness deadline after a fallback is the same deadline, asked twice (section 2.6), and its own extension is a later row. A pass that makes no visible progress for a whole stall window (clamp(4 × cadence, 120 s, 600 s)) is still a timeout. - **(k) ROW C IS IN THIS CUT, with its limits** (section 2.6): the retry is one and only for the pin's freshness read; a tail that misses both attempts costs a refused landing about 6.7 s instead of 3 s; whether a miss was a contended ingest lock or a hung connect is read from the tail's `freshness-action:` line, not the client's; the 1:41pm refusal's cause is diagnosed, not fixed. - **(l) ROW D IS IN THIS CUT, with its limits** (section 2.7): a publication granted to `*` still walks every warehouse, as does a publication the box primary does not name, a run under `--at`, or a box whose primary will not answer inside 60 s — the pin line names which; the lake walk is still taken on every landing; a tenant that subscribed to a publication that never granted it reads `no grant for ; no accept from `. - **(m) The ERP's own estate has not been re-run at 100 tenants with the `max_connections` knob raised** (section 2.1's limits); the 120-tenant shape is covered by the unit replay at both polarities and the box gate at six tenants. The knob sizes the primary only; a per-tenant compute's limit is named, not sized. The arithmetic is printed, not enforced. - **The two `[pooler]` keys are read at start** (section 2.2's limits): a change needs a restart; hot reload was not built; a per-tenant `[pooler.pool_size].` override still wins. - **The refresh's total cost is unchanged** (section 2.3's limits): one catalog read per table per hour, 41 per pass instead of 4,838 in one; a table seeded from the cut record reads the tail's own coordinate until the census reaches it, inside the first hour. - **A `404 TableNotFound` for a table the same walk listed is still reported as that disagreement** (section 2.4's limits); the warehouse-level prune believes a tenant warehouse is named after its database. - **A bare or two-part spelling is read in the box's PRIMARY database** (section 3.1's limits); the kit's sample app still reads the lake copy by its lake name. - **The template gate's `lake-publish` leg was not re-run against a box image built from the idle-box fix** (section 3.2's limits). - Everything the v1.5.7.21 notes' section 6 lists stands unchanged, and through them the v1.5.7.20 and earlier notes' limits sections. ## 8. Everything else is v1.5.7.21, unchanged Every feature, fix and limit the v1.5.7.21 notes state (and, through them, v1.5.7.20's and every earlier v1.5.7.x page's) applies to v1.5.7.22 as written there, except where a section above says otherwise. Read them in the v1.5.7.21 notes (`docs/releases/v1.5.7.21.md`, ). **Candor — what v1.5.7.22 does NOT change, and what it has not measured.** - **Nothing here was measured on splink-server or on any customer estate by this cut** except two readings this cut's lane took on 2026-11-02 at 3:26am ET: the ref box's environment names `/srv/erp/argondb-v1.5.7.21` (so the conformance gate for this version is BLOCKED from our side — Build facts), and `/usr/sbin/pgbouncer` answers `PgBouncer 1.26.1` and is running. The ERP coordinator's field lines of 2026-11-01 (10:13am, 1:41pm, 2:08pm, about 2:2xpm, 5:16pm to 7:42pm and 9:27pm ET; the 143 s preflight and the three refused referee runs) are theirs, labeled as theirs in section 2; the 11 min 11 s freeze is the coordinator's reading; the landing lanes' readings of the estate's and the reference box's logs are the lanes', labeled so. The after-figures on the ERP's estates are theirs, owed at their swap, and this page does not project them. - **the release tarball does not bundle PgBouncer; a box whose host has no `pgbouncer` binary prints `pooler: NOT RUNNING` with the Ubuntu install line and serves every tenant on its direct port, and the `[pooler]` pool sizes bind nothing until the binary is installed** (section 2.2, candor line (i)). - **The 630 s client bound on one `cut_now` call and the pin's 3 s freshness deadline are unchanged** (candor line (j)); a stall window is still a timeout. - **Row C and Row D ARE in this cut** (sections 2.6 and 2.7; candor lines (k) and (l)), each with the limits its fragment states; the first plan for this version deferred them to v1.5.7.23 and the interim levers it named are not needed as workarounds on these bytes. - **The fifth product change was built and landed by hand by the coordinator** (section 2.5), proven by the whole crates' suites before its landing and by the landing's own gate round on `main`; the hand landing's two reworks (a second progress channel the landing's `cargo test` caught; a hand rebase that dropped main's rows, the landing's lint caught) are recorded as post-mortems 2 and 3 of that landing and changed nothing in these bytes beyond the pin window reading one channel. This cut re-ran the three crates whole on the cut bytes. - **(a) The tail and the readers of one estate upgrade together** (section 6; the v1.5.7.17 limit stands). - **(b) THE CROSS-VERSION GOLDEN COPY IS A KNOWN GAP** (section 7). - **(c) through (h)** stand as the v1.5.7.21 notes state them (section 7). - **Which authorizer decides did not change**: the box selects `openfga` or `off`; `dual` and `engine` boot only when set by name; the catalog is the v1.5.7.21 catalog by patch content (section 4). - **The text index's per-table pins, the estate record and its reader side, the scoped transform pin, the catalog client's 408 retry, the warehouse-wide durable-servable pin's promise and proof, the tail's cadence loop, the cut body, the ring-read bound, the first-cut sort spill, the view maintainer, the generated append body and the uuid COPY rendering are unchanged.** - **This cut was verified on one product source.** At the cut, the release-verification pipeline with its gating idle-estate suite and the lake gate's uuid-keyed ERP-shape leg, the cross-tenant soak alone on an idle node proven clear by a process census, the twin landing at the ERP shape as the cut's own step on ms-01, and the ten product landings' own regression tests named in Build facts ran on the product bytes of this tag (the soak on binaries built from the cut lane's tip, whose `crates/` are byte-identical to `main`'s tip — the diff proof is in Build facts). The customer-sequence replay was not run at the cut (as every v1.5.7.x cut). The product lanes' BOX gates (`compute-max-connections`, the pooler gate, `publish-status-refresh-beside-the-pass`, the scratch-box prune measurement, `pin-freshness-retry-and-refusal`, the consent-scope proof) were run by their lanes on their trees and are quoted as theirs; this cut re-ran their unit and crate tests on the cut bytes, not the box gates. The harness changes' own gates were not re-run at the cut. No box of this cut ran a hundred tenants. - **Linux only.** The macOS channel stays at v1.5.7.13 until its sibling cut, which rests until a macOS user exists; its own notes state its version. The aws and azure channels are retired for new cuts [D-2026-10-05-e957f6]; ArgonDBCloud has its own channel. - The rollout to any customer box is a separate step, not part of this cut. ## 9. The guide at this tag The Developer Guide, the Reader's Edition, the doc index and the code map were regenerated at this cut from this tree's chapters, so the copies at the `v1.5.7.22` tag describe this release's tree. Read the guide from the tag, not from `main`. Both documents are published at in Markdown, Word and HTML. Guide 8 is at this tag and is published as written [D-2026-10-04-1ff98e]. The four guide sentences the v1.5.7.4 notes' section 13 lists as wrong are still in the chapters and still wrong at this tag; no guide pass has corrected them. The guide does not describe `clone-box` (the deployment spec's "CLONE BOXES" section and the v1.5.7.11 notes are its reference), the three new `[compute]` and `[pooler]` keys (section 6 of this page and the fragments of section 2 are their reference), the cut-ask window and the pin windows (section 2.5 is their reference) or the in-engine authorizer (the design page `docs/2026-10-24-in-engine-authorizer-design.md` at this tag). ## Not in this release Every "Deliberately not designed" and "Not in this release" item in the v1.5.7.21 and earlier notes still applies unless a section above closes it. In addition: - **The 630 s client bound's conversion to a window, and the 3 s freshness deadline's extension**: not in this release (section 2.5's limits); both are rows of the absolute-bounds census with their owner. - **A fix for the tail's state lock held for seconds under ring reads** (the 1:41pm refusal's cause): not in this release; Row C diagnoses it (section 2.6). - **A consent read scoped under a `*` grant, under `--at`, or when the box primary will not answer**: not in this release (section 2.7's limits). - **Hot reload of `[pooler] default_pool_size` and `server_idle_timeout`**: not in this release; a change needs a restart (section 2.2). - **Enforcing the connection arithmetic**: not in this release; the box prints and warns, it does not refuse a tenant (section 2.1). - **A bundled PgBouncer**: not in this release and not planned — the platform provides it (candor line (i)). - **A re-run of the ERP's hundred-tenant load on these bytes**: not in this release; the ERP coordinator's, at their swap. - **A `TableNotFound` told apart from a 503 on the client side**: not in this release (section 2.4's limits); the catalog's own log is the only witness. - **The dual run's measurement and the in-engine authorizer deciding by default**: not in this release (section 4); `dual` and `engine` are explicit-only. - **A proof of the cross-version golden-copy clone**: not in this release (candor line (b)); recorded as a known gap, not chartered. - **The macOS sibling cut at this version**: not in this release; it rests until a macOS user exists. - **`argon-coord`, `argon-engine` or `argondbcloud` in the tarball**: not in this release and never were (section 1). - Everything the v1.5.7.21 notes list under this heading. - No change to the fix-number rule (section 1). ## Build facts (measured by the verifying run, 2026-11-02) - Artifact: `argondb-1.5.7.22-linux-x86_64.tar.zst` — 472,374,527 bytes - sha256: `67a92f3bb03be0885740b2692d13f53ab2ae3fb9e1de006147792853850e5228` - Source commit: `8b2e449ac915bef731a4fa75227b2275a100954b` (tag `v1.5.7.22`, annotated, unsigned) on the branch `release/v1.5.7.22` — `main`'s tip `dcfd42471c49236d0e9340b4571c5444437a91c5` (2026-11-02 3:15am ET, the cut-ask fix's landing) plus the commits that carry these notes, the v1.5.7.11 through v1.5.7.21 notes main never carried, the records assembled at the cut, the regenerated cut-time documents and the re-derived file-roles registry. `git diff --stat dcfd42471c49 -- crates/ scripts/ testing/ storage/ Cargo.toml Cargo.lock deploy/` is EMPTY: no crate, no shipped script and no gate differs from `main`'s tip (the diff is EMPTY: 0 files), and the product delta since the `v1.5.7.21` tag is section 1's. The first v1.5.7.22 lane's candidate `fa4574ebb593` on this branch (retired 2026-11-01 9:19pm ET before any publish step) is superseded by this commit; the branch was moved to it with a lease on that exact sha. - **This is a REBUILD, not a reuse of the v1.5.7.21 artifact.** Between the `v1.5.7.21` tag `a1ddf5f15386` and this source the crates the tarball builds moved by 24 files, 6,780 added lines and 340 removed (section 1), in ten product landings headed by the seven of section 2. The artifact's inputs changed [D-2026-10-11-ad81a6], so everything below was built, verified and gated on the new bytes. - glibc floor: 2.43 (measured from the shipped objects; enforced by `install.sh`, which refuses a host below it naming both numbers; NOT gated by the pipeline — no `--max-glibc` was given, so the floor is reported, not judged [D-2026-09-26-2f91d7]). **That floor is above Ubuntu 24.04 LTS (2.39) and 22.04 LTS (2.35), and `install.sh` refuses to install on either** — the same limit v1.5.7 through v1.5.7.21 state; the build node runs Ubuntu 26.04 and a native cut can only be as portable as its build host. - Toolchain and bundled binaries, as `PROVENANCE.txt` records them: `rustc 1.94.0 (4a4ef493e 2026-03-02)`, `postgres (PostgreSQL) 17.5`, `pg_build_type release (cassert absent, -O2 present, proven from pg_config)`, `openfga v1.14.2` (sha256 `46c52492…`, 62,034,082 bytes), `target x86_64-unknown-linux-gnu`, `build_os Ubuntu 26.04 LTS`, `build_kind native`, `build_host_glibc 2.43`; **PgBouncer is not bundled** (section 2.2, candor line (i)); the build host is `xps` (the cut's held node, a native build on Ubuntu 26.04 LTS, glibc 2.43 — the same OS, glibc and toolchain as ms-01); built 2026-11-02 10:25:52 UTC. - **THE CATALOG, PROVEN FROM THE ARTIFACT'S OWN BYTES (section 4), three readings — the v1.5.7.21 catalog by patch content.** (i) `PROVENANCE.txt`'s row: `lakekeeper lakekeeper-bin 0.13.1 sha256=e949cb647621f3e964cc6f20b407ce260eda984af2027c0449df402af2e5fe2a source=https://github.com/lakekeeper/lakekeeper.git v0.13.1 1f6a1fb6ee0ef78d5cb0ca5a96837ee579a03f1c backend=lakekeeper-authz-argondb 0.4.0 (core argondb-catalog-authz; lakekeeper 1f6a1fb6ee0ef78d5cb0ca5a96837ee579a03f1c; overlay 6cf891adafbb) modes=argondb,argondb-dual,openfga,allow-all overlay=6cf891adafbb modes=argondb,argondb-dual,openfga,allow-all build_seconds=132`. (ii) The published artifact's `bin/lakekeeper argondb-authz backend-version` on ms-01: `lakekeeper-authz-argondb 0.4.0 (core argondb-catalog-authz; lakekeeper 1f6a1fb6ee0ef78d5cb0ca5a96837ee579a03f1c; overlay 6cf891adafbb) modes=argondb,argondb-dual,openfga,allow-all` (rc 0). (iii) `strings bin/lakekeeper | grep -c argondb-dual` on the published artifact: 1; `DUAL authorizer` (the dual arm's serve line) 1, `dual forward` (the dual forwarder's text) 3. The overlay line the catalog build printed on the XPS inside the verify: `lakekeeper build: overlay: already at 6cf891adafbb` (the cached checkout's record read the patch's sha before and after: `record=6cf891adafbb9ec820a1ed1de8e3640bb339286c34d95fda354fd38dc51a29cb dual-arm-lines=2 modes-const-lines=1` both before and after); `lakekeeper build: BUILD_SECONDS=131`; `lakekeeper build: MODES=argondb,argondb-dual,openfga,allow-all`; `lakekeeper build: OVERLAY=6cf891adafbb`; `lakekeeper build: WARM=yes`; `lakekeeper: no host copy carries the backend under this repo's overlay — building the catalog from source at its pin`. The backend is INERT BY DEFAULT — the box selects `openfga` or `off`, and `dual` / `engine` reach the catalog child only when set by name. - **What is in `bin/`, and what is not** (section 1): `argondb argondb-maintenance argondb-mcp argondb-query argondb-scan argondb-tail lakekeeper openfga` — the same eight as v1.5.7.21. `argon-coord` and `argon-engine` are NOT among them and never were. No file in the artifact has `argondbcloud` in its name. The cut builds exactly `cargo build --release -p argondb-ctl -p argondb-tail -p argondb-mcp -p argondb-query` (`scripts/release/build-artifact.sh`) plus the catalog; the `argon-coord`, `argon-harness-db`, `argondbcloud`, `argondbcloud-cli` and `argon-engine` crates are not among them. - Verification (`scripts/release/release-verify-linux.sh 8b2e449ac915bef731a4fa75227b2275a100954b --version v1.5.7.22 --node xps --strict-overlay --timeout 18000`, 2026-11-02 4:56:03am to 5:56:09am ET, ALONE on the XPS under this cut's node-wide hold of its three slots — no other box, no other lane's process on the node (the census the soak used) — driven from the release tree at the source commit ON the XPS itself, so the tested release-path scripts are the source commit's own): strict overlay `OVERLAY divergent=0 identical=8 absent=0 of=8`, `NOTES section=present version=v1.5.7.22`; `VERDICT: PASS release-verify-linux — every suite green and at or above its run-count floor`. One candidate, one verify run; no re-cut. Suites: `SUITE checkout STATUS=PASS ran=4 passed=4 floor=4 detail=clean-export-of-8b2e449ac915-with-4-vendored-pg-submodules`; `SUITE build STATUS=PASS ran=1 passed=1 floor=1 detail=argondb-1.5.7.22-linux-x86_64.tar.zst`; `SUITE glibc-floor STATUS=PASS ran=1 passed=1 floor=1 detail=measured-2.43-NO-LIMIT-GIVEN-pass---max-glibc-to-gate-it`; `SUITE install STATUS=PASS ran=2 passed=2 floor=2 detail=INSTALL-OK-into-/var/tmp/argon-relverify-8b2e449ac915/prefix-and-the-pooler-key-in-/var/tmp/argon-relverify-8b2e449ac915/prefix/box/argon.toml`; `SUITE box-acceptance STATUS=PASS ran=4 passed=4 floor=4 detail=install.sh--smoke-against-/var/tmp/argon-relverify-8b2e449ac915/prefix`; `SUITE box-lake-acceptance STATUS=PASS ran=8 passed=8 floor=8 detail=pg+lakekeeper+store+tail+mcp-from-the-installed-binary`; `SUITE idle-estate-acceptance STATUS=PASS ran=7 passed=7 floor=7 detail=ESTATE-ACCEPTANCE-MET:-idle-BatchCheck/min-12.1-<-100,-openfga-+-backends-0.002-core-<-0.5-`; `SUITE transform-landing STATUS=PASS ran=838 passed=838 floor=2 detail=18-cargo-test-binaries-across-2-passes-external-pg`; `SUITE starters STATUS=PASS ran=4 passed=4 floor=4 detail=4-shipped-legs-executed=18-legs-skipped=2`; `SUITE m3-tail STATUS=SKIP-STRUCTURAL ran=0 passed=0 floor=0 detail=docker-present-but-this-pipeline-does-not-own-compose-2-run-the-m3-gates-from-a-compose-2-holder`. **The idle-estate acceptance suite, the gating suite, against the INSTALLED artifact:** `MEASURE: idle BatchCheck/min over P2 (the idle pass, nothing written): 12.1 (all sources); openfga + backends 0.002 core(s)`, `ok: ESTATE ACCEPTANCE MET: idle BatchCheck/min 12.1 < 100, openfga + backends 0.002 core < 0.5 (with the 24-table landing in P3 (P2..P3): 155.7/min, 0.007 core; landing marginal checks 590, wall 10.6 s)`. **The lake gate's uuid-keyed ERP-shape leg (the v1.5.7.20 fix, still landing), against the installed artifact:** `== an append publication over a table no view enrolled lands into a grantee (the ERP's shape) ==`; `box-lake: PASS (full product from one command)`. The compose-stack tail-correctness gates (m3) did not run inside the verify: the pipeline holds no compose-2 mutex (`SUITE m3-tail SKIP-STRUCTURAL`); the stats-quiet-skip gate ran on the compose-2 stack on the XPS after the soak instead (below). - Build-host disclosure scan: `artifact-buildhost-scan: CLEAN - build user 'steveis' is named nowhere in 1778 file(s) / 2461852368 byte(s) under /var/tmp/argon-relverify-8b2e449ac915/release-out/argondb-1.5.7.22-linux-x86_64`. - **The cross-tenant soak, ALONE on the XPS under the node-wide hold, one run** [D-2026-10-11-964bab], on binaries built on that node from the cut lane's tip (`main`'s tip plus the lane's proof commit, whose `crates/` are byte-identical to `main`'s tip; the soak reads no catalog build and no document): the node-wide hold requested FIRST at 3:27:05am ET on 2026-11-02 and HELD 3/3 at once (load 1.55, no slot held (0/3); one foreign claude -p lane of another task on the node holding no slot); the soak dispatched at 3:28:39am ET (the self-node local arm: the cut lane runs on the XPS; the hold HELD 3/3 at 3:27:05am) with the census read again (at 3:28:45am (the payload's own census at start): load average 1.61; `census-node: 12 lane process(es) on xps over 1 task(s)` — the one other task's `claude -p` lane (`harness-fix-2026-11-01-one-slot-table-…-conflict-1`), holding no slot; this lane's own shells excluded by `XSOAK_OWN_TASK`; slot1/2/3 this lane's); the soak's own precondition — `scripts/lib/node-census.py` reading zero foreign lane processes beside load1 at or under 2.0, every 300 s, bounded at 10,800 s (the v1.5.7.20 and v1.5.7.21 cuts' wait, set from the start inside the payload; the soak and its bound untouched), with the cut lane's OWN task excluded from the census because this cut's lane ran on the XPS itself (`XSOAK_OWN_TASK`, the soak's own hook; its idle `claude -p` shell is not a foreign lane) — NOT met at the first 11 polls (0 s to 3,000 s: load1 20.13 to 1.19 — the soak's own build, then this lane's preliminary lint — and 16 to 4 foreign lane processes of the one other task, the last four of them orphaned `sleep 14400`s of that lane after its exit and cleanup, then 0 from the 3,000 s poll) and **MET after 3,300 s: `[xsoak] precondition MET after 3300s: load1 1.16 <= 2.0, no foreign lane process (census-node: 0 lane process(es) on xps over 0 task(s); 394 process(es) with an unreadable cwd (other uid))`**; 4:33:51am to 4:54:18am (the dispatch 3:28:39am; the build 3:28am–3:38am; the precondition wait 3:38:51am–4:33:51am) ET; census rows `census-node: 0 lane process(es) on xps over 0 task(s)` at both at the soak's start and end): `cross-tenant-soak: PASS — 0 refusals, every view current at every phase end — 180 landing(s) over 3 phase(s), 13 view(s); median 16522 ms, slowest landing 30034 ms (phase 2 #56 wh04 -> [wh01,wh05,wh09], consent pin 1221 ms); pins/landing 17.38, round trips/pin 39.1; bound 359256 ms (baseline lane-cut-landing-rerun-2037 max 179628 ms x 2)`; record `cut-v15722-dcfd42471c-xps-alone` (`2026-11-02 180 16522 30034 17.38 39.1 PASS`); phases `phase 1: 60 landed, 0 refused; landing median 15212 ms max 30022 ms; views current 13/13 (slowest to current 10s)`; `phase 2: 60 landed, 0 refused; landing median 16842 ms max 30034 ms; views current 13/13 (slowest to current 10s)`; `phase 3: 60 landed, 0 refused; landing median 17249 ms max 26494 ms; views current 13/13 (slowest to current 10s)`; 88 one-minute load samples. The baseline row was not committed (it would tighten every later soak's bound, a shared gate definition; named for the coordinator, as the v1.5.7.16 through v1.5.7.21 cuts did). `stats-quiet-skip` on the compose-2 stack after the soak: `SQS_RC=0`. - **The twin landing at the ERP shape, the cut's own step** [D-2026-10-28-eaaed6] (after the soak, before the publish; `scripts/release/cut-twin-landing-step.sh --version v1.5.7.22 --bin-dir `, ONCE, on ms-01 under one fleet slot, the nightly roster row's own runner at its own shape — 24 twins, 400 estate tables, the landing alone under 30 s; RED stops the publish like the soak's): `cut-twin-landing: PASS — twin landing at the ERP shape: 24 twins in 22.1 s against 30 s (v1.5.7.22, sha 8b2e449ac915bef731a4fa75227b2275a100954b, ms-01)` (2026-11-02 5:58:11am to 6:15:50am (step wall 1,044 s; ms-01 slot 2; the artifact's own bin/ through --bin-dir, nothing built) ET; the gate's own line `twin-landing-at-erp-shape: PASS — 8 checks (400 estate tables + 36 views, tenant 45 tables / 24 views, bg [none]; authz=openfga; write->landed 26.3 s; landed->current 58.2 s (24 refreshed, 126 catalog calls); landing alone 22.1 s (24 twins, median 0.7 s, max 1.1 s, 0 cold walk(s), 24 scoped); authorizer in the landing window: 762 BatchChecks (19 reader), 0.939 core; catalog audit lines 780 (11 reader))`). - **The product landings' own gates on the cut bytes** (ms-01, gate set P under one fleet slot, release build of the cut bytes, 2026-11-02 3:28am to 4:10am (ms-01 slot 2) ET, the node at load 1.19 to 22.51): the catalog built by `scripts/release/build-lakekeeper.sh` on ms-01's own cached checkout → `overlay: already at 6cf891adafbb`, the binary answering `lakekeeper-authz-argondb 0.4.0 (core argondb-catalog-authz; lakekeeper 1f6a1fb6ee0ef78d5cb0ca5a96837ee579a03f1c; overlay 6cf891adafbb) modes=argondb,argondb-dual,openfga,allow-all`, `strings`: `argondb-dual` 1, `DUAL authorizer` 1; **(1)** `max_connections` (the knob, the floor refusal, the arithmetic line and its WARN, the 120-tenant replay at both polarities) → `test result: ok. 13 passed; 0 failed; 0 ignored; 0 measured; 1426 filtered out; finished in 0.01s`; **(2)** `pooler::` (the two defaults, the fan-in line, the ini's comment block) → `test result: ok. 37 passed; 0 failed; 0 ignored; 0 measured; 1402 filtered out; finished in 0.02s` (the bin crate; argondb-ctl has no lib target); **(3)** `publish_status` (the refresh beside the pass, the cut in the record, the seed from the cut record) and `lake::` (`lake list --table`) → `test result: ok. 25 passed; 0 failed; 0 ignored; 0 measured; 1414 filtered out; finished in 0.04s` and `test result: ok. 30 passed; 0 failed; 0 ignored; 0 measured; 1409 filtered out; finished in 0.00s`; the tail's freshness record, the cut-ask window and Row C's tail side (`argondb-tail`, whole crate) → `test result: ok. 890 passed; 0 failed; 2 ignored; 0 measured; 0 filtered out; finished in 2.05s (and 14 further test binaries, every one `test result: ok.`)`; **(4)** the reader and Row C's client side (`argondb-query`, whole crate: the scoped walk, the 503, the in-flight ceiling, the freshness retry) → `test result: ok. 470 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.74s (and 16 further test binaries, every one `test result: ok.`)`; `argondb-committer` (whole crate) → `test result: ok. 429 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 26.93s (and 6 further test binaries, every one `test result: ok.`)`; the hybrid spelling resolver (`argondb-common pg_spelling`) → `test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 187 filtered out; finished in 0.00s`; **(5)** the on-demand cut ask's window (`argondb-tail cut_on_demand`, the advancing pass waited for and the stalled one not) → `test result: ok. 12 passed; 0 failed; 0 ignored; 0 measured; 880 filtered out; finished in 0.00s`; **the pin windows and Row D** (`argondb-ctl landing_runner`; `argondb-transform publication`) → `test result: ok. 42 passed; 0 failed; 0 ignored; 0 measured; 1397 filtered out; finished in 0.02s` and `test result: ok. 61 passed; 0 failed; 0 ignored; 0 measured; 265 filtered out; finished in 0.01s` and `test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 1 filtered out; finished in 0.00s` and `test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 17 filtered out; finished in 0.00s` and `test result: ok. 0 passed; 0 failed; 3 ignored; 0 measured; 19 filtered out; finished in 0.00s` and `test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 14 filtered out; finished in 0.00s` and `test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 8 filtered out; finished in 0.00s` and `test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 19 filtered out; finished in 0.06s` and `test result: ok. 0 passed; 0 failed; 4 ignored; 0 measured; 7 filtered out; finished in 0.00s`; the v1.5.7.21 set still green — the in-engine authorizer crate → `test result: ok. 38 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s`; `lake_grant`, `administrator`, `catalog_authz`, `system_create`, `append_publication`, the decoder's batched discovery, copy.rs (the uuid fix), `view_catalog`, `catalog_idle_pool_408` → `test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 1432 filtered out; finished in 0.00s`, `test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 1432 filtered out; finished in 0.01s`, `test result: ok. 19 passed; 0 failed; 0 ignored; 0 measured; 1420 filtered out; finished in 0.00s`, `test result: ok. 13 passed; 0 failed; 0 ignored; 0 measured; 1426 filtered out; finished in 0.00s`, `test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 1436 filtered out; finished in 0.01s`, `test result: ok. 23 passed; 0 failed; 0 ignored; 0 measured; 167 filtered out; finished in 0.00s`, `test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 318 filtered out; finished in 0.00s`, `test result: ok. 21 passed; 0 failed; 0 ignored; 0 measured; 449 filtered out; finished in 0.01s`, `test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.54s`; unit tests over the shipped crates, the authz core, the decoder and the common crate: 4793 passed, 0 failed over 69 result lines (`UNIT_RC=0`); `FMT_RC=0`, `CLIPPY_RC=0`. The product lanes' BOX gates (`compute-max-connections: PASS`, `pgbouncer-pooler-gate: PASS`, `publish-status-refresh-beside-the-pass: PASS -- 7 check(s) on a 4200-table estate`, the scratch-box prune measurement, `pin-freshness-retry-and-refusal: PASS`, the consent-scope scratch-box proof) ran in their lanes on their trees (section 2) and were not re-run by this cut. - **The platform conformance gate for v1.5.7.22** (one gate per version at the cut, an owner on every FAIL row; the project owner's block of 2026-10-21 about 8:2xpm ET): **BLOCKED from this side — owner the ERP coordinator, version argondb-v1.5.7.22.** The gate measures the bytes installed on the ref box; at the cut (2026-11-02 3:26am ET) the ref box's environment (`/srv/erp/argondb-erp-ref-data-v1.5.7/erp-box-env.sh`) names `/srv/erp/argondb-v1.5.7.21` and `/srv/erp/argondb-v1.5.7.22` does not exist; the referee trees under `/srv/erp/referee-trees` on splink-coordinator are the ERP's (`steve1`), and this cut never deploys; the ERP note asks them to run it at their swap (one swap before their 7am review, their 02:17Z note; their gate estates Monday 2026-11-02 afternoon, per the project owner's block of 2026-11-01) and send the rows, an owner on every FAIL row. EXPECTED GREEN on v1.5.7.22 for the twin row (the cut's own twin step above is the same gate on the cut's bytes); a FAIL there is a finding of the first order with owner platform, recorded. - Gates red or not run at the cut: the customer-sequence replay (as every v1.5.7.x cut); `catalog-authz-80-walk` W2 and `idle-stop-wake` J(8) red on `main` before the cut and not gated on; the twin step ran without the gate's two background estates (one slot); `time-travel.sh` step 5 and `view-maintainer-recompute` P6 red on these bytes and on the base they came from (the v1.5.7.17 notes); the product lanes' box gates not re-run at the cut (quoted as theirs above); the cloud arms' gates and the harness changes' own gates not run at the cut; the macOS builder not run; no box of this cut ran a hundred tenants. - Served notes census at the publish: 119 → 120 files; v1.5.7.21's served page `e9c315b0378197e5257a88234525cf50c8f3b711f5a7e85f837589831cc60764` before this publish and byte-identical after it; this page's served sha is the frozen file's. No erratum is appended to any served page by this cut.