Lead to home matching: Ember Estates miss

Proof of concept: how often each set of matching rules finds the right home, over a year of real leads

Withdrawn Oct 28 evening. The numbers in this table and the "What it means" paragraph below were a text-only simulation scored on rows that do not occur in production; see Second pass. Kept for the record only.

What it means: 416 of the 916 leads (45%) are guest cards whose text names no home at all ("can I schedule a time to see this?"). Those are not a matching problem: AppFolio already filed each card under its property and that is where the home comes from. Of the 500 leads whose words do name a home, the rules find it for 92%, up from 47% today, and never pick a wrong home. The 41 still open: 13 land on an Ember sibling (the Ember decision), 20 name nothing specific ("the 205 floor plan", "Lakewood, CO 80214"), 4 carry a Zumper listing id no past card taught us, 2 need an alias we do not have, 2 have unknown truth.

Second pass, Oct 28 evening: the prototype numbers are withdrawn

Fede's read: guest cards arrive with the home, and Clara is handed the property, so no lookup is needed. An independent pass over the real data confirmed it. The earlier numbers scored text-only rows that never occur in production.

Real failures: 30 leads

The known misses on this page, checked one by one

Of 38 "known misses", 8 were real events. 6 of those are the same mistake. The "251 known misses, 93% missed" counted test rows, not leads.

The simplest design

• Card: the card's property is the answer, never a lookup. Unit = AppFolio's unit id, else the exact label, else "this property's open homes". Hand unit streets with the home facts.
• Existing thread: the thread's property. Application and other tools take the thread's property and unit, never a text reference. Search only when the thread has no property.
• Email: mailbox binding first; then subject and body through one address list. The two drop rules exempt known lead relays.
• A search miss on a thread that has a property: internal alert, answer from the property. Never a staff email.
• No alias confirmation step, no eight-layer cascade.

Throw out, keep

Throw out: the 916-row "right home" rate (26% to 50%), the 251-row "known misses" rate, the Situs router 35 of 48. Keep: the 38 cases as a regression list split real / simulated / synthetic, the 50 of 53 email filing number, and the mirror and unit facts.

Report: /Users/federicochapa/agents/003/reports/Lead-to-home failures second pass 2026-10-28.md. Scripts 01 to 08 in resolver-poc/second-pass/.

Percent of 916 leads: 974 real leads and named cases at Western Slope, Situs and JP&Co, minus JP&Co's 58 emails (the mailbox already files them; the new name rule matches all 58). Known misses: percent of the 251 still missed today. 13 Ember parent-or-sibling picks count as neither right nor wrong. Source: resolver-poc/summary-for-fede.md.

Replay of today's live matching code, with and without the chosen fix (simulated)

Source: property-locate/results/before-2026-10-28.md. Detail in section 6 and section 7.

1. Decided (Fede, Oct 28): a search miss is our bug. It raises an internal alert and Clara answers from the card's property; never a question to client staff.
2. Pick A, decided (Fede, Oct 28, "ok"): one alias list for every channel, filled automatically from building, unit and listing addresses plus listing ids; ids first, words last. Loosened name rules (A1) stay in as a late fallback (Fede: "I think it's a good last fallback"). No paid address service (A5) for now (Fede: "no, this not yet"). The proof of concept and the harness are done (Oct 28): Pick A stays, with two amendments (see Results).
3. Pick C, first email: one home, its live listing price, or no price.
4. Decided (Fede, Oct 28, "we don't want a human there"): the alias system's "suggested, waiting for a person to confirm" step is removed. "2858 C 1/2 Rd" had been learned twice at Western Slope and sat unconfirmed because no person was ever in that loop. Sync-built aliases are active on arrival; a learned phrase is confirmed by the engine from evidence (the card it arrived on already names the property), never by a click.

Acceptance bar (Fede, Oct 28): "whatever solution here needs to cover 100% of the misses": every known miss resolves to the right property and the full year's corpus shows zero wrong matches, before any code ships. Known misses include Ember "2858 C 1/2 Rd" (Oct 12, Oct 26, Oct 28), Northridge "575 / 585 Redcliff Cir" vs stored 565 (Oct 7, Oct 28), Flats on Elm "1250 Elm Avenue" vs stored 1240, and Aspen Leaf, Lampliter and Olde Town Terrace at Situs. All five Western Slope cases sat on threads that already carried the right property.

