Elena leads talent acquisition at a 1,200-person financial services firm, with a team of six recruiters who hire across customer service, operations, and software roles. Over the past year her team has folded three AI tools into the workflow: a resume-screening assistant, an interview-scheduling bot, and a video-interview platform that scores structured responses. Each tool was adopted by a different recruiter solving a different problem, and nobody wrote any of it down. When the firm's compliance officer asked Elena a simple question, "if a rejected candidate's lawyer asked how our process works and where AI touched their application, could you answer in writing today," she could not. That question is the reason this project exists.

What You Are Building, and the Auditor in the Room

The deliverable is a documentation package Elena could hand to her legal team, her leadership, or an external auditor and say: this is how we recruit, this is where AI is used, this is how a human stays in the loop, and this is how we check it for fairness. By this point you already know what should be documented, meaning workflows, decisions, AI tools, fairness monitoring, and legal compliance. This project is where that theory meets practice, and the test of whether you built it well is whether someone outside your team could read it and understand your process without asking a single question.

Many recruiting teams avoid documentation. It feels bureaucratic. It feels like it slows you down. It feels like something you do after the fact, once problems arise. That instinct is backward. Good documentation is a strategic asset, not overhead added at the end: it helps you recruit better, make faster decisions, solve problems as they come up, and defend your process if it is questioned. The project assumes you have already designed your recruiting process, integrated AI tools, and put workflows in place. What you are doing now is writing down what you are actually doing and making sure it is solid.

A complete package has eight components: a process overview, AI tool documentation, decision criteria, documentation standards, a fairness monitoring plan, data handling and compliance, a legal compliance checklist, and a change log. The rest of this lesson walks through each one, using Elena's firm as the running example. Build them in order, because each depends on the one before it: you cannot document criteria for a decision point you have not yet named on a map, and you cannot monitor fairness at a stage you have not yet identified as AI-touched.

Component One: The Process Map

Elena starts with a high-level visual map of her process, stage by stage, from application to offer. It is deliberately simple, not a detailed step-by-step procedure: an overview showing where candidates come from, meaning the sourcing channels; where the decision points sit; who makes the decision at each point; where AI is used; where humans review AI output; and what happens to candidates who do not move forward. A map that fits on one page is one people will actually read; a forty-page process manual sits on a shelf.

Her map runs: application and sourcing, then resume screening with AI assist plus recruiter confirmation, then phone screen owned by the recruiter, then structured assessment, which is an AI-scored video for software roles and human-scored for others, then a review step where an engineer reads the assessment results alongside the AI output, then the panel interview with the hiring manager and panel, then reference and background check, then the final decision made jointly by the hiring manager and recruiter, then offer or rejection with feedback. That is a simple view, and simplicity is the point. Anyone looking at it understands the process and can point at a specific decision point, so that if questions arise later you have a shared picture to argue from rather than three people's differing recollections.

The value of drawing it is not the picture. It is that the act of drawing forces Elena to name exactly which stages are AI-touched and which are purely human, which is the foundation for everything that follows. If you cannot point to where AI sits in your process, you cannot document, govern, or defend it. The map also earns its keep in three ordinary situations that have nothing to do with lawyers. If a candidate later questions why they were not hired, you can show them how the process works. If your legal team wants to understand how AI was used, they can see it in the workflow rather than interviewing each recruiter separately. And if you are training a new recruiter, they understand your system on day one.

Component Two: The AI-Use Register and the Tool Sheet

The centerpiece of the package is the AI-use register. For every AI tool in the process, Elena records the same set of facts in the same structure, so that any reviewer can scan one table and understand the firm's entire AI footprint in recruiting. Each row names the stage, the tool and its purpose, what it assesses, the human checkpoint, and the key risk with its matching control. Her screening assistant ranks applicants against role criteria on skills and experience match to the job description; a recruiter confirms every advance and every reject, so the tool never auto-rejects; the risk is adverse impact from proxy variables, and the controls are a monthly four-fifths check and a documented vendor bias audit kept on file. Her scheduling bot matches candidate and interviewer availability and evaluates no candidate at all; a recruiter reviews exceptions and accommodation requests; the risk is accessibility gaps, and the control is a manual scheduling path offered on request under the ADA. Her video platform scores responses to fixed questions for software roles against a rubric, with recruiter and hiring manager review before any decision and no auto-rejection on a low score; because it scores candidates it is an automated employment decision tool, which brings a bias audit, candidate notice, and an alternative assessment route.

