@@ -234,11 +234,15 @@ test('the real interactive keyboard capture collapses to one [Keyboard] diff lin
   }
 
   // The stripped set collapses the ~50 keyboard-surface nodes; what survives is
-  // app content plus the lone keyboard plane line.
+  // app content plus the keyboard plane line and two accepted residues: the
+  // floating home-indicator Toolbar (31) and the inert QuickType UIScrollView
+  // (35) under the assistant markers, which declare no keyboard-owned role and
+  // are not under a system-only subtree host. Noise lines fail loudly; a
+  // subtree claim through the assistant host could swallow app controls.
   assert.equal(survivors.filter((node) => node.type === 'Key').length, 0);
   assert.deepEqual(
     survivors.filter((node) => node.index >= 31).map((node) => node.type),
-    ['Toolbar', 'Keyboard'],
+    ['Toolbar', 'ScrollView', 'Keyboard'],
   );
   // App content never rides along: the search field the fill targeted survives.
   assert.equal(chromeRefs.has(refFor(nodes, 'Search products')), false);
@@ -289,9 +293,10 @@ test('the inputView host frame is stripped without swallowing app input-view con
   );
 });
 
-// An app that hosts editable text inside a keyboard-owned subtree (its own
-// composer riding the input-assistant host) keeps the field it is typing into.
-test('editable text hosted inside a keyboard-owned subtree survives classification', () => {
+// An app that hosts editable text under a keyboard MARKER host (its own composer
+// riding the input-assistant host) keeps the field it is typing into: the marker
+// is chrome itself and owns no subtree.
+test('editable text hosted under a keyboard marker host survives classification', () => {
   const nodes = attachRefs([
     {
       index: 0,
@@ -404,3 +409,81 @@ test('app inputAssistantItem buttons under the assistant view keep the accessory
   assert.equal(chromeRefs.has(refFor(nodes, 'Assistant Bar')), true);
   assert.equal(chromeRefs.has(refFor(nodes, 'q')), true);
 });
+
+// The route #3469 targets: the interactive projection has NO Window anchor, so the
+// app-accessory exemption is empty and only the marker rule protects app content. An
+// app Button under the assistant view survives on its own; a prediction cell beside
+// it, chrome by its own declared role, still collapses.
+test('an app control under the assistant host survives on the Window-less interactive shape', () => {
+  const nodes = attachRefs([
+    {
+      index: 0,
+      depth: 0,
+      type: 'Application',
+      label: 'Example',
+      rect: { x: 0, y: 0, width: 402, height: 874 },
+    },
+    {
+      index: 1,
+      depth: 1,
+      parentIndex: 0,
+      type: 'TextField',
+      label: 'Search',
+      rect: { x: 18, y: 100, width: 366, height: 44 },
+      hittable: true,
+    },
+    {
+      index: 2,
+      depth: 1,
+      parentIndex: 0,
+      type: 'Other',
+      role: 'TUISystemInputAssistantView',
+      rect: { x: 0, y: 546, width: 402, height: 44 },
+    },
+    {
+      index: 3,
+      depth: 2,
+      parentIndex: 2,
+      type: 'Button',
+      label: 'Paste',
+      rect: { x: 8, y: 550, width: 60, height: 36 },
+      hittable: true,
+    },
+    {
+      index: 4,
+      depth: 2,
+      parentIndex: 2,
+      type: 'Button',
+      role: 'TUIPredictionViewCell',
+      label: 'keep',
+      rect: { x: 200, y: 550, width: 60, height: 36 },
+      hittable: true,
+    },
+    {
+      index: 5,
+      depth: 1,
+      parentIndex: 0,
+      type: 'Keyboard',
+      role: 'UIKeyboardAutomatic',
+      rect: { x: 0, y: 606, width: 402, height: 268 },
+    },
+    {
+      index: 6,
+      depth: 2,
+      parentIndex: 5,
+      type: 'Key',
+      role: 'UIAccessibilityElementKBKey',
+      label: 'q',
+      rect: { x: 0, y: 620, width: 39, height: 54 },
+    },
+  ]);
+  const chromeRefs = collectSettleChromeRefs(nodes, undefined);
+
+  assert.equal(
+    chromeRefs.has(refFor(nodes, 'Paste')),
+    false,
+    'the assistant host is a marker: it claims no subtree, so an app control under it survives',
+  );
+  assert.equal(chromeRefs.has(refFor(nodes, 'keep')), true);
+  assert.equal(chromeRefs.has(refFor(nodes, 'Search')), false);
+});
@@ -4,6 +4,13 @@ import {
   hasAndroidSystemChromeProvenance,
   isAndroidSystemChromeWindowResourceId,
 } from '@agent-device/contracts/android-system-chrome';
+import {
+  hasIosKeyboardRole,
+  IOS_KEYBOARD_CHROME_MARKER_ROLES,
+  IOS_KEYBOARD_SETTLE_CHROME_ROLES,
+  IOS_KEYBOARD_SUBTREE_CHROME_ROLES,
+  IOS_KEYBOARD_SURFACE_ROLES,
+} from '@agent-device/contracts/ios-keyboard-ownership';
 import type { SnapshotNode } from '@agent-device/kernel/snapshot';
 import { normalizeType } from '@agent-device/contracts/snapshot';
 
@@ -74,65 +81,30 @@ type SettleChrome = {
 
 const EMPTY_SETTLE_CHROME: SettleChrome = { strippedIndexes: new Set(), refs: new Set() };
 
-/**
- * UIKit classes the keyboard owns whose nodes the regular projection can flatten beside app
- * content — the key plane and a key when no `[Keyboard]` container survives, the system
- * input-assistant (QuickType) bar, and the dock's "Next keyboard" / "Dictate" buttons. Once the
- * projection has dropped the keyboard's own window, neither the container-subtree nor the
- * window walk can reach them, but each node still carries its producing class in `role`.
- *
- * Exact class names only, so a near miss fails closed rather than widening what counts as
- * chrome (the same discipline `geometry-policy.ts` applies to private UIKit roles). Classes are
- * locale-independent, unlike every label these nodes carry, and private to the keyboard
- * surfaces — an app cannot host one in its own view tree.
- */
-const IOS_KEYBOARD_OWNED_ROLES: ReadonlySet<string> = new Set([
-  'UIKeyboardLayoutStar',
-  'UIAccessibilityElementKBKey',
-  'UIKeyboardDockItemButton',
-  'TUISystemInputAssistantView',
-  'TUISystemInputAssistantPageView',
-  'TUIPredictionView',
-  'TUIPredictionViewCell',
-]);
-
-/**
- * The system `inputView` host frame: chrome itself, but it OWNS NO SUBTREE — an app's custom
- * `UITextField.inputView` content (a drawn keypad, a composer) renders under this placeholder and
- * stays a control the agent must see. Stripping only the marker keeps the keyboard's appearance
- * at one visible line without swallowing app content; if the class is ever renamed, the inert
- * marker line returns as noise rather than app content vanishing — noise fails loudly.
- */
-const IOS_KEYBOARD_CHROME_MARKER_ROLES: ReadonlySet<string> = new Set([
-  '_UIRemoteKeyboardPlaceholderView',
-]);
-
-function hasRole(node: SnapshotNode, roles: ReadonlySet<string>): boolean {
-  return node.role !== undefined && roles.has(node.role);
-}
-
-function isKeyboardOwnedRoleNode(node: SnapshotNode): boolean {
-  return hasRole(node, IOS_KEYBOARD_OWNED_ROLES);
-}
-
 function collectKeyboardChrome(nodes: SnapshotNode[]): SettleChrome {
   const byIndex = new Map(nodes.map((node) => [node.index, node]));
   const containerIndexes = new Set(
     nodes.filter((node) => normalizeType(node.type ?? '') === 'keyboard').map((node) => node.index),
   );
-  const ownedSubtreeRootIndexes = new Set(
-    nodes.filter(isKeyboardOwnedRoleNode).map((node) => node.index),
+  // Role-declared keyboard surfaces, reached because the interactive projection flattens them
+  // beside app content: chrome PER NODE (surface roles), chrome by SUBTREE (system-only hosts),
+  // or chrome AS A MARKER with no subtree (hosts the app can also fill — its custom inputView,
+  // its inputAssistantItem bar buttons — so the app content under a marker survives).
+  const surfaceIndexes = new Set(
+    nodes
+      .filter(
+        (node) =>
+          hasIosKeyboardRole(node, IOS_KEYBOARD_SURFACE_ROLES) ||
+          hasIosKeyboardRole(node, IOS_KEYBOARD_SETTLE_CHROME_ROLES),
+      )
+      .map((node) => node.index),
   );
   const markerIndexes = new Set(
     nodes
-      .filter((node) => hasRole(node, IOS_KEYBOARD_CHROME_MARKER_ROLES))
+      .filter((node) => hasIosKeyboardRole(node, IOS_KEYBOARD_CHROME_MARKER_ROLES))
       .map((node) => node.index),
   );
-  if (
-    containerIndexes.size === 0 &&
-    ownedSubtreeRootIndexes.size === 0 &&
-    markerIndexes.size === 0
-  ) {
+  if (containerIndexes.size === 0 && surfaceIndexes.size === 0 && markerIndexes.size === 0) {
     return EMPTY_SETTLE_CHROME;
   }
   const containerSubtreeIndexes = collectSubtreeIndexes(nodes, byIndex, containerIndexes);
@@ -143,36 +115,31 @@ function collectKeyboardChrome(nodes: SnapshotNode[]): SettleChrome {
   }
   // Preserve app-owned accessory controls hosted above the keyboard: they were
   // swept in by the whole-window pass but are not keyboard chrome.
-  const accessoryExemptIndexes = collectKeyboardAccessoryIndexes(
+  for (const index of collectKeyboardAccessoryIndexes(
     nodes,
     byIndex,
     windowIndexes,
     containerIndexes,
     containerSubtreeIndexes,
-  );
-  for (const index of accessoryExemptIndexes) {
+  )) {
     chromeIndexes.delete(index);
   }
-  // Keyboard-owned classes the projection flattened out of every reachable subtree are chrome
-  // by their own declaration — but the walk may NOT outrank the app-accessory exemption above:
-  // an app's `UITextField.inputAssistantItem` bar buttons render UNDER the system assistant
-  // view, above the keys, and the window pass just exempted them; re-claiming them through the
-  // assistant's subtree would hide real app controls from the settle diff. An exempted node
-  // only re-joins chrome when IT declares a keyboard-owned role (a prediction cell is
-  // system-owned wherever it sits); an app node under an owned host stays exempt. In the
-  // flattened interactive shape there is no window anchor, the exemption is empty, and the
-  // walk claims the key plane exactly as the container-descendant walk always did.
-  for (const index of collectOwnedKeyboardChromeIndexes(
+  // No role claim may reach app content: surface roles are chrome per node, subtree claims only
+  // start at system-only hosts the app can never fill, and markers own no subtree. That is why
+  // these passes need no interaction with the accessory exemption or an editable-text guard —
+  // an app node under the assistant view or the inputView placeholder is simply never claimed.
+  for (const index of surfaceIndexes) chromeIndexes.add(index);
+  for (const index of collectSubtreeIndexes(
     nodes,
     byIndex,
-    ownedSubtreeRootIndexes,
-    containerSubtreeIndexes,
-    accessoryExemptIndexes,
+    new Set(
+      nodes
+        .filter((node) => hasIosKeyboardRole(node, IOS_KEYBOARD_SUBTREE_CHROME_ROLES))
+        .map((node) => node.index),
+    ),
   )) {
     chromeIndexes.add(index);
   }
-  // The system inputView host frame is itself chrome, but owning no subtree: an app's custom
-  // input view content under it survives classification.
   for (const index of markerIndexes) chromeIndexes.add(index);
   const refs = new Set(
     nodes.filter((node) => node.ref && chromeIndexes.has(node.index)).map((node) => node.ref),
@@ -185,70 +152,6 @@ function collectKeyboardChrome(nodes: SnapshotNode[]): SettleChrome {
   return { strippedIndexes, refs };
 }
 
-/**
- * The subtree under each keyboard-owned-class root, minus two app-content guards: indexes the
- * app-accessory exemption already granted (an app's `inputAssistantItem` bar buttons ride the
- * system assistant view above the keys), and editable text the app hosts inside an owned root
- * outside the keyboard container, with its subtree. A keyboard's own `Key` nodes trip neither —
- * they sit inside the container subtree, which the accessory pass never exempts — and the
- * flattened interactive shape carries no window anchor, so the exemption is empty there and the
- * walk claims the whole key plane exactly as the container-descendant walk always did.
- */
-function collectOwnedKeyboardChromeIndexes(
-  nodes: SnapshotNode[],
-  byIndex: Map<number, SnapshotNode>,
-  ownedSubtreeRootIndexes: ReadonlySet<number>,
-  containerSubtreeIndexes: ReadonlySet<number>,
-  accessoryExemptIndexes: ReadonlySet<number>,
-): Set<number> {
-  const chromeIndexes = collectSubtreeIndexes(nodes, byIndex, ownedSubtreeRootIndexes);
-  // An exempted node re-joins chrome only when IT declares a keyboard-owned role: a system
-  // prediction cell is chrome wherever it sits, while an app's `inputAssistantItem` bar button
-  // under the assistant view declares no owned role and keeps its exemption.
-  for (const index of accessoryExemptIndexes) {
-    if (!ownedSubtreeRootIndexes.has(index)) chromeIndexes.delete(index);
-  }
-  for (const index of collectHostedEditableTextIndexes(
-    nodes,
-    byIndex,
-    chromeIndexes,
-    containerSubtreeIndexes,
-  )) {
-    chromeIndexes.delete(index);
-  }
-  return chromeIndexes;
-}
-
-/**
- * Editable text the app hosts under an owned root outside the keyboard container, and the
- * chrome claimed beneath it — the inputAccessoryView guard in disguise: an app that rides its
- * own composer on the assistant host keeps the field it is typing into.
- */
-function collectHostedEditableTextIndexes(
-  nodes: SnapshotNode[],
-  byIndex: Map<number, SnapshotNode>,
-  chromeIndexes: ReadonlySet<number>,
-  containerSubtreeIndexes: ReadonlySet<number>,
-): Set<number> {
-  const dropped = new Set<number>();
-  const hostedTextIndexes = new Set(
-    nodes
-      .filter(
-        (node) =>
-          chromeIndexes.has(node.index) &&
-          EDITABLE_TEXT_TYPES.has(normalizeType(node.type ?? '')) &&
-          !containerSubtreeIndexes.has(node.index),
-      )
-      .map((node) => node.index),
-  );
-  for (const node of nodes) {
-    if (!chromeIndexes.has(node.index)) continue;
-    if (hasAncestorIn(node, byIndex, hostedTextIndexes)) dropped.add(node.index);
-  }
-  for (const index of hostedTextIndexes) dropped.add(index);
-  return dropped;
-}
-
 /**
  * Indexes of app-owned accessory content in a keyboard window: non-keyboard
  * nodes whose center sits ABOVE the keyboard container's top edge (an
 
@@ -272,6 +272,10 @@
       "types": "./src/interaction-guarantees.ts",
       "default": "./src/interaction-guarantees.ts"
     },
+    "./ios-keyboard-ownership": {
+      "types": "./src/ios-keyboard-ownership.ts",
+      "default": "./src/ios-keyboard-ownership.ts"
+    },
     "./ios-snapshot": {
       "types": "./src/ios-snapshot.ts",
       "default": "./src/ios-snapshot.ts"
 
@@ -0,0 +1,56 @@
+import type { RawSnapshotNode } from '@agent-device/kernel/snapshot';
+
+/**
+ * iOS keyboard ownership — the iOS twin of `android-input-ownership.ts`, shared by the tap
+ * occlusion band (`tap-keyboard-occlusion.ts`) and the settle chrome classifier
+ * (`@agent-device/capture-kit/snapshot-chrome`).
+ *
+ * The interactive projection flattens the keyboard surfaces beside app content, so ancestry
+ * cannot reach them; each node still carries its producing UIKit class in `role`. The table is
+ * exact class names only, so a near miss fails closed rather than widening what counts as
+ * keyboard-owned (the same discipline the snapshot geometry policy applies to private UIKit
+ * roles). Classes are locale-independent, unlike every label these nodes carry, and private to
+ * the keyboard surfaces — an app cannot host one in its own view tree.
+ *
+ * Three ownership shapes, because "produced by the keyboard" is not one question:
+ * - {@link IOS_KEYBOARD_SURFACE_ROLES}: nodes the keyboard owns PER NODE, safe for geometry
+ *   (occlusion band).
+ * - {@link IOS_KEYBOARD_SETTLE_CHROME_ROLES}: per-node chrome for the settle classifier only —
+ *   the QuickType prediction cell. Kept out of the surface table so a QuickType candidate never
+ *   joins the occlusion band's geometry.
+ * - {@link IOS_KEYBOARD_SUBTREE_CHROME_ROLES}: system-only hosts whose WHOLE subtree is
+ *   keyboard chrome — the key plane and the prediction bar. An app can never fill these, so a
+ *   subtree claim here cannot swallow app content.
+ * - {@link IOS_KEYBOARD_CHROME_MARKER_ROLES}: hosts the app CAN also fill (its custom
+ *   `inputView`, its `inputAssistantItem` bar buttons ride the assistant view). The marker is
+ *   chrome itself and owns NO subtree: app content under it survives classification.
+ */
+
+/** Keyboard-owned per node; contributes geometry wherever the projection places it. */
+export const IOS_KEYBOARD_SURFACE_ROLES: ReadonlySet<string> = new Set([
+  'UIKeyboardDockItemButton',
+  'UIAccessibilityElementKBKey',
+]);
+
+/** Per-node settle chrome beyond the surface table; never occlusion geometry. */
+export const IOS_KEYBOARD_SETTLE_CHROME_ROLES: ReadonlySet<string> = new Set([
+  'TUIPredictionViewCell',
+]);
+
+/** System-only keyboard hosts; their entire subtree is keyboard chrome. */
+export const IOS_KEYBOARD_SUBTREE_CHROME_ROLES: ReadonlySet<string> = new Set([
+  'UIKeyboardLayoutStar',
+  'TUIPredictionView',
+]);
+
+/** Keyboard hosts the app can also fill: chrome itself, subtree left to the app. */
+export const IOS_KEYBOARD_CHROME_MARKER_ROLES: ReadonlySet<string> = new Set([
+  '_UIRemoteKeyboardPlaceholderView',
+  'TUISystemInputAssistantView',
+  'TUISystemInputAssistantPageView',
+]);
+
+/** True when this node's own UIKit class is one of `roles`. */
+export function hasIosKeyboardRole(node: RawSnapshotNode, roles: ReadonlySet<string>): boolean {
+  return node.role !== undefined && roles.has(node.role);
+}