The same page, rendered from 5,229 DynamoDB commands instead of 7,079 — and none of them a full-table Scan.
15 Sept 2026 · branch perf-atlas-scans · captured against propflow-stage · at fbd882fff8+local
Data note. Every name and balance below comes from propflow-stage, which is anonymized by construction (ADR-0097/0110 — phones in the impossible +1000 NPA, emails @example.test). The identical capture against prod would carry real tenants' names and balances and is not safe to attach anywhere, which is why the generator refuses to run against one.
Atlas on this branch, against stage: 94 buildings across 41 organizations, rendered for a platform admin. Every root folder and every org tile that rendered before still renders — the loader reads the Organization and Property rosters off the entityType GSI, one Query each, and fans out per building and per org from those ids. What is gone from underneath it is the full-table ScanCommand: 1,798 paged Scan commands per load, which listAllVendorMemberships() was issuing because its spine-cohort read falls back to a Scan whenever the index is absent or below its floor — which is exactly what stage does.
What to look at: the root tiles carrying their loaded sublabels (the tool and metric catalog counts, which the loading shell only ghosts) and the org tiles under Organizations. This capture is what a human sees; the operation counts are the guard test's job, and rendered-data parity is pinned numerically in the PR body (distinct ids in the payload, identical before and after).
Asserted in the captured DOM — ops + voice unified · per-property snapshots are derived. Two root-tile SUBLABELS that only the LOADED tree paints. `AtlasLoadingShell` renders the `Atlas` breadcrumb and every `rootTileChrome()` label (Organizations, Spine Orphans, …) through the real tiles, so asserting those was vacuous — a capture of the skeleton passed 3/3. The shell's own docblock names what it ghosts: 'only the count + catalog-count sublabels'. These two strings are catalog-count sublabels, absent from the shell's source, so a ghost capture fails 0/2 and a loaded one passes 2/2.
The selected read bound — a viewer who picks two orgs and reads only those — is exercised by the guard test (a one-org case that pins the operation counts and asserts no key outside that org was touched, plus a one-building case), not photographed here. No principal this lane can sign in as can produce that render: the smoke account is a pure platform admin, resolveGrants drops the staff org by rule, so its grant is empty and deriveSelection returns the empty selection for it. Staging a selected render from a fixture would be a picture of a test, not of the page. Making a staff selection narrow the read is the next part, and the PR body says so.