The register is the summary view. Behind each row sits a fuller one-page information sheet for that tool, and this is where most teams stop too early. The sheet should carry eleven fields.

• Tool name and vendor, plus the version where the version matters.
• Purpose, stated as the problem the tool solves: screening resumes, predicting fit, scheduling interviews.
• How it works, in plain English rather than technical jargon, including what input it needs and how it generates output.
• What it measures or assesses.
• Vendor validation data: what the vendor claims about accuracy and fairness, and whether they have tested it.
• Your internal validation: whether you have tested it against your own applicant pool and checked fairness metrics with your specific data.
• How output is used: as a filter or a recommendation, whether human review is required, and whether candidates can appeal.
• Human review process: who reviews AI recommendations, what training they have, and how they override the tool when needed.
• Data sources feeding the tool, such as job performance data, interview feedback, or resume elements.
• Data retention: how long data is kept, and whether it is deleted after the hiring decision or after a set number of months.
• Appeals or escalation: what happens if a candidate disagrees with the AI output, and whether they can request human review.

The most important column in the register is the human checkpoint, because it is the documented proof that no candidate is rejected by a machine alone. But the internal validation field is what separates a serious package from a performative one. A vendor's fairness claim is about their data, not yours; your documentation has to answer whether the tool behaves acceptably on the applicants who actually apply to you. There is also a quieter payoff to this level of detail. A tech company used an AI tool for phone screen scheduling and told candidates nothing about it. The tool matched availability algorithmically, and some candidates found the scheduling frustrating and seemingly arbitrary. When the company documented the tool and explained its logic to candidates, perception changed, and it changed not because the logic changed but because transparency changed how candidates interpreted the same behavior. Your legal team needs this detail to understand your AI use; you need it to audit past decisions; and new team members need it to understand what each tool cannot do as much as what it can.

Component Three: Decision Criteria Written in Job-Related Terms

A process map shows where decisions happen; decision-criteria documentation shows how they are made. For each major yes-or-no point, Elena writes down what advances a candidate, what stops them, and what is merely a nice-to-have. Take the phone screen pass or no-pass decision. Her pass criteria are relevant experience in the core technology area, with a stated minimum of one year of demonstrated experience; clear communication ability, meaning the candidate can articulate their past work and their thinking; and genuine interest in the specific role rather than in any job. Her no-pass criteria are missing critical skill requirements, for example no Python experience where Python is required; communication barriers that genuinely prevent understanding; and red flags surfaced by the background check.

Two of those no-pass criteria carry notes that are the most legally sensitive lines in the package, and they must be written down rather than left to a recruiter's judgment in the moment. On communication: this is different from accent or non-native English. Everyone with non-native English will still be assessed on communication skills, but accommodations will be made. The criterion is clarity of substance, not the sound of the speaker. On background checks: document what a red flag actually means for this specific role, because an unspecified red flag is where arbitrary judgment hides, and criteria that are not job-related are exactly the kind of screen that produces disparate outcomes without producing better hires.

Explicit criteria are what let two different recruiters reach the same conclusion about the same candidate, what let Elena explain a rejection months later in concrete, job-related language rather than "it wasn't a fit," and what give a candidate who asks for feedback something real to hear. When you look back at a batch of decisions a quarter later, written criteria are the only way to check whether the decisions actually followed them. Vague criteria are where inconsistency and bias both live, and after the fact the two are indistinguishable.

Component Four: The Documentation Standard That Makes It Happen

Naming what should be documented is not the same as ensuring it gets documented. Component four defines how decisions are logged and what information is captured, which is the operational half of the package. Elena's standard is short and specific enough to audit. All phone screens are logged within 24 hours, and each log includes the date, the interviewer, the candidate feedback, the pass or no-pass decision, and a brief reason for that decision. All rejections include the feedback statement actually sent to the candidate. All AI tool outputs are flagged and reviewed by a human before a decision is made. Fairness metrics are spot-checked monthly. Any anomaly is logged and escalated rather than absorbed quietly by whoever noticed it.

