The Past-Finalist Rediscovery Playbook: ATS Archive to a Cleared Warm Slate

This playbook is for in-house recruiters, sourcers, and founders who have just opened a req for a role the company has hired before. It makes the ATS archive a timed, auditable first step that comes before any cold sourcing. You pull the right finalists, remove everyone you may not contact, decide which old rejections no longer apply, check each remaining person against their current public profiles, and re-score them against the new spec. After one working session you have one of two things: a ranked warm slate with a first message for each person, or a written finding that the archive has nothing to offer.

What is past-finalist rediscovery, and when is it worth a session?

Past-finalist rediscovery means going back to the people who reached the final or offer stage on earlier reqs for the same role. You confirm which of them you may lawfully contact, then re-engage the ones whose original blocker has gone. It is worth a session whenever a req reopens for a role you have hired before. It costs a few hours, and the alternative is paying to cold-source people you have already interviewed.

Terms used throughout this guide:

• Silver medalist: a finalist who was not hired, usually because another candidate was preferred.
• Active pool: records kept so you can contact the person about future roles.
• Archive mode: records kept only as evidence, for example in case a hiring decision is challenged. You never contact these.
• Contact gate: the set of tests a record must pass before anyone may message the person.
• Spec delta: a short written list of what changed between the last hire for this role and the new req.
• Warm slate: the ranked list of past candidates you will message this week.

The best public evidence that rediscovery matters is first-party data. Gem's recruiting benchmarks cover over 165 million applicants and 1.2 million hires. They found that 46% of sourced hires came from rediscovered candidates, up from 26% at the start of the dataset's window. The same dataset found that sourced candidates were nearly eight times more likely to be hired than inbound applicants.

Read that number carefully. It is not a share of all hires, and Gem's own homepage shortens it in a way that invites exactly that misreading. No published source compares reply rate, interview rate, or time-to-fill for re-engaged finalists against cold-sourced candidates. The honest expectation is "this is a real channel", not a specific multiplier. Several figures that circulate in vendor content fail a provenance check:

If someone quotes an excluded figure to justify skipping cold sourcing, ask for the primary source. None of these three has one I could locate.

The rediscovery procedure, step by step

The procedure has seven steps. It takes about two hours of fixed work plus 5 to 10 minutes per surviving record, and each step ends in a written "done" state. These durations are my estimates from desk practice, not published benchmarks. Time your own first run and replace them.

Published guides disagree on the order. Some vendor guides segment first and deal with consent afterwards. Others treat data protection as the constraint that comes before everything else. My position is in between. Agree the gate rules with your data protection officer (DPO) before the session; you do this once per jurisdiction, not once per req. Then pull the segments. An export is only a filter. Nobody refreshes, enriches, or messages a record until it has passed step 3.

Which past candidates may you contact? The contact gate

A past candidate is contactable only if all four of these hold:

• The record is in an active pool, not in archive mode.
• There is no objection or deletion request on file.
• It carries no Security concern rejection reason.
• It is still inside its jurisdiction's window, measured from last contact.

A record that fails any one test leaves the slate. Every record that passes gets a logged reason.

The windows differ sharply by jurisdiction. The table below is the reference I use. Each row is only as current as its source, so re-check them on a schedule (see the last section).

France: the clock resets on contact

The CNIL's HR retention framework allows data on an unsuccessful candidate to be kept for up to two years after last contact in a talent pool. Separately, it allows five years from when the post was filled for evidential purposes, in case of a discrimination action. The framework has already been updated once since publication, so read the current version rather than a summary. "Last contact" means the last email exchanged, the last login to the candidate portal, or your last follow-up.

That definition has a practical consequence. A documented re-engagement legitimately extends how long the record stays usable. An undocumented message cannot be used to justify keeping it.

The outreach log is a compliance asset, not a CRM note.

UK: an ambiguous window, so act conservatively

Under the ICO's storage limitation principle, an employer without a clear business reason should not keep records on unsuccessful applicants beyond the statutory period in which a recruitment claim can be brought. Sources disagree on how long that period is: one says three months less one day, another says six months. The ICO's recruitment guidance is itself a draft under review following new legislation. In practice, most employers keep unsuccessful applications for 6 to 12 months.

My rule: a UK record older than about 12 months needs documented consent or a recorded business reason before anyone contacts the person. That makes a UK past-finalist pool smaller than a French one, because the French window is two years.

US: retention floors are not contact permission

