Clara Onboarding — Overnight Fleet

The onboarding we ran at Situs Group on the night of Sep 1, turned into a repeatable 11-stage playbook, a data inventory with load/don't-load verdicts, and a review UX — plus nine decisions that need Fede.

Proposed — pending Fede's review · 2026-09-02

1 · The pitch, and what last night proved

This is the vision's "judgment with boundaries" loop run once, up front: outside policy Clara asks, the answer becomes policy, and she never asks again. Onboarding is that loop compressed into one night of collection and one short review session — instead of six months of the operator catching mistakes one at a time.

Commercially: pre-seed, seed raise in 6–9 months, pre-PMF, Situs is the first paid design partner. The overnight fleet is the wedge (nobody else can stand up a property's rulebook from the client's own records in one night) and it is the seed story (every property onboarded makes the next one cheaper).

What last night proved — one run, Situs Group, situsgroup.appfolio.com

Human baseline measured from their own records: median 46 min to an individual human answer in hours, 11 h after hours, 22% never answered. Replay: 56% of Clara's draft replies acceptable cold, before any of this context was loaded.

2 · Playbook v1 — 12 stages

~4.5 h of stage time; ~2.5 h wall clock with exports and entity pulls parallel and policy mining, replay and the config audit concurrent. PMS-specific stages change mechanics per PMS; PMS-agnostic stages survive a swap to Yardi or RealPage unchanged in shape.

Order changed on Sep 2 (D9). S5 documents and S7 policy mining were the lane we built first; both were then measured and neither moved the replay headline. The new stage S9b makes the question-bank coverage check an explicit gate rather than a report, and the post-run fill order puts live integrations ahead of documents — the calendar, availability, balances and application status first, because 64% of real question volume needs live state that no document can supply.

Go-live blockers the playbook must catch (S10 top P0s)

3 · What was noise, and what to cut

17% waste on a first-of-kind run, and only ~2.3 h of it is genuine defect rework. The biggest single item was a deliberate scope add, not a mistake.

The pattern: every defect that cost real time has the same shape — no post-condition on a captured record. Empty shells, a bad URL builder, a fetch from a blank page, an aborted render call. Playbook v1 turns each into a guard.

4 · What to load, and what not to

59 entities inventoried across the client's PMS. The verdict, not the volume, is the product of this stage.

ONBOARD — the 8

EXCLUDE — the 4

The 11 exclusion filters — context rot

These cut across entities rather than removing one, and they are separate from the 4 excluded datasets.

5 · The missing documents

And we already own the capability. The browser-agent repo carries three live-verified document readers the dump toolkit simply never called: an executed-lease reader (proven byte-identical to what the UI prints), a renewal-letter renderer, and a per-document signature-status reader. What last night captured was the pointer — a filename and a link, as scraped text. The link was never followed.

Priority order, by blocked replay rows: fee schedule (70) → application and screening criteria (84, fair-housing sensitive) → house rules → executed leases and templates → vendor and pest schedules (21).

5b · The question bank and the coverage check

397 canonical questions — P0 154 / P1 200 / P2 43 — built from 5,465 real inbound turns across two corpora: Situs Group (1,636 apartment turns, 2026) and Camellia Apartments (3,829 turns since April 2026, pulled read-only from production). 1,940 of those turns (35%) are questions; the rest are acknowledgements, greetings and content-free fragments. Every question carries the fact key that would answer it — 112 keys, 89 of them behind at least one P0 question — plus where that fact lives in AppFolio and which document normally carries it.

The fifteen questions properties actually get

The top question is 12% of all question volume on its own. Tiers are cumulative share of question volume: P0 is the top 80%, P1 the next 15%, P2 the long tail. Spanish is 5.8% of question volume, carried almost entirely by Situs.

Running it against Situs — the first coverage check

Coverage is flat across the three communities (23–29%), so this is a portfolio-level gap, not a per-property one: the knowledge blocks are built from the same PMS fields everywhere, and the same fields are empty everywhere. Filling one building's gaps fills all thirteen.

The fill list — what to go get, ranked by the inbound it unblocks

A separate long-tail bucket (177 turns of one-off questions with no shared fact) sits between #1 and #2 and is not fillable as a fact. Six of the ten are live system state. The single biggest gap is not a document at all — the tour calendar alone blocks 598 inbound messages, nearly a third of all question volume, and there is no AppFolio field for it. Full ranking in coverage_fill_list.csv.

