@@ -21,7 +21,11 @@ as the comparand itself, as an implicit-equality comparand, or as an `$in` / `$n
 
 Measured on `origin/main` `17bd3187` before the change: `FilterConditionSchema`, a dataset `filter`, a dataset measure `filter`, a dashboard widget `filter`, a report `runtimeFilter` and a joined report block `runtimeFilter` each parsed with `success: true` for `{ stage: { $eq: { a: 1 } } }`, `{ stage: { $in: [{ a: 1 }] } }` and a `Map` comparand, at the top level and inside a nested relation. The comparand-type face and the analytics `where` door refused each with `INVALID_FILTER` / 400. A dashboard widget `filter`, a report `runtimeFilter` and a joined report block `runtimeFilter` also parsed with `success: true` for the three nested-relation shapes above, which the analytics door refuses when they are charted.
 
-**One slot, one issue — a dedupe; no verdict moves.** A slot raises the first refusal the query doors give, in their order: the comparand-shape face, then the comparand-type face, then the `$null` / `$exists` flag rule. So `{ stage: { $null: { a: 1 } } }` reads as the type face's refusal, as it does on chart. Where a face refuses a slot, the schema door's own `$icontains` and date-preset arms stay silent on it. Before, two issues could land for one defect: for example `{ created_at: { $between: ["last_7_days"] } }` reported the malformed range at `created_at.$between` AND the preset endpoint at `created_at.$between.0`; now it reports the range only, and the preset is reported once the range is fixed. Every document refused before is still refused, and every document accepted before is still accepted — only the second issue on an already-refused slot is gone.
+**One issue per slot at the top level and in the combinators — a dedupe; no verdict moves.** The faces' verdict on a slot is one refusal: the first the query doors give, in their order — the comparand-shape face, then the comparand-type face, then the `$null` / `$exists` flag rule. So `{ stage: { $null: { a: 1 } } }` reads as the type face's refusal, as it does on chart. At the top level of a filter and in its `$and` / `$or` / `$not` members, where a face refuses a slot the schema door's own `$icontains` and date-preset arms stay silent on it. Before, two issues could land there for one defect: `{ created_at: { $between: ["last_7_days"] } }` reported the malformed range at `created_at.$between` AND the preset endpoint at `created_at.$between.0`; now it reports the range only, and the preset is reported once the range is fixed.
+
+Inside a nested relation on an analytics carrier (a dataset or measure `filter`, a widget `filter`, a report or joined-block `runtimeFilter`) a slot can still carry TWO issues. There the carrier's nested-relation walk asks the faces, while the schema door's own `$icontains` and date-preset arms keep judging nested slots as they did before this change. So `{ acct: { name: { $icontains: new Map() } } }` gets both the `$icontains` sentence and the type face's at `filter.acct.name.$icontains`, and `{ acct: { created_at: { $between: ["last_7_days"] } } }` gets the malformed range at `filter.acct.created_at.$between` and the preset endpoint at `….$between.0`. The document is refused either way; only the issue count differs.
+
+Every document refused before is still refused, and every document accepted before is still accepted — the dedupe removes only a second issue on an already-refused slot at the top level and in the combinators.
 
 **The words are the type face's**, less its location clause (`at where.<field>.<op>`), because the issue's path carries the location: for example `Filter comparand is a plain object ({"a":1}), which no driver can compare. A comparison value must be a string, number, bigint, boolean, null or Date. Refusing rather than guessing: …` at `filter.stage.$eq`, and at `filter.stage.$in.1` for a list member.
 
 
@@ -54,9 +54,12 @@ export const entry: SemanticMigration = {
     + 'The save door now asks the type face itself, read-only, after the shape face, so it '
     + 'refuses exactly what the face refuses and passes what it passes; one slot raises one '
     + 'refusal, in the query doors\' order (shape, then type, then the flag rule), in the face\'s '
-    + 'own words less its location clause; a second issue on a slot a face already refused (the '
-    + 'schema door\'s own $icontains and date-preset arms) is no longer raised, which moves no '
-    + 'verdict. The widget filter and both report runtimeFilters declare the same '
+    + 'own words less its location clause. At the top level of a filter and in its $and / $or / '
+    + '$not members, a second issue on a slot a face already refused (the schema door\'s own '
+    + '$icontains and date-preset arms) is no longer raised; inside a nested relation on an '
+    + 'analytics carrier those two arms still judge the slot beside the faces, so a nested '
+    + '$icontains with a refused comparand, or a nested one-bound $between of a preset name, can '
+    + 'carry two issues. Neither moves a verdict. The widget filter and both report runtimeFilters declare the same '
     + 'analytics-carrier filter as the dataset carriers, so their nested-relation slots are '
     + 'judged by the same walk: every stored filter the analytics where door charts now refuses '
     + 'on save what that door refuses on chart. Metadata AT REST is not rewritten and this entry adds no D2 '
 
@@ -9731,9 +9731,12 @@ const step18: MigrationStep = {
         + 'The save door now asks the type face itself, read-only, after the shape face, so it '
         + 'refuses exactly what the face refuses and passes what it passes; one slot raises one '
         + 'refusal, in the query doors\' order (shape, then type, then the flag rule), in the face\'s '
-        + 'own words less its location clause; a second issue on a slot a face already refused (the '
-        + 'schema door\'s own $icontains and date-preset arms) is no longer raised, which moves no '
-        + 'verdict. The widget filter and both report runtimeFilters declare the same '
+        + 'own words less its location clause. At the top level of a filter and in its $and / $or / '
+        + '$not members, a second issue on a slot a face already refused (the schema door\'s own '
+        + '$icontains and date-preset arms) is no longer raised; inside a nested relation on an '
+        + 'analytics carrier those two arms still judge the slot beside the faces, so a nested '
+        + '$icontains with a refused comparand, or a nested one-bound $between of a preset name, can '
+        + 'carry two issues. Neither moves a verdict. The widget filter and both report runtimeFilters declare the same '
         + 'analytics-carrier filter as the dataset carriers, so their nested-relation slots are '
         + 'judged by the same walk: every stored filter the analytics where door charts now refuses '
         + 'on save what that door refuses on chart. Metadata AT REST is not rewritten and this entry adds no D2 '