Every one of those lines is written as an observable event with a time bound, which is what makes the standard enforceable. "Log phone screens promptly" is a wish; "log phone screens within 24 hours" is something you can sample ten records against. Documentation does not happen by accident; it needs process. When it is standardized it becomes habit, and when it is expected, people do it. When it is not standardized it happens sporadically, and sporadic records create the appearance that some candidates were documented and others were not.

Component Five: The Fairness Monitoring Plan

Documentation that never checks itself is just description. The fairness monitoring plan is your plan for detecting and preventing bias, and it needs five parts. First, the metrics you track, whether that is adverse impact at each stage, interview scores broken out by demographic group, offer rates by source, or time-to-feedback across groups. Second, the frequency, whether weekly, monthly, or quarterly, written down, because an unnamed cadence becomes no cadence. Third, the disparate-impact threshold that triggers action, and what that action is. Fourth, the investigation process, meaning who looks at what and in what order when you spot a potential problem. Fifth, the corrective actions on the table when bias is confirmed: retraining the model or the interviewers, changing the criteria, or auditing past decisions made under the old criteria.

Elena's core metric is selection rate by group at each AI-touched stage, checked monthly against the EEOC four-fifths rule: if the selection rate for any group falls below 80 percent of the highest group's rate, the stage is flagged for investigation. In one month the screening stage advances 50 percent of applicants in the highest-advancing group and 36 percent of another group. The ratio is 36 divided by 50, which is 0.72, below the 0.80 threshold, so the rule is tripped and the stage is investigated. Elena's team finds that the screening tool was over-weighting a credential that correlated with the disparity, adjusts the criteria, retests, and logs the change. The four-fifths rule is a screening heuristic that flags a disparity for further analysis, not a final finding of discrimination, but it is exactly the kind of tripwire a monitoring plan should encode so that a slow drift gets caught before it compounds across hundreds of decisions.

A second real example shows that the disparity you find is often not where you were looking. A company tracked offer rates by gender and noticed that for engineering roles, men were offered positions at a 35 percent rate and women at 28 percent. That is not a huge gap, but it was consistent, so they investigated. The cause turned out to be that interviewers' rubrics were not clearly defined: some interviewers weighted nice-to-have skills heavily, and the men in their pool happened to have more of those skills. They tightened the rubrics, provided interviewer training, and re-monitored. Offer rates equalized. No AI tool was implicated and no one intended anything unfair; the monitoring is what turned an invisible drift into a fixable rubric problem. Fairness does not happen by good intention. It requires measurement, investigation, and action, and a written plan is what makes that systematic rather than occasional.

Component Six: Data Handling and Candidate Rights

The sixth component documents how candidate data is collected, stored, used, and deleted. Start with collection: what information you collect, at what point, from what sources, and with what consent. Then storage: where the data lives, who has access, and what security measures protect it. Then usage: how the data is used, who can see it internally, and whether it is shared with any third party, which for most teams includes at minimum the AI vendors in your register. Then retention: how long you keep candidate data and when it is deleted. Then compliance: how your approach aligns with GDPR, CCPA, FCRA, and any relevant local law. Then candidate rights: whether candidates can request their data, request deletion, or opt out of particular uses, and how they make that request.

This component connects directly to the tool sheets in component two, and the two should agree. If the screening assistant's sheet gives a retention period, the data-handling document has to state the same period, and both have to match what the vendor's contract actually permits. Contradictions between your own documents are worse than gaps, because a gap reads as incompleteness while a contradiction reads as a process nobody controls. Privacy laws are increasingly strict, and documentation shows you are taking them seriously. It also has immediate operational value: when a data question arises, whether a breach, a deletion request, or a candidate asking who saw their video interview, you have a clear policy to act on rather than an improvised answer. Candidates appreciate knowing how their data is treated.

Component Seven: The Legal Compliance Checklist

