What happened
In early 2020, an experienced tutor in her mid-fifties applied to teach English online through iTutorGroup, a Shanghai-headquartered tutoring company that recruits and contracts US-based tutors to teach students primarily in China. She entered her real date of birth on the application form. She was rejected within minutes, without an interview, without a phone call, without any reason given. She applied again the same day, with the same qualifications and an altered date of birth. She was invited to schedule an interview.
The Equal Employment Opportunity Commission investigated. What the investigation found was that iTutorGroup's application software had been configured to automatically reject women aged fifty-five and over and men aged sixty and over. The rule was not buried inside a model. It was a date-of-birth filter inside the scheduling and screening tool, applied at the moment of application, before any human reviewed a candidate.
More than two hundred qualified applicants had been rejected on age alone in the period the EEOC was able to identify. The EEOC filed suit in the Eastern District of New York in May 2022. The case is on the public docket as EEOC v. iTutorGroup, Inc., 1:22-cv-02565. On 11 September 2023, the case settled. iTutorGroup agreed to pay USD 365,000 to the affected applicants, was placed under a five-year consent decree, was required to invite each rejected applicant to reapply, and was required to adopt new anti-discrimination policies, conduct training, and submit to ongoing EEOC monitoring.
The settlement was the first the EEOC had ever obtained in a case involving an automated hiring system. The agency used the announcement to confirm publicly what its enforcement actions had long implied. When an employer's decisions are produced by an algorithm rather than a person, the employer remains responsible for the result. The decision has been cited in every subsequent US enforcement action involving AI in employment, and informed the EEOC's 2023 technical assistance document on algorithmic accountability under the ADEA.
What an auditable version would have shown
The iTutorGroup filter was, technically, the simplest kind of automated decision. An if date_of_birth < threshold then reject rule. It was not a model. It was not an opaque system. It was a deliberate, documented configuration choice. But the company could produce no internal record of who had made the choice, when, on what authority, or what alternative was considered. The discovery materials in the EEOC case relied on plaintiff-side testing, the same applicant submitting twice with different ages, rather than any contemporaneous record from the company.
A conduct record would have made the rule itself the auditable surface. Every applicant evaluation captured as a signed event, with the rule version that was applied, the inputs that were filtered on, and the decision that was reached. A monthly outcome metric, also signed, breaking down acceptance rates by protected category, would have flagged a one-hundred-percent rejection rate for applicants over the age threshold within thirty days of the rule going live. The discrimination would have been visible to the company's own compliance function before it was visible to the EEOC.
Where the gap was
The gap was not the algorithm. The algorithm did what it was told. The gap was that nobody was watching what it was told to do, and nobody was watching the outcomes.
Algorithmic hiring tools produce decisions at a volume no human screener could match and at a granularity no traditional audit can recover after the fact. A single rule applied to ten thousand applications a month leaves no individual victim's footprint visible inside the company, because each application is rejected silently and the rejected applicants do not know each other. The pattern only becomes visible when an outcome audit is run as part of the system, or when a regulator forces one from outside.
iTutorGroup ran no such audit. There was no demographic outcome monitoring, no signed log of the rule that was applied, no review process for the configuration of the screening tool. The system worked exactly as designed for at least three years before the EEOC found it. It would have continued working as designed if a fifty-five-year-old applicant had not happened to submit her application twice.
What governance should have looked like
A signed conduct record for every automated employment decision, and a signed outcome metric run on a fixed cadence, would have made this incident impossible to sustain at scale.
from headlights import ConductRecord, MetricRecord, sign, chain
from datetime import datetime, timezone
# Every automated decision captured as a signed event
record = ConductRecord(
agent_id="applicant-screener-v4",
decision_type="application-screening",
rule_version="screen-2020-03",
inputs={
"application_id": application.id,
"submitted_date_of_birth": application.dob, # captured for audit, never for filtering
"filters_applied": ["qualifications", "geography"],
# date-of-birth is NOT in filters_applied
},
decision="rejected" if rejected else "advanced-to-interview",
decision_reason=rule_engine.cite_reason(application),
timestamp=datetime.now(timezone.utc),
previous_record_hash=last_record.hash(),
)
chain.append(sign(record, key=company_key))
# At the end of every calendar month, an outcome metric is computed and signed
metric = MetricRecord(
period="2020-04",
metric_type="applicant-outcomes-by-protected-category",
breakdowns={
"age_band_55_64": {"applied": 412, "advanced": 0, "rate": 0.0},
"age_band_45_54": {"applied": 891, "advanced": 207, "rate": 0.232},
"age_band_35_44": {"applied": 1304, "advanced": 309, "rate": 0.237},
"age_band_25_34": {"applied": 2110, "advanced": 487, "rate": 0.231},
},
automated_alert_triggered=True, # rate of 0.0 in a protected band is a hard alert
timestamp=datetime.now(timezone.utc),
)
chain.append(sign(metric, key=company_key))
MetricRecord is the layer iTutorGroup did not have. A monthly outcome breakdown by protected category, signed and chained, makes a hundred-percent rejection rate in any protected band into an alert the compliance function cannot miss. The signature means the record cannot be quietly edited after the fact. The chain means the company can demonstrate to a regulator that the alert fired and what was done about it.
Pre-deployment, a separate gate runs every proposed automated decision rule against historical applicant data and reports the disparate-impact ratio under the EEOC's four-fifths rule. Any rule that produces a selection rate for a protected class below eighty percent of the rate for the most-favoured class is blocked from deployment until reviewed. Date-of-birth as a filter input would never have passed that gate.
These are not exotic primitives. They are documented practice in any mature compliance framework, and the EEOC's 2023 guidance on algorithmic accountability now expects them. The reference implementation lives in the open source repository at github.com/saffronandindia/headlights-oss, Apache 2.0 licensed, free for any company to install before its next regulator does the auditing for it.
This entry is an educational analysis based on the publicly reported sources listed below. It does not constitute legal advice. Facts are stated to the best of our knowledge as of the date of publication; corrections will be issued promptly on request. Contact: ellie@useheadlights.com.