Leasing funnel — why the numbers disagree

Root-cause investigation of Sean's four Phase-1 data-trust items, with live production receipts. Diagnosis only — no code was changed.

Round 2, 2026-08-30 — supersedes round 1 in place · source: Sean's Aug 30 UI feedback · receipts read from propflow-prod, read-only · repo at main

One line per bug

The receipt — one property, one instant, four surfaces

Read from propflow-prod for the one live customer property (1773625953462), by running the repository's own predicates over real rows — loadLeasingStats, loadScopedProspects, foldProspectsToHouseholdRows, prospectPassesDateWindow, countFunnelFlow, pipeline-stage-members. Zero writes. Names, phones and emails were never read into the output; prospect ids are truncated. Re-measured in round 2 and unchanged.

Where Sean's 47 and 6 come from

Round 1 called this "most likely a filter he had set or a moment's drift". That was a guess. It has now been settled by exhausting the page's parameter space.

The sweep

The prospects page has exactly five things a reader can change that move these numbers, and one thing it does unconditionally. All six were enumerated and crossed:

What moves both digits at once

46→47 and 5→6 is one difference, not two, and the mechanism is the one bug 2 is about. Folding a two-person application group removes one household row from the cohort and one application from the tile, because the row folded away is itself an application. Camellia has four application groups; two of them are two-member groups with exactly one member inside the 30-day window at an applied-or-beyond stage. Un-folding either one, at the 30-day window, on today's rows:

Group ids are AppFolio's rentalApplicationGroupId, read off ProspectInquiry.af. The fold rule is prospect-households.ts; the key is (propertyId, af.rentalApplicationGroupId) and nothing else.

The bound on when

The four-tile strip Sean is reading did not exist before 2026-08-25 19:12 UTC — that is the commit that introduced DEFAULT_PROSPECT_LIST_WINDOW and the tiles-plus-funnel layout (e8d90c8514, "Prospects: the tiles stay, and clicking one opens the real funnel"). So his recording lies inside a five-day span, during which the page's default window itself changed three times and the underlying rows changed every day:

Default-window column from git log on tableDefaults.ts. The two count columns are not reconstructed — they are the daily METRIC#YYYY-MM-DD snapshot rows for PROP#1773625953462 in propflow-prod (totalContacts and pendingApplicationsCount), which is real recorded history.

Bug 1 — 35 vs 47 prospects

Where each number is computed

The differing predicate, quoted

Dashboard — prospectsInWindow

return prospects.filter((p) => {
  if (([PROSPECT_STAGE.REJECTED, PROSPECT_STAGE.LEASE_SIGNED] as string[]).includes(p.stage)) {
    return false;
  }
  if (!p.createdAt) return false;
  return inWindow(parseDate(p.createdAt), window);
});

pipeline-stage-members.ts:105-116 — window basis createdAt (row write clock), and two stages excluded outright.

Prospects page — prospectPassesDateWindow

if (prospect.stage === PROSPECT_STAGE.APPLIED) return true;
if (prospect.stage === PROSPECT_STAGE.LEASE_SIGNED) {
  const signedAt = prospect.inquiry?.signedAt ?? prospect.signedAt;
  ...
  return elapsed >= 0 && elapsed <= Number(dateWindow);
}
return isProspectInDateWindow(prospect.lastActivityAt ?? prospect.inquiryDate, dateWindow, now);

prospect-date-window.ts:181-215 — three window bases in one predicate (open applications never age out · signed leads date off their signing stamp · everyone else off latest activity), no stage excluded.

So the two numbers differ on all three axes at once

1. Window basis. createdAt versus lastActivityAt. A lead who inquired in June and is messaging today is inside the prospects page's 30 days and outside the funnel's.
2. Population. The funnel deletes REJECTED and LEASE_SIGNED; the page keeps them. Live now: 3 Camellia rows created inside 30 days sit at those two stages and are silently absent from the funnel's 35.
3. Counting unit. The funnel counts inquiry records; the page counts households (ProspectsClient.tsx:665). Camellia folds 143 records to 138 households; inside the 30-day window it folds 50 records to 46 rows, 4 of them inside Applications.
4. Window length. They do not even nominally agree by default: the funnel card defaults to 3 months (DashboardHome.tsx:696) and the prospects list opens on 60 days (tableDefaults.ts, DEFAULT_PROSPECT_LIST_WINDOW = '60'). Even a reader who correctly assumed one definition would be comparing 90 days to 60.

Bug 2 — 9 applications vs 6, and Sean's hypothesis

