@@ -39,11 +39,12 @@ the rows path add exact decimals and round once. It was rejected because SQLite'
 adds the stored doubles (`0.30000000000000004`), so the rows path would then disagree with SQLite
 for exactly `0.1 + 0.2`.
 
-**Residual, stated.** Double sums are added in row order, one after another, as the rows path
-adds them. SQLite 3.43 and later adds with compensated summation. So for a group of three or
-more fractions, SQLite's native answer can still differ from every other face in the last
-place (`0.1 + 0.2 + 0.3`: SQLite `0.6`, every other face `0.6000000000000001`). This was
-already true of SQLite's two paths before this change. Two addends cannot differ.
+**Residual, stated.** On PostgreSQL and MySQL the double sums are added in row order, one after
+another, without compensation. SQLite 3.43 and later adds with compensated summation, and since
+#20489 so does the engine's rows path. So for a group of three or more fractions, the PostgreSQL
+and MySQL native answer can still differ from SQLite's and the rows path's in the last place
+(`0.1 + 0.2 + 0.3`: PostgreSQL / MySQL native `0.6000000000000001`, SQLite and the rows path
+`0.6`). Before #20489, SQLite's own two paths differed there too. Two addends cannot differ.
 
 A consumer that compared `sum` / `avg` over a fractional column with a decimal literal on
 PostgreSQL or MySQL (`$eq: 0.3`) now gets the answer SQLite and the rows path already gave:
 
@@ -32,9 +32,9 @@ JS number.
 **Residual, stated.** PostgreSQL and MySQL add `sum` / `avg` natively in double without
 compensation, and that arithmetic is the database's own. So over three or more fractions their
 native path can still differ from the rows path in the last place (`0.1 + 0.2 + 0.3`: native
-`0.6000000000000001`, rows path `0.6`). This replaces the residual the `@objectstack/driver-sql`
-entry for the double accumulation states: that difference is no longer SQLite's native path
-against every other face; it is now PostgreSQL / MySQL native against the rows path. The
+`0.6000000000000001`, rows path `0.6`). The `@objectstack/driver-sql` entry for the double
+accumulation states the same residual: the difference is no longer SQLite's native path against
+every other face; it is PostgreSQL / MySQL native against SQLite and the rows path. The
 in-memory driver (`@objectstack/driver-memory`) still adds naively in its own `aggregate`, so on
 that driver the two paths can now differ in the same last place. An exact `$eq` on a fractional
 sum compares doubles: compare with a range.
@@ -25,9 +25,11 @@
  * `having` is evaluated by the engine, over the value this door answers
  * (`having-filter.ts`: `$eq` compares the value with `==`), so the value pinned
  * here is what decides `having` `$eq` / `$in` on every face. The expected
- * values are computed from `find()`'s own rows with the rows path's arithmetic
+ * values are computed from `find()`'s own rows, added in row order
  * ({@link rowsPathSum}), plus the literal the triage named, so a decimal
- * answer, a compensated sum or a string each fail.
+ * answer or a string each fail. Over these fixtures — two addends, and
+ * integer-valued columns within 2^53 — that sum is also the rows path's, which
+ * adds with compensation since #20489: the two folds cannot differ there.
  *
  * What stays as it was, pinned too: `count` / `min` / `max`, and a `sum` over
  * an integer-valued column, which keeps the database's exact total (above 2^53
@@ -49,10 +51,10 @@ function toNumber(v: unknown): number {
   return Number.isFinite(n) ? n : 0;
 }
 
-/** The rows path's `sum`: `values.reduce((a, b) => a + toNumber(b), 0)`, in row order. */
+/** `values.reduce((a, b) => a + toNumber(b), 0)`, in row order: the rows path's `sum` over this file's fixtures (see the header). */
 const rowsPathSum = (values: readonly unknown[]) => values.reduce<number>((a, b) => a + toNumber(b), 0);
 
-/** The rows path's `avg`: the non-null values' `sum`, divided by how many there are. */
+/** The non-null values' {@link rowsPathSum}, divided by how many there are: the rows path's `avg` over this file's fixtures. */
 function rowsPathAvg(values: readonly unknown[]): number | null {
   const defined = values.filter((v) => v != null);
   return defined.length === 0 ? null : rowsPathSum(defined) / defined.length;
 
@@ -1594,11 +1594,13 @@ const AGGREGATE_ANSWER_KIND: Readonly<Record<AggregationFunction, 'number' | 'co
  * would widen the binary32 value (`0.1` → `0.10000000149011612`) where the
  * client reads `0.1`. MySQL's `CAST(… AS DOUBLE)` needs 8.0.17 or later.
  *
- * ⚠️ Residual, stated: the double sums are added in scan order, one after
- * another, as the rows path adds them. SQLite (3.43+) adds with compensated
- * (Kahan-Babuska-Neumaier) summation, so a group of three or more fractions can
- * still differ in the last place on SQLite's native face alone (`0.1 + 0.2 +
- * 0.3`: SQLite `0.6`, every other face `0.6000000000000001`). Two addends
+ * ⚠️ Residual, stated: on PostgreSQL and MySQL the double sums are added in
+ * scan order, one after another, without compensation. SQLite (3.43+) adds with
+ * compensated (Kahan-Babuska-Neumaier) summation, and since #20489 so does the
+ * engine's rows path (`in-memory-aggregation.ts`, `compensatedSum`), so a group
+ * of three or more fractions can still differ in the last place between the
+ * PostgreSQL / MySQL native faces and those two (`0.1 + 0.2 + 0.3`: PostgreSQL /
+ * MySQL `0.6000000000000001`, SQLite and the rows path `0.6`). Two addends
  * cannot differ, which is why the pin is `0.1 + 0.2`.
  *
  * A `Record` over `AggregationFunction` for the same reason as