AEDT Data Provision: What the Auditor Needs

When the Data Request Lands in Your Inbox

Your independent auditor emails a data request three weeks before the annual audit is due, and it's longer than you expected: applicant records by role, disposition outcomes, demographic self-ID fields where collected, the date range the AEDT was actually in use, and a note on any periods the tool was paused or reconfigured. You have most of this somewhere — spread across the ATS export, an HR analyst's spreadsheet, and an email thread with the vendor from eighteen months ago. Nothing is in one place, and nothing is labeled the way the auditor asked for it.

This is the moment where a lot of Local Law 144 timelines slip — not because the audit itself is hard, but because nobody organized the raw material before the auditor needed it. The auditor doesn't build your data set. You do. They compute the selection rates and impact ratios; you're the one who has to know where every field lives, whether it's complete, and what to do when it isn't.

By the end of this piece, you'll know exactly what a bias auditor typically asks for, how to tell whether you're handing over historical data or test data, and how to package it with a manifest that survives a follow-up question.

AEDT Data Provision: What the Auditor Actually Needs From You

Local Law 144 puts the computational work — selection rates, impact ratios, the bias audit's actual math — on the independent auditor's side of the table. But an auditor can only compute what you give them. That's the core of AEDT data provision: the employer assembles and hands over the underlying records; the auditor turns those records into the audit.

In practice, most auditors are asking for some version of the following:

• Candidate/employee-level records run through the AEDT during the review period, tied to a role or job category.
• Disposition outcomes — who advanced, who didn't, and at what stage the AEDT's output entered the decision.
• Demographic categories where legally collected (often via voluntary self-identification), broken out by the sex, race, and ethnicity categories the audit's impact-ratio calculations rely on.
• A record of the AEDT's deployment window — when it went live, any pause periods, and any material reconfiguration or retraining that could split the audit into "before" and "after" segments.
• Vendor-supplied documentation describing what the tool scores and how its output feeds the hiring decision.

None of this is exotic. What trips employers up is that the data usually doesn't exist in one clean export — it's scattered across an ATS, a vendor portal, and whatever manual tracking someone set up when the tool first went live.

Historical Data vs. Test Data: Which One Your Auditor Is Asking For

The audit is supposed to reflect how the AEDT actually performs on real people, so an auditor's strong preference is your genuine historical selection data — the actual candidates or employees who went through the tool, with real outcomes attached.

The complication is volume. A newly deployed AEDT, or one used on a small applicant pool, may not have enough historical records yet to produce a statistically meaningful selection-rate comparison. In that situation, an auditor may work from test data instead — records built or sampled specifically to represent the deployment, structured to stand in for what historical data would eventually show.

Which one applies to your engagement, and exactly how much historical volume is "enough," is a judgment your auditor makes based on your specific deployment. Don't guess at the threshold yourself — ask your auditor directly which category your data set falls into, and confirm the current expectations with DCWP if the answer isn't clear-cut. What you can control is showing up with both possibilities covered: real historical records where they exist, and a clean explanation of exactly why they don't where they're thin.

The Fields, Format, and Gaps to Check Before You Send Anything

Before any file goes to the auditor, run it through a gap check. Four things go wrong most often:

1. Missing demographic fields. If self-ID data wasn't collected consistently, or was collected but never linked back to the AEDT-scored record, the auditor can't compute an impact ratio for that group — and a gap here is exactly the kind of thing that has drawn outside scrutiny. A 2025 academic review of published Local Law 144 audits found that many under-report disparities specifically because of missing demographic data, opaque aggregation choices, and metrics that don't reflect how the tool was actually deployed. Your job is to make sure your data set isn't a contributor to that problem.
2. Role misclassification. If candidates for materially different jobs are lumped into one category, the selection-rate math gets diluted. Tag roles consistently before the export, not after the auditor asks why the numbers look strange.
3. Date-range mismatch. If your export window doesn't line up with the AEDT's actual deployment period — including any pause or reconfiguration — the auditor may be comparing outcomes to a tool that wasn't running the same way the whole time.
4. Format inconsistency. Free-text disposition notes instead of structured outcome codes, inconsistent date formats, duplicate records from ATS re-exports — none of these are audit failures on their own, but each one adds a round-trip email to your timeline.

As a worked example of why the demographic fields matter: if your data shows a 90% selection rate for one group and a 60% selection rate for another, that 60% is two-thirds of the 90% rate — below the four-fifths (80%) benchmark commonly used to flag a possible adverse-impact signal. That's not a finding on its own — the auditor's actual methodology governs the real result — but it shows why a missing or incomplete demographic field isn't a paperwork nuisance. It's the field the entire calculation depends on.

Employer Prepares, Auditor Computes: Where the Line Sits

This is worth stating plainly, because it's easy to blur under deadline pressure: preparing and organizing your data is an operational task, not a legal or audit determination. You are not scoring anyone, you are not computing an impact ratio, and you are not deciding whether a result constitutes bias. That work belongs to your independent auditor. Nothing in this article, and nothing in a data-prep workbook, substitutes for that engagement or for legal advice — if a question comes up about whether your data set is sufficient, or whether a result needs a specific disclosure, route it to your auditor or to counsel, not to a template.

What you control is getting clean, complete, well-labeled material to the auditor on time, with a documented account of what you sent and why. That's the operational half of the audit relationship, and it's the half most likely to slip when nobody owns it explicitly.

Building a Transfer Manifest the Auditor Can Actually Use

A transfer manifest is just a cover document that travels with the data set: what's included, what's excluded and why, the date range, the field definitions, and a signature line showing who prepared it and when. It does three things for you:

• It gives the auditor a map instead of a raw file to reverse-engineer.
• It creates a dated record that you provided a complete data set — useful if a question ever comes up later about what the auditor did or didn't have.
• It forces the gap check described above to happen before the handoff, not during it.

The manifest isn't extra paperwork on top of the audit — it's the difference between "we sent a spreadsheet" and "we can show exactly what we sent, when, and why it was complete."

Your First Action Item

If you're staring at a data request with three weeks on the clock, the fastest path forward is a structured starting point rather than a blank spreadsheet. The AEDT Data-Provision & Historical-Data Prep Workbook walks through the field checklist, the historical-vs-test-data decision points, the gap-flagging steps, and a ready-to-fill transfer manifest — so your first response to the auditor is organized instead of improvised.

For more on how auditors scope their side of the engagement, see our breakdown of what data a bias auditor actually needs and the deeper comparison of historical data vs. test data in a bias audit. If you haven't yet nailed down engagement scope with your auditor, start with independent auditor engagement scope under Local Law 144 and our guide to choosing an independent bias auditor. And if you're still mapping the full compliance picture, our NYC Local Law 144 compliance guide is the place to start.

Download the workbook, build the manifest, and hand your auditor a data set they can work with the first time.