Claim-by-claim AI resume scoring: one claim, all the way down.

It is a resume-scoring approach that decomposes a job description into 5 to 15 testable claims with visible weights, classifies each as must-have, nice-to-have, or red flag, finds (or fails to find) a span of the resume as evidence for each claim, sums the weighted matches into a score, and treats every weight override as a logged tool call so the rubric and the score live inside one audit trail. The artifact is the ledger, not the number.

A single number cannot be defended to a hiring manager who disagrees, to a candidate who asks why, or to a regulator under NYC Local Law 144 / Illinois HB 3773 / Colorado CAIA / EU AI Act high-risk hiring. A weighted ledger of testable sentences can be defended to all three, because each line of the ledger is independently verifiable against the resume. The score is just the sum of the lines.

The classifier reads the JD plus the org-wide hiring criteria and projects each candidate sentence onto one of three buckets. Must-have is gating: a missing must-have caps the score. Nice-to-have is additive: present spans add weight, absent spans cost nothing. Red flag is subtractive: a supported red-flag span subtracts weight from the score. Every classification ships with a proposed weight that the recruiter can override before the first candidate is scored.

Six fields. id is a string. text is the claim sentence. kind is must_have, nice_to_have, or red_flag. weight is an integer, conventionally 1 to 5. evidence_span is the substring of the resume that supports the claim, or null if no span supports it. supported is a boolean derived from whether the span exists. The score formula is the sum of weight where supported, with red_flag entries subtracted instead of added. There is no opaque similarity number anywhere in the record.

The override is a tool call: match.override_weight(claim_id, prior_weight, new_weight). It writes one row to the audit log with actor, timestamp, prior, and new. The score recomputes from the new weight. If the recompute moves a candidate across a decision boundary (advance to reject or vice versa), that flip is logged with the same shape. There is no free-text comment, no model-confidence dial, no implicit override. The override IS the audit row.

Claims that are not testable against a span. 'Strong communicator', 'culture add', 'high-agency', 'looks like a leader' are the four most common bad shapes. None of them can be sourced to a substring of the resume; they belong in the loop debrief, not in the rubric. A well-built claim extractor declines to write them. If your AI resume scorer is happily emitting them, the rubric is doing the work of vibes, and the audit trail is fictional.

Greenhouse, Ashby, Gem, Lever, and SeekOut all ship LLM resume summarizers in 2026. They read the JD plus the resume and emit a paragraph plus a 0-100 fit score. The paragraph cannot be edited as a structured artifact. The score is the rubric, but the rubric is implicit in the model. Claim-by-claim scoring inverts that shape: the rubric is the artifact, the score is the byproduct, and every weight is a knob the recruiter can turn.

Score = sum(weight where supported and kind in {must_have, nice_to_have}) minus sum(weight where supported and kind = red_flag), normalized by the maximum possible (sum of all positive weights). On a Senior AE req with 11 claims totaling positive weight 28, a candidate supporting 22 weight worth of must-haves and nice-to-haves and zero red flags scores 0.79. Drop a claim's weight from 4 to 3 and the same candidate scores 0.78 because the denominator changes too. The math is recomputed every time a weight changes.

Two claims that share evidence are allowed. 'Carried a $1.5M+ quota' and 'sold into mid-market accounts' often map to the same line on a sales resume, and both are scored independently. The recruiter can demote one weight to avoid double-counting if the team treats them as the same signal. The override is a logged tool call; the reasoning is recoverable later. The model does not silently merge them; it surfaces both and lets the rubric editor decide.

Not as the primary detection layer, but it shifts detection earlier. If a claim's evidence_span is null on a resume that looks long enough to contain it, that absence surfaces in the ledger before the phone screen. If two supported spans contradict each other (a Series B startup tenure that overlaps with a 'Director at FAANG' claim by three years), red-flag claims fire on the contradiction. The recruiter spends thirty seconds on the ledger view, not an hour on a phone screen with a synthetic candidate.

Paste the JD, paste the org criteria, get back 5 to 15 candidate claims with proposed weights. The first edit pass takes a recruiter about ten minutes the first time, under three minutes after the team has scored a few reqs and the proposed weights start landing close. Scoring inbound applicants against the saved ledger is one batched tool call: match.rerun_score against the candidate set, no per-candidate clicking.

It is the Match Rating agent. It ships on the Starter plan ($0, up to three open reqs, no credit card) along with the rest of the agents, including the MCP server. You can run it as a pre-screen layer in front of an existing ATS for a quarter and decide later. The same Match Rating ships on every plan; the only thing that scales is open req count and team seats.