Job search returns everything: soft-only ranking gives a user no way to exclude

[s-annam]

Problem

Three respondents in the Aug 2026 feedback round independently reported the same thing: the job search returns postings they did not ask for, and nothing they can reach makes it stop.

"when it comes to find jobs all jobs are appearing it doesn't relate to the role we gave"

"when I search for the jobs then it is giving the jobs which I didn't mention in the title for the job"

"It is one of the useful web for the engineering the jobs but some of the one wants to get the jobs for their near locality so provide that"

(Verbatim, apostrophes normalized. No respondent identifiers.)

This is not a defect report — it is the designed behaviour, read back by users as a broken result set. That gap is the issue.

Why the code does this

Every narrowing signal in the ranker is a soft, bounded axis. Nothing is ever dropped.

src/lib/job-search/rank.ts states both cases outright:

• Location ([job-search] No location signal in job query, ranking, or deep links #545) — "a MATCH flag, remote always matching. Feeds a bounded minor axis in rateJobs; a non-local strong fit is never dropped, only edged by an equal-fit local one. No longer a flat sort-key boost ([job-search v3] Location boost dominates fit — a flat +10 outranks the entire fit signal on real data #570)."
• Seniority ([job-search v3] Derived seniority never reaches in-app filtering or ranking; role taxonomy has no level axis #562) — "the ladder-rung DISTANCE between the query's derived level and the posting title's level... Feeds a minor axis; a level mismatch trims the rating a little, it no longer sinks a strong fit."

Both were deliberate corrections (#570 de-boosted location from a sort key; #716 bounded the axes). The consequence users hit is that a query stating a role and a city still returns everything the feed had, reordered.

Hard filters do exist — refineSearchResult (src/lib/job-search/refine.ts) applies role families (#568), exclude terms (#563), target level, comp floor, and location, and re-ranks live with no new fetch. They sit behind the filters step in query-steps.ts:137. No respondent appears to have found them.

The three cases

1. Off-role results (2 respondents). Titles beyond the starred one already narrow locally (matchesQuery in search.ts), but the soft axes mean a poor-fit posting is demoted, never removed. There is no relevance floor and no "hide poor matches" affordance.

2. Near-locality (1 respondent). location is a MATCH flag only — no radius, no local-only mode, no distance model. "Near me" is not expressible.

3. Freshers have no way in (2 respondents).

"As a fresher we don't have any technical work experience so you have to mention what kind of experience"

"the mentioning of work experience must be provided based upon the year"

Seniority is derived from title patterns (SENIORITY_PATTERNS, query-builder.ts), then ordered by the rung ladder in seniority.ts. A candidate with no prior title has nothing to derive from. The ladder has Intern and Junior rungs, but Mid is documented as unreachable — "the current pattern table never emits it" — which shows the title-only derivation is already lossy at the bottom of the range. Years-of-experience is not an input anywhere.

The design question (do not pre-bake)

Three candidate answers, and this issue deliberately does not pick one:

1. Surface what exists — the refine controls already do most of this; the failure may be entirely discoverability. Cheapest, and would resolve cases 1 and 2 with no ranker change.
2. Add a relevance floor — a hard cutoff below which postings are hidden, with a count and a way to see them.
3. Add the missing inputs — a years-of-experience axis feeding seniority when no title implies one; a location mode beyond MATCH.

Run /ui-ux-pro-max before committing to any of them. The likeliest correct answer is (1) plus a narrow slice of (3) for freshers.

Constraints

• Egress is unchanged either way. query-steps.ts:74 states the contract: "Only the starred title is sent to the job feeds. Every other title narrows and ranks the results right here on your device." Filtering is local, so no option here adds a network call. providers/keywords.ts stays the sole resume-derived egress helper.
• Fetch fires only on the Search click. refineSearchResult exists so control edits re-rank without re-fetching (FindJobsPanel docblock). Any new control must go through it, not around it.
• Do not undo [job-search v3] Location boost dominates fit — a flat +10 outranks the entire fit signal on real data #570 / Fitness rating should be absolute, not set-relative #716. Those bounded the axes for a reason — a strong non-local fit outranking a weak local one is correct. The fix is giving the user an explicit way to say "local only", not re-inflating an implicit boost.

Acceptance

• A user who states a role and a location can reach a result set that excludes non-matching postings, in at most one interaction from the results view
• A candidate with no prior job title can express their level and see it change the ranking
• Whatever is hidden is stated as a count and is recoverable — never silently dropped
• Control edits still re-rank through refineSearchResult with no new fetch
• No change to what leaves the browser; work-authorization-egress.test.ts and the keywords egress tests stay green

Non-goals

• No new provider or feed
• No résumé text in the query egress, under any option
• Not a re-litigation of the bounded-axis model ([job-search v3] Location boost dominates fit — a flat +10 outranks the entire fit signal on real data #570, Fitness rating should be absolute, not set-relative #716)

[s-annam]

Prior art — #567 asked this exact question and was closed without answering it.

#567 ([job-search v3] Weak-match display policy — floor for sub-threshold postings) opens with what is effectively this issue's problem statement:

"The panel shows every posting that survives the funnel, in ranked order, with no floor... ordering alone still renders a long tail of weak matches inline, and the panel makes no statement about where 'worth looking at' ends."

It was closed COMPLETED on 2026-07-25 by PR #569 (feat(job-search): rank on honest fit — level, comp, exclusions, specificity). That PR delivered the ranking half of epic #566. The display floor itself did not ship: there is no fold, threshold, or show-all in JobSearchResults.tsx, and no posting-level cutoff in rating.ts. The weak occurrences in the lane are all term-quality.ts skill-chip verdicts, a different concern.

So the floor was not rejected on the merits — it was absorbed into a sibling PR and closed with the epic. Its intended anchor also moved underneath it: #567 specified the threshold as "a single named constant reading #561's number", and #561 shipped as the saturating star rating, which #716 then made a pure per-posting function with no set context.

Why this matters for this issue: the three-way design question above lists a relevance floor as option 2. That option has history — it was specified, scheduled, and lost, and nobody decided against it. Whoever picks this up should read #567 before re-deriving it, and if the floor is again declined, say so explicitly here so the next round doesn't rediscover it a third time.

This does not change the recommendation direction (surfacing the existing refine controls remains the cheapest first move), but it does mean option 2 is a resumption, not a new proposal.

[rohithgollapalli]

Option 2 already shipped — it is not a resumption, and it is not declined.

Picking this up, the first thing to check was the prior-art comment above. It is out of date. The relevance floor is live on main today:

• src/components/features/weakMatchThreshold.ts — WEAK_MATCH_STAR_THRESHOLD = 2.5, keyed on [job-search v3] Fit score is JD-term coverage — rewards thin postings, penalizes well-specified ones #561's star rating so the fold can never disagree with what the card shows, plus a WEAK_MATCH_LABEL derived from the constant so the header cannot drift from the cutoff.
• src/components/features/WeakMatchesSection.tsx — the collapsed tail: Show weak matches (N) — below 2.5★ match, auto-expanded when there are zero strong results so an all-weak set is never empty-by-construction.
• JobSearchResults.tsx splits the page on isWeakMatch and renders both halves.

Both landed in 76c2384 — #569, the same PR the comment credits with delivering only the ranking half. So the comment's "there is no fold, threshold, or show-all in JobSearchResults.tsx, and no posting-level cutoff in rating.ts" is right about rating.ts and wrong about JobSearchResults.tsx. The floor did not get lost; it shipped in the sibling PR alongside the ranking.

Recording that explicitly, per the comment's own request that the next round not rediscover this a third time: the floor exists, at 2.5★, stated as a count, recoverable by disclosure. Nobody needs to re-derive it.

One residual, filed as a note rather than fixed here: JobSearchResults.tsx splits weak from strong within the current page slice, not across the whole ranked set, so the count in the disclosure is per-page. That still satisfies "stated as a count and recoverable", so it is not a blocker — but it is not what the floor reads like it does.

---

A second correction, to this issue's own body.

Hard filters do exist — refineSearchResult (src/lib/job-search/refine.ts) applies role families (#568), exclude terms (#563), target level, comp floor, and location

Only the first two. Before #905, refineSearchResult hard-filtered on role families and exclude terms alone; target level, comp floor and location were passed straight into rankPostings as bounded soft axes and removed nothing. There was no hard location filter anywhere in the tree.

That matters because it moves case 2 out of "discoverability" and into "missing capability": acceptance criterion 1 — "can reach a result set that excludes non-matching postings" — was not reachable by any combination of existing controls, so option 1 alone could not have closed this.

---

What #905 does, for the record: option 1 plus the narrow slice of option 3 the issue predicts.

• A JobResultRefineStrip beside the results carrying location, a local-only toggle, level and exclude — the levers exist, the fold was hiding them.
• JobQuery.locationOnly as an explicit, user-armed hard filter. Deliberately a boolean, not a radius: the predicate is a string comparison over a feed's free-text location field, and a distance model needs a geocoder, which is a network call this app does not make.
• The strip's level control is ungated, unlike the form's AddPill — whose reveal condition ("a level was derived from a title") is exactly the fresher it excludes.

No re-litigation of #570 / #716: every axis's default behaviour is unchanged, and the fix is an explicit lever rather than a re-inflated implicit boost.