The checklist maps each legal obligation to how the process meets it, phrased as questions you can answer yes or no. Because Elena's structured-assessment tool scores candidates, it qualifies as an automated employment decision tool, which means that for any hiring in New York City the firm must comply with Local Law 144: an independent bias audit of the tool conducted within the prior year, publication of a summary of the most recent audit results, and notice to each candidate at least 10 business days before the tool is used, stating the qualifications and characteristics it assesses.

The rest of the checklist runs through the regimes that apply to nearly every recruiting team. Under FCRA, the Fair Credit Reporting Act: do you use background checks, and if so are you following FCRA requirements; do you notify candidates before running one; and do you provide an adverse action notice if the results affect the hiring decision. Under EEO: are you recruiting without discrimination based on protected characteristics; are you tracking recruiting metrics by demographic group even if you are not publicizing them; and can you demonstrate that decisions were merit-based. The EEOC adverse-impact framework and the four-fifths rule are the analytical machinery behind that last question, which is why component five feeds this checklist directly. Under the ADA: are your job descriptions, application forms, and interviews accessible; do you provide reasonable accommodations for candidates with disabilities; and do you have a named person candidates can contact if they need one.

State and local law adds obligations that vary by where you hire, so list them by jurisdiction rather than in general. If you operate in Colorado, do you follow Colorado's salary history law, which prohibits asking for salary history. If you operate in California, do you follow California ban-the-box law, which prohibits asking about criminal history early in the process. International hiring adds its own layer: GDPR in Europe, including the rights around automated decisions, plus data protection law in any other country where you recruit, and the EU AI Act classification of recruitment systems as high-risk, with its human-oversight and record-keeping duties. Elena does not interpret any of these alone; her checklist flags each one for review with counsel. You are not a lawyer, but you do need to understand whether your process is legally defensible, and a checklist makes that concrete while demonstrating to a reviewer that you thought about compliance before you were asked to.

Component Eight: The Change Log

The final piece is a dated record of how the process evolves: what changed, why, whether fairness testing was done, and what the impact was. Elena's entries are short. One reads: first quarter; implemented a new AI resume screening tool; reason, the previous manual screening was a bottleneck and the tool reduces time-to-screen by 60 percent; fairness testing completed, yes, with no disparate impact detected; impact, all new applications from March 1 use the new tool. Another reads: second quarter; added fairness monitoring for interview feedback by gender; reason, a spot check revealed potential bias in how male and female candidates received feedback; action taken, interviewer training on structured feedback; impact, more consistent feedback and a baseline established for ongoing monitoring.

Two things are worth noticing. The fairness-testing field is present in both entries, which means the log doubles as evidence that testing accompanied change rather than trailing it. And the second entry documents a problem the team found in itself: a change log that records only improvements is a marketing document, while one that records what went wrong and what you did about it is the one that carries weight. When someone asks a year from now why the screening criteria look the way they do, the answer is a log entry, not a guess, and when you are troubleshooting a sudden shift in pass rates, knowing what changed and when is usually the whole investigation.

Three Anti-Patterns

Documenting after the fact instead of as you go. Many teams skip documentation while executing, then try to reconstruct it later. By then institutional knowledge has faded, people remember decisions differently, and details are lost. It fails because the documentation ends up incomplete and inaccurate, and because recreating it is painful; when you finally need it for a legal question, an audit, or a fairness investigation, it is not helpful. The fix is to integrate documentation into the process itself. Create a template and make it a step in the workflow rather than a task after the workflow. After the phone screen, log it. After the interview, document the feedback. After the hiring decision, document why. Small habits compound into complete documentation, and none of them individually take more than a few minutes.

Making documentation only for legal. Some teams treat documentation purely as a compliance artifact, so they produce defensive, legalistic documents. Lawyers review and approve them, and the recruiting team never opens them again. It fails because the documentation becomes separate from the actual work: it is not useful operationally, new recruiters do not read it, and it sits on a shelf going stale. The fix is to make it useful for your team. Write it in plain language, include it in training, and reference it in conversation, so that when someone asks why a decision was made you point at the documentation. The paradox is that documentation written to be operationally useful also turns out to be the more defensible kind, because it describes what really happens.

