Atlas: every record's health, as independent facts

2 · Part 15, negative control: a test company with no mailbox

The same row on Module Gate Probe (TEST), a stage test company with no live company mailbox hook. It reads not attached, which is a different answer from not loaded yet (the read has not answered) and from unreadable (the read failed). Its email setup choice is recorded even though no mailbox is attached, which is the reverse of the company above.

3 · Parts 1, 3, 7, 8, 12: a building (August Court) and where its answers come from

The building focus shows several blocks. Where the settings resolve from is part 8. Who each notice goes to is part 12: each chain is one row naming the rung that answered, never the address. PM mail resource is part 1, Phone lines is part 3, and Where the knowledge came from is part 7. The lazy blocks are captured after their reads answer.

This section uses August Court, which has no phone line. The scattered-homes building carries the PropFlow bench line, and the evidence tool's contact scan refuses to publish any page that shows it. The tool is right to refuse, and its check was not widened. So the phone block appears here in its no-line state, as a sentence.

4 · Part 16: settings whose reader reads the stored row (August Court)

The Where the settings resolve from block now also answers the 19 registered settings whose product reader reads the stored setting row itself: the hand-off and ring lists, the catch-all and emergency routes, the call switches, lease billing, the vendor roster walk, the cross-sell rule and the digest recipients. One call to the shared resolver answers all of them, and the resolver names the level that answered: this building, the company, or the PropFlow default.

On this test company the rows that exist are all at the company level, so they read from the company. No building-level row exists on stage, so the building-beats-company case is proved by the unit falsifier rather than this capture. Contact lists, phones and emails read set (value not shown): only on/off switches, numbers and fixed choices show their value. Part 16 took the not-shown count from 95 to 76.

5 · Part 17: settings nothing in the product reads yet (August Court)

18 more registered settings are answered by the same resolver call. No code in the product reads them yet, and each row says so in plain words: the product does not read this yet. Settings whose idea already lives somewhere else, such as a phone number on the building record, are left out on purpose, so none of these rows says "not set" beside a value the product uses. A test fails the moment one of these settings gets a reader. With one setting removed from the registry since part 16 (100 registered now).

6 · Parts 18 to 25: every other setting with a door of its own (August Court)

Each of these settings now goes through the door the product itself uses, and the panel says which level answered: this building, the company, or the PropFlow default. Part 19 covers the three company-only settings (the buffer between tours, the application link mode and the staff observer copy). Part 20 covers the tour booking lead time and the PM reminders; the reminder numbers are the ones the product actually sends with. Part 21 covers the customer building control (worked out from whether Clara is live when no choice is stored) and the in-PropFlow switch. Part 22 covers office hours and the escalation copy list. Office hours are read two ways: phone calls also read the company's stored hours, while booking, Clara and escalation timing read the building's alone, and the panel shows both when they differ. This company stores hours and this building does not, so both readings show here. Part 23 covers renewal offer terms and eligibility through the renewal engine's own read, where a failed read is never shown as "a person handles renewals". Part 25 covers the application link. Part 18 corrected part 17: outreach cadence is no longer called unread.

Phones, emails, links and lists only ever say "set". A failed read always says "not answered".

7 · Parts 24, 26 and 27: every registered setting is accounted for (August Court)

Every registered setting is now either answered by the door the product uses, or given an explicit state saying where its value is kept and that no shared lookup reads it yet (part 24, a Driver ruling: an explicit documented state, not a new chain). Part 27 labels the last twelve: the groups of settings with one value per trade, role, function or fee, the legal floors, and the per-staff-member tour alerts. The summary row now reads none — every registered setting is shown, and a test fails the moment a newly registered setting has neither a door nor a stated home. Part 26 words a saved empty application link as the stored state only.

8 · Part 28: the building's PMS connection health (August Court)

The sync keeps PMS state per connection (company and PMS account), so the building is mapped to its connection the way the sync does it, and the block reads the sync's own rows: whether the building names a PMS account, whether the company's sync is paused, the dispatch mode, and the connection's health rows per sync job with the health sweep's own verdict. Nothing is invented: this connection has no health row on stage, and the block says exactly that, never "healthy". Error text and free-text reasons never cross. A failed read is not answered.

Operating-record content (condition reports, key pickups, appliances, maintenance tasks and manuals) is excluded on the row by a recorded decision; key pickups already show through the notice-chain block and work-order tasks inside the work-order focus.

9 · Part 13: the building's own record (August Court)

The building's own Connections and integrity block. Write-back wiring (pmsSource) is one row and where the last rent roll came from is another, because only the first gates a push. The PMS connection owner, the sync stamp, the PMS visibility, the ticker and time zone, and whether the recorded unit count agrees with the unit rows each get a row too. A missing owner reads unverified, never dangling.

10 · Part 10: a unit and its listing

The unit's listing flag and whether the product would offer the unit are two rows. The lease pointer and the live leases on the unit are separate facts too.

11 · Part 6: a tenant occupancy