6 · The review session — UX

The customer's job is disposition, not authoring, and most facts never reach them at all. Consolidation runs first, unattended; the human sees only what the data cannot settle.

Consolidation before review — what never reaches a human

A raw extraction produces hundreds of candidate facts per portfolio (Situs: 112 fact keys × 16 properties, plus every message-mined restatement). Reviewing them one by one is the queue we refuse to build. Five rules, applied by the pipeline with no human in the loop, decide almost all of them:

What is left for a human is exactly one thing: conflicts — staff vs staff, staff vs document, document vs system setting — plus the rare outdated item where a document contradicts a current setting. On the Situs data that is 13 conflict topics against 112 keys. The review is a 20-minute session, not a project. When the queue is longer than a coffee, the pipeline is wrong, not the customer.

Evidence floor and dedup are the same rules the "What Clara knows" page is built from, so the review queue and the brain page are one dataset with two views.

Ten principles

Information architecture — portfolio first, property as an override

Topic-first buries the handful of items that actually need a human inside hundreds that don't. Property-first repeats the same fact sixteen times. The tree is portfolio-first; a property is a filter that shows only where it differs from the default.

Portfolio
 ├─ Needs You (2 types, badge-counted)
 │   ├─ Conflict (staff vs staff, staff vs document, document vs setting) — scoped to the properties where it occurs
 │   └─ Outdated (a document contradicts the current system setting)
 ├─ Policy Book — portfolio defaults (auto-confirmed, browsable by topic)
 │   └─ Overrides table: fact × property, only where the value differs
 └─ Property view (e.g. "Carr Street Flats") = defaults + this property's overrides + its open conflicts

"Confirm" and "Missing" are gone from the human tree on purpose: confirm is decided by the evidence floor, missing goes to the fill list. Intercom Fin's four-way taxonomy (missing / unclear / duplicated / contradictory) still applies, but three of the four are handled by the pipeline.

Card anatomy, and the conflict view

┌─────────────────────────────────────────────────────────────┐
│ CONFLICT · Late fee grace period            [Applies to: ▾]  │
│                                              Willows only ▾   │
│ Staff says the grace period is either 3 days or 5 days.      │
│                                                                │
│  Variant A — "3 days"            Variant B — "5 days"         │
│  ────────────────────            ─────────────────────        │
│  "we always give a 3 day        "our policy is 5 days,        │
│   grace window"                  we've never enforced          │
│  — Erika, text to tenant #4021   day 4"                        │
│  Aug 14, 2026 · 1 of 6 msgs      — Darrin, staff Slack          │
│                                   Jul 2, 2026 · 1 of 2 msgs     │
│                                                                │
│  System setting (AppFolio): late_fee_grace_days = 5           │
│                                                                │
│  Recommended: Variant B (matches system, more recent, 3       │
│  independent mentions vs 1)                                    │
│                                                                │
│  [ Keep A ]  [ Keep B ✓rec ]  [ Something else… ]  [ Skip ]    │
└─────────────────────────────────────────────────────────────┘

Every card carries: the claim in one line; evidence quotes with speaker, source, date and corroboration depth ("1 of 6 msgs"); a confidence label, not a number ("3 independent mentions"); the system-of-record value where one exists; a recommendation with its reasoning stated; and a scope selector — this property / these properties / whole portfolio — defaulted to the narrowest, so a correction never silently propagates.

Conflicts always show two or three named, attributed variants side by side. Base = the system of record when there is one, otherwise the better-corroborated variant leads. Anonymized conflicts cannot be resolved with judgment.

Batch and keyboard flow

Documents, audit trail, end state

Upload triggers scoped re-derivation. A property can upload a lease template, house rules or fee schedule at any point. That runs the same agent pipeline restricted to the claims the document touches, and re-opens only the affected cards. Never a full portfolio re-run. Uploaded documents outrank message-mined evidence and carry an "Official document" badge — but if the document conflicts with what staff actually do, that surfaces as a variant, because the gap between the written policy and the practiced one is itself a finding.

Audit trail. Every disposition writes item id, before-value, after-value, decision type, reviewer, timestamp, scope, and whether the customer took the recommendation or overrode it. Browsable per property, filterable to overrides only — the fastest way to spot a review decaying into rubber-stamping.

End state: one policy book for the portfolio, with a per-property override table. Every resolved item organized by topic, each showing its evidence, its resolution, who confirmed it and when, and its next re-check date. That is what Clara reads. Nothing enters it without a disposition; skipped items stay in Needs You until they are resolved or their snooze expires.