Where it stands (Oct 28): not met. With Pick A planted, 10 of 16 known misses still fail on their own channel (9 of them on email filing) and false matches stay at 0; the proof of concept leaves 2 of 251 unreached. Detail in sections 6 and 7.

The fix spans Western Slope and Situs and every channel (email, text, phone). The existing pages are closed incident write-ups (Ember Estates, September) and a Situs-only report.

Micheal M. asked on Zillow about "2858 C 1/2 Rd, Grand Junction". No email reached us: AppFolio created guest card 3053 and filed it on Ember Estates itself. Clara's reply ran on Ember Estates. Inside that reply she searched for the address, nothing matched, and she treated it as a home we might not manage.

Ember Estates has two addresses. Our building record holds one; the other sits on two of its unit records, where the search never looks.

Related, not the center: Situs email leads are filed by a different matcher that does not read the alias list either; "Aspen Leaf Apartments" missed "Aspen Leaf" on Oct 27 (harness).

How Clara turns the words in a lead into one of our properties, and the options we weighed.

Oct 28 results: Pick A stays decided, with two amendments: the mailbox router reads the same alias list, and one twin rule for a home that is both a unit and its own record (sections 6 and 7).

Matching lives in the PMS adapter layer behind a written interface. Core flows never name AppFolio; listing ids are stored with a provider prefix.

Cells are reasoned, not measured, except one: harness control C1 shows an active "2858 C 1/2 Rd" street name finds Ember Estates with today's code. A1 to A5 come from the 003 Situs report; A6 is new here.

"so this is first bug. we should not email the customer this is an engineering bug."

Fede, Oct 28

Decided by Fede, Oct 28 The fix is owned by another session; this page does not open it.

Your 10/22 rule: never over-share availability. This case adds: never a delisted home's price.

Which matching rules we need: we ran each rule over a year of real leads and kept the ones that add right homes without ever picking a wrong one. Prototype only: local, read-only, no repo change, no CI. Every matching layer was run alone and stacked over 974 real leads and named cases at all three customers.

Withdrawn Oct 28 evening. The numbers in this table and the "What it means" paragraph below were a text-only simulation scored on rows that do not occur in production; see Second pass. Kept for the record only.

What it means: 416 of the 916 leads (45%) are guest cards whose text names no home at all ("can I schedule a time to see this?"). Those are not a matching problem: AppFolio already filed each card under its property and that is where the home comes from. Of the 500 leads whose words do name a home, the rules find it for 92%, up from 47% today, and never pick a wrong home. The 41 still open: 13 land on an Ember sibling (the Ember decision), 20 name nothing specific ("the 205 floor plan", "Lakewood, CO 80214"), 4 carry a Zumper listing id no past card taught us, 2 need an alias we do not have, 2 have unknown truth.

