How Luminid evaluates candidates

How Luminid evaluates candidates

Methodology version 2.0

Luminid exists to give people a fairer chance at work.

Luminid is a verified hiring platform. We replace resume screening with work-sample evaluation so recruiters can decide based on what candidates have demonstrated, not what their resumes claim.

Verified hiring is the category Luminid creates. The Spanish equivalent is reclutamiento verificado. The term refers to hiring decisions based on capability candidates have demonstrated, not credentials they have claimed.

This page documents the methodology behind the Role Match score: the formula that produces it, the role AI plays and the constraints that govern it, how bias is handled, how the system is calibrated against actual job performance, and the known limitations of what we can validate today.

The methodology is public because hiring decisions affect people's lives. Software that participates in those decisions should be transparent about how it works. We publish this page before we have a long customer track record because methodology should be public from day one, not after we have accumulated reasons to defend specific outcomes.

This page is version 2.0 of the Luminid methodology. Material changes are tracked at the bottom of the page and in the Luminid changelog.

What Luminid evaluates

Luminid evaluates candidates on demonstrated skills.

Every Luminid job requires a work-sample simulation. When candidates apply, they complete a simulation tied to the actual work of the role: contract review for a paralegal opening, customer call handling for an inside sales role, a coding task for an engineering position, a case analysis for an operations manager. The simulation produces evidence. The evidence is scored. The score is what Luminid calls a Role Match.

A Role Match reflects the candidate's demonstrated capability for the specific role being applied to. It is not a verdict on the candidate as a person. The same candidate may have a high Role Match for one role and a low Role Match for another, because Role Match measures fit between a person and a job, not the person in isolation.

Skills are the primary signal. Each role specifies the skills that matter for it (required skills and preferred skills), and the Role Match reflects how well the candidate's simulation performance demonstrates those skills. Skills earn verification when a candidate scores well on a simulation that tests them. Verified skills carry the most weight in scoring. Self-declared skills, by contrast, contribute almost nothing. The system is designed so that candidates cannot inflate their match score by claiming skills they have not demonstrated.

The decisions about which skills are required for each role are made by recruiters. Luminid does not infer required skills from job titles or industry conventions. A recruiter posting a paralegal role decides what work the role actually involves and selects skills accordingly. The full skills taxonomy comes from ESCO, an international standard maintained by the European Commission, supplemented by skills Luminid has added through use.

What Luminid does not evaluate as part of the Role Match:

• Years of experience. A candidate's job history appears on their profile as context. It does not factor into the Role Match number.
• Education level. Degree, institution, and field of study appear on the profile. They do not factor into Role Match.
• Language self-declarations. Languages a candidate speaks appear on the profile. They contribute to a knockout filter only if a recruiter has explicitly required a specific language at a specific level for the role.
• Certifications and portfolio pieces. Candidates may upload certifications, degrees, publications, or portfolio work to a Credentials and Portfolio section on their profile. Recruiters see this content as context. It does not drive the Role Match. Luminid does not verify self-uploaded credentials. A candidate's verified skills come from simulation performance, not from uploaded documents.

This distinction is structural. Luminid scores what candidates can demonstrate. Credentials, experience, and education appear on the profile because they are part of who a candidate is, and recruiters use them as context. They do not enter the formula because the formula is designed around demonstrated capability.

The research grounding this choice is documented in industrial-organizational psychology. Work-sample tests correlate with on-the-job performance at 0.54. Resume screening correlates at 0.03. The gap is the entire reason Luminid exists.

How the Role Match works

A Role Match is a number between 0 and 100. Higher numbers mean stronger demonstrated fit between the candidate and the role. The number comes from a single formula:

Three inputs. Each one is described below.

Skills (85% of the score)

The Skills component reflects how well the candidate's simulation performance demonstrates the skills the role requires. Each role has a list of required skills and preferred skills. When a candidate completes a simulation, the AI scores their responses against a construct map that defines what the simulation measures. Skills the candidate demonstrates at strong evidence levels get verified at the skill-and-tier level. The Skills component is then computed from the candidate's verified skill levels against the role's skill requirements, weighted by whether each skill was marked required or preferred by the recruiter.