"I think it might not be counting the three signed leases as well. So this should, if we got nine applications, this should still say nine and then three have been signed as leases." — Sean, video 1

What actually produces the smaller number

The prospects page counts households; the dashboard counts records. Measured live on Camellia over the same 30-day span:

The repo already names this exact case, three inches from the code that does it:

cohort is HOUSEHOLDS, so these tiles count households: one grouped rental application is one Application, not one per co-signer. That is the point — Camellia read four Applications for two real ones. … SCOPED TO THIS PAGE ON PURPOSE. The shared dashboard/report computations still count RECORDS; the headline-metric decision is open with Fede.
— ProspectsClient.tsx:890-899

A second, unreported defect found while checking this

Bug 3 — the tour that exists in the conversation but not on the profile

This one is a genuine join bug, not a definition difference. The prospect detail page fetches tours with an intersection and then subtracts; the conversation panel beside it fetches with a union. That asymmetry is the whole shape of the bug: the tour is narrated in the thread the page renders, on data the same loader fetched in the same Promise.all.

The failing predicate

const [scoped, siblings] = await Promise.all([
  getTours(prospect.propertyId, prospect.personId),
  loadSiblingInquiries(prospect),
]);
const mine = await recoverMergeStrandedTours(prospect, scoped.filter(...), siblings);
const siblingPinned = pinnedTourIds(siblings);
return mine.filter((t) => t.id === prospect.tourId || !siblingPinned.has(t.id));

load-prospect-detail.ts:346-359 — siblings is every other ProspectInquiry row on the same personId. If a sibling row pins the tour and the row you opened does not, t.id === prospect.tourId is false and siblingPinned.has(t.id) is true, so the tour is filtered out — silently, with no log line.

The prod witness

Camellia has exactly one person carrying more than one inquiry row, and exactly one row whose tour is removed by that subtraction. It is a prospect at stage applied, whose sibling row is at tour_confirmed and holds the tour. That is precisely Sean's description — "he did submit an application… he had a tour scheduled… you can see it in the conversation".

Both rows resolve to the same personId (pers_e8bb…). One Tour row exists on that person: 47337c83…, date=2026-08-29, schedulingState=confirmed, not cancelled, on the correct property. Both inquiry rows carry a conversation. Personal identifiers were not read into the working output and are redacted here.

The production loader, run on both rows

Round 1 could not exercise this — loadProspectDetail refuses a session-less call. Round 2 satisfied the auth envelope with a synthesized platform-staff session and called the real loader, read-only, against propflow-prod. It is the loader itself that drops the tour:

The rendered profile, captured

The detail island was then server-rendered with those exact payloads and the markup reduced to text. Same person, same six conversations, two profiles:

One correction to round 1

Why the section comes back empty rather than showing a placeholder

1. Tours resolve to [] (measured above), so hasTourEvidence is false at ProspectDetailClient.tsx:1013.
2. The placeholder branch is if (!hasTourEvidence && !isPostApplication) (:1030). This prospect has applied, so neither branch fires — zero stage: 'tour' events are emitted.
3. The rail buckets events by stage (prospect-stage-rail.ts:157), so the Tour node has no content, and it reads "Not yet" because :1588 hands hasTourEvidence: false to reachedFunnelStage.
4. The recovery pass next door does not help: its gate is Boolean(prospect.tourId) && !tours.some(...) (load-prospect-detail.ts:460-497) and this row's tourId is null, so it returns early.

Three adjacent defects on the same page, true regardless of the data

• The Tour card is unreachable for anyone who applied. :426 returns 'application' before the tour branch is evaluated. So even with healthy tour data, a toured-then-applied prospect can never show the Tour card. The two renders above are the demonstration: the sibling does get a Tour card, and it is the one that has not applied.
• The Application card renders header-only for lease_signed and rejected. stageHeadlines has entries only for APPLIED and APPROVED; every other content block is separately gated off.
• The "Application Submitted" row has no date when the stamp is missing. It reads prospect.inquiry?.appliedAt only (:1049-1059), and appliedAt is stamped in exactly two places — the PATCH route (route.ts:82-84, which only fires on a move to APPLIED, never a jump straight to approved/lease_signed) and the AppFolio rental-application writer. Live count of Camellia rows at applied/approved/signed/rejected with no stamp: 1.

Bug 4 — the leasing tab

There is no separate computation to find. /leasing renders the same LeasingSection component and the same buildLeasingFunnelInsight spec as the dashboard (leasing/page.tsx:32-37, :63). It inherits bugs 1 and 2 verbatim, and adds one of its own:

