How the matcher works

1. Parse. The message becomes structured JSON: firm filters (budget with an explicit stretch rule, beds/rooms/baths, type, area, must-haves, commute, HOA / vaad bayit) and weighted soft wishes. Each market has its own lexicon: Israel reads shekel budgets ("under 3.5 million shekels", "₪4.2m", "NIS 2,800,000"), Israeli room counts (a 4-room apartment is 3 bedrooms + living room), km, and must-haves like a mamad (safe room), parking, a Shabbat elevator or a sukkah balcony; United States reads $ budgets, beds and miles. This demo uses a deterministic rule + lexicon parser; the API can use an LLM instead, with the same JSON schema enforced and the rules as fallback.
2. Filter. The structured plugin turns firm filters into a SQL WHERE clause (SQLite/Postgres in the API, the same rule spec evaluated in JS here). Nothing over budget or short on bedrooms can reach the matches list. Listings that miss exactly one filter by a little are shown apart as near misses, with the reason.
3. Rank. Plugins are picked by data type: vector (MiniLM embeddings over description sentences and neighborhood blurbs) for wishes like "quiet street"; keyword/BM25 for exact amenities and proper nouns like a school name; geo for "near the marina" or "within 2 miles of the park"; and field checks where a column already holds the answer (school rating, yard size). Their scores are fused per wish.
4. Explain and qualify. Each match shows which firm filters it passed and how strongly each wish matched, with the evidence. The lead gets a score, follow-up questions for missing info and a CRM-ready JSON payload. Nothing is sent anywhere in this demo.