explorer: free-text search does not filter the main samples table — "N match the current filters" shows unrelated samples (A1 gap)

[rdhyee]

Summary

A free-text search (e.g. bucchero) leaves the main "Samples table" and its "N samples match the current filters" count showing samples that have nothing to do with the search term. The search box flies the camera to the right place and the side-panel list shows the correct hits, but the most prominent results surface — the table under the map — fills with whatever happens to be in the new viewport. The label "match the current filters" is actively misleading, because the search term is not one of the filters.

This is a concrete, user-facing instance of the A2 → A1 gap already captured architecturally in #234 (roadmap Step 4 / A1: "search as global filter"). Filing as a standalone reproducible bug so there's something crisp to point at and verify a fix against.

Reproduction

URL (production):

https://isamples.org/explorer.html?search=bucchero&sources=OPENCONTEXT%2CGEOME%2CSMITHSONIAN#v=1&lat=40.8958&lng=5.2905&alt=3048966

(bucchero = Etruscan pottery; the canonical site is Poggio Civitate / Murlo, Tuscany.)

Observed once loaded:

Surface	Result	Correct?
Camera	Flies to Poggio Civitate / Murlo, Tuscany (≈43.15, 11.40)	✅
Side-panel list (samplesSection, right column, below the fold)	Top-50 = OpenContext "Pottery PC…/Object PC…" — genuine bucchero finds, all at (43.15, 11.40)	✅ but easy to miss
Search-results line	50 of 2,693 results for "bucchero"	✅
Main "Samples table" (the big one under the map)	"43,803 samples match the current filters", every visible row a GEOME marine mollusk (Turritella, Cerithium, Bittium) in the Tyrrhenian Sea. 0 rows are bucchero.	❌

So a user who types bucchero and looks at the obvious results table sees 43,803 sea snails described as matching their filters.

Root cause

The main table + its count are driven by loadCount() / loadPage() (explorer.qmd, ~L2091–2155). Their WHERE clause is only:

WHERE pid IS NOT NULL
  ${sourceFilterSQL('source')}   -- source checkboxes
  ${facetFilterSQL()}            -- material / context / object_type
  ${bboxSQL}                     -- viewport

There is no searchWhere. The text term lives entirely in a separate code path (doSearch, ~L3850+) that only (a) flies the camera and (b) paints the side-panel samplesSection list. After the fly, the table reloads for the new viewport — around Tuscany that's dominated by GEOME mollusk samples — and reports them as "matching the current filters."

summaryText() (~L2157) hard-codes the phrase "…match the current filters." regardless of whether a search is active, so the wording asserts a relationship that doesn't hold.

This is the same coherence family as the recent #234 Step 3 / B1 work (which aligned the facet legend, table count, point loader, and heatmap on a shared viewport bbox) — but none of those surfaces incorporate the search term. Per #234's own constraint table, "Search text" is ✅ only for the search-results line and ❌ for Map / Stats / Table / facet counts.

Severity / impact

• High confusion, low data-integrity risk. Nothing is computed wrong; the surfaces are just answering different questions while sharing one label.
• Especially bad for spatially-concentrated terms (archaeological types like bucchero) where the camera fly relocates the viewport over an unrelated dense source, so the mismatch is maximal and reads as "the search returned sea snails."

Suggested fixes (in rough order of correctness vs. effort)

1. Real fix — implement explorer: architectural direction — make filter semantics coherent across all surfaces #234 Step 4 (A1). Thread searchWhere into loadCount / loadPage (and ideally the globe), so table + count + dots all reflect the search term. Biggest behavior change; note explorer: architectural direction — make filter semantics coherent across all surfaces #234 open question Use fixed width font for displaying records #4 flags that folding ILIKE into every count query may want the FTS substrate (Explorer FTS Track 1b: Honesty fix for query-spec / live mismatch #168–Explorer FTS Track 5: GO/NO-GO decision gate #172) first for scale.
2. Interim honesty fix (cheap). When a search is active, stop claiming the viewport table "matches the current filters" — relabel it (e.g. "samples in this view — your search results are in the panel →") and/or surface the side-panel results more prominently. Removes the false assertion without the SQL surgery.
3. Promote the side list. The correct results already exist in samplesSection; auto-scroll/expose them on search so they aren't lost below the fold.

Recommendation: ship the interim honesty fix (2/3) now to stop the active misinformation, and schedule A1 (1) as the durable fix under #234.

Cross-refs

• explorer: architectural direction — make filter semantics coherent across all surfaces #234 — architectural umbrella; this is roadmap Step 4 / axis A1 ("search as global filter"). Lists this exact confusion ("I have pottery Cyprus in the search box but the facet counts and 'Samples in View' don't reflect it").
• Explorer state contract: URL/DOM/widget-state inventory + search-as-global-filter decision #164 — state contract / search-as-global-filter decision.
• Explorer FTS Track 1b: Honesty fix for query-spec / live mismatch #168–Explorer FTS Track 5: GO/NO-GO decision gate #172 — FTS substrate (may gate a scalable A1).

---

Diagnosed via live inspection of production isamples.org/explorer.html + code read of explorer.qmd.

[rdhyee]

Question raised (RY)

Should this be fixed ad hoc, or as part of the big coherence drive we're currently on (#234)? And is this actually a problem with our full-text search machinery — if we search for bucchero, can we get a clean query with the right answer?

Analysis

This is not an FTS-machinery problem. The search substrate produces a clean, correct answer:

• 50 of 2,693 results for "bucchero"
• Top-50 (side panel) are all genuine OpenContext bucchero finds — "Pottery PC…", "Object PC…", every one at (43.15, 11.40) = Poggio Civitate / Murlo, the canonical Etruscan bucchero site.

The searchWhere predicate (ILIKE '%bucchero%' over label / description / place_name, weighted-relevance ranked) runs correctly in doSearch. bucchero is a distinctive token, so substring false positives are very unlikely (top-50 + count verified; not all 2,693 enumerated, but the query shape is sound). The defect is purely a wiring gap — that correct predicate is applied only to the search-results list and is simply absent from the SQL behind the main table, the count line, and the globe. Nothing is computed wrong; three surfaces answer different questions under one label.

So the fix cleaves along the same seam:

Part	Where it belongs
Make search actually filter the table / globe / counts	Big drive — this is #234 Step 4 / axis A1. Touches every count surface; #234 OQ4 flags it may want the FTS substrate (#168–172) first so per-count re-scans stay cheap at scale.
Stop the misleading "N samples match the current filters" when a search is active (relabel + promote the side-panel results)	Ad hoc, now — pure copy/UX change in summaryText() (+ optionally auto-exposing samplesSection). No SQL surgery, no substrate dependency.

Recommendation: don't pull the behavioral A1 fix out of sequence (risk of doing it without the substrate and redoing it). But ship the cheap honesty fix as a standalone small PR now, because A1 is far enough out that leaving "43,803 sea snails match your bucchero search" live is its own small embarrassment.

[rdhyee]

Interim honesty fix opened as #250 (head rdhyee:fix/search-table-meta-honesty) and live on rdhyee staging. Real fix (search as a global filter) remains #234 Step 4 / A1.