Replying to syndicated guest cards

Approved by Fede 2026-09-18

Brief standalone version of the design in section 5 of the Western Slope go-live page.

Decision

Fede's ruling, 2026-09-18 evening: Clara replies only to guest cards whose oldest activity-log entry is "Guest Card Received" by System. No setting, no value, no transition path. Staff-typed cards are parked. Once the client stops typing cards, every card passes on its own.

Contents

The rule
The one exact signal
How it works
What exists vs. what is left
Rollout
Three decisions, answered
After Clara replies: the card in AppFolio
Tonight's build
Guest-card sync audit (2026-09-18)
Replay results (held drafts)
Readiness report — 2026-09-19

1. The rule

Clara replies only to guest cards a listing site (Zillow, Apartments.com) created, never a staff-typed card. AppFolio's own "new lead" email is not the trigger; Western Slope gets none of those. The card's "Source" label doesn't work either: 772 staff-typed cards and 381 listing-site cards carried identical labels.

2. The one exact signal

Every guest card's activity log starts with one line naming who made it: "Received" for a listing-site card, or "Created" by a staff name otherwise. That's the only reliable tell, so a reply goes out only once that line reads "Received."

3. How it works

flowchart LR
  A[Feed checks AppFolio\nonce a minute] --> B{New card?}
  B -- no --> A
  B -- yes --> C[Feed calls the robot service's\nread endpoint, 1-2 sec]
  C -- "staff name" --> D[No reply]
  C -- "Received by System" --> E{Company's live\nswitch is on?}
  E -- no --> D
  E -- yes --> F[Clara sends the first reply]

A new card gets one quick, read-only HTTP call to the hosted robot service's read endpoint, on its already-logged-in session, about a minute after the card lands. That call normally takes 1 to 2 seconds; a cold re-login happens rarely and takes up to 2 minutes when it does. Expected load at Western Slope: one to three look-ups a day.

4. What exists vs. what is left

Piece	State
Feed that copies every new card into PropFlow every minute	Built, running
Robot read endpoint the feed calls	Built for other work; not yet wired to this feed
Recording who actually created each card	Not built
The switch that starts a reply when a new card lands	Exists in code, deliberately turned off
The message Clara sends as the first reply	Built, currently paused by Fede
The company-wide on/off switch for live replies	Built
Graded test run against real past cards	In review

5. Rollout

Ships dark, off by default, as a company setting. Before it's turned on, the team replays 47 real Western Slope cards through a safe copy of the system and publishes the graded result here. Turning it on for real prospects is Fede's call, made after reading that result.

6. Three decisions, answered

Question	Answer
Let the robot read each new card to check who created it?	Yes, read-only, via the hosted robot service's read endpoint.
Un-pause the work that drafts and sends the first reply?	Yes, un-paused 2026-09-18 evening.
Include Zillow's referral-network cards?	No, excluded.

7. After Clara replies: the card in AppFolio

Once Clara's first reply goes out, two things happen back in AppFolio.

Assign

On Clara's first reply, the card's inquiry is assigned to Clara in AppFolio (Fede, 2026-09-18: "we should assign clara"). That needs a "Clara" user set up in Western Slope's AppFolio — that's the client's step, not ours. The target user to assign to is an org setting; if it isn't set yet, the assign write parks instead of failing or guessing a user.

Notes — cadence pending Fede

Proposed — pending review. Notes are written by outcome, not by turn: one note per outcome, not one note per message. Outcomes that get a note: first reply sent (what was offered), tour booked / moved / cancelled, application link sent, prospect said not interested (quoted), parked for a human. Each note is one line naming the outcome plus one line of the prospect's own words. Alternative considered and rejected: a note per message — that turns AppFolio's Actions Log into a full transcript, effectively one robot session logged per line, which is noise for the leasing team, not a summary.

Where this gets proven

Both mechanics — assign and notes — get wired and proven at the Willows (JP&Co test property 45) while the note cadence above is being decided. Never a test write into Western Slope's live database.

Who builds what

Piece	Owner
Reply path — intake, composer, replay	Session 000
AppFolio write path — note and assign intents, drain, robot	Session 003

Hand-off between them is one call at reply-send completion, carrying the card id, conversation id, outcome, reply body, and whether to assign.

8. Tonight's build

Step	State
Red main	Fixed (#9632)
Robot actor field	Merged, armed (#387)
createdBy stamp	Armed (#9633)
Lead-source setting	Fixing tests (#9484)
Composer	Armed (#9425)
Intake + seam	PR opening
Replay driver	PR opening
Note + assign write path (session 003)	PR opening
Aliases	Armed (#9643)
Rent-sweep	Armed (#9634)
Lock-in promise	Armed (#9635)
Weekend date	Armed (#9642); #9475 landing

9. Guest-card sync audit (2026-09-18)

Read-only audit of the code that copies AppFolio guest cards into PropFlow, prompted by a Western Slope card that looked six days late. Nothing was changed. The fixes are a separate step.

What the six-day gap actually was

The evidence, in order:

The sync never missed a beat. Runs for this property appear on a roughly 60 second cadence from 12 Sep onward, all successful, none failed. The request every time is the same year-wide, all-statuses report call, so 12 Sep was inside the window the entire time.
The row count is the proof. rows=9 on every tick from 12 Sep through 18 Sep 22:45:08 UTC. Then rows=10, created=1 at 18 Sep 22:46:10 UTC. From that tick on it reports unchanged=1.
AppFolio also dated the card 18 Sep, not 12 Sep. Our record's date is a straight copy of AppFolio's Received value and is never set to our own clock. It reads 18 Sep 22:45 UTC, which is 4:45 PM local, about a minute before we first saw the card. So AppFolio's report said the card was received on the 18th while the card's own activity log says the 12th. Those are two different AppFolio fields and they disagree by six days.
The card's neighbour synced normally. The card immediately before it in AppFolio's numbering belongs to another Western Slope property and reached us on 12 Sep at 18:14 UTC. Consecutive cards, made in the same AppFolio moment, six days apart on our side. That points at the card, not at the pipe.
No onboarding run, no new enablement. No onboarding import ran for this client in the sampled fortnight, and this property had been syncing for at least a week before the card showed up. One brief, routine backoff on 17 Sep resolved in under three seconds and failed nothing.

Ruled out explicitly: a date window, a paging cutoff, a throttle, a failed run, and "the sync was switched on today". The 30 day rule that blocks creating a record from an old card never applied either, since the card presented itself as same-day.

What we cannot see is why AppFolio held it back. That needs someone to open card 2910 in their interface. The likely shapes are a card that sat in a state their report excludes until something promoted it, or a card their system re-received.

How it runs today

Where cards come from: AppFolio's guest-card report, one row per card, asked for a full year back with every status included. Status has to be asked for explicitly or AppFolio quietly returns only active cards.
How often: every minute, for every AppFolio property we hold credentials for.
Who it runs for: everyone. There is no per client or per property switch on ingesting cards. The only related setting changes how the rows are fetched, never whether they are.
How a card finds its person: by the card's own number first, then the inquiry number, then a live lookup by email or phone, then a fresh re-check right before anything new is made. The new record's id is derived from the card number, so two workers racing the same card land on one row instead of two.
Replies: the sync starts no outreach. The hook exists and is deliberately left unconnected until Fede says otherwise.

Findings

#	What breaks	Where	Fix in one line
P0-1	The first minute after a new AppFolio account is connected, every card received in the last 30 days is made as if it were a brand new lead, with nothing marking it as backfill. The day the reply trigger is switched on, that is a month of stale leads getting a first text at once. Not what happened here, but it is waiting for the next client.	`guest-card.ts:1572`, `writers/utils.ts:161`, `lambda/appfolio-sync/handler.ts:4224`	Record when we first saw each card and make the reply trigger require that the card is new to us, not merely new in the list.
P0-2	A lead's created date is AppFolio's `Received` value, so we cannot tell a card we just discovered from a card that just arrived. Every funnel number keyed on created date is AppFolio's clock. This case shows the field can also be six days off the card's own history.	`guest-card.ts:1631`, seeded once at `dynamo/inquiries.ts:711`	Add our own "first observed" timestamp instead of overloading one field with two facts.
P1-1	The writer states that a bookkeeping-only save leaves "last updated" alone. The storage layer overwrites it on every write regardless, so closed leads keep reading as "just updated" in every recent-first screen. Visible on this very record: made at 22:46, rewritten at 22:47 with nothing meaningful changed.	`guest-card.ts:1501` against `dynamo/inquiries.ts:605`	Let the caller opt out of the automatic stamp, or drop the claim from the writer.
P1-2	The "already handled" marker is saved before the identity repairs run. If anything throws in between, the marker survives and every later minute skips that card. The person stays nameless or phone-less, silently and indefinitely.	`guest-card.ts:1518` and `:1527`; the roll-back at `:1857` cannot be reached from that throw	Save the marker only after the repairs report success, or move the roll-back into the catch.
P1-3	A card that moves to another property makes a second lead under the new property and the first is never retired. Two live leads, one card.	`guest-card.ts:1612` (the id includes the property); the snapshot at `:928` is property-scoped	Look the card up across the client's properties before creating, and retire the record on the property it left.
P1-4	Nothing on the synced card says who created it in AppFolio, so the "only reply to listing-site cards" rule in section 2 has nothing to read. The activity type that would carry it is defined and used nowhere.	`domain/pms/types.ts:649-679`; `prospect-activity-log/contract.ts:296`	Carry AppFolio's creator field on the synced card, the way the application sync already does.
P1-5	The per-property fetch throws away AppFolio's "there was more" signal. A very large property could silently lose rows with only a log line nobody watches. The purchase-order fetch guards against exactly this; guest cards do not.	`pms-adapter.ts:797`, `appfolio/client.ts:537`	Use the metadata-returning fetch and fail the tick when the answer is truncated.
P1-6	A card's status is judged by hunting for words like "inactive" or "application complet" inside whatever string AppFolio sends. AppFolio also sends a separate last-activity field we ignore entirely. A dead lead whose status wording contains no recognised word stays live in Clara's eyes.	`guest-card.ts:504` and `:519`; unused fields at `appfolio/types.ts:716`	Confirm what each client's status column actually contains, then match a known list instead of substrings.
P1-7	A card deleted or merged in AppFolio simply stops appearing and we never notice, so the lead lives on pointing at a card that is gone. The same blindness that let this card's six-day absence go unremarked.	no disappearance handling anywhere in `guest-card.ts`	Compare each run's card numbers against what we hold for the property and flag the ones that vanished.
P2-1	The roll-back save is the one save in the file that does not advance the row's version counter, and the stale row is then handed to the rest of the batch. A second card for the same person in the same minute loses the write race and is skipped for that tick. This is the issue the reviewer flagged.	`guest-card.ts:1858-1859`; every other save bumps at `:1328`, `:1511`, `:1540`, `:1667`	Bump the version after the roll-back save, like every other save site.
P2-2	When an identity repair fails, the reason is thrown away. The warning names the card but never says what went wrong, so the roll-back cannot be triaged.	`guest-card.ts:817-821`	Log the error before swallowing it.
P2-3	AppFolio sends the card's notes in the row we already fetch and we drop them. Notes are what the leasing team actually reads.	`appfolio/types.ts:740`, not mapped at `pms-adapter.ts:1917`	Carry the notes field through, read-only.
P2-4	If two lead rows ever carry the same card number, the lookup quietly keeps one and the other becomes invisible to the sync for good.	`writers/utils.ts:10-17`	Detect the collision and log it rather than letting last-one-wins decide.
P2-5	The schedule file still lists guest cards as every 15 minutes. That line stopped firing on 13 Sep and the real cadence is every minute. Six comments in the writer size their read cost "per 15-minute tick", so the load they are reasoning about is 15 times smaller than the real one.	the guest_cards entry in `lambda/appfolio-sync/schedules.json`; comments throughout `guest-card.ts`	Delete the dead cadence line and correct the comments.
P2-6	Cards whose date did not parse sort to the front of the batch, so they write first and can be overwritten by better data later in the same run. Harmless today, undocumented.	`guest-card.ts:951`	Sort dateless cards last.

P0 means it can reach a customer. P1 means data goes wrong quietly. P2 is cleanup.

Questions the audit answered along the way

Several inquiries on one card. AppFolio's report carries one inquiry number per card, so a second inquiry just replaces the first on our record. Nothing treats it as a fresh lead event.
Edits to an existing card. Status can only move a lead nobody has touched yet, never walk one backwards. A unit is filled in only if we have none. Notes are not synced at all, per P2-3.
Duplicate prevention. Strong, and the strongest part is that a new record's id is derived from the card number, so two workers racing the same card write to one row.
Co-signers. A card for someone already folded into another applicant's group never makes a second lead, and that is decided by a lookup rather than by reading a typed-in name.

Read-only audit against main at 456eddbb, plus production records and sync logs. No prospect names appear on this page.

10. Replay results (held drafts)

Section 5's replay, run: 47 real Western Slope guest cards (the 48th window read is included below; one card is out of window) replayed against org_ws_mirror_test, a sandbox copy of the Western Slope roster used only for this kind of test — never the client's own AppFolio account or database. The company's live-reply switch stayed off the entire time, so nothing was ever delivered to anyone; every reply Clara composed was held and written to a record instead of sent.

Replayed against commit 3f8aa1e67b70ca59a794e352f644858dcf976bd0 on fede/gca-assign-clara-engage; grading logic as of commit 65c53d93d7 on PR #9712.

Metric	Count
Cards replayed (held intents graded)	48
Composed a real reply (draft body on file)	14
Not graded (never reached the send door)	34
Held (company not live)	14
Passed grading	12
Failed grading	2

Grading correction, round 2 (2026-09-18). The first correction (below) was itself wrong in one place: it folded a subject-only row into a blanket "not a failure" bucket regardless of cause. That bucket actually held two different things — an intent left at pending (the reply pipeline never reached the send door at all) and, separately, an intent held with heldReason: 'send-failed' because the composer produced an empty reply (a real error, not a decision). The grader now tells them apart: an empty-reply error is a fail; a never-reached-the-door row is its own outcome, not_graded (nothing was decided, so it's neither a pass nor a fail). In this replay, all 34 subject-only rows are the never-reached-the-door case — none hit the empty-reply-error path.

Checked what actually happened on those 34 rows instead of trusting the label: read each one's own persisted conversation. All 34 already have a real, non-empty reply Clara composed sitting in the conversation — the reply pipeline worked every time. What never happened is this feature's own bookkeeping write, which stamps the composed draft back onto the held-intent record; that write never landed for these 34, despite the compose succeeding. That's a real bug in the send module, tracked as a follow-up — not a routing decision and not an empty reply, as the original "no reply composed" label implied.

The first correction (2026-09-18) also turned up a real bug of its own: 2 of the 14 composed replies asserted a tour was already booked and confirmed when nothing was ever booked — a hallucinated confirmation. Both are shown below. A grader rule fails any first-touch draft that asserts a booking is confirmed, since Clara has no thread history to draw on for a first touch and the guest-card data she reads today carries no "showing scheduled" field to confirm against.

Four representative held drafts (inbound → draft)

Prospect and staff names replaced with [prospect] / [staff]. Inbound is the prospect's own first words, taken from the AppFolio guest-card record, exactly as Clara read them.

1. Hallucinated tour confirmation — FAILS the new rule

Inbound: "We were told to come by between 2-4 on Thursday??"

Subject: Interested in Ember Estates HZ

Draft: "Yes, that's right — you're all set for Thursday, September 24th at 2:00 PM at Ember Estates HZ, 2858 C 1/2 Road, Grand Junction, CO. See you then!"

Nothing in the card or the inbound message names September 24th, 2:00 PM, or a confirmed booking — this is Clara's first-ever touch with this prospect, so there is no prior thread to be echoing. She invented a specific date/time and asserted it as already-booked. A second card in the same replay (address and other names redacted here) did the same thing with a different fabricated date. Both now fail grading.

2. Bilingual (Spanish) tour scheduling — passes

Inbound: "Friday"

Subject: Interested in 2978 Krista Street

Draft: "Perfecto, el viernes 25 de septiembre tengo disponibilidad desde las 9:00 AM hasta las 4:30 PM. ¿Qué hora le acomoda mejor? Y para terminar de agendar, ¿me podría compartir su nombre?"

Proposes a time and asks — never asserts anything is already booked.

3. General availability follow-up — passes

Inbound: "Hi, sorry. I've been applying to a lot of places. Which complex are you with?"

Subject: Interested in Northridge Apartments

Draft: "No worries at all! I'm with Northridge Apartments, at 565 Redcliff Cir in Ridgway, CO. You'd previously looked at a one-bedroom here. Want me to check on current availability, or would you like to come take a look in person? I've got openings tomorrow between 9 AM and 4:30 PM if that helps."

4. Not graded — reply pipeline succeeded, bookkeeping write never landed

Inbound: "No thank you I think I found something else. Curiosity though how much is a two bedroom two bath or a one bedroom one bath"

Subject: Interested in Northridge Apartments

Draft on the intent record: (none — the intent stayed pending with no body)

The intent record looks like Clara never got here, but the conversation it points to tells a different story: it already holds a real, non-composed-of-nothing reply. The compose step worked; the step that was supposed to save that draft back onto this held-intent record never ran. Not a routing decision, not an empty reply — a bookkeeping gap, tracked as a follow-up.

The full 48-row inbound-and-draft table lives with the grader in PR #9712 (stacked on #9425's branch, not yet merged — review in progress), which also carries the corrected grader and the new hallucinated-booking rule.

Full detail (evidence, file references, options considered) → Western Slope go-live, section 5.

11. Readiness report — 2026-09-19

When you flip Western Slope's company switch, Clara starts answering — by email — new guest cards that AppFolio creates from syndicated listing sites (Zillow, Apartments.com). That's it; nothing else about the client's setup changes. Turning it on takes two settings: the company's live switch, and a lead-source setting telling Clara that Western Slope's leads come from AppFolio guest cards. Both of those switches are OFF for every org right now, including Western Slope, so nothing acts on a real card no matter what merged overnight. Everything below this line shipped dark tonight so it's ready to flip once the proof holds up — no overnight report exists, and none of tonight's proof runs have happened yet.

What ships tonight

Piece	Effect in plain words	Status
Sync reads the card and who created it	Every new guest card gets checked for whether a person typed it in or a listing site sent it automatically.	Merged and live in the sync worker (PR #9785 — fixes the key the sync job reads the card by)
Reply only to System-created cards	Clara only writes back on the automatic, listing-site cards — never one a staff member typed.	Merged (standing rule, shipped earlier)
Zillow relay cards skipped	Cards that came through Zillow's referral network, not a direct listing, are left alone.	Merged (standing rule, shipped earlier)
Company live switch holds every email	Until you flip Western Slope's switch, no email goes out, no matter what else is working.	Merged (standing rule, shipped earlier) — currently OFF for every org
Lead-source setting	Tells Clara "Western Slope's leads come from AppFolio guest cards" so she knows which pipe to trust.	Merged (standing rule, shipped earlier) — currently unset for Western Slope
Composer writes the exact draft that later gets sent	The reply Clara would send is written out in full now, not a placeholder filled in later.	Merged (PRs #9633, #9705, #9635, #9484, #9737, #9425)
Draft composed before hold so held drafts are reviewable	Even while the switch is off, you can read the exact email Clara would have sent.	NOT merged — PR #9721 has a green review; one red test is under triage
Real composer wired into the sync worker	The live card-reading job now calls the real reply-writer, not a test stand-in.	Merged and live in production, web and the sync worker (PR #9750)
First-touch gate on the mailbox	Clara only auto-replies to a prospect's very first email, never everything that lands in the mailbox.	Merged and live in production (PR #9761)
Booking-promise guard	Clara is blocked from telling a prospect a tour is booked unless a tool actually booked it.	Merged (standing rule, shipped earlier)

What still blocks real cards

PR #9721 (composing the draft before it's held) has not merged — review is green but one test is red and under triage. Until it lands, a held draft during testing won't be the exact text that would go out.
The browser robot that hands back the prospect's actual question off a card's page (PR appfolio-browser-agent#397) merged overnight (2:43 AM MT), so this is no longer a blocker as of this report — carried here because it was still open when this section was first drafted.
Both company gates — the live switch and the lead-source setting — are OFF for Western Slope and every other org. Turning either on is a separate, explicit step, never automatic on merge.

Proof

What was tested	Where	Result	Evidence
Replaying real Western Slope guest cards end to end through the reply logic (Willows email proof)	Test mirror org only — never the real Western Slope database	Not run. Pending — blocked on PR #9721 landing and a test inbox.	—
Sending the rental application after a tour (Willows application send)	Willows test property	Not run. Pending. The mode setting (PR #9779) merged this morning; the post-tour wiring (PR #9783) is being moved onto main; the drain step (PR #9784, session 003) has not merged. The robot's send route itself is live and was proven on a bench card — see the "SMS/Email Rental Application Sent" entry by Clara PropflowAI in that card's Actions Log.	—
Temporal tour-scheduling workflow, live run evidence	Willows test property	Not run. Pending.	—

Deploy: production web is serving commit 30a22927, confirmed via the health endpoint at 2026-09-19T13:38:57Z UTC (7:38 AM MT) — that commit includes PR #9750 and PR #9761. The sync worker Lambda (propflow-appfolio-sync-prod) is running main@c7eb90d9, deployed 2026-09-19T12:58:00Z UTC (6:58 AM MT) per its function Description — that build includes PR #9750, #9761, #9785, and #9809. PR #9721 has not merged.

Duplicate prospects

The root-cause fix (PR #9809) is merged and live in the sync worker as of the deploy above. The last 3 remaining Western Slope duplicate pairs were collapsed at 7:33 AM MT today, with backups kept; zero duplicate prospect groups remain in Western Slope's data. One thing this can't touch: AppFolio can still create two guest cards for the same person on its own side — that's a duplicate inside AppFolio itself, not something fixable from ours. The replay harness that catches this class of bug going forward (PR #9771) is open, but its own review check is currently failing (red) — not yet mergeable.

Follow-up issues: #9807 (9750 follow-up, backfill terminal no-inquiry-text holds); #9812–#9816 (9809 follow-ups, duplicate-fix defects); #9817–#9824 and #9855 (9771 follow-ups, replay-harness test defects).

What is NOT included tonight

Assigning Clara on the guest card in AppFolio.
Writing notes on the card in AppFolio.
Sending the rental application. The per-property mode setting (PR #9779) merged this morning. The post-tour/on-request trigger wiring (PR #9783) is being moved onto main. The send intent (PR #9780) is merged. The drain step that pushes a queued send through (PR #9784, session 003) has not merged yet. Three more follow-ups were flagged this morning and are tracked as GitHub issues (not yet PRs): #9778 Guest-card outbox drain on a Temporal workflow (durable retries + visibility), #9795 Application link mode select renders unselected state on properties, #9796 Application link recovery window needs comment accuracy. The browser robot's send action itself is live and already proven on one bench card — the "SMS/Email Rental Application Sent" action by Clara PropflowAI in that card's Actions Log — but the trigger chain in front of it isn't wired end to end yet. This also still needs a "Clara" user set up inside Western Slope's own AppFolio account, which is the client's step, not ours. Proof once it ships: pending — no application send has been proven end to end at Willows yet (only the robot's own send action has been bench-proven in isolation); this line updates once the drain step and trigger wiring land and a real end-to-end send is proven.

How to turn on in the morning

Read the proof results above once they land — all three are still pending as of this report.
Set Western Slope's lead-source setting to "AppFolio guest cards."
Flip Western Slope's company live switch on.

How to turn off: flip the live switch off. The effect is immediate — no new replies go out from that moment on.

Known limits

Clara only replies to cards created after the switch is enabled — nothing older gets a first touch.
This covers the first email only. Once a prospect replies, the conversation continues through the existing email lane, unchanged.
Held drafts (from testing, or if the switch is ever off) are reviewable in the prospect's own conversation record in PropFlow — the compose step writes there even when the send never goes out.
The booking-promise guard's replay numbers, from a 30-day test-traffic replay: 1,464 turns checked, 69 where the guard would have changed the reply, 14 true positives (real problems caught), 55 false positives (all on test traffic, not real prospects). Tour-booking proof from the live scheduling workflow: not run yet — pending.
AppFolio's application-send only works if the guest card has an email address on it — no email on the card, no send.
In AppFolio mode, if a prospect stalls after a tour, the post-tour follow-up just stops instead of rewording its ask and trying again the way the email lane does elsewhere.