Page reads and company separation

Every workspace page, one row each: does it read live from the database, is that read bounded to the caller’s own company and buildings, and can an admin at company 1 ever be handed company 2’s rows? With the file and line that enforces it, and the test that pins it.

2026-09-22 · read at origin/main 9146303fc8 · read-only audit of code and tests, no production reads · 20 pages · every cited assertion was re-opened by hand before it entered this table

The honest count

“Separated” here means: an org admin’s request never receives a row that belongs to another organization. It is a statement about the answer. “At the database” is a different statement, about the read: is the boundary in the partition key the query addresses, or applied in memory after a wide read? The two must stay in separate columns — a page can read widely and still be perfectly separated (vendors is the canonical case), and the table is worthless if they blur.

Where the boundary sits, for each page’s business rows: 15 pages key every business read on the caller’s own scope (or, for routine, a database-side filter); 4 are mixed — at least one business read pulls every company’s rows into the process for an org caller and narrows there (prospects’ AppFolio-mirror arm, dashboard, renewals board, clara); 1 is separated in memory only — settings, which reads one shared global row and every user on the platform.

Where separation is enforced — the three primitives every row depends on

Consequence for Half 2: an org admin cannot receive null from any of these, so the only way another company’s row could reach them is a read that ignores the scope entirely, or an in-memory narrowing that is skipped. Each row below names the line that applies the bound and the test that would go red if it were removed.

The matrix — 20 pages

Path = the request path (server seed and the route the browser polls, with cadence). Test class: A = asserts the database was never asked for the other company’s partition (strongest); B = asserts the other company’s rows are absent from the output (the read may still have happened). Control = a test that breaks the scope and shows the assertion going red, so it cannot be passing vacuously. “Every Property row” = a no-argument getProperties() → property.ts:202, a query on the constant key GSI3PK='Property': every building of every company, narrowed in memory.

Half 2, answered directly: can an admin at company 1 ever see company 2’s rows?

On these twenty pages, no — and here is the shape of the guarantee, so you know what it rests on.

• An org admin never receives an unbounded scope. getUserPropertyScope gives null to platform_admin only; an org admin’s Set is their own company’s roster, resolved from the Organization’s own building rows (helpers.ts:530-554). Every page above either keys its reads on that Set or filters against it before answering.
• The two routes whose bound is that Set alone (no second org check): /api/leasing/stats (serving the leasing home, dashboard and maintenance home tiles) and the named-id arm of /api/mass-sends. They are separated because the Set is the roster; a corrupted assignedPropertyIds entry naming another company’s building would be filtered by the dashboard’s chain (stats/route.ts:117-118, pinned at route.propertyid-scope.test.ts:166-181) and not by those two. Defence in depth, not exposure.
• The one page separated in memory only is settings: one global row and every user on the platform enter the process on every request, and a hand-kept allowlist (settings/route.ts:112-120) plus an org filter (team/route.ts:63) decide what leaves. That is the class of guard that stays correct only while someone re-reads it; no mutation control proves it can fail.
• Where the answer is “no” but the read is wide (dashboard, renewals board, clara, prospects’ mirror arm, three review feeds’ roster read, and thirteen pages’ getProperties()): another company’s rows are held in the request process and dropped before the response. Correct today; each is one deleted filter line from a leak, and only conversations has an executed control that would notice.
• Platform staff are a different question. A PropFlow staff login with nothing selected reads the whole estate on 18 of 20 pages by design (the two that refuse outright: work orders and the renewals board; routine’s seed and the tenant-confirmations feed refuse too, but their sibling legs on the same page do not). Several suites pin that as intended. That is the existing board row about the staff null scope, not a customer-separation finding.

Corrections to the working matrix of 2026-09-21

Every place this verification disagreed with the prior night’s table. The two that change its headline come first.

What should become board rows

None of these is a customer seeing another customer’s data; nothing here met the interrupt bar. Ordered by how close each sits to that line.

