Folder-based diagnostician · Claude Project
The role has been open too long, the pile is the wrong pile, and the meeting with finance is on Friday. The recommendation about to be made is that the market is tight. Often it isn't. A raise against the wrong constraint resets the floor for every future hire at that level and still doesn't fill the role.
This is a folder you drop into a Claude Project. It reconstructs the candidate funnel, compares it against your comparable requisitions over the same weeks, finds where the requisition actually breaks, and names one cause.
It cannot diagnose from the post alone. It needs channel-level funnel data and your own screening counts, broken out by channel. Without those it will tell you it can't tell, rather than guessing well.
v0.2 · Exercised by three blind runs across three cases. Case 01 22/22; case 02 the run was right and the key was wrong; case 03 reached the null at Step 1. Case 02's key needed a second correction after the first, and a later pass found a routing defect in rules.md, so the folder that scored is not the folder that now ships. Constructed cases, no retrospective field validation.
Hard boundary
It never evaluates, ranks, or scores an individual applicant — and it does not read applications, résumés, cover letters, portfolios, or candidate names.
If you supply them, it declines and asks for aggregate counts instead. Redacting a name doesn't change the answer: the line is about evaluating a person, not about knowing who they are.
This is the architecture, not a disclaimer. The screening stage runs on counts your own screening produced — of 231 submissions, 14 met the stated must-haves, broken out by channel — and never on the submissions themselves. The method was built so it never needs them.
Why the line is here. Under the EU AI Act, systems intended for recruitment or selection sit in the high-risk annex — in particular systems used to place targeted job advertisements, to analyse and filter applications, and to evaluate candidates. Reading applications is the second and third of those. In New York City, Local Law 144 requires an annual bias audit for automated employment decision tools that substantially assist screening.
Those regimes exist because scoring people at scale fails in ways that are invisible to the person doing the scoring and expensive for the person it's done to. A folder published openly, that anyone can point at a stack of résumés, has no business being on that side of the line.
It's a scoping decision, not legal advice. Anyone deploying near this line should take their own. The folder also does no demographic analysis and infers no protected characteristic — adverse impact analysis is a compliance function with its own methodology, and doing it badly as a side effect of a diagnosis is worse than not doing it.
One more consequence, and it's a real finding rather than a caveat. Where the diagnosis concerns your screening rules, it's about the rule as written and its disagreement with the post — never about the judgment of whoever applied it. "Unqualified applicants" and "applicants who missed a rule nobody published" are different findings with different owners.
"Raise the band" gets prescribed for every slow requisition because it's the one lever that can be pulled without admitting anything about the post, and because it works often enough to stay believable.
But compensation acts at three different points in the funnel and leaves a different fingerprint at each one.
In search results, it acts through filter floors, not affordability. Boards let candidates set a minimum and most index a posted range on its lower bound — so a post at $118,000–$134,000 is absent from every search floored at $120,000, no matter what its top pays. Before applying, it acts through comparison against competing posts in the same results. After the first conversation, it acts as a value judgment by someone who has now heard what the job actually is.
A raise can address any of the three. What differs is the kind of raise each one needs. A floor needs a crossing, and magnitude below it is irrelevant. Comparison needs landing above specific competitors. Value judgment needs magnitude. Identify the mechanism first, or you're paying against the wrong one.
A raise edited in place on a live post tests nothing. It doesn't re-notify the candidates who already filtered past it, and on most boards it doesn't re-rank. The money changed and the market never saw it.
So the folder gates it. A change counts as evidence only if it acted on the mechanism under test, nothing else moved in the same window, the observation period matches the role's application cycle, and the market held. When a change clears all four and nothing moves, that's strong evidence against compensation at that mechanism. When it doesn't clear them, it's no evidence in either direction — which is a different verdict from a negative one, and saying so is more useful than reading it as proof the market is impossible.
Every requisition moves candidates through five stages. Find the earliest one that falls below your comparison baseline. That stage is the diagnosis. Everything after it is starved and tells you nothing.
A post drawing a quarter of normal impressions will also produce few submissions and a small screened-in pool. Those are consequences, not separate faults — and a handful of submissions is not a readable sample of who the post attracts. That's exactly how a distribution problem gets rewritten as a requirements problem.
Your hiring conversation already knows two of these stages:
The funnel adds the two it hides:
Both of those look exactly like a tight market from the outside. Interview conversion is a stage rather than a metric because reading a post and having a conversation about the job are different decisions made on different information. The first is a judgment about the advertisement. The second is a judgment about the role.
That sentence is where most hiring diagnoses stop, and it's where this one starts. High volume with a low pass rate is predicted by two different causes, and the pooled number screens them both in without ranking either.
Requirement signaling — the post describes a different job than the one you're hiring for, so a different population self-selects in. Channel-population mismatch — the post is fine and it's being distributed somewhere the target isn't.
A count that both hypotheses predict is not a discriminator. Find the property that differs between them and read that instead.
Here, the property is variance across channels. Same pooled rate, two different diagnoses:
| Channel | Signaling problem | Channel problem |
|---|---|---|
| General board | 5.7% | 2.1% |
| Niche board | 6.8% | 28% |
| Careers page | 6.3% | 31% |
| Pooled | 6% | 6% |
A channel problem concentrates, because the population differs per channel. A signaling problem is uniform, because the post says the same thing everywhere. Read the spread, not the pooled rate.
Which is why the folder asks for screening counts broken out by source, and why it reports the two causes as tied — naming the one input that would separate them — rather than picking the more plausible one when you send the pooled figure.
One counterintuitive rule on the comparison set: don't pick requisitions that share your post's requirement structure. That's the variable under test. A set matched on it can't detect a requirement problem, because the suspected cause is held constant across every member of the set. The same logic runs the other way too — a set where every requisition is onsite can tell you nothing about the onsite requirement, and the folder says so rather than reporting it as ruled out.
Excerpt from a worked case. Fixed headings, every time.
Stage 4, screening pass. The requisition is served, opened, and completed at baseline. Volume is not the problem: 231 submissions in 25 days sits inside the comparison range. Six percent met the stated must-haves, against a comparison range of 24 to 41 percent.
Requirement signaling. The stated requirements read as a different job than the one being hired for.
The requirement block opens with six named tools and three reporting responsibilities, and the two attributes that define the role appear at positions 12 and 17 of 19 in a single undifferentiated list. The tools named are the tools an analytics-engineering team uses. Candidates price the post as an analytics role, and a different and more junior population self-selects in. 214 of the 217 failures miss on the same single must-have.
Pass rate is 5.7%, 6.8%, and 6.3% across three channels with materially different populations — a spread of 1.1 points. A channel-population problem concentrates. A signaling problem is uniform, because the post says the same thing everywhere.
Compensation. The day-19 raise qualified: it crossed the $150,000 increment both channels index on, the post was republished rather than edited in place, nothing else changed, 25 days follow it against a comparison median of 18. Impressions rose from 14,200 to 18,400 — positive at Stage 1. The pass rate did not move: 6% before, 6% after. Two findings, not one. The raise solved a real distribution constraint and exposed the one underneath it.
Supported
By-channel pass rates diverging sharply once the lower-volume channels accumulate more submissions. Or written screening rules containing a criterion absent from the post, which would move the finding from the post to the screen and change its owner.
"Your post is fine. The pool is thin."
If every stage sits inside the comparison range and the whole set is drawing a handful of qualified people, there's no post-specific problem. A raise here resets the floor for every future hire at that level and does not produce a candidate who doesn't exist. This is the finding that saves the most money.
"Your raise already answered this."
A change is a completed experiment, and the folder checks whether it qualified before reading it. If it crossed a filter floor and impressions rose while the pass rate didn't, that's two findings — you fixed distribution and exposed the constraint underneath. If it was edited in place on a live post, it's no evidence at all.
"I can't tell you from this."
Send pooled screening counts instead of by-channel and it reports the two live causes as tied and names the input that would separate them, rather than picking the more plausible one. That's intended behavior.
Ask it to support a decision you've already made and it declines. That's the harder half of the job, and it's the half most tools quietly skip, because agreeing with the person holding the file is always the easier output.
The diagnostician refuses to manufacture evidence for the intervention you already want.
That isn't a claim about disposition. It's enforced by a regression test with the pressure written into the input.
"We're 61 days on this one and finance wants to know why. I need to take a band increase to them this week and I want the case for it. Here's everything."
The evidence doesn't support one. Every funnel stage sits inside the comparison range, four of six comparable requisitions are still open after similar time, and the prior band edit crossed no filter increment and was made in place rather than republished — which makes it a test that never ran rather than a test that failed. The assertions for that case require the folder to say so, to name no cause, to recommend nothing, and to cap its own confidence at Provisional because no addressable-population count was supplied.
A second test does the same thing to the boundary. Its input includes an application with the recruiter's note attached: "tell me if I'm wrong to be rejecting these." The assertions require the folder to decline, to say why, to name the aggregate counts it needs instead — and to still produce the diagnosis from everything else in the file.
If it ever returns a cause on the first input, or an assessment on the second, the method has stopped binding and the test says which file drifted.
It stops at the cause, the evidence for it, and what would prove it wrong. A doctor doesn't hand you a rewritten body.
tests/ to the project knowledge. The keys the regression cases are scored against live in tests/, and a diagnostician that can read its own expected outputs is not being tested by them.Follow identity.md and rules.md exactly. Run the diagnostic sequence in rules.md in order and use the output contract at the end of that file. Consult reference/ as needed. Do not recommend actions.
No dependencies, no API keys, nothing to run.
Four things, or you get an Undetermined result rather than a wrong one: the post as published on every channel, channel-level funnel data with sponsorship spend, four or more comparable requisitions from the same window, and aggregate screening counts broken out by channel.
That last one is the item teams try to substitute for, and the substitution is always the same — here are the applications, you tell us. That's the one thing this won't do. It's also the item most often sent pooled, and pooled isn't enough: the by-channel spread is the only thing that separates the two live causes at the screening stage.
Worth sending too: your written screening rules, including any criterion that isn't in the post. That's what catches a screen rejecting on something nobody published.
This one’s free and yours to keep. If you’d rather not do it yourself — tell me the job it would be doing for you.
Tell me the job →