Keep the Output, the Version, the List You Saw, and the Reason

How long do these records have to live?

Longer than your system's default, and longer than any single rule. Federal Title VII recordkeeping requires personnel and employment records to be preserved for one year from the making of the record or the personnel action involved, whichever occurs later, and once a charge or an action is filed, all personnel records relevant to it are preserved until final disposition ¹.

One year is a floor and it has already moved in one large state. California's amended FEHA regulations lengthened the employment-records retention period from two years to four and said expressly that automated-decision-system data is included ². The period runs from the later of the record's creation or the personnel action, and it applies to employers covered by FEHA.

So set the schedule to the longest period that applies across the states where your candidates sit, not where your office is. Which of those rules reaches your organization is a question for counsel. Then look ahead to the next change: Colorado's replacement law takes effect January 1, 2027 and requires a deployer to give a plain-language description of the technology's role within 30 days after a decision that produces an adverse outcome, alongside a right to ask for meaningful human review ³. A description you cannot write is a retention problem wearing a disclosure label, and the records that would let you write it are created today.

What does your ATS quietly fail to keep?

The four objects, in most systems. An applicant tracking system reliably keeps the application, the resume and the disposition code. What it usually does not keep is the value the tool produced at the moment of the decision, the version of the model or ruleset that produced it, the ordered list as it was rendered on someone's screen, and anything that reads as a reason.

Each has a mechanical cause worth knowing:

• The output is a field that gets recomputed. A re-index, a model update or a re-run against new criteria writes over the value that was there, and the value that was there is the one a challenge asks about.
• The version is often not stored on the candidate record at all. Without it, an output cannot be tied to the logic that produced it, and a vendor's later fix becomes indistinguishable from the behavior you actually used.
• The list exists only at render time. It is assembled from filters, weights and sort order when the page loads, so nothing persists once the page closes.
• The reason is a taxonomy, not a sentence. "Not a fit" and "more qualified candidates" are disposition codes; neither one describes a decision.

The Uniform Guidelines also expect a user to keep records that disclose the impact of its selection procedures on identifiable race, sex and ethnic groups ⁴. That analysis cannot be run backwards over stage-level counts nobody captured, which is a reason to check whether your ATS turned its own AI features on by default before you write the schedule.

Ask the vendor whether it snapshots or overwrites

Send one question and keep the answer. At the moment a candidate is dispositioned, does the platform store the output, the ordering and the version as they stood, or does it recompute them on the next refresh? Vendors answer that quickly, and the answer decides whether your retention policy is a filing rule or an export schedule.

If the answer is overwrite, the policy needs a cadence, not a folder:

• Export stage-level records per open requisition on a fixed schedule, and again at every disposition.
• Export in a format that opens without the vendor's software, plus a rendered copy of the list as displayed.
• Store it against the requisition, not inside the tool, and name one owner per requisition.
• Record the tool and version on the export itself, so the two never separate.

A cadence nobody runs fails at the worst possible moment, so give it an owner and a trigger rather than a calendar reminder. The trigger that works is the disposition itself: the same action that moves a candidate to rejected writes the export. Anything that depends on someone remembering at quarter end will be missing the quarter you need.

Put the same asks in the contract at renewal, because an export right that expires with the subscription is not a retention plan. This is the same list that turns up when a vendor has to support an EEOC inquiry, which is the honest way to size the work: you are building the evidence file once, for whichever arrives first.

Why does the written reason matter more than the number?

Because the number is not the decision and the reason is. A challenge asks what the employer did and why, and a stored value with no sentence attached describes a process in which the tool decided. One line from the person who decided, written the same day, is the cheapest evidence in this exercise and the only part nobody else can reconstruct for you later.

A usable reason names the requirement and points at the evidence: which qualification was missing, where in the file that shows, and what the alternative candidate had instead. An unusable one restates the code or the output. The test is whether a colleague could read the line two years later and reach the same outcome without asking anyone.

Keep the field small enough that people fill it in. One required line of free text at disposition, written by the person who decided, beats a structured form with nine dropdowns that gets clicked through in four seconds. A template answer is worse than a blank, because a file full of identical sentences describes a process nobody was running.

That line does double duty. It is what stands behind a decision when a candidate asks how it was made, and it is the record that shows a person exercised judgment rather than ratifying a list, which is the same fact pattern at issue in whether a candidate can demand human review. Write it at the moment of the decision. A reason composed after a complaint arrives is a different document, and it reads like one.

Read the evidence >