What not to build

7 · North star — Clara calls and asks

Same four decision types, same evidence-and-recommendation structure. Different order and phrasing, because a call can't show a side-by-side card.

8 · Decisions for Fede

9 · Next steps

• Land the three fixes-first in the collection toolkit: mandatory write guard, a real year parameter, mandatory manifest gaps.
• Build S5 on the document readers we already have — fee schedule and screening criteria first, since they block the most replay rows.
• Fix the go-live blockers that make a new property impossible today: outbound number resolution, listings sync, and the per-account config layer that currently has no persistence.
• Ship the review queue behind the existing onboarding wizard, dark, and run the Situs policy ledger through it as the first real load.
• Done, and it found nothing: the replay was re-run with the mined knowledge base loaded and the headline held at 56%. Next is the other lane — wire the tour calendar, live availability, balances and application status, and re-run the question-bank coverage check after each one (D9).

10 · From client answers to the knowledge base (2026-09-15)

Proposed — pending Fede's review · 2026-09-15

Where we are today

Western Slope finished the in-product review this morning: 26 of 26 items answered by Jay — 6 corrected, 4 open/conflict questions answered, 16 confirmed.

Correction 2026-09-15: the apply step merged with a write target Fede had not confirmed (anchor property). Nothing was written anywhere. Re-targeting to company + building is the next PR chain; the walker PR was stopped before opening.

Target flow — the goal is autopilot, not a hand-run playbook

Fede, 2026-09-15: onboarding should scale to people self-signing up, with no engineer running steps by hand. Five moments:

Three small, dark PR chains

Decisions for Fede

11 · What we learned onboarding Camellia, Situs and Western Slope (Sep 5–15)

Proposed — pending Fede's review (2026-09-15)

Rulings that are now standing rules

Mistakes we will not repeat

Learnings from the Western Slope knowledge day (2026-09-15)

1. One record per customer from the first hour. A hand-typed placeholder on Sep 5 and a real record on Sep 12 left two copies of the same company for ten days; nothing in the database or in Gera's model refuses that today. Cost: a full afternoon to inventory and delete 2,049 rows. Rule: the first pull creates the real company under its AppFolio database name, and no session creates a second one by hand.
2. The questionnaire is the decision. Once the client answers, we stop debating with our own history ($32 charges vs their $40). Flags go back to the client only when their own answer contradicts itself.
3. Know what the platform already does before asking the client anything. The draft asked how prospects book tours. Clara books tours. Check the client's own sent mail and guest cards first; "how do people apply" turned out to be a per-home button in AppFolio, not a link.
4. Name the data source before reasoning about it. "Rent roll" on the placeholder was a public-page scrape, while the real company had AppFolio's feed all along. Half an hour of wrong conclusions came from not checking which job wrote the rows.
5. Entries are facts; Clara does the talking. Scripted lines ("tell me which home and I'll give you the amount") read wrong to Fede in seconds. Facts, short, one figure per line, property exceptions in their own table.
6. Never hand Fede a link before the deploy is green. Three edits pushed in three minutes cancelled each other's deploys; he read the stale first draft twice and lost trust in the page. Watch the deploy, then send the link, once.
7. Subagents draft without product context. Every review page a subagent writes gets a pass against the writer rules and the platform's abilities before it reaches Fede.
8. Delete with a backup and a checklist. What blocked the placeholder delete was not the data but what pointed at it: a shared company id, a workflow that re-created it on every push, a daily test job, a rollback agent. Inventory those first; the delete itself took 20 minutes.
9. 2026-09-16 — Approved knowledge landed only half loaded. The gold set's 17 company facts loaded; the 7 home exceptions never reached what Clara actually reads, and nobody had compared the live render against the approved file — "knowledge reviewed" meant the client approved the file, not that Clara reads it. On a live call Clara said Ridgway tours are in person; the client had said lockbox-only. Root cause: the loader only knew how to place company-level facts, and no command diffed live output against the gold set. Rule: the loader places every approved fact (company or the home it names) and refuses to finish if a fact has nowhere to go; a verify command renders exactly what Clara reads and diffs it against the gold set before "knowledge reviewed" counts as done.
10. 2026-09-16 — Western Slope: the 17 company facts loaded, the 7 property exceptions never did, and the tracker said "knowledge reviewed". Clara told a caller a lockbox-only home had in-person tours. Fix: scripts/knowledge/load-knowledge-gold-set.ts places exceptions on the property row and refuses to finish with any unplaced; knowledge:verify-live diffs what Clara reads against the approved file; the onboarding harness (scripts/onboarding-harness/knowledge.ts) runs create → load → verify red-before/green-after on a scratch org. "Reviewed" is never "loaded"; only the verify output counts.