Documenting too much or too little. Some teams document every single detail, which is overkill; others document almost nothing, which is risky. Too much documentation is overwhelming, expensive to maintain, and quickly outdated, so people stop trusting it. Too little leaves you exposed the moment questions arise. The fix is to document what matters: your overall process, your AI tools and how they are used, your decision criteria, your fairness monitoring, and your data handling. Do not document every phone screen conversation. Do document your phone screen decision criteria. The distinction is between the individual instance and the rule that governs the instances, and it is the rule that carries both the operational and the legal weight.

Practice

• Create your visual workflow map. Draw or describe your process from application to offer or rejection, showing decision points, AI touchpoints, and human review points. Keep it high-level. If you are stuck, start with these stages: application, screening, phone screen, interviews, final decision, offer.
• Document one AI tool. Pick one tool you use or plan to use and create a one-page sheet covering name, purpose, what it assesses, how it works, validation results, how output is used, the human review process, data sources, retention, and appeals. Do not worry about perfect language; capture the essential information.
• Create decision criteria for one key decision point. Pick one moment where you make a yes-or-no call, whether the phone screen, an interview decision, or the reference check. Document the criteria explicitly: minimum qualifications, deal-breakers, and nice-to-haves.
• Design a documentation standard. Define what information must be captured, when, and in what format, and how you will ensure people actually do it. Produce a simple template or checklist rather than a policy essay.
• Outline your fairness monitoring plan. Name the metrics, the frequency, what you will do if you spot potential bias, your investigation process, and your corrective action process. Keep it to one page.
• Create a compliance checklist. Identify the requirements relevant to your recruiting, including FCRA, EEO, ADA, applicable state and local law, and GDPR if it applies. For each, document whether and how you are compliant, and note the gaps.

Reflection

• What aspect of your current recruiting process would you most want to document, and why that one first?
• If you were a candidate, what documentation would give you confidence that you were treated fairly?
• What is one AI tool you use but do not fully understand? That is the one to document first.
• If your legal team asked to audit your recruiting process tomorrow, how ready would you be, and what would be missing?
• How would documentation change your ability to make recruiting decisions, not just to defend them?

Glossary

• Disparate impact. A legal concept where a policy or practice has a disproportionate negative effect on members of a protected group, even where there was no intent to discriminate. In recruiting it means decisions that result in different outcomes for different groups.
• Adverse impact. Hiring decisions or processes that disproportionately exclude candidates from protected groups. It must be monitored and corrected, not merely noted.
• Documentation standard. A template or checklist defining what information must be documented, when, and in what format. Standardization is what produces consistency and completeness.
• Fairness metrics. Quantitative measurements used to assess whether outcomes are equitable across groups, such as offer rate by gender, time-to-feedback by demographic group, or interview advancement rate by source.
• Compliance framework. The set of laws, regulations, and internal policies that govern a process. In recruiting it includes FCRA, EEO, ADA, GDPR, state and local law, and your own internal policies.
• Change log. A historical record of changes to a process, including what changed, when, why, and what impact it had. Used both for understanding your own evolution and for troubleshooting.

Related Lessons

• Documentation and Evidence: Building a Trail for Compliance covers the per-candidate record that sits underneath this package, including retention periods and the fields an AI-assisted decision has to capture.
• Documentation Standards: What to Document and How Much Detail goes deeper on the proportionality question raised by the third anti-pattern, across a wider range of hiring situations.
• Decision Logging: Recording Human Decisions, AI Input, and Reasoning is the mechanics of component four, and specifically of keeping the AI's input and the human's decision in separate fields.
• Fairness Metrics: Defining and Measuring Bias in Outcomes expands component five beyond the four-fifths rule into the fuller set of measures you might track.
• Compliance and Legal Review: Documentation for FCRA, EEO, and GDPR maps each regime in component seven to the specific evidence it expects.
• Hands-On Project: Audit a Recruiting Workflow for Bias is the natural companion project: this one documents the process, that one stress-tests it.

Closing