So two visually identical "Leasing pipeline" cards print 35 and 130 for the same word, and only one of them offers a control that would let a reader discover why. The labels do carry the window ("Prospects (12 mo)"), which is the only thing keeping this honest rather than false — but Sean read past it, which is the evidence that a suffix is not enough. There is a second, quieter failure mode in the same component: when a windowed field is absent from the payload, LeasingSection.tsx:122-125 falls back to the all-time snapshots (activeLeads, upcomingTours, pendingApplications) — so the same tile can silently switch from a windowed count to an unwindowed one without changing its caption.

Every surface that computes a funnel number

Round 1 reasoned about four surfaces, because four is what Sean could see. That framed the fix as reconciling four call sites. The repository was then swept for every place a prospect, tour, application or signed-lease count is computed or displayed — by predicate name, by field name, and by hunting inline .filter() bodies that duplicate a predicate without importing it.

The canonical library — the thing surfaces either inherit or copy

• pipeline-stage-members.ts:105 prospectsInWindow · :127 applicationsInWindow · :150 applicationsAwaitingInWindow · :173 signedLeasesInWindow · :188 toursInWindow · :205 leadsInWindow
• funnel-reach.ts:145 APPLICATION_REACHED_STAGES · :186 reachedFunnelStage
• funnel-stages.ts:115 countFunnelStages · :246 countFunnelFlow · funnel-outcomes.ts:180 countStageOutcomes
• prospect-date-window.ts:123 isProspectInDateWindow · :181 prospectPassesDateWindow · prospect-households.ts:181 foldProspectsToHouseholdRows

The inventory

Unit is rec = inquiry record, hh = household, unit = deduped target unit, lease/tenant where the row is not a prospect at all. Source is inherits (imports the canonical predicate), own (its own rule, no canonical equivalent), or COPY (duplicates a canonical predicate inline).

The sixteen inline copies

Each of these is a filter body that duplicates a function already exported from the canonical library. Each is a place the numbers can drift again independently, and none of them will fail a test when it does.

Two more things the sweep turned up

• Seven catalogued funnel metrics have no producer at all. applicationsReceived (metric-catalog.ts:1596), funnelContactToTour :1610, funnelTourToApp :1617, funnelAppToSign :1624, funnelOverallConversion :1631, claraToursScheduled :1834, claraLeasesSigned :1841. The names for the conversion rates this whole investigation is about are reserved and empty.
• Neither lambda is a surface. metric-snapshot/handler.ts:31-33 and portfolio-insights-snapshot/handler.ts:35 are pure delegators. There is no funnel arithmetic anywhere under lambda/.

The one canonical definition

Round 1 recommended hoisting one function and pointed four call sites at it. That recommendation was right in kind and an order of magnitude too small in scope. With 61 surfaces and 16 inline copies on the table, "point the call sites at a shared function" is not a refactor anyone finishes in one pass, and a plan that assumes it will is the plan that leaves the next divergence in place.

Three specific fixes that need no decision at all

• The conversion rate that is not a rate. insight-specs.ts:848-853 divides a signedAt-windowed numerator by an appliedAt-windowed denominator. Either count Signed as "applied and signed in the window" so the populations nest, or drop the third percentage the way the first two already were.
• Two identically-named functions with different meanings. toursInWindow means past-and-future in pipeline-stage-members.ts:188 and completed-only in compute.ts:1194. One of them must be renamed whatever else is decided.
• The tour-date field disagreement. lead-funnel-leak.ts windows tours on createdAt (when the row was written) while every other surface uses the tour's own date. That is a defect on any reading of the decisions below.

And a guard, in the same PR as the first wave. Assert that, given one prospect set and one window, every adopted entry point returns equal counts under equal options — the guarantee pipeline-stage-members.ts already gives between a badge and its drill-down, extended across surfaces. Without it, wave 2 and wave 3 will re-diverge before they are reached: that is exactly how sixteen inline copies came to exist next to a library written to prevent them.

What a human must decide

The implementer cannot pick these. Each is being raised as its own decision block; All four are now open on the Decisions tab, batched into three blocks — (2) and (3) are one question, since the window basis settles the terminal-stage rule.

Bug 3 needs no decision — the sibling-pin subtraction, the Tour card that is unreachable for anyone who applied, and the unstamped appliedAt are defects on any reading and can be fixed immediately. So can the three items under "no decision at all" above.

Method, and what could not be verified

Round 1 published 2026-08-30; round 2 supersedes it in place at the same URL. Freeze mode: diagnosis only, no source changed. Implementation is a separate effort.