Idea: shift job matching from title-lookalike matching to 'could this person's experience solve the employer's problem' matching

[197281t-ship-it]

Ran /scrape against my own profile (15+ years immunology/flow cytometry, PhD, core facility leadership, PI on a grant, biomarker assay development at a CRO) and the top result the system converged on was Medical Science Liaison roles.

MSL is a defensible inference — PhD + immunology + strong communication + wants industry does point that direction. But it throws away most of my actual career capital: platform ownership, assay strategy, research leadership, grant/PI work, staff management. It also walks me straight into the one thing I'm weakest on by conventional ATS standards (prior MSL/pharma experience), while several MSL postings carry 60–75% travel.

I think the underlying issue is that the matching logic is doing something like "find the closest known job-title box for this CV" rather than "find organizations that need someone who can do what this person has actually been doing." A career that spans immunologist + cytometrist + core administrator + PI + scientific manager + biomarker scientist doesn't fit one box — the intersection across all of them is the actual asset, and a title-matching approach keeps shaving pieces off until it lands on something familiar.

As a calibration example: AbbVie's (now-expired) Scientific Director, Precision Medicine Immunology posting in North Chicago — owning translational/biomarker strategy, managing assay development and CRO validation, leading cross-functional translational teams, working with KOLs, flow cytometry listed as desirable — is a far closer match to my actual background than MSL is, even though I've never held that title either. (https://careers.abbvie.com/en/job/scientific-director-precision-medicine-immunology-in-north-chicago-il-jid-6059)

Concretely, I'd propose:

1. Changing the instruction framing from "find jobs I qualify for based on my CV" to "identify jobs where my accumulated experience could plausibly solve the employer's problem, even when my titles don't match the posting's title."

2. Letting users define target "lanes" by function rather than by title — in my case, translational scientific leadership, principal-level scientific roles, core-facility/platform leadership, scientific-affairs-at-a-vendor, and program/portfolio scientific leadership, roughly in that priority order, with MSL demoted to a secondary lane rather than the default landing spot.

3. Making the scoring rubric explicit and user-editable, with a clear split between things that should be penalized (excessive travel, explicit prior-title requirements, sales quota ownership, roles clearly below current seniority) versus things that get over-penalized today but shouldn't automatically be disqualifying (e.g. "pharma experience preferred" shouldn't auto-reject someone whose academic/CRO experience is arguably equivalent).

Happy to share the specific weighting scheme I ended up hand-writing for my own fork if it's useful as a starting template for a more general "define your own lanes and weights" feature.

[MadsLorentzen]

Verified against the actual files before answering, and your diagnosis is right - and lands one layer higher than you aimed it. /setup's search-configuration step literally asks "What job titles should I search for?" (Section 9), those titles become the priority query categories in search-queries.md, and /scrape runs the top categories. The title-box convergence is baked in at onboarding: the scoring rubric downstream never even sees the postings your functional lanes would have surfaced, because the queries never fetched them.

Which is also why two of your three proposals exist already, structurally:

• The rubric is yours to edit. 04-job-evaluation.md is a personalized framework file, same class as your profile. Its Experience dimension already scores "related experience, transferable skills clear" and "adjacent, would need to make the case" rather than gating on title identity, and heavy travel is already a FLAG (surface and ask), not an auto-reject - the same penalize-vs-flag split you propose in point 3, which is this framework's standing design (the Language Gate works identically: FAIL only on hard absence, FLAG anything judgment-shaped). If 60-75%-travel MSL postings reached your shortlist unflagged, that's a real bug - report it separately and I'll chase it.
• Lanes exist structurally but not conceptually. Your five lanes are exactly what the priority query categories are for - /scrape runs the top 3 by default, in order. You can rewrite yours today as functions rather than titles, with title-shaped strings demoted to search terms under each. Nothing stops you; the problem is that nothing told you.

That last clause is the real defect, and it's upstream-worthy: the framing. Three concrete edits, all market-agnostic - (1) /setup Section 9 asks for functions or role families first and title search-terms under each, instead of leading with "what job titles"; (2) search-queries.md's category guidance says to write categories by function; (3) 04's Experience dimension gains your one-line framing - "could this person's accumulated experience solve the employer's problem, even where titles don't match". PR invited if you want to write it - your AbbVie-vs-MSL example is the perfect motivating case for the docs. Otherwise it goes on the maintainer list.

And yes - share the weighting scheme. A gist linked from here is ideal; if it generalizes, it could inform a "define your own lanes and weights" section in 04, and other forks would use it tomorrow.