Plagiarism Detection: Thresholds, Appeals, and False Positives

It is 9:12 AM. A candidate posts a screenshot of your rejection email on LinkedIn: "Rejected for plagiarism. No one will explain why." Your Support queue spikes, your recruiting ops lead is asking for logs, and a hiring manager wants to keep the candidate because the interview went well. In that moment, similarity detection is no longer a technical feature. It is a customer experience and reputation problem. If you cannot explain the decision, show the evidence you relied on, and offer a fair appeal path, you will either reverse decisions inconsistently or double down on a bad call and eat the blowback. What you want instead is a calm, repeatable playbook: similarity thresholds that route cases, a short human review with a checklist, and an appeal workflow with timelines and outcomes that Support can execute without improvising.

Implement a similarity policy that (1) sets thresholds by assessment type, (2) minimizes false positives through risk-tiered step-ups, and (3) gives Support a clear appeal workflow backed by evidence packs instead of opinion.

Fraud pressure is real. Checkr reports that 31% of hiring managers say they have interviewed a candidate who later turned out to be using a false identity. Directionally, that implies many teams are already absorbing avoidable downstream cost: wasted interview time, rescinded offers, and internal blame. It does not prove that all industries or all roles have the same rate, and it does not isolate plagiarism specifically from other fraud types. Pindrop reports that 1 in 6 applicants to remote roles showed signs of fraud in one real-world pipeline. Directionally, that supports treating hiring as an integrity surface, not just a recruiting workflow. It does not mean your funnel is identical, and "showed signs" is not the same as confirmed fraud. Support impact is straightforward: every unclear rejection becomes a ticket, every inconsistency becomes a screenshot, and every slow appeal becomes a churn event for your employer brand. Similarity detection can help, but only if your process is predictable and explainable.

If ownership is fuzzy, the appeal path becomes an internal escalation chain. Lock this down before you tune thresholds. Recommended operating model: - Recruiting Ops owns the policy and routing rules in the ATS workflow (what happens at each similarity band). - Security or Trust (if you have it) owns the fraud taxonomy and step-up requirements for elevated-risk cases. - Hiring Managers own the technical judgment call when a case is truly ambiguous, but they should not be the default reviewers. - Support owns candidate communications, timelines, and the appeal intake checklist. Automation vs manual review: similarity scoring and evidence collection are automated; outcomes in the review band require a short human decision with a documented rationale. Sources of truth: ATS is the system of record for stage and disposition; the assessment system is the system of record for code, similarity artifacts, and proctoring signals; the verification service is the system of record for identity checks. Do not let email threads become the record.

A single cutoff like "over 80% is plagiarism" is how you manufacture false positives. Operators use bands because they map to actions and review cost. Start with three bands: - Low similarity: proceed. No candidate-facing mention. Log the score for monitoring. - Review band: send to a bounded integrity review queue. No auto-reject. Candidate keeps moving only after review. - High similarity: trigger step-up verification plus expedited review. High similarity is suspicious, but still not an automatic guilty verdict. How to pick starting thresholds without pretending you have perfect calibration:

The review band is where your signal-to-noise ratio is won or lost. Keep it fast and consistent. Review checklist (keep it short): - Does the match occur primarily in boilerplate or in the candidate-authored logic? - Is the overlap in a common pattern (standard DFS template) or in idiosyncratic choices (variable names, comments, unusual structure)? - Are there timing anomalies (sudden completion, long idle then perfect solution) that increase risk? - Did multiple candidates share unusually specific mistakes, which often indicates collusion? - Is the solution explainable in a brief follow-up? If yes, prefer a verification step over rejection. Output must be one of three dispositions: allow, step-up verification, or reject with documented rationale. Avoid "needs more info" purgatory that creates Support debt.

An appeal workflow is not weakness. It is how you control false positives without turning reviewers into improvisers. Appeal design principles: - Time-box it. Support needs an SLA, and candidates need a clear expectation. Example: acknowledge within 1 business day, decision within 3 business days (illustrative). - Require a structured appeal intake. Ask for a short explanation of approach, resources used, and whether anyone assisted. - Separate "resourcefulness" from fraud. Open-book use of docs can be allowed; copying another candidate or using a proxy is not. - Prefer "prove it" steps over debate. For borderline cases, offer a short live verification: 10-15 minutes to explain key choices or modify the solution in real time (illustrative). - Close the loop. If you overturn, remove the stigma internally and ensure the ATS disposition is corrected. If you uphold, provide a concise explanation and the next eligible reapply window, if applicable. Support should never have to invent the rules mid-ticket. Your templates should reference policy, not personal judgment.

• Auto-rejecting solely on a similarity percentage, which teaches cheaters how to evade and punishes honest convergence. - Letting candidates retake immediately with the same prompt after a flag, which creates an iterative evasion loop. - Using vague rejection language with no appeal path, which converts uncertainty into public escalation and Support churn.

This example shows how to encode bands, actions, and evidence requirements so Support and Recruiting Ops are aligned. Tune the numbers to your prompts and baseline data.

IntegrityLens AI is the first hiring pipeline that combines a full ATS with advanced biometric identity verification, AI screening interviews, fraud detection, and coding assessments. For similarity detection, IntegrityLens helps teams turn a raw score into an operator workflow: route candidates by risk, trigger step-up verification before interviews, and generate Evidence Packs for reviews and appeals. TA leaders and recruiting ops teams use it to keep the funnel moving without extra tools. CISOs and Security teams use it to enforce privacy-first controls and defensible decisioning across the pipeline.