1. Renewals board: same-company cross-building saga misattribution, and the test for it exercises the other path. leasing.ts:2066 filters sagas by scopeIds, which is undefined on the board’s positional call (load-renewals.ts:49), so the filter is inert; the file’s own header (:1957-1967) describes the resulting defect: a resident at two of the same company’s buildings can have the unselected building’s renewal state rendered on the selected one. renewals-saga-attribution.test.ts covers only the opts.propertyIds path (:493, 554, 663, 731). A Person carries one organizationId (persons.ts:10), so this is within one company — a correctness bug, not a separation one.
2. /api/vendor-outreach: no separation test, and a live unguarded estate fan-out for staff. Org re-key is present (:88-90); nothing pins it; vendor-coordination-session.ts:53 is reachable when effectiveQueryScope is null.
3. /api/team: every user on the platform read and filtered in memory, no test. user.ts:24 → team/route.ts:63. And /api/settings’ allowlist (route.ts:112-120) has no mutation control.
4. /api/leasing/stats has no org leg (:329-335, self-declared) and the named-id arm of /api/mass-sends has none when nothing is proposed (:93-96, 112). Both rest on the org admin’s Set being their roster. Defence in depth owed.
5. Prospects: an un-narrowed ?propertyId= reaches two reads before the scope intersect when no selection is proposed (route.ts:161-163): a point read of the foreign building (prospect-record-owner-fetch.ts:78, discarded at :86-92 with a warning log naming the id) and, for an AppFolio-owned caller, a GSI query on the foreign building’s partition (load-prospects.ts:563, narrowed at :566). No foreign row is returned.
6. Vendors and turnovers hand a null caller the wide path (vendors/(list)/page.tsx:32 + read-vendors-list.ts:49-53; load-turnovers-list.ts:94). Both are behind a gate (session middleware; the admin bearer), both documented; both are the shape read-over-scope.ts:120-141 names as the cause of a measured incident on /properties.
7. Routine: seed reads nothing for staff, poll reads everything, and a test pins the poll. route.ts:122→192; route.org-isolation.test.ts:159-170, 309-325. Staff-only; the two doors implement two rules.
8. Three suites claim a mutation control “in the PR body” (tours, calendar, the three review feeds). That is a claim about a PR, not a test in the tree. Executed controls exist for: conversations (in-suite), work orders, routine, costs, mass sends, properties (visibility), dashboard, leasing home, vendors, renewals board and clara (the last three as registered scripts/mutation-controls/*).
9. Thirteen pages read every company’s Property rows on every request, for every caller (property.ts:202): prospects, tenants, turnovers, work orders, collections, costs, routine, tours, calendar, conversations, dashboard (twice), three review feeds, renewals board. Four more do it for staff only (mass sends, leasing home, clara, vendor-outreach). Only properties uses the roster partition. One change, thirteen wins.
10. Zero pages paginate at the database. Prospects is the copy to make (adopt the chunk the envelope already carries); conversations needs its dark index wired first; everything sorted in memory needs a clock-keyed projection before a Limit means anything.

Not measured

Absence of a cell is not a pass. These were on or near the request path and were not traced to their database call: the name-heal spine reads on tours and calendar; the calendar move-in BatchGet of profile rows; EventRow’s per-row messages fetch; the settings child cards (email, calendar, checklist, BCC, on-call); routine’s modal reads of /api/properties and /api/vendors; prospects’ per-row buildRow sub-reads; collections’ tenant-name and occupancy maps; clara’s /api/properties/options; the dashboard’s per-property metric-history fan-out (traced only briefly). The browser-side questions (skeletons, re-renders, debounce, lazy loading) were not audited on any page. No production latency was measured; every number above is a count of reads, not a timing.

Method: the request path was read, not the loader symbol — every route the browser fetches was enumerated per page and traced to its DynamoDB command. Every test cited was opened and its assertion read; a test was classed A only where it asserts on the partition key or the arguments the reader received, never on the response alone. git grep -P throughout. Nothing was written to any environment.