`strongMatch` accepts unrelated results for an exact service-name query

[epistemedeus]

Reproduction

Environment: @selat-ai/selat-cli@0.16.15 with bundled @selat-ai/selat-discovery@0.24.8, Node 22.23.2 on Linux.

selat search "SameDayDesk Seller Integrity Audit" --top 20 --json

The free search completed with all eight sources healthy and reported:

• strongMatch: true
• user_summary: "Found 8 services that can do this..."
• 1,302 raw and 1,205 merged services
• eight onTarget results, all unrelated Apify tools
• the top two matched only the token audit with semantic score 0.234
• the remaining six matched only seller with semantic score 0.164

Examples include an SEO crawler, broken-link checker, and Amazon seller scrapers. None is the named service or performs x402 seller-integrity contract auditing. No wallet, initialization, target call, or payment was used.

Expected behavior

When a query looks like an exact branded service name and no catalog record matches the brand or enough of the full intent, the response should not assert that the returned services can do it or set strongMatch: true. A controlled no-match with nearby alternatives would be accurate.

A possible general fix is to require either brand or phrase coverage, or multi-token intent coverage above a threshold, before onTarget results can promote the aggregate to strongMatch. Single generic-token overlap such as audit or seller should remain exploratory.

Why this matters

strongMatch and onTarget are machine-readable admission signals. A buyer agent can otherwise move from an exact requested service to a semantically unrelated paid tool. This also makes catalog-presence and acquisition measurements report a false positive instead of an honest missing listing.

[epistemedeus]

Root-cause follow-up from the published packages:

In @selat-ai/selat-discovery@0.24.8, scripts/lib/rank.mjs currently emits:

onTarget: !!(semantic.strongHit && semantic.score > 0)

semantic.strongHit can become true when one intent token crosses the IDF specificity bar in a strong field. Then scripts/rank.mjs sets strongMatch from whether any onTarget row exists. For this four-token query, a one-token hit on audit or seller is therefore enough to promote unrelated rows.

A broad coverage cutoff is not yet safe. The package's own scripts/lib/rank_eval.mjs previews coverage < 0.6 && padding >= semanticShare, but documents that this would also abstain on the correct StableEnrich result for “answer a question using current web sources.” That suggests the fix needs to distinguish an exact or brand lookup from a generic capability query, rather than tuning one global score threshold to this report.

Suggested acceptance contract:

1. Add a negative fixture for a missing multi-token named service where candidates overlap only one generic token. It must return strongMatch: false.
2. Keep the existing perplexity brand-lookup control and the valid web-search fixtures passing.
3. Make --json emit the controlled no-match summary for the negative fixture.
4. Make --pick and the selat run path refuse the same result unless the caller explicitly pins or forces it.
5. Verify against both the merged CLI corpus and the hosted corpus, since the current eval already records corpus-dependent verdict drift.

The public selat-cli repository wraps the published discovery package, while the package metadata points to SELAT-AI/selat-discovery, which is not currently accessible as a public repository. I did not open a wrapper-only PR because guarding only selat search would leave the paid selat run path inconsistent.