Documentation is Your Insurance Policy

Good documentation serves two purposes: learning and defensibility. Without documentation, you can't trace what happened, why decisions were made, or what checks were in place. When questioned by regulators, lawyers, or candidates, documentation is your evidence.

Documentation doesn't have to be perfect or comprehensive. It needs to be clear, current, and sufficient to answer: "How did we make this decision? What checks occurred? Why did we do it this way?"

Five Categories of Documentation

1. Tool Documentation

What to document:

• Tool name, vendor, version deployed
  - What the tool does (specific function in your workflow)
  - Input data (what does it need?)
  - Output (what does it produce?)
  - Configuration (weights, thresholds, decision rules)
  - Any updates or changes made to the tool
  - Accuracy and fairness metrics (latest audit results)

Detail level: Enough that someone new could understand the tool and how it works. Don't need source code or algorithm details; focus on what you did and why.

Format: 1-2 page document per tool. Update immediately if tool changes.

2. Workflow Documentation

What to document:

• Step-by-step process (sourcing -> screening -> interviews -> offer)
  - Who does what at each step
  - What decisions are made (by whom? based on what?)
  - Quality gates and checkpoints
  - Escalation paths (what happens if something's wrong?)
  - Timing (SLAs for each step)

Detail level: Specific enough that a new team member could follow it. Not so detailed it becomes unmanageable.

Format: Flowchart + written steps. 2-3 pages per workflow.

3. Decision Criteria

What to document:

• Hard requirements (non-negotiable)
  - Soft criteria (preferred but not required)
  - Scoring rubric (if scoring is used)
  - Thresholds (who advances? who filters?)
  - Exception process (how to override standard criteria?)

Detail level: Specific and measurable. "Strong technical background" is too vague. "5+ years Python programming, demonstrated by GitHub or work history" is better.

Format: 1-2 pages. Simple table format works well.

4. Quality Monitoring and Audit Results

What to document:

• Weekly/monthly quality audit results
  - Fairness audit results (disparate impact analysis)
  - Candidate feedback (surveys, complaints)
  - Incident reports (when something went wrong)
  - How you responded to issues found

Detail level: Specific findings, not just "all clear." If something was found, document root cause and fix.

Format: Spreadsheet for tracking. Narrative for incident reports.

5. Change Log

What to document:

• When tool versions change
  - When process changes
  - When criteria change
  - Team training (who trained on what?)
  - Why changes were made

Detail level: Enough to know what changed and why, not detailed explanations of how.

Format: Simple changelog format (date, what changed, why, owner).

The Right Level of Detail

Too Vague (Not Defensible)

"We screen candidates for technical fit."

Documentation Maintenance: Keeping It Current

Doc Type
Update Frequency
Owner
Trigger for Update

Tool Documentation
Immediately if tool changes
Recruiting Ops
New version, config change, bug fix

Workflow Documentation
Quarterly review; immediately if changes
Recruiting Ops
Process change, new tool, feedback from team

Decision Criteria
Quarterly review; immediately if changes
Recruiting Manager
Role requirements change, business need changes

Quality Monitoring
Weekly/monthly logs; quarterly summary
Recruiting Ops
End of week/month per schedule

Change Log
Immediately upon change
Change owner
Any change to tool, process, or criteria

Documentation Tools and Systems

Option 1: Shared Folder + Documents

Structure:

Recruiting folder

+- AI Tools

| +- Tool_ResumesScreening_v1.2.gdoc

| +- Tool_Scheduling_v2.1.gdoc

| +- Tool_Sourcing_v1.0.gdoc

+- Workflows

| +- Workflow_ScreeningToOffer.gdoc

| +- Workflow_SourcedCandidates.gdoc

+- Criteria

| +- Criteria_TechnicalRoles.gdoc

| +- Criteria_SalesRoles.gdoc

+- Audits

| +- WeeklyAuditLog.gsheet

| +- MonthlyFairnessAudit.gsheet

| +- IncidentReports.gsheet

+- ChangeLogs

+- ChangeLog_Master.gsheet

Pros: Simple, accessible, version history built-in

Cons: Can become disorganized if you have many tools/processes

Option 2: Spreadsheet Hub

Single Google Sheet with tabs:

• Tool Documentation (columns: Tool Name, Vendor, Version, Function, Input, Output, Last Updated)
• Workflow Overview (columns: Step, Owner, AI Role, Human Role, Quality Gate)
• Decision Criteria (columns: Role, Hard Requirement, Soft Criteria, Scoring Rubric)
• Audit Log (columns: Date, Type, Findings, Action, Status)
• Change Log (columns: Date, Category, What Changed, Why, Owner)

Pros: All in one place, searchable, easy to share

Cons: Can become unwieldy if comprehensive; doesn't work well for narrative docs

Option 3: Wiki or Confluence

Pros: Professional, searchable, version control, collaborative

Cons: Requires tool investment, higher maintenance overhead

Best for: Larger organizations with multiple hiring teams and frequent updates

The Defensibility Checklist

If a regulator asked to audit your recruiting process, could you hand over documentation that shows:

• Clear, written criteria for screening candidates
  - Documentation of any AI tools used (what they do, how they work)
  - Evidence that you monitor for fairness (audit results, disparate impact analysis)
  - Record of decisions made (who decided what, when, based on what criteria)
  - Evidence of human oversight (where humans review AI decisions)
  - Record of any issues found and how you fixed them
  - Evidence that you address accessibility and accommodate candidates
  - Record that your process has been trained (team knows how to use it)

If you can hand over this documentation and it's clear, current, and complete, you're in good shape.

Common Documentation Mistakes

Mistake 1: Documentation Exists But No One Updates It

Written a year ago; tool has changed three times since; documentation is outdated.

Fix: Assign clear owner. Schedule quarterly reviews. Update immediately if tool/process changes.

Mistake 2: Documentation is Too Vague

"We screen for fit." What does that mean? What criteria?

Fix: Be specific. What criteria? How do you measure? Who decides?

Mistake 3: No Documentation of Fairness Monitoring

No record of audits, no analysis of outcomes by demographic group.

Fix: Document monthly fairness audits (even if just "no issues found"). Shows you're actively monitoring.

Mistake 4: Documentation Hidden in Someone's Brain

One person knows how the tool works; if they leave, knowledge is gone.

Fix: Write it down. Make it accessible. Don't rely on individual knowledge.

Mistake 5: Documentation Doesn't Match Reality

Written documentation says "recruiter reviews all candidates" but actually AI filters out 90%.

Fix: Document what actually happens, not what you wish happened.

Key Takeaway

Document five things: tools (what you use, how it works), workflows (step-by-step process), criteria (specific, job-relevant standards), quality monitoring (audit results, fairness checks), and changes (what changed, when, why). Be specific and current. Level of detail: enough that someone new could understand; not so much it becomes unmanageable. Documentation is your insurance policy and learning system.

How much documentation is "enough"?

Enough to answer: "How do you screen candidates? What criteria? How do you monitor for fairness? What AI tools do you use? What human oversight happens?" If you can answer all of these with documentation, you're in good shape.

Should documentation be shared with candidates?

Parts of it, yes. Candidates should know your criteria (job posting), that AI is used (transparency), what happens at each step (in job posting or application page). Internal details (weekly audit logs, incident reports) are for you, HR, and legal.

What happens if my documentation is outdated?

If audited, outdated documentation looks bad: "You claim to do X, but actually do Y" or "This hasn't been updated in 18 months." It suggests you're not actively monitoring or managing your process. Keep it current or admit it's not current ("Last updated January 2024, needs refresh").

Who should own documentation updates?

Assign clear owners by category: Tool docs (Ops), Workflow docs (Ops), Criteria (Manager), Audits (Ops), Change logs (anyone who makes changes). Don't assume "someone will do it." Assign it explicitly.

Should I document negative findings (bias found, quality issues)?

Yes. Document problems and how you fixed them. This shows you're actively monitoring and addressing issues. "We found X, investigated, and implemented fix Y" is defensible. Hiding problems is not.