A candidate who demonstrates all the required skills strongly will score high on this component. A candidate who demonstrates few of them will score low. Candidates who demonstrate preferred skills in addition to required skills score higher than candidates who demonstrate only required skills.

Simulation Bonus (15% of the score)

The Simulation Bonus rewards strong overall performance on the simulation as a whole. When a candidate completes a simulation, the AI produces an overall performance score in addition to scoring the specific skills the construct map evaluates. That overall score becomes the Simulation Bonus, weighted at 15% of the Role Match. A candidate who scores 80% overall on a simulation contributes 12 percentage points to their Role Match from the Simulation Bonus. A candidate who has not completed a simulation for the role has a Simulation Bonus of zero, and the Role Match is computed only from the Skills component.

Knockout Multiplier

Knockouts are recruiter-defined requirements that a candidate either meets or does not meet. A recruiter might require Spanish proficiency at the C1 level. Or work authorization in a specific country. Or a specific professional license. Knockouts are binary. A candidate either meets them or fails them.

The Knockout Multiplier reflects whether the candidate has cleared all knockouts. A candidate who meets all knockout requirements has a multiplier of 1.0, and the formula returns the Skills and Simulation Bonus components as the Role Match. A candidate who fails one or more knockouts has a multiplier of 0, and the Role Match is 0 regardless of Skills or Simulation Bonus performance.

Knockouts exist because some role requirements are non-negotiable for legal, regulatory, or operational reasons. A candidate without work authorization in a country where the role is based cannot be hired into that role regardless of capability. Luminid surfaces knockouts honestly: candidates see which knockouts a role has before they apply, and recruiters see whether each knockout was met.

Recruiters can override knockouts on a per-candidate basis when business judgment warrants. An override is recorded with timestamp and reviewer identity for audit purposes.

Knockouts are validated when a recruiter creates them. If a recruiter sets a knockout that creates likely disparate impact (such as a 5-year minimum experience requirement for a role that does not legally require seniority), Luminid surfaces a warning. Recruiters who proceed past warnings do so with documented acknowledgment.

What the formula does not include

The formula does not include years of experience. It does not include educational credentials. It does not include language proficiency self-declarations (those contribute only to knockout filters when a recruiter has explicitly set one). It does not include certifications or portfolio items uploaded to the candidate's profile.

This is structural. The signals that did not predict job performance in industrial-organizational psychology research are not present in the formula. The signals that did predict performance, work samples and demonstrated skills, are the entire formula.

What AI does, and what it does not do

Luminid is built by people and scored by evidence. People design and approve every simulation and its scoring criteria before it is published; AI then applies those criteria consistently to each response, and must cite evidence from the candidate's own words for every score. That assistance operates within strict, documented constraints. The constraints exist because hiring decisions affect people's lives, and AI used unconstrained in hiring has produced documented harms in this industry and others.

What AI does

AI scores simulation responses against a construct map. Each Luminid simulation has a construct map that specifies what the simulation measures: which skills are evaluated, at what evidence levels, with what scoring criteria. The construct map is built by Luminid's research team and reviewed by industrial-organizational psychology principles before the simulation is published. When a candidate completes a simulation, the AI evaluates their responses against the construct map and produces:

• A score for each skill the simulation tests, at a discrete evidence level
• An overall performance score that becomes the Simulation Bonus
• Cited evidence: specific quotations or references from the candidate's response that justify each skill score

Recruiters see all three. They see the Role Match number, the underlying skill verifications with cited evidence, and the Simulation Bonus. The AI does not hide its reasoning. Every score is traceable to specific moments in the candidate's submitted work.

What AI does not do

AI does not screen resumes. Resume screening is structurally absent from Luminid. Candidates do not submit resumes to Luminid for AI evaluation. The information that appears on a candidate's profile (experience, education, languages, uploaded credentials) is read-only context for recruiters. AI does not process it for scoring purposes.

