Compset Discovery Audit: Compsets > My Compset

The scoring library's own header states the invariant: missing data must never outscore honest unfavorable data on the same brick. It is violated twice. Under the lender persona, a candidate with an unknown chain scale scores 5 points while an honest one-tier-off comp scores 4. On the new stay-mix brick, a candidate with no stay data scores 10 points while an honest large-mismatch operator (0.28 non-tax-share gap) scores 8. Both were confirmed by executing the deployed scoring functions directly. Effect: hotels with data holes rank above honestly mismatched hotels and can flip who makes the recommended core. Roughly 4.6% of the candidate pool (193 of 4,232 STR summary rows) rides the missing-data default today.

On the live HOUZN page, current member Staybridge Suites Houston Willowbrook shows score 0/100, no rank, 0.00 mi, and the new stay strip counts it as "1 unknown". The engine never scored it: its STR summary row is marked status: inactive, which excludes it from the candidate universe, even though it filed 12 consecutive months of receipts through 2026-06 totaling $2,108,158 TTM. The wrong status is almost certainly an ownership-transition artifact (its merged hotel rows carry two different taxpayer numbers). Three separate lies land on screen from one root cause: a fake zero score, a fake 0.00 mi distance, and a footer count ("7 currently in compset") that contradicts the members table ("8 peers").

Today's stay-mix commit changed the batch pipeline to classify product type from brand_name || canonical_name, but the deal-compset edge function (which imports the same "single source of truth" library and carries a "keep in sync" comment) still passes brand_name only. A hotel with a null brand but a brand-bearing name (e.g. "Homewood Suites ...") scores the full 15-point product brick in the nightly batch and 0 in the deal path.

The lender persona can append up to 2 members to push RGI into the 105-125 band. Those additions are checked for tract, size, correlation, value, and tier, but not for the STR concentration rules (single property ≤ 50%, brand ≤ 50%, parent ≤ 70%). Worse, the cached compliance_by_persona is snapshotted before band-seek runs, so the UI can show a green "all five rules pass" badge on a lender set that violates rule 3.

The STR upload reconcile writes the subject hotel into its own compset as an active member. The dashboard drift metric counts all active members, but the engine excludes the subject from its universe, so the subject can never be a "top-7 pick" and every self-including compset takes an automatic drift hit. Recomputed both ways from live data: HOURP reads 13% drift but is truly 0%; CFDBR and CLLUD read 40% vs a true 25%; CLLSP 33% vs 20%; HOUZN 33% vs 25%. Four properties wear a drift badge one severity band too alarming.

The Discovery tab has loading and empty branches but no error branch. Any RLS, network, or PostgREST failure renders "Discovery has not been computed for X yet ... appears within a day", a false factual claim. The compset list page does the same: a metrics query error silently renders every RGI/MPI/ARI as a dash, indistinguishable from genuinely missing data.

The Add and Watchlist mutations do bare INSERTs into compset_members, which has a unique constraint on (compset_id, hotel_id). Hotels dropped by an earlier STR reconcile still have a row (status "watch", reason "dropped from STR upload"), and they render as suggested cards with live Add buttons. One click surfaces a raw Postgres duplicate-key error in the toast. Freshly staged adds have the same trap: the overlay only fetches active and watch rows, so a hotel just staged with status "add" keeps offering "+ Add", and the second click hits the same crash.

On the live HOUZN view, the persona pills read "RGI 108", which is the recommended set's implied RGI, with no qualifier on screen. The swap line says "your index vs the set 112 → 108 (tax-receipt basis)", the current set. The list page says RGI 112.3, from the Jun 2026 STAR report. Same word, three bases, only one of them labeled. An owner glancing at the pills reads their RGI as 4 points lower than it is.

The Discovery tab receives the viewed compset's id but ignores it; mutations resolve the target as the most recent compset for the property code, while the membership badges read the viewed compset. Today no subject has two compsets so it works by coincidence; the day one does (e.g. a deal compset alongside the operating one), adds land in the wrong set with no error.