29 CFR 1602.14 requires application forms to be kept for one year from the date the record was made or the personnel action taken, whichever is later. Once a charge is filed, records on all other candidates for the same position must be kept until final disposition. California is reported at four years for employers covered by its Fair Employment and Housing Act, but that figure comes from a secondary source, so confirm it with counsel.

All of these are minimum retention periods. I found no federal limit on re-contact. Whether you may contact someone depends on state law and on what your own privacy notice told candidates. If a record is held because a charge is pending, send it to legal before anyone messages the person.

Log every gate decision in the same format so the slate can be defended later:

Record ID:
Jurisdiction:
Pool status: active / archive
Last contact date (email, portal login, or follow-up):
Window applied: (e.g. France 2 years from last contact)
Inside window on today's date: yes / no
Objection or deletion request on file: yes / no
Security concern reason present (queried with flag on): yes / no
Gate result: contactable / removed
Reason logged by and date:

Which rejection reasons still hold? Triage

Rejection-reason triage sorts each record that passed the gate into "blocker gone" or "still disqualifying". Reasons tied to circumstances (timing, compensation, location, sponsorship, level) can expire when the spec changes. Reasons tied to conduct or verification (a failed background check, any Security concern reason) do not.

Start by splitting the export into two segments: employer-rejected (the company said no) and candidate-declined (the person said no). The candidate-declined segment is often the warmest. Those people wanted something you could not offer at the time, and the spec delta may now offer it.

Greenhouse is the documented case. By default it requires a rejection reason whenever a candidate or prospect is rejected. Its default reasons include "Preferred another candidate", "Didn't like offer", and "Wasn't available". There is also a separate Security concern type that covers "Fraud concerns identified", "Irregular application activity", and "Suspicious interview behavior". Its best-practice guidance adds reasons that expire with circumstances, and reasons that should keep disqualifying.

Some reasons can't be triaged at all. Greenhouse itself lists "Not chosen", "Applicant disqualified", and a blank reason as bad practice, because they record that a decision happened without saying why. For those records, read the interview notes. If the notes settle the question, tag the record from the notes. If they don't, tag it still disqualifying for this req and move on.

I have not verified the archive-reason lists in Lever or Ashby. If you use another ATS, map its labels onto the two tags before the session and store the mapping with your gate rules, so every req uses the same mapping.

How stale is a past finalist's record? The refresh step

Assume every record is stale until you have checked it. The people most likely to have been finalists are mid-career, and mid-career workers change jobs most often. A refresh means confirming current employer, title, and location, plus recent public code for technical roles, then stamping the record with a refresh date.

The proxy evidence comes from the BLS employee tenure release. Median tenure across US workers is 3.9 years. It falls to 2.7 years for workers aged 25 to 34, against 9.6 years for ages 55 to 64. About 22.2% of workers had been in their job less than a year. Public-sector median tenure is 6.2 years against 3.5 in the private sector, so private-sector finalists go stale faster.

What these figures can't tell you is how many of your own finalists have moved after 6, 12, or 24 months. No public source establishes that. You can measure it yourself: on each run, count how many refreshed records show a new employer, grouped by months since last contact. After a few reqs you will have your own staleness curve, which is worth more than any proxy.

For each survivor, check these signals. Each one tells you something, and each can be misleading:

• Current employer. Shows whether they moved, and whether a non-solicit or off-limits rule now applies. It misleads when the profile hasn't been updated, so confirm with a second public source before you rely on it.
• Title. Shows whether their level moved toward or away from the new req. It misleads when the same words mean a different job in a different market or function.
• Location. Shows whether a relocation blocker still applies. It misleads when a profile lists a home city for someone who now works remotely, or the reverse.
• Recent code, for technical roles. Shows they are still hands-on in the stack the delta names. It misleads when the activity is old or in an unrelated stack.

Title noise is the trap I see most often. In Refolk's index of professional profiles, the counts of people holding Sourcer, Talent Sourcer, or Sourcing Specialist titles look like this:

In the French sample, 17 of 25 profiles are titled "Sourcing Specialist", and the top employers include GE and BD. My inference, which I have not verified per profile, is that many of these are procurement roles, not recruiting ones. A refresh that confirms "still a Sourcing Specialist" proves nothing until you have checked the employer and industry too.

Most of the 5 to 10 minutes per person goes on opening profiles one at a time and comparing them with the ATS record. Refolk replaces that with one plain-English request across GitHub, LinkedIn, and the open web. It also surfaces the finalists who have changed employer since you last spoke to them, which is the change most likely to make an old record wrong.

How do you re-score survivors against the new spec?