Documentation is how you turn an intuitive recruiting process into a defensible one. When you document what you do, why you do it, and how you ensure fairness, you build a system you can explain, defend, and improve. The package is not busy work: it tells your leadership what you are doing, your team how to stay consistent, your legal team that you are compliant, auditors that you have thought about fairness, and candidates that you are intentional. Most companies recruit ad hoc, decide on intuition, and hope no one asks.

Start with what you have, even if it is incomplete. Pick one component, document it, then move to the next. Over a few months you will have a complete picture, and your process will have improved simply because writing it down exposes the parts that do not make sense. The difference between Elena before this project and Elena after it is not that her process changed. It is that she can now answer her compliance officer's question in writing, on the day it is asked.

Key Takeaways

• Complete documentation has eight components. A process overview, tool documentation, decision criteria, documentation standards, fairness monitoring, data handling, legal compliance, and a change log. Build them in that order, because each depends on the one before it.
• Documentation serves two purposes. Defensibility, if you are questioned, and operationality, meaning it helps your team work better. A package that serves only the first purpose will not be maintained, and one nobody reads improves nothing.
• Start with a one-page process map. Naming each stage, its decision owner, and where AI touches the candidate is the foundation. If you cannot point to where AI sits, you cannot document, govern, or defend it.
• The AI-use register is the centerpiece, and the tool sheet is its depth. One row per tool with stage, purpose, what it assesses, the human checkpoint, and the key risk and control; behind each row, a sheet covering vendor validation, your own internal validation, data sources, retention, and the appeals path. The human-checkpoint column is the proof that no candidate is rejected by a machine alone. If you cannot explain what a tool does, you should not be using it.
• Write decision criteria in job-related terms. Explicit pass, no-pass, and nice-to-have criteria let two recruiters reach the same conclusion and let you explain a rejection concretely. Communication is assessed on clarity of substance, never on accent or non-native English, and accommodations are available.
• Standards are what make documentation actually happen. Time-bound, observable rules such as logging phone screens within 24 hours and flagging every AI output for human review before a decision turn intention into habit.
• Fairness monitoring is not optional. Track selection rate by group at each AI-touched stage and check it monthly against the EEOC four-fifths rule. A ratio below 0.80 is a tripwire for investigation, not a verdict. Name your metrics, cadence, threshold, investigation process, and corrective actions in advance.
• Map every obligation to a control. NYC Local Law 144 requires an independent bias audit within the prior year, published results, and 10-business-day candidate notice for automated employment decision tools. EEOC, ADA, FCRA, state and local law, GDPR, and the EU AI Act each impose their own duties; flag each for counsel rather than assume it.
• Keep a change log. A dated record of what changed, why, whether fairness testing was done, and what the impact was turns "I think we changed that" into a defensible answer.

Frequently Asked Questions

Where do I start if I have nothing? Start with the process map, because everything else references it and it is the one component you can finish in an afternoon. Then document the single AI tool that touches the most candidates, since that is where your exposure concentrates. Do not try to produce all eight components at once. An incomplete package that is accurate is far more useful than a complete one assembled from guesses.

Our AI vendor gave us their bias audit. Does that cover component five? No. A vendor's audit tells you how the tool performed on the vendor's data, and it belongs in the tool sheet as vendor validation, but it is not internal validation and it is not monitoring. Fairness monitoring measures what happens to your applicants in your process on your cadence. Keep the vendor's audit on file, since Local Law 144 requires one conducted within the prior year for automated employment decision tools, and run your own selection-rate checks alongside it.

How do I document a criterion that is genuinely subjective, like communication ability? Define it in terms of an observable behavior and write down what it is not. Elena's criterion is that the candidate can articulate their past work and their thinking, which two recruiters can assess against the same standard, and the accompanying note states that it is assessed separately from accent or non-native English and that accommodations are available. Subjectivity is not the problem; unstated subjectivity is.

What if documenting our process reveals that our process is not defensible? That is the project working. Finding a gap while you are writing it down is far cheaper than finding it during a charge or an audit, and the change log exists precisely to record the correction. Note the gap, decide whether the fix is a criteria change, a new human checkpoint, or a conversation with counsel, and log what you did and when. A documented gap that was found and closed reads very differently from an undocumented gap that someone else finds.