The company on screen and the company the rows were fetched for
Board row bug-an-empty-org-parameter-…: on `?org=&prop=` — an org key PRESENT BUT EMPTY — the screen named one company while the data behind it answered for another. #9324 fixed the predicate; this is the rendered proof, which its own entry says it did not deliver.
18 Sept 2026 · branch empty-org-label-rows-p2 · captured against propflow-stage · at 4602935622
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 · The control — the remembered company, named by the ADDRESS
What agreement looks like when there is nothing to disagree about: the address names the company outright, so both halves have the same input. The rail names the company; every row in the PROPERTY column names that company's building; the strip counts that company's inquiries. This section exists so the two below can be compared against something, not against a description of something.
Asserted in the captured DOM — Fairhaven Residential (TEST) · Fairhaven Homes · 53 prospects. The company in the rail, the company in the ROWS, and the served count — all three read out of the same frame.
2 · THE ROW'S SHAPE — ?org=&prop=, with that company REMEMBERED and nothing in the address
This is the address the board row is about, and the one a bookmark or a shared link really carries: org is present and empty beside an equally empty prop. The server reads that as SILENCE and lets the remembered selection answer. The client used to read it as the address SPEAKING, derive from nothing, and land on the viewer's own default — so the rail named the default while every /api/* call on the page was scoped to the remembered company. Each half was internally consistent; they were answering different questions.
Here the rail and the rows agree, and the page is indistinguishable from section 1 in every asserted place. That is the whole claim: the name over the figures is the name the figures were fetched under.
Asserted in the captured DOM — Fairhaven Residential (TEST) · Fairhaven Homes · 53 prospects. Byte-for-byte the same three strings as section 1 — the label, the ROW company, and the served count — captured on an address that names nothing.
3 · The second silent shape — ?org= alone, same remembered company
One key present and empty, the other absent. Measured through the real functions, the two predicates disagreed on exactly the addresses where every selection value is empty after parse's filter(Boolean) — ?org=&prop=, ?org=, ?prop=, ?org=,,&prop=,,. This is the second of them, and it holds the same way.
A correction to the row's own prose, measured rather than assumed. The row spells the shape ?org=&prop=<id>. With a real building id that spelling never diverged: prop carries a usable value, so both predicates read “the address spoke”. The divergent shapes are the ones in the row's title — an EMPTY org parameter. A company-B building id under an empty org= resolves to company A's whole roster on both sides, which is the per-dimension widening — a different row, guarded by #9287.
Asserted in the captured DOM — Fairhaven Residential (TEST) · Fairhaven Homes · 53 prospects. The same three strings again, on the other silent shape.
4 · The discriminator — the other company, so “they agree” is not “there is only one answer”
The row is explicit that “the two companies used must differ in the asserted places or the control is vacuous.” Sections 1–3 would all be satisfied by a page that could only ever name one company. This one names a different one, with a different count, on the same surface — so the strings above are discriminating rather than constant.
Cropped shorter than §§1–3 because the discriminating facts here are the company and the count, not the roster. Every name visible in any section of this page is a stage stand-in, not a customer. The capture refuses to run against anything but a source anonymized by construction (propflow-stage here, ADR-0097/0110), and the rendered text is scanned for reachable contacts before publishing.
Asserted in the captured DOM — JPCO. A different company name in the same rail, in the same frame as its own figures.
5 · The separate finding — a page that never joined the sweep, on an address that SPEAKS
This section is NOT part of the row's acceptance and is not evidence that anything is fixed. It is a separate defect, recorded because it was found while building the control and because it looks exactly like this row's defect until you check the cause. The rail names the selected company; the building cards under it belong to every company. And this address speaks — it names the org and its roster outright — so no predicate disagreement can explain it.
The cause is upstream of the selection entirely: loadPropertiesList scopes through the legacy getUserPropertyScope/getUserOrgScope path and has never read the ADR-0137 selection, so these rows do not follow the selection on any address. That is a consumer-sweep gap (ui-s-d), not the empty-org divergence, and it is not claimed as closed here.
Asserted in the captured DOM — Fairhaven Residential (TEST) · Western Slope Stage Property. The rail names one company while a card from a different one is in the same frame — on an address that speaks.
What this does and does not close
It closes the row's acceptance on the surfaces that carry the selection. The label and the served rows are read out of one frame, on both silent address shapes, with two genuinely different companies available — and the unit control shipped in this PR reddens under the restored key-presence predicate (2 failed | 2 passed, exit 1, first failure expected 'Birch Yard — Bellwether' to contain 'Park West').
A separate finding, recorded rather than folded in. The same two addresses were first captured on /properties, where the rail correctly named the remembered company and the building cards below it did not change at all — they stayed on every company's buildings. That is not this row's defect reappearing: loadPropertiesList still scopes through the legacy getUserPropertyScope/getUserOrgScope path and has never read the ADR-0137 selection, so its rows do not follow the selection on any address, including one that speaks. It is a consumer-sweep gap (ui-s-d), it is real, and it belongs to whoever owns that sweep.