The occupancy's unit, its lease found by PMS id and by person and unit, and its lease window each get their own row.

12 · Part 11: a person's own record

This shot is taken once the lazy person read has answered. Before that, every row that depends on it reads not loaded, never no.

13 · Part 5: a person's role

The role's state and every id it names get their own rows. A role is a grant, not a connection, so sign-in state reads not applicable.

14 · Calendar half, part 29: a person's own calendars

A focused person gets a Calendars block, one row per calendar, saying what each one is used for. The booking calendar and its own endpoint row are merged into one row. A second calendar would read its busy times are checked too; nothing is booked here. A connection that never finished reads never finished connecting, and one that lost access reads lost access — needs reconnecting. No address, calendar id or credential reaches the page (#15714).

This person is in another stage company, not the test company. Their calendar is PropFlow's own test Google account.

15 · Calendar half, part 30: a company's schedule view and its connected calendar (Fairhaven Residential (TEST))

The company card shows two separately labelled rows. The Company schedule view always exists and needs no connection. The Company connected calendar is a real connection with its own status and provider. Its row names the buildings it is declared to serve: all, a named list, unreadable, or none. This company declares no list, so it reads every building (#15720).

16 · Calendar half, part 30, negative control: a company with no connected calendar

The same two rows on a test company with nothing connected. The schedule view is still there, and the connected calendar says not connected. It serves no building, because nothing is connected.

17 · Calendar half, part 31: a person with no calendar of their own, and the shared calendar their buildings fall back to (Fairhaven Residential (TEST))

A leasing agent with no calendar. Their Calendars block says This person has no calendar of their own. Directly under it, Shared calendars at this person's buildings shows what a tour at their buildings would look for. It is the tour pool's own answer, not a second copy of it. Their job covers the whole company, so the company calendar is shown once, with its state (#15904).

The follow-ups make the block honest in three more cases. A role whose end date passed, or one held under an arrangement that ended, is not counted as a job. A building with no shared calendar is listed, saying none — no building or company calendar would be tried at this building, instead of disappearing (#15965). A failure while judging the jobs makes only this block unreadable, not the whole person (#15980).

Not captured here

Part 4 (a vendor's engagements) and parts 2a/2b (a work order's dispatch and PMS mirror) are not captured. The test company has no vendor membership and no work order on stage. Filling the gap by photographing another customer's rows would move this page off the test company.

What the two screenshot → critique rounds found, and fixed before this page was published.

• Round 1, company card. The Identity row read sandbox: yes (the isSandbox flag) next to sandbox purpose: no, and nothing said these are different fields. The flag now has its own row.
• Round 1, unit. The unit read last written by the PMS sync, but this unit is fed only by a public listings page, and that sync stamps the same field. The row is renamed.
• Round 1, building. Part 1's mail block said the organisation rung was owed in the same view where part 12 answers it. The row now points at the notice-chain block.
• Round 1, publishing refused. The scattered-homes building carries the PropFlow bench phone line, and the contact scan refused to publish it. The check was not widened. The building section moved to one with no line.
• Round 2, building. On a test building both team-notice rows read no rung has an address, while the staff page directly above them answered from the company's escalation owner. The team chain gates that owner with the sandbox guard. The rows now say that an owner is set and a test building may not reach it.

Part 15's two critique rounds.

• Round 1. On the test company the email setup row read not recorded directly above company mailbox: attached. On the negative control it was the reverse. Both read like a contradiction. The setup row now says no setup choice recorded or a setup choice is recorded. The provider was a bare word after the status, and it is now labelled.
• Round 2. The re-capture at the fixed commit, with all eight sections, showed both setup rows reading as choices and both mailbox rows as their own answer. Nothing else on the company card disagreed with the new row, so nothing changed in this round.

Calendar half: what is pinned by tests and NOT shown on screen. Stage holds neither of the following cases, and the ruling for this row (f3218f8cb) was to pin them in tests rather than invent stage fixtures. A read-only stage scan of 1.76M items found no person with two calendars and no company calendar limited to a list of buildings.

• A person with two calendars. Pinned in src/__tests__/atlas-person-calendars.test.tsx: two calendars render as two rows, each saying what it is used for, and only the booking calendar reads tours with this person are booked here.
• A company calendar serving only some buildings, and a building with no shared calendar. Pinned in src/__tests__/atlas-person-shared-calendars.test.tsx (the pool drops the company calendar for an excluded building, and that building is still listed as none — no building or company calendar would be tried at this building). A company calendar declared for exactly two of its buildings names those two on the company card. That is pinned in src/__tests__/atlas-company-calendars.test.tsx (#15720).
• A lapsed job, and a failure while judging jobs. Also pinned in atlas-person-shared-calendars.test.tsx (#15965, #15980). Neither changes how a row looks.

Calendar-half screenshot rounds. Each of parts 29, 30 and 31 had two screenshot → critique rounds before its PR. In part 31's second round, the shared block moved from below the connection credentials to directly under Calendars. That way, "no calendar of their own" is read right above what the buildings fall back to.