diff --git a/adr/0002-pluggable-dtype-layout-compute.md b/adr/0002-pluggable-dtype-layout-compute.md
index c4963b162..70437547b 100644
--- a/adr/0002-pluggable-dtype-layout-compute.md
+++ b/adr/0002-pluggable-dtype-layout-compute.md
@@ -5,6 +5,15 @@
 - **Deciders:** project maintainer
 - **Related:** [ADR 0001 — Split read and write runtimes](0001-split-read-and-write-runtimes.md)
 
+> **Update (2026-10-20):** the "Java status today" table below predates several changes.
+> Encodings are registered on the builder-only `ReadRegistry`/`WriteRegistry`, with no
+> `ServiceLoader` and no auto-discovery (as in Rust). Layout decoding is pluggable through
+> `LayoutRegistry` (unknown layouts always fail, no allow-unknown). `DType` is still sealed and
+> extensible only through `DType.Extension` with a registered `ExtensionDecoder`/`ExtensionEncoder`
+> (the Rust `ExtVTable` model). A compute layer now exists in `reader.compute`
+> (ADR 0013, ADR 0019) but has no registration SPI. Of this ADR's decision, "keep `DType` sealed"
+> and "no compute SPI" still hold; "keep `Layout` sealed" no longer does.
+
 ## Context
 
 The Rust reference implementation
diff --git a/adr/0005-vector-api-adoption.md b/adr/0005-vector-api-adoption.md
index b8a1597ba..f348b3bea 100644
--- a/adr/0005-vector-api-adoption.md
+++ b/adr/0005-vector-api-adoption.md
@@ -5,6 +5,15 @@
 - **Deciders:** project maintainer
 - **Related:** [CLAUDE.md §Memory model — Hot-loop rule](../CLAUDE.md)
 
+> **Update (2026-10-20):** the Vector API was adopted regardless of condition 1 (PR #524). The
+> kernels shared by reader and writer sit behind `SimdOperations` in `core.simd`, with
+> `AutoVectorizedSimdOperations` (C2-shaped loops, the default) and `VectorApiSimdOperations`
+> (opt-in via `--add-modules jdk.incubator.vector`); `SimdOperationsSupport#preferred()` picks one.
+> Both give Rust-parity results, `scripts/simd-benchmark.sh` (also a CI job) measures the
+> speedups, and the module's incubating status is the only reason it is opt-in. This is
+> Strategy A by module detection, not the rejected Strategy B (`DecodeContext` flag). The
+> decision text below is kept as written for the record.
+
 ## Context
 
 Two TODO items describe Vector API adoption:
diff --git a/adr/0018-calcite-sql-adapter.md b/adr/0018-calcite-sql-adapter.md
index e1d26a80e..2ef2edd65 100644
--- a/adr/0018-calcite-sql-adapter.md
+++ b/adr/0018-calcite-sql-adapter.md
@@ -11,6 +11,15 @@
   [ADR 0016 — vortex-arrow bridge](0016-vortex-arrow-bridge.md),
   [ADR 0005 — Vector API adoption](0005-vector-api-adoption.md)
 
+> **Update (2026-10-20):** the adapter has grown past the phases recorded here, so treat
+> "not yet" and "still scans for now" below as dated. It now also pushes down `ORDER BY` and
+> `ORDER BY ... LIMIT` (`VortexSortPushDownRule`), `GROUP BY` on dictionary-encoded string,
+> boolean and integer columns (`Compute.groupedAggregate`), `COUNT(DISTINCT)`, `SELECT DISTINCT`
+> and `LIKE 'prefix%'`, reports table row counts to the planner, and exposes a directory of
+> `.vortex` files as tables (`VortexCalcite.connect(Path)`, `VortexSchemaFactory`). The
+> `jdbc-driver` module wraps that as a `jdbc:vortex:<dir>` JDBC driver. See `CHANGELOG.md` for
+> the per-release detail.
+
 ## Context
 
 The reader exposes typed zero-copy columns and (ADR 0013) a path to filter/aggregate
diff --git a/adr/0019-columnar-transducer-facade.md b/adr/0019-columnar-transducer-facade.md
index e299f317a..31425472c 100644
--- a/adr/0019-columnar-transducer-facade.md
+++ b/adr/0019-columnar-transducer-facade.md
@@ -6,6 +6,13 @@
 - **Supersedes:** —
 - **Superseded by:** —
 
+> **Update (2026-10-20):** the façade is still unbuilt, but the bespoke-static-method path this
+> ADR warns about kept growing, and some of the blockers named below are gone. `Compute` now has
+> `matches`, `matcher(Chunk, RowFilter)` and `matcher(RowFilter)` (a per-scan row test returning a
+> `RowSelection` with `nextSelected(long)`) and `groupedAggregate`, and `GROUP BY` push-down
+> (ADR 0018's Phase 3) shipped through it. Status stays Proposed: nothing composes a chunk-level
+> computation yet, and each new capability is still another static entry point.
+
 ## Context
 
 ADR 0013 shipped the compute primitives as two fused kernels behind `reader.compute.Compute`:
diff --git a/adr/0020-jazzer-fuzz-infrastructure.md b/adr/0020-jazzer-fuzz-infrastructure.md
index 65b0c769a..1109efe47 100644
--- a/adr/0020-jazzer-fuzz-infrastructure.md
+++ b/adr/0020-jazzer-fuzz-infrastructure.md
@@ -1,12 +1,12 @@
 # ADR 0020: Jazzer fuzz testing infrastructure
 
-- **Status:** Accepted — fuzz mode landed as a dedicated `fuzz` module with one target
-  (`VortexReader` full-file open), seeded with a handful of existing small reader fixtures so the
-  mutator starts past the trailer magic instead of having to guess it; direct
-  `PostscriptParser.parseBlobs` fuzzing is deferred (it is package-private, so a separate module
-  needs a cross-module access seam); automated per-encoding corpus extraction, per-encoding
-  targets, differential fuzzing, regression-corpus wiring, nightly CI, and OSS-Fuzz submission
-  still pending
+- **Status:** Accepted — implemented in a dedicated `fuzz` module (reader `open`, `scan`,
+  `filter` and metadata-blob targets, plus an FSST round-trip) and in `integration`
+  (`WriteReadFuzzIntegrationTest`: write→read round-trip and the vortex-jni differential). Each
+  target replays its saved inputs (seeds plus every past finding) in the routine build, and the
+  weekly `Fuzz` workflow explores new ones. Still pending: automated per-encoding corpus
+  extraction, per-encoding targets, and OSS-Fuzz submission. The detail below describes the first
+  cut (one target, five hand-picked seeds) and is kept as written.
 - **Date:** 2026-07-12
 - **Deciders:** project maintainer
 - **Related:** [ADR 0003 — VortexException sanitization](0003-vortex-exception-sanitization.md),