--- class: reference purpose: Release notes for ArgonDB v1.5.7.13 macOS (Apple Silicon) — the earned-view stall and landing-wait cut; frozen. template: product --- # ArgonDB v1.5.7.13 — macOS (Apple Silicon) > **Cut 2026-10-14, from the SAME source commit as Linux v1.5.7.13** — > `924d7573615186fe0851bddf3e34b13346c8c78f`, git tag `v1.5.7.13`. One > version, one commit, both platforms. v1.5.7.13 is the earned-view stall > and landing-wait cut, cut from the tip of `main` the minute its two fixes > landed, under the standing cut ruling [D-2026-09-21-4707dd]; the number > is the next on the v1.5.7 patch line after v1.5.7.12 [D-2026-10-12-cbdd72], > and the macOS sibling was queued at the same commit behind the Linux cut. > **v1.5.7.13 exists for two escaped defects** the ERP coordinator's demo > gate found on their reference box running v1.5.7.12, within hours of its > install: one tenant's `v_program_earned` view stalled three times in 48 > hours, reported as "awaiting ring" for 1790 s each time while the 94 s > ring-read bound of v1.5.7.12 never fired, because the stall was not in > the ring read; and every one-row publication landing of their demo build > took 130-140 s, about 41 s of it inside the platform. **The product delta > since the v1.5.7.12 tag is TWO commits, exactly as the Linux v1.5.7.13 > page attributes them in its section 1**: the view maintainer's step mark > now ends when the ring read ends, so a view stalled in its own recompute > is REPORTED as `awaiting recompute` with the bound that applies to that > step (its section 2); and a cut on demand answers a landing's ask as soon > as the tables the ask names are stamped, not at the end of the tail's > pass (its section 3). Said plainly, in the Linux page's words: **section > 2 names the stall correctly and does not fix it.** A view stalled in its > recompute is still ended only by the 1800 s pass deadline, and what the > earned view's recompute waits on is not known. Section 3 is a fix, > measured on a Linux box shaped like the ERP's: 3.7 s per one-row landing > against 29.5 s before. There is no migration command, no catalog repair, > no lake schema change and **no new knob**. The restart procedure is > v1.5.7.12's with the new path. The complete account of both changes is > the Linux v1.5.7.13 page, served beside the Linux artifact; **the two > product commits are in `argondb-tail`, `argondb-committer`, > `argondb-query` and `argondb-ctl` (the `argondb` binary), which the macOS > artifact ships too.** Everything a Mac does differently is on the macOS > v1.5.7 page and is unchanged here. Every build fact at the bottom of this > page is measured from the artifact, none declared. **ArgonDB on one Mac.** 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. Apple Silicon only. ## What this release carries — main's tip at the tag, for a Mac on v1.5.7.12 A Mac moving from v1.5.7.12 to this artifact receives, in one step: - **A view's `ring` step ends when its ring read ends** (the Linux page's section 2, commit `c0bc101b15`): a view is reported in `ring` only while a ring read is in flight — the mark spans exactly the awaits the ring bound wraps (connect, `do_get`, drain) and carries the bound it is under — and when the read returns the view's step becomes `recompute`. The "still running" and ABANDONED lines name the bound that applies to the step (`awaiting ring for view (41s in that step; its per-step bound is 94s, ARGONDB_VIEWS_RING_STEP_SECS)`, or `awaiting recompute for view (590s in that step; no per-step bound — the pass deadline ends it)`). The ring bound itself is unchanged and is now tested at its 94 s default in both directions. **The stall itself is not fixed**: a view stalled in `recompute` is still ended only by the 1800 s pass deadline. - **A one-row publication landing pays its own tables' cut, not the whole tail pass** (the Linux page's section 3, commit `8778699af9`): the tail stamps the tables a waiting ask names first and answers the ask as soon as they are stamped; the other clean tables are stamped after, handed to the next pass in rotation when the next landing asks (each pass stamps at least 16 of them). The consent read's catch-up now asks for a cut before it waits on the cadence (its pin line says `BY CUT`); the 120 s floor and the 600 s cap are untouched and paid only when the tail cannot answer the ask. Measured on Linux: eleven one-row landings in series took 3.6-7.1 s each (median 3.7 s) against 26-46 s (median 29.5 s) before. - **Nothing else that reaches the artifact.** Between the `v1.5.7.12` tag and the cut's source, `git log --oneline 5d431498dce7..fda5486bf4 -- crates/` lists FOUR commits: the two above (product — `crates/argondb-tail/src/cut_on_demand.rs`, `service.rs`, `flight.rs`, `crates/argondb-ctl/src/landing_runner.rs`, `crates/argondb-committer/src/await_step.rs`, `crates/argondb-query/src/lib.rs` and tests) and two test-only ones (the ring-read log test's subscriber; the crate tests' scratch directories). No dependency and no vendored PostgreSQL source moved. The other commits in the range are the project's harness, gates, release tooling and records (the Linux page's section 4), none of them in the tarball. - **The default-off cloud-facing configuration keys** of v1.5.7.4, unchanged (the Linux page's section 5); a box that sets none of them behaves as before. The ArgonDBCloud crates in the source tree are not in this artifact, as on Linux. The aws and azure one-click channels are retired for new cuts [D-2026-10-05-e957f6] and stay at v1.5.7.3 as published; AWS and Azure ship through ArgonDBCloud. ## What is changed and fixed in v1.5.7.13 — read the Linux v1.5.7.13 notes **The step mark, as the Linux v1.5.7.13 page states it.** Its section 2, *Changed: a view's `ring` step ends when its ring read ends, so a stall after the read is reported as `awaiting recompute` with the bound that applies — the stall itself is NOT fixed*: at 2026-10-12 13:25Z, 2026-10-13 01:42Z and 2026-10-13 17:17Z, a view maintainer pass on the Splink reference box stopped on one tenant's `v_program_earned` view and sat there until the pass's own 30-minute deadline ended it; every other view of the pass waited behind it. The box had `ARGONDB_VIEWS_RING_STEP_SECS` unset, so the 94 s ring-read bound was in force — and it never fired. The third sighting's maintenance log says why: the earned view's four ring reads all answered within their bound (`verdict=within-bound bound_s=94`), and the view then stalled in its own work after the read — the rest of the pin and the query plan, whose lake reads run on worker tasks that leave no step mark — so the view kept the `ring` mark from its last ring read. The ring bound only ends ring reads, so it had nothing to end. After the restart the same stall is logged as `awaiting recompute for view … (590s in that step; no per-step bound — the pass deadline ends it)`, and the pass STILL ends only at 1800 s. The ring-read lines of v1.5.7.12 are unchanged. **The landing fix, as the Linux page states it.** Its section 3, *Fixed: a one-row publication landing pays its own tables' cut, not the whole tail pass*: every one-row landing of the ERP's demo build took 130-140 s, about 41 s of it the platform's — the landing's data pin asked the tail for a cut, the cut committed in under half a second, and the tail answered the ask only at the END of its pass, after quiet-stamping every clean table of the estate (about 200 on the ERP's box); the rest, about 90 s, was the ERP drive's own wait on `argondb lake list`, which is on the drive's side. The tail now stamps the asked tables first and answers at once. **The candor the Linux page carries, carried here.** **This release does not fix the earned-view stall. It only names it correctly.** A view stalled in `recompute` is still ended only by the 1800 s pass deadline, and only then counted against its breaker; every other view of the pass still waits behind it. No per-step bound covers a recompute yet; whether to add one is an open product decision, and the lane for a recompute bound is NOT in this release. **What the earned view's recompute waits on is not known**; the v1.5.7.12 notes' lead (the ring delivery for an input re-registered mid-pass) is NOT where the third sighting's stall is, because its ring reads answered, and the diagnosis starts over from the recompute (a CONSTRAINED pin on the view's derived twin four minutes before the pass is the one fact in the extract that is not routine). Plan for the same stall to recur until that cause is found. On the landing fix: **one older gate is red on this commit because of this change, and the product is not the reason** — `landing-cut-on-demand` leg (c), ten landings started together, read `10 landings -> 0 ask(s)` twice, because a pass that has answered an ask now yields its remaining quiet stamps to the next pass, so a pass end is no longer a cadence boundary and a plain cadence cut landed the row while the ten landings were still in their consent pins; the landings were correct, the gate's timing assumption is what changed, and re-fixturing it is the gate owner's. What this cut has NOT proven: that ten SIMULTANEOUS asks are answered as one; the Linux soak's three landings in flight at a time (180 of them, 0 refusals, median 17.9 s against 86.9 s at v1.5.7.12) are the nearest evidence. The landing fix's field effect on the ERP's box is projected from a Linux box shaped like it (150 clean tables), not measured there. **What was NOT measured on a Mac, stated as such.** The two fixes' own tests, the cross-tenant soak, the new `one-row-landing-pays-the-cut` gate, the view suite's box gates and the box gates of the v1.5.7.1 to v1.5.7.12 fixes ran on the Linux build node against this same commit. **No macOS gate runs a view-maintainer pass, lands a publication or asks the tail for a cut**, so neither change has been exercised on Apple Silicon by a gate; the two gates that ran against this artifact are in "Coverage on Apple Silicon" below. The claim that a Mac carries the two changes rests on the shared code and the Linux proofs of it. ### One source commit for both platforms, stated as a measurement The macOS artifact is built from `924d7573615186fe0851bddf3e34b13346c8c78f`, the commit the Linux v1.5.7.13 artifact was built from, and `PROVENANCE.txt` inside the tarball carries that sha. There is no shipped-code difference between the two platforms at this version. The tag `v1.5.7.13` is the Linux cut's; the macOS cut neither created nor moved it. ## Everything else is macOS v1.5.7.12 and earlier, unchanged Beyond what "What this release carries" lists, this release changes nothing for a Mac. Everything the macOS v1.5.7.12 page says — the per-step deadline on the ring read, the `ring-read:` lines, the one knob `ARGONDB_VIEWS_RING_STEP_SECS` and the short-pass-deadline refusal, all unmeasured on a Mac — everything the macOS v1.5.7.11 page says — `argondb clone-box` released, cut on demand, the pass-line count and the reader-pin fix — everything the macOS v1.5.7.10 page says — the three fixes of that release, its after-restart view step and its re-baseline steps — everything the macOS v1.5.7.9 page says — the landing pin's one retry and the principal-naming refusal — everything the macOS v1.5.7.8 page says — the eight fixes of that release and the memory knob — everything the macOS v1.5.7.7 page says — the four Splink fixes of that release and the check cache ON at 1 s — everything the macOS v1.5.7.6 page says — the four fixes of that release and every other change since v1.5.7.5 — everything the macOS v1.5.7.5 page says — the view-maintainer stall fix and the v1.5.7.4 fixes — everything the macOS v1.5.7.3 page says — the deleted-publisher pin fix — everything the macOS v1.5.7.2 page says — the per-tenant lake tail — everything the macOS v1.5.7.1 page says — the restart fix and `argondb tenant delete` — and everything the macOS v1.5.7 page says about a Mac — the per-tenant compute memory floor read from `vm_stat`, the bundled policy engine, the platform-supplied pooler, the absent cgroup mechanisms and the tail's uncapped bound, the machine-wide 32-segment SysV shared-memory budget, the unsigned ad-hoc signature, the Homebrew libraries the artifact links and does not carry — applies to v1.5.7.13 exactly as written there, except where the Linux page's sections 2 and 3 say otherwise. Read them at , , , , , , , , , , , and . ## Upgrading a Mac — the v1.5.7.12 restart procedure; no new knob Replace the binaries. The data directory stays as it is — it is data, not a binary version, and no catalog or lake migration runs; there is no migration command for your own tables, no catalog repair and no lake schema change. Stop the serve (SIGTERM to the box pid, and wait for it to exit), place the v1.5.7.13 binaries where the v1.5.7.12 ones are, and start the serve on the SAME data directory with the same `--data-dir` and `--port`. Any process that reads the box restarts after the serve. A Mac being upgraded from v1.5.7.11 or earlier follows the macOS v1.5.7.12 page's procedure first, and through it the earlier pages' restart sections (a Mac on v1.5.7.7 or earlier drops `ARGONDB_VIEWS_MEMORY_MB=off` at that start, as the macOS v1.5.7.8 page says). **The knobs: leave every one as it is, as the Linux page's section 6 states it.** Nothing in v1.5.7.13 adds a knob or changes a default. `ARGONDB_VIEWS_RING_STEP_SECS` keeps its 94 s default and its v1.5.7.12 meaning and limit (set it below `ARGONDB_VIEWS_PASS_DEADLINE_SECS` on a box with a short pass deadline, or the maintenance worker refuses to start and says so); `ARGONDB_VIEWS_MEMORY_MB` and `ARGONDB_LOG_MAX_BYTES`, where a box sets them, are untouched. What is different at the first start on v1.5.7.13, as the Linux page's section 6 states it: nothing at the boot line, the tenants or the catalog; a view that stalls after its ring read is logged as `awaiting recompute … (no per-step bound — the pass deadline ends it)` instead of `awaiting ring`, and the pass still ends at 1800 s; a one-row publication landing's data pin is answered as soon as its own tables are stamped — a few seconds on a box like the ERP's instead of about 41 s — and a caller's own pre-landing wait, if it keeps one, is unchanged. None of this has been run by a gate on a Mac. ## Coverage on Apple Silicon **Two gates ran on this platform, both against this artifact installed from the tarball under a clean prefix:** `box-pgmcp` (the pg-mcp acceptance — AI access to a box with the lake off) and `macos-lake-acceptance` (the lake on, under a second prefix, one database, `per_tenant` off). Their verdict lines and assertion counts are on the served copy of this page. That is the whole of the macOS coverage for v1.5.7.13, exactly the shape v1.5.7.12, v1.5.7.11, v1.5.7.10, v1.5.7.9, v1.5.7.8, v1.5.7.7, v1.5.7.6, v1.5.7.5, v1.5.7.3, v1.5.7.2, v1.5.7.1, v1.5.7 and v1.5.5 had. The release's proof is the two fixes' own tests on Linux against this same commit, the cross-tenant soak alone on an idle Linux node (`0 refusals, every view current at every phase end — 180 landing(s) over 3 phase(s), 13 view(s); median 17923 ms`), the new one-row landing gate, the view suite's box gates and the box gates of the earlier v1.5.7.x fixes on the same commit, and the Linux release-verification run. None of the continuous-view, multi-tenant, publication, clone-box or catalog-authorization surfaces — the two this release changes included — has a macOS gate. **This is the shape of having two gates on this platform, and it is a coverage gap, not a claim of equivalence.** ## Installing Unchanged from v1.5.7. The `curl` install path is unaffected by code signing; a browser download hits Gatekeeper once per binary and `xattr -rc` clears it. The installer refuses below the minimum macOS and names both numbers, and probes each Homebrew library the artifact links and names the missing ones. ## Limits and known issues, macOS only **Every limit on the macOS v1.5.7.12, v1.5.7.11, v1.5.7.10, v1.5.7.9, v1.5.7.8, v1.5.7.7, v1.5.7.6, v1.5.7.5, v1.5.7.3, v1.5.7.2, v1.5.7.1 and v1.5.7 pages, and through them the Linux v1.5.6 through v1.5.7.13 pages, applies here too.** What this release adds to that list: - **The earned-view stall is NOT fixed and its cause is NOT established** (the Linux page's section 2). A box that hits it again sees one pass held to its 1800 s deadline with every other view waiting; the difference is that the log names `recompute` and the step's bound. No per-step bound covers a recompute; the lane for one is not in this release. - **The v1.5.7.12 reading of the cause (the ring delivery for a re-registered input) is not where the third sighting's stall is**: its ring reads answered. The diagnosis starts from the recompute. - **Neither change is measured on a Mac.** No macOS gate runs a view-maintainer pass, lands a publication or asks the tail for a cut; the proofs are the Linux tests, gates and soak against the same commit. - **Ten simultaneous asks answered as one is not proven by a gate on this commit**: `landing-cut-on-demand` leg (c) is red for the timing reason the Linux page's section 3 states; the Linux soak's three-in-flight landings are the evidence that exists. - **The landing fix's field effect on the ERP's box is projected**, from a Linux box with 150 clean tables, not measured on the ERP's ~200. - **An ask whose table names the tail cannot read, or that names no table, is still answered at the end of the pass**, as before. - **Under a steady stream of landings, a clean table's lake coordinate can trail by a few passes**; each pass still stamps at least 16 of them, in rotation. - **A cut on demand still costs the cut itself plus the stamps of the asked tables**; on a box whose cut is slow, that is the floor. - **A caller's own pre-landing wait** (the ERP drive's `argondb lake list` wait, about 90 s on their box) is on the caller's side; `publication land` waits for its own run start, so a caller does not need that wait. - **The Linux v1.5.7.12 known limits apply unchanged** (the Linux v1.5.7.13 page's section 7 lists them): a legitimate ring larger than the 94 s default was sized for is abandoned every pass until the knob is raised; a box with a pass deadline under 94 s and the ring bound unset refuses to start its maintenance worker; a `do_get` the tail never gets to answer writes no tail line; the ring bound at work is proven by the test file, not by a box gate; the tail's `ring-read:` log volume; the clone-box limits (a running box cannot be cloned, a BYO-S3 or Azure endpoint is not rewritten, the tenant-port re-pick pending, promotion of a clone to band 0 not proven, the MCP sub-surface ports not moved by the offset, the 6373 warehouse-endpoint reading owed by its operator); a caller-named coordinate before a table's first lake snapshot still refuses the whole pin; why the view-alias regression surfaced on v1.5.7.9 not established; duplicates a cut retry wrote stay until re-baselined; the partial-cut landing path unit-tested only; the gaps-pin retry bounded; `tenant-create-sequence` P9c and the replay's idle leg as the v1.5.7.10 erratum records them (the customer-sequence replay was not run at this cut); `catalog-authz-80-walk` W2 and `idle-stop-wake` J(8) red on `main` before the cut and not gated on; `publication-grant-accept-revoke` leg T5 stale against the per-table pin. - **The v1.5.7.9, v1.5.7.8, v1.5.7.7, v1.5.7.6, v1.5.7.5 and v1.5.7.4 candor applies unchanged**, including the cause of the 02:31Z `NamespaceNotFound` refusal not established, the two-warehouse fix measured in-process with two memory catalogs, the 6,062-consumer population not reproduced, the warehouse-wide durable-servable pin, the 120 s lease, the 484-tenant shape not run, the 48 h orphan horizon, the 1 s check-cache window (`ARGONDB_OPENFGA_CHECK_CACHE=off` restores instant revocation), the roster cache's one entry per user per host, the one-time re-scan after an upgrade from v1.5.7.5 or earlier, and that a box already setting `[storage] remote` uploads WAL after an upgrade from v1.5.7.3 or earlier. - **A deleted tenant's lake data is still not removed**, and the `system list` 4/5 defect the Linux v1.5.7.1 page names is not fixed by this release on either platform. - The per-tenant tail limits of macOS v1.5.7.2 — unmeasured on a Mac, one uncapped `argondb-tail` per awake tenant — are unchanged. - The macOS-only limits of v1.5.7 — no cgroup, the pooler never started by a gate here, the 32-segment SysV budget, the high minimum macOS, not signed or notarized, Apple Silicon only, Homebrew libraries not bundled, no launchd service, `.pkg` or Homebrew tap — are unchanged. ## Not in this release, and deliberately not implemented, macOS only Everything the Linux v1.5.7.13 page lists under "Not in this release" holds here in the same words: a fix for the earned-view stall, or a per-step bound on a view's recompute, not in this release (the recompute-bound lane lands in a later cut if it lands); the cause of the stall, not established; a change to the ERP drive's pre-landing wait, the drive's and not this release's; everything the v1.5.7.12 notes list under that heading; ArgonDBCloud not released and not in the artifact; no change to the fix-number rule. Unchanged from v1.5.7 on this platform: code signing and notarization, a launchd service, a `.pkg`, a Homebrew tap, an Intel build, bundling the Homebrew kegs, a macOS gate for any continuous-view, multi-tenant, publication, clone-box or catalog-authorization surface, and a cgroup-equivalent enforcement of the tail's bound on this platform. This release adds nothing to that list and removes nothing from it. ## Build facts **`PROVENANCE.txt` inside the artifact is the record; this table repeats it.** **The copy of this page INSIDE the tarball is frozen before the tarball exists**, so its table cannot carry the tarball's own size and checksum; the served copy at is the filled one, and it is the only place the two differ. `SHA256SUMS` beside the download carries the tarball's own size and sha256 either way. | | | |---|---| | Source commit | `924d7573615186fe0851bddf3e34b13346c8c78f` — git tag `v1.5.7.13` (annotated, unsigned), **the same commit the Linux v1.5.7.13 artifact was built from**; there is no shipped-code difference between the two platforms' v1.5.7.13 | | Artifact | `argondb-v1.5.7.13-macos-arm64.tar.gz` — size and sha256 on the served copy of this page and in `SHA256SUMS` beside the download | | Artifact contents | measured at the cut — on the served copy | | Built on | MacBook Air `Mac15,12` · Apple M3 · 8 GB — the macOS version, `rustc` and cut time on the served copy | | Minimum macOS | measured from the shipped binaries' `LC_BUILD_VERSION` `minos` — on the served copy | | Install names | `@loader_path`-relative, asserted at the cut and read again on the INSTALLED prefix — the counts on the served copy | | Lake tier | lake-capable: `lakekeeper` bundled (its sha256 in `PROVENANCE.txt`); the object store is `argondb lake-store serve`, built into `bin/argondb`; `s3s-fs` is not in the artifact | | Policy engine | `bin/openfga` v1.14.2, darwin/arm64, verified against the `openfga-darwin-arm64` content pin at the cut — its sha256 in `PROVENANCE.txt`; started with its check cache ON at a 1 s TTL by this release's box | | Connection pooler | NOT bundled — a platform PgBouncer ≥ 1.25.2, optional (Linux v1.5.6 page, section 10) | | Storage tier profile | release | | Code signature | ad-hoc; every shipped binary verified before tarring — the counts on the served copy | | Build-host disclosure | the cut's own scan over the staged tree — its result on the served copy | | Acceptance | `box-pgmcp` and `macos-lake-acceptance` on this artifact installed from the tarball — the verdict lines and assertion counts on the served copy | | Tail memory cap | **UNCAPPED on this platform** — cgroup v2 does not exist on macOS; the composed bound is 6,144 MiB per tail and the byte budgets inside each tail are in force; one tail per awake tenant under `per_tenant` | ### Measured by the cut, 2026-10-14 (the served copy's block) - Artifact: `argondb-v1.5.7.13-macos-arm64.tar.gz` — 449,725,139 bytes - sha256: `fcc69e9a9df8e2bef7f208c4ba7fc6bc2732b66ecd0352b98685d279af3a1a47` - Source commit: `924d7573615186fe0851bddf3e34b13346c8c78f` (tag `v1.5.7.13`, annotated, unsigned — the Linux cut's tag, neither created nor moved by the macOS cut); `argondb --version` read back from the staged binary: `argondb v1.5.7.13 (924d75736151)`. - Artifact contents: 1,775 files, 1,366,143,035 bytes unpacked; 90 binaries ad-hoc signed and verified (30 re-signed after the install-name rewrite, 4 after a debug-map strip, the rest linker-applied). No file in the artifact has `argondbcloud` in its name. - Built on: MacBook Air `Mac15,12`, Apple M3, 8 GB, macOS 26.5.2, `rustc 1.94.0 (4a4ef493e 2026-03-02)`, `built_utc 2026-10-14 07:54:21 UTC`, under neutral build roots (`/private/var/tmp`), `CARGO_BUILD_JOBS=4`. The cut's disk floor applied the v1.5.7.12 PASS cut's growth stamp (`FLOOR: OK -- needs 845MB (last PASS growth, stamp /private/var/tmp/.argondb-cut-growth-mb), df reports 34590MB free under /private/var/tmp`) and re-stamped the cut's measured growth, 845 MB, for the next cut; the build caches were kept. The argon workspace's cargo target had been removed on the build machine between the v1.5.7.12 and v1.5.7.13 cuts, so this cut rebuilt it from scratch (28 minutes); the storage tier's target and the vendored PostgreSQL install were reused. - **Minimum macOS: 26.5** — measured from the shipped binaries' `LC_BUILD_VERSION` `minos`; the installer refuses below it. A high floor, because the build machine runs a current macOS. - Host libraries the artifact links and does not carry (Homebrew kegs, probed by the installer): `openssl@3` (`libcrypto.3.dylib`, `libssl.3.dylib`) and `icu4c@78` (`libicui18n.78.dylib`, `libicuuc.78.dylib`). - Install names: `assert-macho-relocatable: PASS — 77 Mach-O, 0 absolute non-system install names (34 relative, 89 system, 11 host-keg import(s))`, at the cut and again on the INSTALLED prefix. - Loader paths at publish: `publish-gate-loader-paths: PASS — 201 loader path(s) read, 0 under a build host home`. - Lake tier: lake-capable, `lakekeeper` 0.13.1 bundled (sha256 `b86fc6cb246a882b855730821b74d8a0644dadfdfe5f2f761d31714bc47c910c`), the flag set explicitly at the cut and asserted on the build machine before the build. - Policy engine: `bin/openfga` v1.14.2 (sha256 `7e8589475d77614d3b596d13475b50b4d7d5f8e0fe1e1d0c002b820950fdcf81`, 59,855,762 bytes), verified against the `openfga-darwin-arm64` content pin at the cut; this release's box starts it with its check cache ON at a 1 s TTL. - Served-text census: `24 served citation(s) read … 24 present, 0 absent`. - Build-host disclosure: `artifact-buildhost-scan: CLEAN - build user 'steveis' is named nowhere in 1775 file(s)`; one ADVISORY home-path string belonging to another account, from a redistributed upstream binary, not blocking. - Acceptance on this artifact installed from the tarball: `box-pgmcp: PASS (AI access without the lake)` and `macos-lake-acceptance: PASS — 35 assertion(s), 0 failed` (the same count v1.5.7.12, v1.5.7.11, v1.5.7.10, v1.5.7.9, v1.5.7.8, v1.5.7.7, v1.5.7.6, v1.5.7.5, v1.5.7.3, v1.5.7.2, v1.5.7.1, v1.5.7, v1.5.5, v1.5.4 and v1.5.3 measured). - Tail memory cap: UNCAPPED on this platform (no cgroup v2); one such tail per awake tenant under `per_tenant`. The tarball published is the exact tarball the cut built and the acceptance gates tested — the build is not bit-reproducible (`PROVENANCE.txt` carries a build timestamp), so the bytes that were tested are the bytes you download. ## License ArgonDB is Apache-2.0. The artifact carries the license texts and attributions for its inherited and third-party components in `notices/`. Lakekeeper and OpenFGA are Apache-2.0.