Score each refreshed survivor against the step 1 delta only, never against the old job's keywords. A finalist who ranked first last time ranked first for a job that may no longer exist. The output is either a ranked slate or a written "archive empty" finding, and both count as a finished session.

Work through it with the hiring manager in one sitting. For each person, place them on two axes. The first is how well they fit what changed. The second is whether the old blocker is truly gone.

Rank the "slate now" quadrant by fit to the delta. Use recency of last contact to break ties, because people you spoke to recently remember you and their records are less stale.

If that quadrant is empty, write the archive-empty finding. List the counts at each step (exported, removed at the gate, tagged still disqualifying, scored weak fit) and the main reason at each drop. This takes ten minutes and saves an argument later: the hiring manager can see why cold sourcing starts now. The spec delta is also the cold-sourcing brief, so you can paste it into Refolk as a plain-English request without rewriting it.

Every first message must refer to the person's actual history with you. A generic "we have an exciting opportunity" note wastes the one advantage a warm slate has.

Subject: {New role title}, and what has changed since we last spoke

Hi {first name},

We last spoke in {month} when you reached the {final round / offer stage} for {old role title}. {One specific, true detail from that process, e.g. what the panel valued in your system design session.}

At the time it did not work out because {the honest reason, e.g. the role was office-based in Lyon / the band sat below your ask}. That has changed: {the relevant line from the spec delta}.

I am now hiring for {new role title}, reporting to {hiring manager name}. Given what you have done since at {current employer from your refresh}, I think it is worth 20 minutes. Would {two specific slots} work?

You are hearing from me because your details are held in our candidate pool under {pointer to privacy notice}. If you would rather not hear about roles, reply "remove" and I will delete your record.

{Your name}

How rediscovery goes wrong

Most rediscovery failures fall into two groups. Some send a message that was not lawful to send. Others put someone on the slate who should not be there. The seven below are the ones to check for on every run, each with the check that catches it.

1. The gate clock is measured from the wrong date. The window gets measured from the application date instead of from last contact, or an evidential archive gets treated as a pool you can contact. Check: export last-contact timestamps and confirm the archive flag on every row before the gate runs.
2. The US one-year floor is read as permission to contact. That rule governs retention only. Check: confirm against state law and your own privacy notice. If neither supports contact, the record does not pass.
3. Vague reasons get triaged anyway. "Not chosen", "Applicant disqualified", and blank fields cannot be sorted honestly, and guessing usually lands them in "blocker gone" because that is the more hopeful tag. Check: read the interview notes, or default to still disqualifying.
4. A missing fraud flag is read as clearance. Records closed before Security concern reasons were enabled carry no fraud field at all, and exports pulled without the product flag drop fraud outcomes. Check: query with the flag on, and re-run identity verification before any offer.
5. A title keyword is taken as a match. "Sourcing Specialist" in France returns procurement staff, as the index sample above shows. The same trap exists for any title shared across functions. Check: confirm employer and industry, not the title alone.
6. Survivors are re-scored against the old job's keywords. Old finalists rank high on a spec that has since changed, and the slate looks strong but is wrong. Check: score against the step 1 delta only, with the hiring manager present.
7. The 46% figure is misread as a share of all hires. That inflates expectations, and an empty archive then gets treated as a sourcing failure. Check: quote it as "46% of sourced hires" every time.

Some records will survive all three filters and still feel wrong to the hiring manager. If so, write down their reason in the record. An unexplained veto turns into an untriageable reason the next time the req opens.

How do you close the loop so the next req starts warmer?

Every record you touched should leave the session with a specific reason, a refresh date, and a logged contact. That lets the next search for this role start from clean data rather than another round of archaeology. The rules behind the gate also need re-checking on a schedule, because at least two of them are in flux.

Close-loop work, in order:

• Re-tag reasons specifically. Replace any vague or blank reason you met with the real one from the notes, or with "untriageable, notes insufficient" so the next recruiter doesn't waste time on it.
• Log every contact with its channel and date. In France this is what keeps the two-year window running from the right point.
• Record refresh dates and what changed. These records become your own staleness curve.
• Measure the channel. The one published metric set for rediscovery is rediscovery hire rate, cost per hire, time to fill, and 90-day retention, each compared against external hires. Track all four per req. Nothing published tells you what tagging costs in minutes per req, so time it yourself.
• Re-check the law. The CNIL framework has been updated once since publication and the ICO's recruitment guidance is a draft. Re-read both, plus your state rules if you hire in the US, whenever you review your gate rules with the DPO.