Western Slope onboarding — what went wrong and the rule that prevents it (2026-09-17)

Every row below happened between Sep 7 and Sep 17 while standing up one new client. The rule column is what the next onboarding does instead; the last column is where the rule is enforced, so it survives this page.

Pull requests behind these rules: 7919, 7962, 8007, 8043, 8060, 8314, 8375, 8378, 8458, 8553, 8606, 8638, 8704, 8726, 8750, 8844, 8861, 8882, 8893, 8900, 8912, 8913, 8923, 8927, 8934, 8958, 8962, 8964, 8968, 8969, 8970, 8973, 8977, 8978, 8979, 8980, 8986, 9013, 9031, 9036, 9046, 9047, 9098, 9103, 9105, 9113, 9135, 9137, 9139, 9140, 9144, 9148, 9155.

12 · The repeatable playbook

Proposed — pending Fede's review (2026-09-15)

Pre-go-live checklist — one line of proof each (added 2026-09-17)

Every step below exists because Western Slope's go-live hit the matching failure in section 11. A step is done when its proof artifact is pasted on the client's go-live tracker row — not when the code merged.

How a session uses this

Start here: this page. The go-live tracker (docs.propflowai.co/a/western-slope-go-live) is the status board — every stage above should have a row there once it's wired for a client. The scripts to know by name: the appfolio-onboard tool/skill for the raw pull, load-knowledge-base.ts and export-knowledge-base.ts for the review record, and apply-knowledge-review (PR #8650) for the knowledge build. No new doc page — updates to this playbook go here.

What the mailbox audit feeds

Proposed — pending Fede's review (2026-09-15)

The audit's output feeds knowledge, shared parsing code, and a client ask. Owned by the shared-mailbox lane — see the go-live tracker row ws-shared-mailbox-access-gap-2026-09-15 (docs.propflowai.co/a/western-slope-go-live) and the design section docs.propflowai.co/a/email-architecture-2026-08-14#inbound-lead-flow-2026-09-15.

13 · Build now for Situs Group

Proposed — pending Fede's review (2026-09-15)

Situs Group is next: 645-ish units, no AppFolio API access (browser-only), full 2025/2026 raw dumps already sitting in ~/situs-data, no org/property in prod yet, shared AppFolio login with JP&Co today. Ranked in Fede's stated priority order, each a small dark PR (≤300 lines):

From the mailbox audit (Western Slope, also needed for Situs) — owned by the shared-mailbox lane. See the go-live tracker row ws-shared-mailbox-access-gap-2026-09-15 (docs.propflowai.co/a/western-slope-go-live) and the design section docs.propflowai.co/a/email-architecture-2026-08-14#inbound-lead-flow-2026-09-15.

Proposed — pending Fede's review (2026-09-15)

Not now: Clara interviewing the team (long-term only, not this build); sending the questionnaire to the client fully automatically — that stays gated on Fede's check until two company runs have gone cleanly through hello@ first.

14 · Design: intake document → knowledge base (2026-09-15)

Proposed — pending Fede's review · 2026-09-15

Inputs

Today: a customer-facing document upload already exists — the property page's Knowledge Upload modal (KnowledgeUploadModal.tsx) posts a PDF/text file to /api/properties/[id]/knowledge/ingest, which extracts discrete knowledge sections with an LLM and saves them to the property's DynamoDB knowledge row — so the upload step is existing, not to be designed, and the draft generator reads documents from that knowledge base store, not from a mailbox.

The core checklist comes first (Fede, 2026-09-15)

Proposed — pending Fede's review (2026-09-15)

Core leasing checklist — Western Slope audit, 2026-09-15

Proposed — pending Fede's review (2026-09-15)

Totals: 15 filled, 4 conflicting, 5 empty, 2 listing-only.

Flow

Implications

Decisions

Example — Western Slope item 1, office hours

Jay's answer: "Our office is closed Monday and Friday. Tuesday–Friday 1–3pm our doors are open to the public, but we encourage prospects to call us instead to receive assistance. We also accept physical appointments."

