Talent Pool Management and Past Applications

The pool is not the raw list of every application in the panel. An application joins the pool scan only once its CV analysis is complete; a candidate whose analysis is still running or has failed never shows up in the list. A candidate you cannot find in the pool is not necessarily a rejected one, they may simply be an unread one.

The second filter is about the process. By default the pool holds candidates still moving through a process: Hired, Rejected, Terminated and Dismissed stay out unless you pick that filter explicitly. Deleted applications and archived internship applications never enter under any condition.

A single scan reads at most 500 profiles, starting from the most recently updated. There is no semantic pre-filtering: at the company sizes we see today the whole pool is ranked by the deterministic scorer, so the list in front of you is not a sample.

When you pick a posting, the workbench shows that posting applicants by default. The "Whole Pool" switch in the header widens the list to the entire pool; the toggle explains itself: "Rank the whole pool for this posting, including people who did not apply."

In pool mode the target posting is a real posting, not a temporary position derived from a query. In practice that means a persistent fit record is produced and stored for every candidate against that posting, rather than recalculated the next time you open the screen.

A candidate with no score is not treated as a zero. A candidate whose fit was never calculated drops to the bottom of the ranking with an empty score; a 0 on screen is a genuinely calculated zero. No score is invented for a candidate whose CV text has not been extracted yet, and where a stored fit exists, that is what you see.

• Two simultaneous requests for the same candidate and posting pair share a single run, and the result is written once
• The overall CV score is never used to rank a pool; the ranking comes from the criteria of the posting itself
• Scoring does not stop when credits run out or the subscription is suspended, it falls back to the deterministic scorer; the only thing that changes is how detailed the explanation is
• AI suggests candidates from the pool, it does not pick them: a status change goes through the regular application status transition service and asks for confirmation

One candidate and posting pair is billed once. A candidate fit against the posting they applied to is part of the application analysis, so it is already covered before you flip the switch. Scoring a pool candidate against a different posting is a new pair, and every unscored pair costs one AI evaluation credit.

Once a pair has been scored, rescoring is free in every case: changed criteria text, shifted weights, a bumped rubric version or a manual "Re-analyze" makes no difference. Measured rescoring cost is around 0.40 TL, and billing it could burn a whole monthly allowance in one edit on a posting with 129 applicants.

The module itself sits behind no plan gate, it is open on every plan including the trial. The only thing tied to the plan is the number of monthly AI evaluation credits: 100 on the 14 day trial, 150 on Mini, 400 on Starter, 1,200 on Professional. Pool scoring spends from that allowance.

When you edit the requirements of a posting, the old fit records are not deleted, they are marked stale. An amber banner appears in the panel: "The position analysis of N applications is out of date." The subtext says what happens next: scores refresh automatically when they are viewed on the AI Advisor screen, and you can refresh all of them from there right away.

Staleness derives from three keys: the document digest when the CV changes, the criteria digest when posting requirements change, and the version number when the rubric version moves. A fit that still holds all three keys is never recalculated. If only a weight, a band or a description changed, the criteria digest does not move; no record is marked stale and the ranking is rebuilt locally on the next read, without reaching the model at all.

What the banner counts is the live applicants of that posting, not the pool. Stale records of archived, deleted and terminal status candidates are not counted; if they were, the banner would never reach zero. Candidates you scored from the pool stay out of this counter too.

• Bulk re-analysis processes four candidates at a time and skips records that are already current
• Editing criteria never touches the candidate CV profile, the CV is not extracted again
• You never have to postpone fixing criteria for cost reasons: rescoring the same pair spends no credit

The pool never counts the same person twice, and it never merges two applications into one record either. A history banner opens on the candidate detail and shows their earlier applications, which posting each one went to and how it ended. The tone of the banner follows the strength of the match.

Matching looks at contact details rather than identity: email and phone together make a strong match, email alone a medium one, and a phone on its own counts only when the name matches as well. The banner shows more than past applications: it also tells you whether the person has an employee record at the company, as an intern, full time, part time or contract, active or inactive.

Reapplying to the same posting is normal behavior and needs no human review. A separate flag is this: when the facts extracted from a CV are identical but the candidate is different, the record enters the human review queue as a "suspected duplicate CV". Nothing surfaces on the candidate side and the analysis keeps running. The same candidate applying to another position raises no flag at all; otherwise half of an active pool would carry a duplicate stamp.

For a user without permission to view candidate data, pool results come back masked from the server: the name drops to an initial, email and phone to asterisks, and the CV passage behind the match disappears entirely. Masking happens on the server before the data reaches the screen, so a screen added later cannot skip it. The flag showing that a candidate is in human review stays, because the work to be done is the same for that user too.

Candidates see what is read on their side as well. The screen that opens after applying lists the experience titles, date ranges and technologies extracted from the CV. Scores, bands, gate decisions, rankings and comparisons with other candidates are never shown to the candidate; that screen never looks at fit records. A candidate who says "my details are wrong" is not rejected, the record is flagged for human review: the candidate cannot edit the data, this is an objection channel.

On retention, the limit of what can be promised is clear: the product has no counter that deletes candidate data automatically after a set period. Deleting an application is manual and soft, and the record can be restored from the trash; a deleted file stays in storage for 30 days, then it is permanently cleared. Every company sets its own retention policy and schedule.

• Every search leaves a trail: the user, the pool, the target position, whether a query was used, the filter keys and the result count are recorded; the query text itself never reaches the audit log
• A non-existent application cannot be discovered by trial and error: the answer is the same whether the record is missing or the email does not match
• The module depends on the AI analysis flag in company settings; while it is off the route never appears in the menu and every endpoint stops at the gate
• Viewing and searching require ai_advisor:view, bulk actions and gate overrides require ai_advisor:manage. These are role gates, not plan gates