Atlas — a failed person, tool or metric read is not an empty answer
When the lazy detail read fails, the person, tool and metric focus say so instead of 'never reached', a 0, or a blank trend.
1 Oct 2026 · branch p10-core-surfaces-focus-could-not-load · captured against propflow-stage · at b27c773c4da
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.
1 · Control: a test tenant's person focus, nothing blocked
A person on the sandbox TEST building (the tenant on test work order 112), focused with nothing blocked. Ordinary titles and counts.
Asserted in the captured DOM — Identity Claims · Tenant Occupancies
Sections 2–4
2 · The same person, with the person read failing
The browser's request to the detail route is aborted. Before this change the page said No identity claims yet — this person was never reached on phone or email. with a 0, a statement of fact about a read that never happened. Now the lists that only that read can fill say they could not load, and the lists the page can partly fill from its own rows say they are partial.
The two critique rounds
Round 1: the partial lists drew 0+ when the page had no rows for them (Prospect Inquiries, Conversations), which reads as noise. Fixed in code: a partial list draws N+ when the page had rows, and no badge when it had none. The tool callers block kept its older one-line hint; it now says, like the others, that the list is unknown, not empty, and how to retry. Also found here, and handled: a metric opened by URL gets its history in the first page load, so only a metric opened from the catalog can have that read fail; section 4 is captured that way.
Round 2 (these captures): could not load on the lists only the person read can fill, partial, the full read failed with 1+ on the tenant list the page could partly fill, and no badge on the empty partial lists. Not this PR: the Merge button and the tenant phone also come from the person read, so they are absent on failure, unchanged. No further change.
Asserted in the captured DOM — Identity Claims — could not load · Vendor Memberships — could not load · Tenant Occupancies — partial, the full read failed
3 · A tool, with its callers read failing
The tool's 7-day invocation read is aborted. The callers block says it could not load and draws no 0.
Asserted in the captured DOM — Callers (last 7d) — could not load · The invocations could not be read, so this is unknown, not empty. Reload to try again.
4 · A metric opened from the catalog, with its history read failing
A metric deep-linked by URL gets its 30-day history in the first page load and never fetches it, so it cannot fail that way (the first capture of this section proved it: real sparklines, no failure). Opened by clicking from the Metric Catalog, the history comes from the detail route, and that read is aborted here. Every trend cell is empty for that reason, and the block title now says so.
Asserted in the captured DOM — Per-property snapshots — trend could not load
