Position Fit Score and Candidate Ranking

What is measured is not the general quality of a candidate, it is whether they evidence what this posting asks for. The requirements are broken into check items, each item is looked for in the candidate document, and the coverage ratio becomes the score. The same candidate can score differently on two postings, because the questions are different.

The breakdown happens once per posting, not per candidate; it is stored and applied identically to everyone. Versions are immutable, and only an approved version ever enters scoring.

The model produces no score. For each item it answers whether it is evidenced in this document and leaves a verbatim quote next to its call. The coverage ratio and the total are computed in code.

Most of the score is set by how the criteria are written, not by the model. Criteria are defined on the posting form and each one carries a weight; the save button stays closed until the weights add up to exactly 100. The server applies the same rule again on write, so giving three criteria a weight of 30 and leaving the rest empty cannot be saved.

A criterion that cannot be verified from a document produces no rubric item. A phrase such as being a team player never enters scoring; the posting editor lists it in a separate warning box. The distinction that raises the warning and the one applied during scoring are the same, so the call you see while writing the posting cannot drift from how candidates are scored.

The rubric is generated as a draft first, then approved item by item with the sample evidence in view. There is deliberately no approve all button: it would reward approving without reading.

• Weights must add up to exactly 100; the save button and the server apply the same rule
• Only measurable items can serve as hard criteria: years of experience, degree, language level, grade average
• A free form skill statement cannot be marked as an elimination gate
• Criteria that cannot be verified from a document are counted in the warning box and left out of the rubric
• With no approved rubric the system does not stop: the same three way call and quoting contract are applied with a single item per criterion

Year arithmetic is never asked of the model, it happens in code. The gate is pure arithmetic: it does not read the database, it takes today date from outside and returns one of three values. In measurement it made the right call on 12 out of 12 difficult edge cases, with no false elimination.

Matching a technology name is not string equality; different spellings of the same technology are folded into one name. When plain equality was tried, the phrase React 18 wrongly eliminated a candidate with 4 years of experience; that folding is now shared by the gate, the keyword stuffing check and criterion classification.

A hard criterion flag is not an elimination switch, it is a cap placed on the score. The default cap is 54, just under the strong band: a candidate whose gate is closed cannot read as strong, and is not removed from the list either. The panel says as much in its own words: these candidates were not eliminated, they sit apart because the gate is closed, and the decision is yours.

Quotes are validated by code, not by the prompt. The permitted set the model may quote from is built from the candidate document and their form answers; a quote that does not sit in that set is dropped. Comparison follows Turkish letter rules, so yilmaz and Yılmaz count as the same word.

A second grading run is not taken on every candidate. It runs in two cases only: at least one item came back unclear, or the score sits within 3 points of a band boundary. When the two runs disagree on the same item, no average is taken; the item is marked unclear and leaves the denominator. The second run spends no extra credit.

A criterion with no evidence is not counted as half a point: its weight leaves both the numerator and the denominator. The absence of evidence is not a shortcoming of the candidate, the decision goes to a person, and the criterion explanation says so in plain words.

• The criterion explanation states how many of the check items were evaluated with evidence and how many stayed unclear
• On a measurable duration condition the arithmetic owns the call; if the deterministic gate does not say passed, a positive call from the model does not stand
• If the document carries signs of keyword stuffing, the claim is not trusted: an item that only appears in a skill list earns no points
• The grader runs at temperature 0; as long as criteria, weights, rubric version and document stay the same, the same application gets the same score

Two different changes get mixed up here. Changing a weight or a decision band needs no new AI request; the stored per item calls are simply re-added locally. The scoring settings panel says it plainly in its own copy: recalculation is entirely local and no AI request is made.

If the criterion text changes, the stored scores are marked stale, but the document is not reprocessed because the candidate document did not change. When only the wording of a rubric question was corrected, the meaning of the item is unchanged and records scored with the old version stay valid: on a posting with 200 applications, fixing a typo is not 200 re-analyses.

The billing rule fits in one sentence: one candidate and posting pair is charged once. Fit against the posting a candidate applied to is part of the application analysis. When credits run out or the subscription is suspended, scoring does not stop, it falls back to the deterministic path; what changes is the quality of the explanation.

AI changes no status on its own. Inviting to interview, approving and rejecting are human actions; even the bulk action bar asks for confirmation and states in its own note that AI only offers suggestions and that status changes are applied with human approval. The system does not learn from past hiring outcomes either: who was invited or hired never enters scoring.

A single candidate card cannot answer whether your threshold is right. The calibration report shows the band distribution across the company, how often the gate closed or could not decide, and how often a person stepped in. It starts closed and opens when you ask for it.

Every score record keeps the version, the model, the temperature and the structured basis of the gate; the re-analysis history is stored separately. Opening the gate with a reason is recorded as an immutable event independent of the fit record, so the human decision stays on file even if the score is deleted.

• A record is written the moment someone looks at the group of candidates with a closed gate; the posting closing warning looks for the absence of that record
• The reason for a recalculation is not picked by the user; the system compares the recorded version with the current one and works it out
• For a masked user the audit trail hides the reason text and still shows who made the decision and when
• Panel access is role based: the fit screens ask for separate view and manage permissions