Removing AI inference from experience scoring
Methodology version 2.0 of the Luminid Role Match shipped in May 2026. The change it made to the formula was significant. Experience scoring, weighted at 20% of the Role Match, where the system would have inferred whether a candidate's prior job history made them a likely fit for a role, was removed entirely. Education scoring, weighted at an additional 15%, was removed. Language self-declarations were removed. The Role Match now reflects demonstrated skills and simulation performance only.
This post is the story of why we made that change, what we kept, and what we learned about how AI should be constrained in hiring.
What the earlier version would have done
Methodology version 1.0 was a specification, not a deployment. It defined how the Role Match would be computed if the platform launched with the design we had on paper. The earlier formula included a component for experience scoring, weighted at 20% of the Role Match. The intent was reasonable on its face: candidates with directly relevant prior experience should rank higher than candidates without it, all else being equal.
The implementation of this component was where the problem started. Experience scoring requires the system to interpret the candidate's job history. A candidate's resume lists job titles, employers, dates, and brief descriptions. None of that translates directly into "this candidate has X years of experience doing the kind of work this role requires." To get from a resume to an experience score, the system has to make inferences. It has to decide what counts as relevant experience for this role. It has to weigh the recency and depth of that experience. It has to handle the cases where the candidate's titles do not match the role's title even when the underlying work is the same.
The natural way to do this with current technology is to use a language model. The candidate's job history goes in. A score comes out. The model has interpreted the experience in light of the role.
We scaffolded the infrastructure for it. We never deployed it.
Why we stopped
Three reasons, in order of how much they weighed on the decision.
First, the inference was the most likely place for bias to enter the score. The candidate's job history is full of signals that correlate with protected demographic characteristics. The names of their employers. The names of their schools (when listed). The pattern of their career trajectory. The gaps in their employment. A language model asked to score experience relevance is also implicitly making judgments about all of this, because there is no clean way to separate "this candidate has relevant experience" from "this candidate's career looks like a successful career to the model."
The other components of the Role Match (skills demonstrated in simulations, simulation overall performance) are scored against narrow construct maps with cited evidence. Experience scoring could not be constrained that way. The construct being scored (career relevance) is too broad to operationalize cleanly.
Second, the inference duplicated work we did not need to do. The point of Luminid is that work-sample simulations predict job performance at 0.54, while resume signals like experience predict at 0.18. We were spending effort to compute a signal that was much weaker than the signal we already had. The simulation already told us what we needed to know. The experience inference was adding noise weighted at 20% of a score that was supposed to be based on demonstrated capability.
Third, the regulatory environment for AI-assisted hiring is changing. Jurisdictions are increasingly requiring that AI-assisted hiring tools be auditable, transparent, and able to justify their scoring decisions on grounds that are not vulnerable to disparate impact claims. An AI experience inference that produces a score with no clear evidence chain back to the candidate's actual capabilities is exactly the kind of feature that creates compliance risk under emerging frameworks. The methodology argument and the regulatory argument pointed the same direction.
What we kept
Removing AI inference from experience scoring does not mean removing experience from the platform.
Experience appears on every candidate profile. Recruiters see it. They can read it, evaluate it themselves, and weigh it against the Role Match number as they see fit. The same is true for education, certifications, and uploaded portfolio items. The platform makes the candidate's full background visible. It just does not score it.
This distinction matters. Luminid is not anti-experience or anti-credentials. We are anti-using-credentials-as-a-replacement-for-demonstrated-capability. A recruiter who looks at two candidates with similar Role Match scores and chooses the one with more relevant experience is making a reasonable human judgment. The system supports that judgment by showing experience clearly. What the system does not do is bake that judgment into a number that pretends to be objective.
We also kept knockouts. A recruiter can require, for a specific role, a specific credential or qualification (a professional license, work authorization in a specific country, a specific language at a specific level) as a binary knockout. The candidate either meets the knockout or does not. The knockout is recorded honestly. It is not an experience inference; it is a binary qualification check.
What this taught us
The most important thing we learned was this: every place where AI infers something about a candidate is a place where the methodology has a hole.
AI scoring of work samples is defensible because the construct map specifies what is being measured, the evidence is cited from the candidate's own work, and the methodology can be audited and validated against outcomes. AI inference about a candidate's career is not defensible in the same way. There is no construct map for "career relevance" that can be operationalized cleanly. The evidence is the candidate's resume, which is itself a weak signal. The validation against outcomes is not possible because the inference is not specific enough to test.
This principle is now structural in how Luminid is built. We use AI in places where it can be constrained, audited, and validated. We do not use it in places where it would have to make holistic judgments about a candidate as a person. The Role Match formula reflects this constraint. The methodology page documents it. Future architectural decisions will be made the same way.
Methodology 2.0 is what this principle looks like in practice. The Role Match is narrower. The methodology is more defensible. The platform does less, and what it does, it does with evidence.
That is the trade we made. We will not be the last hiring vendor to make it.
Luminid is the verified hiring platform. The methodology is at /methodology. Material changes are tracked at /changelog.