• Say to prospects: "Our office is open to walk-ins Tuesday through Thursday, 1 to 3 pm, and closed Monday and Friday. Happy to set up an in-person appointment."
• Clara knows, never says: the team prefers calls over walk-ins, so Clara steers to a call or a booked appointment and never suggests "just stop by."
• Back to the client: Friday is listed as both closed and open. Tier: company.

Implications

• The apply script merged today writes corrections verbatim and cannot apply this lens; the lens is a classification step (model + rules) that runs before any write, and Fede's one-by-one rulings on Western Slope's 26 answers are its gold set.

State of the Western Slope record, 2026-09-15

Proposed — pending Fede's review (2026-09-15)

Not decided here: the generator prompt, the harness, the automatic trigger. No code until Fede settles the above.

Lessons for the automated pipeline

Proposed — pending Fede's review (2026-09-15)

Rules for the knowledge base writer (Fede, 2026-09-15, from the Western Slope pass)

Fede reviewed the first machine-drafted knowledge base for Western Slope entry by entry. Every rule below is a mistake the draft made. The script, the draft generator and the review page follow them from now on. Result: Western Slope knowledge base.

1. The client's answer is the decision. Once the questionnaire is answered, the answer is the fact. Old charges, unit settings and lease templates are context in the internal note, never a "conflict" and never a question back. (Fee: Jay said $40 twice; the draft flagged it against $32 history.)
2. Ask back only when the client's own answer contradicts itself, and even then take the explicit statement (Friday: "closed Monday and Friday" wins over "Tuesday to Friday 1 to 3").
3. Entries are facts, not lines. Never write what Clara will say ("Tell me which home and I'll give you the amount", "I'll text you the link"). Write the fact; Clara phrases it per channel.
4. Short. Figures as variables, no explanations. "Refundable pet deposit $300 total. Pet rent $35 per pet per month." A caller cannot follow a paragraph.
5. Company table and property table, separate. The general rule lives at the company (a leasing associate hands over keys). The exception lives on the building it names (Pomona Park, Ember Estates, Flats on Elm: door code, keys inside). Never a company entry that lists building exceptions inline, and never a company entry whose only content is naming which buildings differ.
6. Listing data is not knowledge. Rent, deposit amount, utilities included, promotions and the Apply link for a specific home come from the listing. The knowledge base holds only the rule ("deposit is usually one month's rent; amount on each listing").
7. Never ask the client what the platform does or what the listing knows. No "how do prospects book a tour" (Clara books it), no "what is the apply link" (each listing's Apply button), no "what is the move-in payment method" unless a prospect actually asks that.
8. Volunteer nothing sensitive. "No pets" is the entry for 632 Hill. Assistance animals are not mentioned; if asked, Clara's standing behaviour sends it to the leasing team. No "review with counsel" notes on a client page.
9. No investor words. "Portfolio", "units", "screening report" only where the client uses them. "Home", "the office", "the leasing team".
10. The review page is the cleaned version only. Two tables, property above company, columns # / topic / entry. No raw column, no banner, no questions section, no flags unless rule 2 applies.
11. Three layers. Company = the general policy. Property = its exceptions only. Listing = what that home adds on top (rent, deposit amount, utilities, promotions). The writer never copies a listing fact into either table. (Fede, team meeting 2026-09-15: "general ones at the company, some exceptions at the property level, and the listing could specify something in addition.")
12. Short because Clara reads it all. On a call she tends to read the whole entry. Anything per home or at the team's discretion is one line that ends in "on the listing" or "the leasing team decides", never a paragraph. (Fede, same meeting: "I don't want Clara to read all this on a phone call.")
13. "How do people apply" is an action, not an entry. Check how the client's staff do it in their sent mail and guest cards before asking anyone. Western Slope: staff click "Send application" on the guest card in AppFolio; one form per home; no generic link. Clara has no per-home apply link today (one link per property setting); gap logged on the Western Slope page.
14. Classify before writing. Each client answer is first sorted: prospect-facing fact, internal context Clara knows but never says, or not knowledge (listing data, setting, action). Never transcribe the raw answer. (Fede, 2026-09-15.)
15. Tag the audience. Every entry carries who it is for: prospect, resident, staff. A resident-only fact never reaches a prospect. (Fede, 2026-08-26: "how do we segment the knowledge base so we don't give this info out to everyone.")
16. The questionnaire triggers the build. No person writes or runs a script per client. Said in four sessions since 2026-09-02: "that works for one customer, it doesn't work for ten."

Mined 2026-09-15 from every session since August: five of the rules above had already been said before today (tiers 4 sessions, automation 4, short 3, trust the client's answer 3, listing data 2). Full hit list in the session scratchpad kb-corrections-history.md.

The test that keeps these rules alive: western-slope-knowledge-gold-set.json holds Jay's 26 raw answers and the 24 entries Fede approved. The first draft-generator PR must reproduce those entries from those answers (topic, tier, and every figure) before it merges; a rule without that check is just prose.

Verbosity budget still applies on top (Aug 29 knowledge-layer): voice one figure and one date per turn; text answer plus figure plus link; email full.

AppFolio: sending the rental application (documented 2026-09-15, not built)

Documented — not built (2026-09-15)

Ran the flow once, headless, at Willows (property 45, jpco.appfolio.com), to document it — not to automate it. Guest card action row: Rental Application ▾ → Send Rental Application (AppFolio's own help docs still call this "Email Rental Application" — the label changed). Opens a "Send Rental Application by Email" modal: Unit or Campaign (searchable, blank by default, not pre-filled from the guest card's existing interest), Recipients (pre-filled with the guest card's email), optional Bcc and SMS checkbox, and a pre-filled Message. Submits to POST /guest_cards/{id}/email_rental_application, confirmed by a 204 response and an "Email Rental Application Sent" line in the guest card's own audit log.

Matching the right property

• The identifier the send is keyed on: the submitted interest_prefixed_id, a unit-level id (u_<id>) — more granular than the property. It comes from a live text search inside the modal, not from the guest card's own interest.
• The mapping problem: PropFlow's own listing/unit id is not this value. Any future automation needs a maintained, re-resolved-at-send-time mapping from PropFlow's id to AppFolio's live u_<id> — the search matches free text (address, unit number, rent), not a stable key.
• The risk: because the field is blank by default and keyed on an id AppFolio doesn't expose plainly, a stale mapping or a send that skips re-resolving it would silently email a prospect the wrong unit or wrong property. Real risk, not hypothetical, if this is ever automated.

Matches rule 12 above: no generic per-home apply link is exposed here either — AppFolio builds and sends it, and it never appears in the admin UI or any captured request.

16 · Go-live switches: two front doors, two switches (inspected 2026-09-16)

Built and merged 2026-09-16 — dry run pending

The rule Fede set today. A new client connects their mailbox, calendar and AppFolio and everything reads and records from that moment, with no flags. Two front doors bring people to Clara: the phone line and the leasing mailbox. Nobody gets Clara's text number any other way, so texting needs no gate. Voice goes live when the client forwards their number. Email goes live when we flip the company's live switch, which holds every email Clara would send for that company until then. That is the whole go-live: one flag on our side, one call-forward on theirs.

What exists today, per front door

The company's own settings blob at Western Slope also carries copies of the global email and SMS switches set to off. Nothing reads those copies; the real switches are global and on. Harmless, but confusing, and worth deleting in the same chain.

Other switches found, and why they do not matter here

• Per-company, default off, no UI: vendor email to calendar (Fede's 2026-09-16 ruling, stays off), booking on agents' calendars, AppFolio guest-card thread import, the onboarding import runner. All are opt-in features, not gates on the front doors.
• Per-property tour behaviour flags (window matching, decider mode, invite copy, chokepoint): every one defaults to a fully working legacy path. A new company gets the same experience Camellia gets today.
• AppFolio writes need the property's PMS source and account stamped, which the import now does automatically. Not a switch.
• Fleet-wide parked jobs (renewals mirror, vendor directory, work orders) are off for everyone, by decision, unrelated to go-live.

PM reminders are opt-in

Fede, 2026-09-16 evening — in progress

Reminder emails to the property manager (e.g. "New application to review") are a per-company setting, off for everyone by default. Turning them on means naming the email that gets them. No new client gets reminders unless they opt in. Camellia (JP&Co) is opted in with its current recipients so nothing changes there. Origin: on 2026-09-16 the hourly reminder sent 100 emails to Western Slope's leasing inbox, one per open application imported at onboarding. The company live switch does not gate these (Fede rejected that).

The plan: four small dark PRs

1. Reader always on. Delete the environment flag and the disabled-schedule arming step from the pull reader. The reader runs every minute and reads every pull-mode mailbox. Safe by construction today because it only hands over replies on threads Clara started, and it stays that way until the lead-source setting widens it.
2. Live switch becomes the master email gate. Move the check from the two narrow seams to the outbound email seam itself, keyed by company: any email Clara would send on a company's behalf to a prospect, tenant or applicant is held and ledgered with reason "company not live" while the switch is off. Inbound is still read, recorded, classified and threaded, so the day the switch flips, nothing is lost.
3. Show the switch. A "Clara replies to email" line on the company page with its state and date, and the switch itself, staff-only. Today the card only appears once live and there is no button.
4. Phone line as an attachment, not a repo file. Attach a number to a company through the admin page using the phone-line attachment model that already exists, and generate the registry from it. This is the largest item and can trail the other three; Western Slope's line already works through the file.

Each PR ships dark, is proven on Fairhaven (sandbox tenant) and Willows, and flipping Western Slope live stays Fede's press. All merged 2026-09-16 (page switch #8889, Zillow suppress #8896, gate #8893, reader #8888); the email gate covers every customer-facing door: the two send seams, the inbound Lambda, the prospect-touch door used by tours and follow-ups, and vendor dispatch. Team mail is never held. Reader proven in prod 22:32Z (schedule on from config, poller ticking, Western Slope stamped push). Gate dry run at Fairhaven pending a neutral-domain prospect inbox.

Decisions

Evidence: production reads of both companies' profiles and attachments (2026-09-16); code paths company-mailbox-poll-flag, org-mailbox-inbound, inquiry-outbound-hold, outreach-trigger, the inbound-processor send gate, clara-live admin route, phone-lookup and phone-registry. Full file list in the session notes.

17 · Hours: one canonical store, not knowledge prose (2026-09-18)

Diagnosis + design rule — follow-up to the 2026-09-17 Western Slope weekend-tour incident (go-live audit, section 11b)

Diagnosis

Hours ended up in five places, three values, because nothing writes hours in one spot. tourHours and officeHours (both structured) are set by staff scripts. Separately, the 09-15 knowledge pass hand-typed a sentence off the client's website into a knowledge entry ("Closed weekends and holidays.") and got it approved into the gold set — nothing compares that sentence to the setting that already existed. Two independent writers, same fact, never reconciled; only a live call surfaced the disagreement.

Design rule going forward

• One canonical structured store per fact. (A) leasing/tour hours incl. weekends: tourHours (property overrides org). (B) business/office hours, separate: officeHours. Never merge.
• Knowledge prose never restates hours by hand — it points at the setting or is rendered from it, never typed and approved as its own fact.
• Every reader resolves the same way — voice, email, SMS and slot generation all call the same resolver, no channel gets its own copy.
• Onboarding import writes the setting once, from the client's answer at intake, not from a scrape typed into prose after the fact.
• KB-writer rule: hand-typing a day/time range into an entry is forbidden when a structured setting exists for that fact.

Build-time check (idea, not built)

Fail the knowledge-base build/apply step when an entry's text contains hour-like patterns (day names, time ranges, "closed", "by appointment") for a field with a structured setting on the same org/property — same shape as the provisioning-script guard already added for officeHours (#9188/#9214), generalized to knowledge prose and to tourHours. Not built; named as the open item on the go-live audit.

Sources

~/situs-data/onboarding/PLAYBOOK-AUDIT.md (forensic audit, timeline, playbook v1, entity inventory, missing documents, repo options) · ~/situs-data/onboarding/UX-RESEARCH.md (patterns, principles, UX spec, wireframes, voice mapping) · ~/situs-data/analysis/CAMELLIA-ASSUMPTIONS-AUDIT.md (go-live blockers) · ~/situs-data/analysis/POLICY-LEDGER.md · ~/situs-data/analysis/replay/RESULTS.md, RESULTS-KB.md (run 2) · ~/situs-data/onboarding/question-bank/ (README.md, question_bank.csv, fact_keys.csv, coverage.csv, coverage_fill_list.csv, RESEARCH.md) · ~/situs-data/analysis/memo-corpus-for-clara.md · ~/situs-data/analysis/WINDOW-AUDIT.md · ~/situs-data/STATUS.md, FLEET-BRIEF-2026.md, situs-dump-2025/RUN-LOG.md, the run manifests · ~/.claude/propflow-vision-2026-08.txt · Situs Group initiative hub · Situs Group — What the Records Show (2026)