What this automation does
The goal is narrow on purpose. The model reads, summarizes and points to evidence. A person decides.
- Pull. When an application lands in your ATS, a workflow fetches the resume, the answers to screening questions and the job’s written criteria.
- Redact. Code removes the candidate’s name, contact details, photo, street address, social links and graduation years before anything reaches the model.
- Assess against a rubric. The model checks each criterion the hiring manager wrote, for example “three or more years managing a warehouse team”, and returns “evidenced”, “partly evidenced” or “not found” with a direct quote from the resume.
- Write back as a note. The assessment is posted to the candidate’s profile in the ATS as a private note. It does not move the candidate to another stage, and it does not produce a rank.
- Recruiter decides. The recruiter reads the application and the note, then advances, holds or declines in the ATS as they normally would.
- Log everything. The redacted input, rubric version, prompt version, model version, output and the recruiter’s eventual decision are written to an audit table.
When it is worth building
Build this when recruiters are spending most of their week reading applications for high-volume roles, such as customer service, warehouse, nursing support or sales development, and the bottleneck is reading speed rather than judgment. Below roughly 50 applications per role, a recruiter reading each resume is faster than maintaining an AI pipeline.
Do not build it if your hiring criteria are not written down. A model cannot apply criteria that live only in a hiring manager’s head, and writing them down is most of the fairness work anyway. Also check what your ATS vendor already offers. Several now ship AI screening features, and some vendors commission bias audits of their tools. Buying can be the better answer, but the obligations under laws like NYC Local Law 144 still fall on the employer, so ask the vendor for their audit and your counsel for an opinion either way.
The legal frame, in general terms
Disparate impact means a practice that looks neutral screens out a protected group at a noticeably higher rate and is not job-related and consistent with business necessity. Title VII has covered this for decades, and it applies to software the same way it applies to a written test. In 2023 the EEOC published technical assistance on AI in selection decisions that made three points worth keeping: an employer can be responsible for a tool a vendor built and runs, the four-fifths rule is a rough rule of thumb rather than a safe harbor, and tools should be checked for adverse impact on an ongoing basis. The EEOC removed that document from its website in early 2025 as federal priorities shifted, but the underlying law did not change, and private lawsuits and state and local rules still apply.
NYC Local Law 144 adds specific duties when an automated employment decision tool is used for New York City candidates or employees: a bias audit by an independent auditor within one year before use, a public summary of the results, and notice at least 10 business days ahead that tells people a tool will be used and which qualifications and characteristics it assesses. Whether a “summarize and quote” design like this one counts as such a tool depends on how much weight its output carries in the decision. That is a question for your counsel. Nothing on this page is legal advice.
Architecture
| Layer | What we use | Why |
|---|---|---|
| Source of applications | Greenhouse, Lever or Workable | Applications already live there, and each exposes a REST API for candidates, attachments and notes; for Greenhouse, build on its Harvest v3 API with OAuth credentials, since v1 and v2 were scheduled for retirement in August 2026 |
| Orchestration | n8n, usually self-hosted | Candidate data stays on infrastructure you control, and each run is inspectable |
| Redaction | A code step with pattern rules plus a model pass that only labels spans | Deterministic removal of contact data; the model helps find names inside free text but never decides what stays |
| Assessment | Claude or OpenAI’s GPT models through the API | Follows a fixed rubric and returns structured JSON with quotes; API data is not used for training by default |
| Quote check | Code that confirms every quote exists verbatim in the resume | Stops the model from inventing evidence |
| Audit log | Postgres table with versioned rubric and prompt IDs | Lets you reconstruct any assessment later and run adverse impact analysis |
| Alerts | Slack channel for recruiters and the HR lead | Surfaces flagged resumes and weekly monitoring results |
Voluntary self-identification data (race, ethnicity, sex, veteran and disability status) stays in the ATS’s separate EEO fields. It is never sent to the model. It is only joined to outcomes later, in aggregate, for impact testing.
How to build it
- Get legal review first. Have employment counsel review the plan, the candidate notice and the data flow before any build work. Identify every location you hire for, because New York City and several states have their own rules on automated hiring tools.
- Write job-related criteria. For each role, the hiring manager and HR write four to eight criteria tied to the actual work. Avoid proxies like “top university” or “culture fit”. Version every rubric.
- Build redaction and test it. Run 50 real resumes through redaction and have a person check what slipped through. Names in email signatures and file names are the usual misses.
- Prompt for evidence, not judgment. Ask the model whether each criterion is evidenced and to quote the line that shows it. Do not ask for an overall score or a “fit” percentage.
- Verify quotes in code. Discard any assessment whose quotes do not appear in the source text, and retry once before routing to a recruiter with no note.
- Shadow mode. For two to four weeks, generate notes but hide them from recruiters. Compare model assessments with recruiter decisions on the same applications.
- Run an adverse impact check. Before go-live, compare the rate at which each group is “evidenced” on each criterion. Under NYC Local Law 144, an independent auditor must perform the formal bias audit. Elsewhere, an internal analysis is still good practice.
- Publish notice and go live. Post the required notice and audit summary if you are covered, show notes to recruiters, and keep the weekly impact report running.
The downloadable starter template below covers the pull, redaction, assessment and note-writing steps for Greenhouse, with the audit log in Postgres.
What breaks in production
- Rubber-stamping. Recruiters start agreeing with the note without reading the resume. Track how often recruiters decide differently from the note. An override rate near zero is a warning sign, not a success.
- Hidden instructions in resumes. White text, tiny fonts and metadata can carry instructions aimed at AI tools. Extract visible text only and flag anything that reads like a command.
- Non-traditional backgrounds. Career changers and candidates with gaps often have the skill described in unfamiliar words. Rubric criteria that name outcomes rather than titles hold up better.
- Rubric edits mid-search. A hiring manager tightens a criterion halfway through. Without versioning, early and late applicants were judged differently and you cannot show it.
- Parsing failures. Two-column PDFs, tables and image-only resumes extract badly. Route low-text extractions to a recruiter with no note rather than a weak one.
Timeline and cost
Expect four to eight weeks, with legal review and the shadow period taking as long as the build itself. Lumeor builds this in the range of $15,000 to $35,000, depending on the ATS, the number of roles and rubrics, and how much reporting you need for impact monitoring. The independent bias audit required in New York City is a separate engagement with an auditor, not something we perform. Model usage for a few thousand applications a month is typically modest compared with recruiter time. If you are still deciding whether AI belongs in your hiring process at all, an AI readiness assessment is a lower-risk first step.
How to measure success
- Recruiter minutes per application, before and after
- Agreement between the model’s criterion calls and a recruiter’s on a weekly sample of 20 to 30 applications
- Recruiter override rate, watched for being too low as much as too high
- Pass-through rate by group at each stage, compared with the four-fifths rule of thumb as a trigger for investigation
- Time from application to first human response for candidates
- Share of quotes that fail the verbatim check, which should trend toward zero
Pair this with a clean job description process, since the rubric should come from the same intake, and with automated interview scheduling so the time saved in screening is not lost in calendar back-and-forth.