Percent of 916 leads (974 minus JP&Co's 58 emails, left out above); known misses as a percent of 251. The table below counts JP&Co's emails, which is why its totals (240 / 523 / 530) are higher.

Per customer and channel (rows whose words name a place)

* Simulated without the per-building mailbox step; production files these by mailbox today. 0 regressions against today.

Keep: 7 layers, in this order (each adds leads, none picks a wrong home)

1. Link ids learned from past guest cards (Zumper building and listing ids, padmapper ids, Zillow building links). 12 leads nothing else gets, including Balsam Manor = Barcelona. L1z
2. Exact aliases built at sync, including every unit's street. Renters type a unit's street while the building is filed under another (Ember, Northridge, Lampliter, Barcelona, Lowry Flats). First rule to fire on 355 rows; fixes most misses. L2
3. Loose address match plus one-letter typos ("Radcliff", "Aspenleaf", "Richtofen"). L3 + L3t
4. One-word building names ("Camellia House", "Zephyr 10", "Dahlia #10"), with a guard for words that are also states, streets or cities. 38 rows only this gets; all 58 JP&Co emails. L3b + L3n
5. Unit labels like "585-201": 7 Northridge leads. L3u
6. Street-only match, as the last rule ("3295 S Bryant", "1391 Zephyr"). L3s
7. The model, last, on leftovers only: +3 (Lamplighter twice, Old Town Terrace). L5h

Design note: layer 4 extends the name rule in PR #22994 rather than replacing it (the widened rule covers every row the PR's rule gets but one).

Not worth it

• Free geocoding: adds 0 leads the rules miss; 143 answers land on several homes within 150 m of each other.
• Model first: 3 wrong homes ("2984 Emerald" read as 2982). The rules made none.
• Zillow home ids: zero rows carry one.

The 2 misses nothing reaches

• "IH Holdings Nineteen LLC": the owner's legal name; Situs data never links it to Barcelona.
• "Balsam Manor" typed as words, no link: Zumper's own name for Barcelona (the link form is solved by layer 1).

Both need a name alias on the property. That is a knowledge-base write, so it is Fede's call (open ask 4).

All aliases are built in the PMS adapter at sync; core code only asks "which home?". Sources: scratchpad/resolver-poc/summary-for-fede.md and results.md (session 003).

Where today's live code fails, and how much the chosen fix would help. Local replay of today's production matching code over snapshots of each customer and a year of guest cards. No model, no sends, never CI. Each lead's words are read through four channels: Clara's in-reply search, a tool naming a home, the scan over the renter's message, and the company-mailbox router.

"Pick A planted" re-runs each row with the expected alias list added as active rows. It is a model of Pick A, recorded, never counted as a pass. All 16 planted-defect controls behave.

By family

F6 (do channels agree on the same words) is rendered from F0 to F3: known misses disagree across channels in 24 of 38 cases today, 13 with Pick A planted.

What the run says about Pick A

• The mailbox router never reads aliases. Every email-filing number is the same with and without the alias list (15 of 56 rows). It also misses exact stored names: 17 of 20 name rows, mostly "Lampliter Apartments", file on the front door. Amendment 1.
• Twins. With aliases planted, the text scan sees two records for one Ember home and picks neither: 6 rows go from right to none. Amendment 2: one rule for a home that is both a unit and its own record.
• Misspellings, "C ½" spellings and Zumper links stay red with aliases ("Lamplighter", "Car Street Flats", "Aspenleaf", "Old Town Terrace", "Brian Gardens", "Radcliff"). They need the late fallback (A1) or link ids.
• Decision 1 timing. On Oct 28 the staff note went 2 seconds before the email that answered in full. A check only at the end of the turn is not enough: the note has to wait for the final reply, or a miss never stages a team note at all.
• 1456 Bunting Ave is Lincoln Apartments (four unit rows), not a home outside our list. A label error the run found and fixed.

Data limits

• Guest cards cover one year (2,894 inquiries); about 12% (349) carry the renter's own words.
• Western Slope emails start Sep 15; Situs emails cover Oct 23 to 28 only (source: resolver-poc/results.md).
• Email bodies are not stored, so email leads are read by subject line only.

The morning seed suite (13 cases) still reads 5 of 12 right; its 7 controls behave. Branch fede/lead-home-matching-harness, head 7bf80bddb0, local only, no PR. The harness session's instruction: squash before any push, because earlier local commits hold real first names and one renter surname in the name checks. Sources: property-locate/HARNESS.md and results/before-2026-10-28.md.

Open, Fede's pick This is separate from the matching decision. Matching finds the property; this is which copy of a home is the record.

Western Slope holds each of the 27 Ember homes twice: once as a unit of Ember Estates (the portfolio, property 399) and once as its own single-family property. Both copies come straight from AppFolio.

The right answer on Oct 28

Gaps in the Oct 19 cross-check

• Lettered house numbers never match (2860A, 2860B, 2862A, 2862B, 2866A, 2866B, 2868A, 2868B: 8 homes). If one gets a lease, its portfolio row still reads open. All 8 are vacant today.
• One-way only. The single-family copies still count as separate open homes at their own price (363 Ember is $2,825 on its own record vs $2,550 listed). Whether Clara has quoted one: not checked.

Other customers. Situs has the same shape: its "DU Portfolio" (property 43) holds 17 rows; 16 of those houses are occupied or pre-leased (14 occupied, 2 marked vacant-rented). 2281 S Lafayette reads open at $2,500 because "S." breaks the match, though its house is occupied (whether offered: not checked). JP&Co: none.

In every option the link is made at the PMS sync boundary (the adapter), never in core flows, and a row that does not link cleanly stays visibly unresolved. Source: research_notes/Ember Estates property addresses/ember_double_representation.md (read-only, Oct 28).