Atlas Bias Audit Methodology

Atlas does not infer protected attributes from any data source — not names, photos, schools, or any other proxy. This is a hard line, restated in CLAUDE.md and enforced at the route layer (see /api/oi/roster-ai-query input + output filter).

All demographic data used in a bias audit arrives intact from the customer's HRIS export (with employee consent), never reconstructed by Atlas. The customer is the controller of demographic data; Atlas is the processor of audit math.

Three Atlas surfaces emit "selection" events that are auditable for disparate impact:

• Opportunity Intelligence— an employee is "selected" when scored above the good_fit threshold (60+) for a given opportunity. Audit runs per opportunity, then aggregates across opportunities for a workspace.
• Roster AI Query— an employee is "selected" when returned as a match in the response payload to a recruiter's natural-language query.
• Talent Phantom— an external candidate is "selected" when surfaced in the search results for a given JD.

For each protected dimension supplied in the customer overlay (age band, gender, race/ethnicity, disability status, veteran status, national origin), Atlas computes:

• Selection rate per cohort = selected / population for that cohort
• 4/5 ratio= lowest cohort's selection rate ÷ highest cohort's selection rate
• Flagwhen 4/5 ratio < 0.80 (the EEOC 80% rule for disparate-impact evidence)

When any cohort has fewer than 30 employees, the runner surfaces the ratio for transparency but suppresses the auto-flag — small-sample noise produces spurious ratios on sub-30 cohorts (EEO-1-adjacent rule of thumb).

• Does not infer protected attributes.Ever. If a customer fails to supply an overlay, the audit returns a structured "skipped — supply overlay" skeleton rather than fabricating cohorts.
• Does not auto-mitigate.Flagged dimensions are surfaced for the customer's compliance team to review and decide. Atlas does not silently rescore or reweight to make the flag disappear — that would be adverse-impact adjustment, which has its own legal risks and belongs to the customer's policy decision.
• Does not run intersectional cohorts. Each protected dimension is audited independently. Intersection amplifies small-sample noise + creates re-identification risk on small workforces.
• Does not predict bias-correlated outcomes (performance, turnover, retention). See the "lines never to cross" section of AI Use Policy.

The audit runner is a pure, deterministic function: src/lib/bias-audit/runner.ts. Same inputs always yield the same outputs. No clock reads, no randomness, no LLM calls.

Admin trigger: POST /api/admin/bias-audit/run (gated to the workspace admin allowlist). Body: { surface: "opportunity_intelligence" | "roster_ai_query" | "talent_phantom" }.

Scaffolding ship 2026-06-29: the runner + admin route are live; ProtectedClassOverlay upload + the bias_audit_runs persistence table land when the first paying customer with a demographic-overlay export onboards.

This methodology is designed to support documentation requirements under:

• NYC Local Law 144 (AEDT)— automated employment decision tools require annual independent bias audits. Atlas provides the data + math; the customer's third-party auditor reviews the runs.
• Colorado AI Act (effective 2026) — consequential-decision AI in employment requires a risk management policy + annual impact assessment. The runner output is the assessment artifact.
• Illinois HB 3773 (effective 2026) — notice + bias-audit requirements analogous to NYC LL 144.
• EU AI Act Article 27 — fundamental rights impact assessment for high-risk workforce-management AI.

This page is informational, not legal advice. Customers should engage their own employment counsel for jurisdictional applicability and compliance posture.