AI does not infer career trajectories or extrapolate from past job titles. The system does not predict how a candidate's resume suggests they will perform. The Role Match reflects what the candidate has demonstrated in the simulation, not what their career history suggests they could do.

AI does not evaluate candidates as people. The system scores work submissions against skill criteria. It does not produce personality assessments, culture-fit predictions, communication-style judgments, or any other holistic evaluation of who the candidate is.

AI does not make hiring decisions. Recruiters and hiring teams make hiring decisions. The Role Match is one input into that decision. Recruiters see the score, see the evidence behind it, see the candidate's full profile, and decide whether to advance the candidate. Luminid does not auto-reject candidates based on Role Match. Recruiters review candidates and choose who to interview.

Before any AI scoring runs, identifying information from the candidate's profile is removed from the content the AI sees: name, email, phone number, school names from the candidate's profile, prior employer names from the candidate's profile. The AI scores the de-identified content. The full process, including how Luminid handles identifying information that candidates may mention in their own responses, is documented in the bias-handling section below.

AI does not operate on prompts that reference protected characteristics. The system prompts used in Luminid scoring are versioned and audited. Prompts that would instruct the AI to consider race, gender, age, religion, national origin, disability, sexual orientation, pregnancy status, or any other legally protected characteristic are explicitly forbidden by the construct map and prompt template structure.

Specific AI vendors and models

Luminid uses commercial large language models for scoring. The specific vendor and model version may change for cost, capability, or reliability reasons. The methodology described on this page does not depend on which model is in use. The construct map, evidence-citation requirement, prompt audit process, and human-review structure apply regardless of the underlying model. Customers can request the current production model and vendor under their service agreement.

How bias is handled

Hiring software that participates in employment decisions is subject to anti-discrimination law and faces well-documented patterns of disparate impact when poorly designed. Luminid's bias-handling architecture is built around three principles: identifying information is removed before AI scoring, prompts are constrained against considering protected characteristics, and every score is traceable to evidence in the candidate's own work.

Luminid does not claim to be bias-free. Bias-free is not a claim any hiring software can honestly make, regardless of marketing. What Luminid claims is documented, audited, and transparent. Specifically:

Identifying information is removed from candidate submissions before AI scoring. Names, email addresses, phone numbers, and profile data including school names and prior employer names are removed from the content the AI processes. The AI scores the de-identified content. The recruiter sees the candidate's full profile separately; the AI does not.

Identifying information that candidates include in their own responses is handled by prompt constraints, not by automated removal. A candidate writing "When I worked at Microsoft" in a response is not edited. Removing such references would damage scoring on simulations that legitimately require domain context. Instead, the scoring prompts explicitly instruct the AI to disregard employer prestige, school prestige, and seniority inferences when evaluating responses. The AI cites evidence from the response for every score it produces; reviewers can verify that evidence is drawn from demonstrated capability, not from identifying context.

Prompts are versioned and audited. The system prompts that guide AI scoring are stored, dated, and reviewable. Prompts that would instruct the AI to consider race, gender, age, religion, national origin, disability, sexual orientation, pregnancy status, or any other legally protected characteristic are explicitly forbidden in the prompt template structure.

Construct maps define what each simulation measures. Before a simulation is used in scoring, its construct map specifies which skills are evaluated, at what evidence levels, with what scoring criteria. The construct map is reviewed against industrial-organizational psychology principles. Skills outside the construct map are not scored. This prevents the AI from inventing implicit criteria during evaluation.

Knockout requirements are validated for disparate impact risk. When a recruiter sets a knockout (a binary qualification a candidate either meets or does not meet), the system reviews common patterns of disparate impact. A recruiter setting "minimum 5 years of experience" for a role that does not legally require seniority receives a warning that this pattern correlates with age discrimination and disparate impact against women and candidates from underrepresented backgrounds. The recruiter may proceed past the warning with documented acknowledgment, but the warning itself is recorded.

Scoring evidence is traceable. Every score the AI produces comes with cited evidence from the candidate's response. Recruiters see the citation alongside the score. This creates an audit trail: any decision a recruiter makes based on a Luminid score can be reviewed against the underlying evidence. If a hiring decision is later challenged, the evidence chain exists.

