Case: The Screening Model Nobody Owned

A candidate complaint unearths a vendor résumé screener that had been auto-rejecting applicants for 18 months — no owner, no audit, no register entry — at a 4,000-person logistics company.

A composite teaching case: realistic fiction assembled from well-documented public patterns — not a real engagement.

The setup. Meridian Freight is a composite: a 4,000-person logistics company — trucking, warehousing, a corporate office in Manhattan — hiring roughly 3,000 people a year, most of them drivers and warehouse staff, a few hundred of them corporate roles posted out of the NYC office. In early 2024, a talent-acquisition manager drowning in applications bought a SaaS résumé-screening tool from a mid-market HR vendor — call it Parsonix — for about $30k a year. Procurement waved it through under the ‘HR software’ category, the same lane as the survey tool and the org-chart plugin. Nobody involved thought of it as an AI purchase, because nobody was asking.

Parsonix scored every application against the job posting and, in the configuration Meridian ran, did something more consequential: auto-advance mode. Candidates above the score threshold moved to a recruiter’s queue; candidates below it received a polite automated rejection. No human ever saw them. The threshold — 62 out of 100 — was set during a one-hour onboarding call by a Parsonix sales engineer and never revisited.

The TA manager who bought it left in mid-2025. The tool kept running. By the time anyone looked, it had processed roughly 47,000 applications and auto-rejected about 61% of them.

The trigger. In February 2026 an email arrived in the careers inbox. A candidate for a Manhattan-based pricing-analyst role had applied at 10:40 p.m. and been rejected at 11:21 p.m. — 41 minutes later, on a Sunday. Her email asked three precise questions: was an automated employment decision tool used to assess her application; where is the bias-audit summary published, as NYC Local Law 144 requires; and where was the notice she should have received at least ten business days before the tool was used on her.

Nobody at Meridian could answer any of the three. HR didn’t know what tool the careers portal used. IT said it wasn’t their system — SaaS, bought by HR. Legal had never heard of Parsonix. The general counsel’s office spent the first two days simply establishing what the company was running, which is its own finding: the mean time to answer ‘what did this tool do to this person?’ was measured in days, for a decision the tool made in milliseconds, thousands of times a week.

The reconstruction. Outside counsel came in during week one; a two-person internal team (an HRIS analyst and a paralegal) spent ten days on archaeology. The vendor’s contribution was a two-page ‘AI explainability statement’ — marketing prose about ‘fair, skills-based matching’. The real record had to be rebuilt from the applicant-tracking system’s API logs, the Parsonix admin console (one recruiter had the only login), and the original contract, retrieved from the departed manager’s archived mailbox. What the review found, numbered because numbered findings get fixed:

The audit. An independent auditor was engaged in week three — LL144 requires independence, so neither the vendor nor Meridian’s own counsel could do it. The audit took six weeks, most of it data work: 18 months of ATS records had to be joined to demographic data that only existed for the ~54% of applicants who had completed voluntary EEO self-identification. Scoring-rate and selection-rate impact ratios were computed by sex, race/ethnicity, and — the part that found the problem — intersectional categories.

Most ratios landed between 0.84 and 1.03. One did not: Black women showed a selection-rate impact ratio of 0.71 against the highest-selected group (white men). LL144 itself sets no pass/fail line — it forces the number into the open — but 0.71 sits well below the four-fifths rule of thumb (0.80) that federal disparate-impact practice uses as a red flag, and everyone in the room knew which number a plaintiff’s expert would circle. The employment-gap feature (F-7) was the leading suspect: in a follow-up ablation the auditor ran, removing it moved the ratio to 0.83. A feature nobody chose, in a tool nobody owned, produced a number nobody could defend.

The decision. With the audit in hand, three options went to a steering group of the CHRO, the GC, and the CIO — the first meeting the three had ever held about an algorithm, and not a warm one. The CIO opened by noting that SaaS bought by HR was not an IT system; the GC replied that it would be an IT system by Friday.

What was done. The steering group chose defang-and-remediate, with the RFP held in reserve as renewal leverage. Auto-advance was switched off within 72 hours of the audit landing; every below-threshold application now routed to a human queue. Recruiters, told they were getting a fairness safeguard, experienced a 60% workload increase and said so. Notices went onto every NYC posting with the 10-business-day clock respected before the tool touched another NYC application; the audit summary went onto the careers site — an uncomfortable publication, since it included the 0.71.

The contract was the slow fix. At renewal, with the RFP visibly warm, Meridian extracted audit and data-access rights, an obligation to support the annual bias audit at the vendor’s cost, 30-day advance notice of material model or feature changes, removal of the employment-gap feature for Meridian’s tenant, and a compliance-cooperation clause. The price went up 12%. Counsel called that cheap; the vendor’s counsel called it precedent-setting and fought for six weeks.

Worth naming the legal backdrop honestly: LL144 enforcement by the DCWP never actually arrived — the complaint didn’t convert into a proceeding. What arrived instead, four months after the audit summary was posted, was a letter from a plaintiff-side firm framing the 0.71 as a claim under the NYC Human Rights Law and Title VII. The audit you publish is discoverable; that is the design of the law, not a flaw in your handling of it.

What broke anyway. Three things, each instructive. First, mid-remediation, Parsonix shipped a platform-wide model update to all customers — improving the model, they said — which shifted score distributions enough to invalidate the audit baseline; the auditor’s ablation numbers no longer described the running system, and part of the analysis had to be redone. (This is why the change-notification clause exists; it didn’t yet.) Second, the litigation hold complicated everything: data the team wanted to clean and archive had to be preserved as-was, and remediation steps were suddenly being drafted with one eye on how they would read in discovery. Third, the register program that came out of the wreckage kept finding wreckage: an expense-report and SSO-log sweep surfaced 14 more AI-flavoured tools nobody had registered — a sales-call scorer, two ‘productivity analytics’ plugins, a chatbot on the benefits portal. The screening model was not an anomaly. It was a sample.

What was born. The lasting output was not the remediated screener — it was the program built so this never has to be reconstructed from an archived mailbox again. An AI register (a spreadsheet for the first quarter, then records in the existing GRC tool): every system that scores, ranks, filters, or decides about people, each with a named owner, a use description, and a review date. A procurement intake gate: six AI questions added to the vendor-intake form, with any ‘yes’ routing to a governance review before signature. A contract playbook: audit and data-access rights, bias-audit cooperation, change notification, and incident-notice clauses as standard asks for anything touching employment, credit, or customers. And an annual audit calendar, because LL144’s audit is annual and the first year taught everyone what happens when ‘annual’ has no owner.