Graceful Failure Paths for Identity Checks: An Ops Runbook

A candidate reaches the identity check 15 minutes before their interview. Their document scan fails due to glare. The screen says "Something went wrong" and offers only "Try again". After three attempts, they abandon. Operationally, that is not a UX issue. It is an SLA incident. - SLA breach risk: the interview slot is wasted, the hiring manager reschedules, and time-to-offer expands because the identity gate is unresolved. - Legal exposure: your process now contains an undocumented exception. Someone will inevitably propose "just let them interview" which breaks identity gating before privileged access. - Audit defensensibility: if Legal asked you to prove who approved this candidate, can you retrieve it? A decision without evidence is not audit-ready. - Cost of mis-hire: the replacement cost can range from 50-200% of annual salary depending on role, which is why exceptions need controls, not improvisation. Graceful failures are how you prevent support from becoming a shadow workflow and how you keep the funnel moving without creating an unverified backdoor.

Most hiring stacks were assembled as sequential checks: ATS stage change triggers a verification link, then an interview platform, then an assessment vendor, then background checks. When verification fails, each vendor reports a different status, often with no shared event IDs, no unified evidence pack, and no consistent SLAs for manual review. The market did not solve this because each tool optimizes its own completion rate, not your end-to-end audit trail. The result is predictable: - Sequential checks that slow everything down when retries are needed. - No immutable event log across tools, so timelines cannot be reconstructed. - No ATS-anchored audit trails, so approvals live in email, chat, or screenshots. - No standardized rubric storage, so "we made an exception" has no consistent criteria. - Shadow workflows proliferate because support must act quickly, and the stack provides no safe path. If it is not logged, it is not defensible.

Graceful failures work only when ownership is explicit and the ATS remains the source of truth. Ownership: - Recruiting Ops owns workflow, candidate communications, review queues, and SLA escalation. - Security owns identity gating policy, step-up verification requirements, and override access control. - Hiring Manager owns interview scheduling discipline and rubric discipline. No interview proceeds when identity gate is unresolved unless a documented exception path is triggered. - Compliance owns audit policy, evidence pack retention rules, and dispute handling. Automation vs manual review: - Automated: failure classification, retry limits, case creation, candidate guidance copy, and evidence pack assembly. - Manual review: ambiguous identity outcomes and potential deepfake or proxy signals. Systems of record: - ATS is the lifecycle source of truth (stage, holds, disposition). - Verification service is the identity source of truth (decision, artifacts, timestamps). - Interview and assessment tools contribute evidence but should write back outcomes into the ATS log.

Design graceful failures as a controlled branch in an instrumented workflow, not as a support afterthought.

IntegrityLens AI sits between Recruiting Ops throughput and Security identity gating to make graceful failures controlled and auditable. - Biometric identity verification with liveness detection, document authentication, and face matching before interview access. - Risk-tiered funnel with step-up verification instead of binary pass-fail. - Immutable evidence packs with timestamped logs and reviewer notes for reconstructable decisions. - ATS-anchored audit trails so holds and overrides are written back as the single source of truth. - Zero-retention biometrics architecture so Compliance can approve controls without expanding sensitive retention.

• "Let them proceed and we will fix identity later" which creates an unverified access path and contaminates downstream evidence. - Manual exceptions over email or chat with no case ID, no timestamps, and no reviewer accountability. - Unlimited retries with no step-up requirement, which trains attackers and inflates reviewer fatigue.

• Owner: Compliance (policy) + Recruiting Ops (copy) - SLA: 5 business days - Logged: copy version ID, policy version, failure category taxonomy - Owner: Recruiting Ops - SLA: 2 days - Logged: failure event, support request event, case ID, timestamps - Owner: Recruiting Ops (queue ops) + Security (reviewers) - SLA: P1 identity holds 4 business hours, P2 1 business day - Logged: reviewer assignment, review start, decision, notes, attachments - Owner: Security - SLA: 10 business days - Logged: trigger reason, method used, decision outcome - Owner: Security (policy) + Recruiting Ops (workflow) - SLA: immediate once configured - Logged: hold placed, hold reason, hold expiry, override approvals - Owner: Analytics - SLA: 2 weeks - Logged: time-to-first-failure, time-to-recovery, time-in-queue, SLA breach flags - Owner: Compliance - SLA: 30 days - Logged: evidence pack retrieval record, requester, purpose, export timestamp

If you want to implement this tomorrow: - Add a support-first option on every verification failure screen that creates a case ID, not an email thread. - Enforce identity gating before interview access. On failure, place a timed hold with access expiration by default. - Publish SLAs for identity exception review queues and assign owners: Recruiting Ops runs the queue, Security approves step-up and overrides. - Require an evidence pack for every override: who approved, when, what failure category, and what step-up method was used. - Instrument time-to-event metrics at failure points so you can see where delays cluster when identity is unverified. - Standardize the exception rubric and store it with the candidate record. A decision without evidence is not audit-ready. Business outcomes to target: - Reduced time-to-hire through fewer abandoned verification sessions and fewer rescheduled interviews. - Defensible decisions because every exception is timestamped, owned, and retrievable. - Lower fraud exposure by eliminating unverified paths and limiting retries. - Standardized scoring and consistent exception handling across teams.