Aggregate bias auditing. Luminid commits to auditing aggregate outcomes for disparate impact patterns. This includes monitoring whether selection rates differ across demographic groups beyond what the four-fifths rule allows, whether specific simulations produce uneven outcomes across populations, and whether scoring drift correlates with non-job-relevant candidate characteristics. The audit framework is documented separately. Early in Luminid's deployment, sample sizes are too small for statistically meaningful aggregate auditing; as the platform accumulates data, audits become more rigorous and are published.

The bias-handling architecture cannot eliminate every source of bias. Bias enters hiring decisions through human judgment, through the historical patterns embedded in training data, through the structural facts of who applies to jobs and who does not. Luminid reduces specific known sources of bias and documents the rest. The methodology evolves as the field's understanding evolves.

Calibration and validation

A scoring methodology is only as good as its ability to predict the outcome it claims to predict. Luminid's calibration loop is how the methodology proves itself against actual job performance over time.

The calibration loop

When a candidate is hired through Luminid and begins work, the hiring company is invited to provide post-hire performance feedback at 45 days, with longer-term performance tracking planned as the methodology matures. The feedback is structured: the company indicates whether the candidate is performing at, above, or below expectations against the same skills the simulation evaluated. Over time, this creates a dataset connecting Luminid simulation scores to actual on-the-job outcomes.

The data feeds back into the system in two ways:

Simulation confidence indicators. Each simulation accumulates outcome data. Simulations with substantial outcome data and strong correlation between scoring and performance are marked as validated. Simulations with weak correlation are flagged for review or deprecation. Simulations new to the platform are marked as such, so recruiters know how much weight to give their scores. The state of each simulation (validated, building, or flagged) is visible to recruiters.

Construct map refinement. When outcome data suggests a construct map is measuring the wrong thing, Luminid's research team reviews and revises it. Construct map versions are stored. Past candidate scores under previous construct map versions remain attached to the candidate; new applications use the current version. This is honest about the fact that scoring is an evolving practice, not a fixed truth.

The honest stage of calibration

Luminid is in early development. The calibration loop requires hiring decisions, hires made, and time on the job. Early in the platform's deployment, very few simulations have meaningful outcome data. Recruiters see this directly: simulations without outcome data are marked, and recruiters can use them with the understanding that scoring carries less validated confidence than scores from established simulations.

The same applies to aggregate bias auditing. Statistical significance requires sample size. Until enough candidates have completed each simulation across enough demographic populations, formal bias audits return inconclusive results. Luminid publishes audit findings as they become statistically valid, not before.

This is the work of building a methodology that proves itself. The methodology is published because methodology should be public from day one. The proof accumulates over time. Both are visible to anyone reading the methodology page and the changelog.

What validation does not require

Validation does not require Luminid to be perfect. It requires Luminid to be honest about what is known and what is not, to publish the framework that produces scores, and to allow external review of both the framework and the outcomes. The methodology is evidence-based and improvable. The validation process is the mechanism by which it improves.

Limitations and known issues

Luminid is in early development. Several limitations are inherent to the current state of the platform and are surfaced here rather than hidden.

Calibration data is limited. The methodology described above produces scores. The validation process by which those scores prove themselves against actual job performance requires hires, time on the job, and outcome feedback. Until customers have accumulated meaningful outcome data, simulation confidence indicators are conservative. Recruiters see this state directly in the product. The methodology improves as the data accumulates.

Aggregate bias auditing requires sample size. Statistical significance for disparate impact analysis requires enough candidates per demographic group per role. Early in deployment, samples are too small for formal audits to return valid findings. Luminid commits to publishing audit findings as sample sizes support them, not before. Until then, the bias-handling architecture (PII removal, prompt constraints, evidence citation, construct map review) operates without aggregate audit verification of its effectiveness.

Construct map quality varies. Each simulation's construct map is the foundation of its scoring. Luminid's research team reviews construct maps against industrial-organizational psychology principles before publication, but construct maps can still measure imperfectly. Simulations with weak construct maps produce less reliable scores. The calibration loop identifies these cases over time, but they exist.

