Talent SummonerDecision Log for Shortlist Changes
Use a decision log for shortlist changes to record evidence, approvals, reruns and the human-owned reason for every ranking update.
A decision log for shortlist changes records what changed between reviews, why it changed and who approved the next action. It prevents a moving shortlist becoming an unexplained sequence of rank changes. Point each event to its evidence, brief version or process correction, while accountable people retain the hiring decision.
Use it when a candidate moves from progress to verify, a person enters the pool, a requirement changes or a reviewer corrects an interpretation. It differs from an evidence matrix, which gives a side-by-side snapshot, and meeting notes, which capture a conversation. The log connects versions over time.
Define the baseline before a change
Save the starting state before anyone edits the shortlist. Record the role, brief version, review date, decision owner, candidates in scope, source snapshot and each current disposition. Preserve the original ranking report or review record; do not overwrite it with the newer order.
The baseline also needs the decision boundary. State which criteria are must-haves, nice-to-haves or operating constraints, and what evidence would count. Record an approved weighting or tie rule if your process uses one. A later change can then be compared with the original question.
Treat a missing fact as unknown, not a failed requirement. If schedule fit was not supplied, a later movement does not prove the candidate was unavailable. Keep the gap and assign a check.
Capture one change event at a time
Give every material event its own identifier. A useful entry answers six questions:
| Field | What to record |
|---|---|
| Baseline | Brief version, shortlist version, date and candidates affected. |
| Trigger | New source, corrected interpretation, approved brief change, pool change or process error. |
| Evidence or decision reference | Exact source passage, link, meeting decision or approval record. |
| Before and after | The prior disposition or criterion treatment and the proposed state. |
| Scope | Which candidates were rechecked and which were not, with the reason. |
| Ownership | Approver, reviewer, next action, due point and stop condition. |
Copy-ready decision-log template
Copy this plain-text block into the same review record as the baseline and complete one entry for each material change. It is an example structure, not a downloadable file or a required vendor format.
Decision log entry: [ID]
Role / brief version: [role] / [version]
Baseline shortlist version and date: [version] / [date]
Candidates affected: [names or identifiers]
Trigger: [new evidence | interpretation correction | brief change | pool change | process correction]
Evidence or approval reference: [source passage, link or approval record]
Before: [prior disposition or criterion treatment]
After: [proposed disposition or criterion treatment]
Scope checked: [candidates rechecked]
Scope not checked and reason: [if any]
Owner / approver: [name or role]
Next action and due point: [action] / [date]
Stop condition: [condition that closes or pauses the check]
Result and closed date: [state] / [date]Write the trigger as an observable event. "Candidate looked weaker" is an impression. "The role owner approved brief version 2, changing the must-have wording" is traceable. Keep source and interpretation separate: a CV sentence, profile passage or brief update may support a narrower claim than the reviewer made.
Classify why the shortlist moved
The reason for a change determines the right response. Use a small set of labels so later reviewers can filter the log:
- New or corrected evidence: a permitted source adds context, or a source was attached to the wrong candidate. Preserve versions and state what is supported.
- Interpretation correction: the team overstated ownership, scope, recency or outcome. Correct it and apply the same standard to comparable candidates.
- Role-brief change: the decision owner approves a new requirement, priority or boundary. Create a version and decide whether all candidates need a rerun.
- Pool or source change: a candidate was added, removed, duplicated or moved between batches. Record the pool boundary so order change is not mistaken for fit change.
- Process correction: a filter or label was applied inconsistently. Pause, document the fix and recheck the affected set.
Do not use "rank changed" as the reason. Rank is the result; the log explains the event that produced it. If no job-related reason can be recorded, keep the prior disposition and assign an owner.
Worked example: a fictional shortlist review
The following fictional customer support operations manager example demonstrates the fields; it is not real candidate evidence or a benchmark.
The baseline is brief version 1: process-improvement ownership is a must-have, CRM migration is a nice-to-have and agreed working-hours overlap is an operating boundary. Candidate A is progress, B is verify because ownership is unclear, and C is hold because the supplied material does not answer the hours question.
The team then records two separate events:
| Event | Trigger | Before | Scope and action |
|---|---|---|---|
| DL-001 | A reviewer notices that a process-improvement passage was interpreted as ownership, although the source only describes participation. | Candidate A: progress | Recheck the ownership criterion for A, B and C; preserve the original interpretation; ask the same ownership question where the gap is material. |
| DL-002 | The role owner approves brief version 2 after removing CRM migration as a selection preference. | Candidate A: progress; B: verify; C: hold | Recheck the changed criterion for every candidate, retain the schedule boundary, and record the new review owner and stop condition. |
Neither event claims that a candidate became more or less capable. DL-001 corrects an interpretation; DL-002 changes the question. The log shows both causes instead of treating the later order as one continuous measure.
Rerun comparable candidates and close the event
When a change affects a criterion, apply it to every candidate evaluated against it. When it affects one source record, explain the narrower scope and whether comparable candidates need the same check. Keep old and new shortlist versions, not just the final order.
When the trigger is a ranking-rule concern, keep the relevant Candidate Ranking report with the baseline and record the supplied brief version used for the rerun. The report is an input to this log, not the log itself.
Close an event only when the owner has recorded the action, source or approval, resulting state and stop condition. Use progress, verify, hold, revise or close, with a job-related reason. "Moved down" is not a close reason. If evidence remains incomplete, leave it open or mark verify.
Where Talent Summoner fits
Talent Summoner is our product. Its current Candidate Ranking tool, checked on 3 September 2026, accepts a pasted or uploaded job description and up to 50 CVs in PDF, DOCX, MD or TXT. It returns a ranked shortlist with plain-English reasoning and a shareable or downloadable report without an account. Use each report as a dated input; it does not replace version history, evidence verification or the human decision.
When the pool is too small, candidate sourcing, checked on 3 September 2026, starts from a role brief and searches LinkedIn, GitHub and other public professional sources across 200M+ profiles. Mark its result as a source batch; a public profile is not proof of availability, interest or working-pattern fit.
What is a decision log for shortlist changes?
It links each material shortlist change to its trigger, source or approval, affected candidates, owner and next action. It explains movement between versions; it is not candidate evidence.
Should every rank movement create a new log entry?
Log every material movement or disposition change. Adding a candidate may need a pool-change entry; a changed criterion needs a new brief version and comparable rerun.
How do I avoid treating a change log as proof of fit?
Keep source wording, interpretation and decision state separate. Record unknowns and use the log to point to verification, not to predict performance.
Can Talent Summoner maintain a shortlist decision log?
The current product pages document ranking reports and public-source discovery, not a dedicated shortlist decision-log feature. Keep version history, approvals and change events in your own process.
For the next shortlist review, save the baseline report, version the brief and create one entry per material update. Recheck affected candidates, record the owner and stop condition, then use candidate ranking for supplied CVs or candidate sourcing for approved discovery.