AI scoring carries residual bias. Identifying information is removed from candidate submissions before AI scoring, and prompts are constrained against considering protected characteristics. These mitigations reduce known sources of bias but cannot eliminate all of them. The underlying language models are trained on text that reflects historical patterns of language, work, and hiring. Some of those patterns may surface in scoring even after the documented mitigations. The bias mitigations Luminid applies reduce identifiable risks but do not eliminate all sources of inherited model bias.

The methodology depends on simulation quality. Luminid's scoring is only as good as the simulations it scores. A simulation that does not accurately reflect the work of the role being hired for will produce scores that do not predict performance for that role. Luminid's research team builds and reviews simulations against role analysis principles, but the library of available simulations is finite and growing. Roles without a strong matching simulation use the closest available match, which produces less precise scoring.

Self-uploaded credentials are not verified. The Credentials and Portfolio section on candidate profiles displays content candidates have uploaded. Luminid does not verify the authenticity of these items. Recruiters see them as context but should treat them as self-reported. Verified skills come from simulation performance, not from uploaded documents.

Knockouts can produce disparate impact. Even with system warnings, recruiters can set knockout requirements that produce disparate impact. Luminid surfaces the warning and records the override but does not enforce knockout policy beyond that. Customers using Luminid are responsible for compliance with applicable hiring law in their jurisdictions.

The platform is not a substitute for legal counsel. Luminid provides scoring infrastructure and documented methodology. It does not provide legal advice. Customers using Luminid for employment decisions should consult employment counsel familiar with their jurisdiction's hiring laws.

What this means for you as a candidate

If you are applying for a role through Luminid, the experience looks like this:

You see the role you are interested in. You see what skills the role requires and what work the simulation will involve. You see whether the role has any knockout requirements before you apply. If a role requires a specific work authorization, language proficiency, or license, that requirement is visible on the role page.

You complete the simulation. The simulation reflects the actual work of the role. Your responses are evaluated against the skills the simulation is designed to measure. The AI scores your responses against the construct map and produces a Role Match number for that specific role.

Your Role Match reflects your fit for this role. It does not reflect your worth as a candidate. The same candidate can have a high Role Match for one role and a low Role Match for another, because Role Match measures fit between you and the work, not you in isolation.

Recruiters see your Role Match alongside the evidence the AI cited from your work to justify the score. They see your full profile (experience, education, languages, uploaded credentials) as context. They make the hiring decision. Luminid does not auto-reject candidates based on Role Match.

You have rights regarding the scoring of your work. Under various jurisdictions' employment laws, you may have the right to know how automated tools were used in evaluating you, to request human review of automated decisions, and to know what information was processed. Luminid commits to transparency about all of these. If you have questions about how your application was evaluated, you can contact the company you applied to. Luminid provides the underlying evidence and methodology used in scoring so the company can respond accurately.

The Role Match score is one input into a hiring decision, not the decision itself. The methodology that produces it is documented above. The system that produces it is one Luminid is committed to improving over time.

About Luminid

Luminid was founded in 2026 by Gabriel Golfin Araya, with seven years of recruiting experience at companies ranging from Amazon and Grupo Bimbo to firms in the legal services space. Luminid operates from Costa Rica, building hiring infrastructure for the Latin American market and beyond.

The methodology described on this page is the foundation of the Luminid product. It is based on industrial-organizational psychology research and built to evolve with calibration data. It is reviewed regularly. The methodology version is tracked at the bottom of this page, in the changelog at /changelog, and in the company's published commitments.

Luminid welcomes external review. Researchers, employment attorneys, HR practitioners, and candidates interested in the methodology can contact the company at hello@luminid.org.

Version history

• v2.0 (May 2026): Skills-only evaluation. Experience, education, and language self-declaration removed from Role Match. Simulation bonus introduced. Knockout multiplier and disparate-impact warning system documented. Bias-handling architecture and calibration loop published.
• v1.0: Specification only. Never deployed.