HR-Open Candidate Schemas: Stop Pipeline Breakage in Tool Swaps
Tool sprawl is expensive. Schema drift is worse. A portable candidate schema is how RevOps keeps speed, cost, and risk under control when the stack changes.
If candidate data cannot move cleanly, your hiring stack is not a stack. It is a set of liabilities with invoices attached.Back to all posts
The incident you do not want during a tool swap
It is week two of a new ATS rollout. Your interview scheduling tool still holds the old candidate IDs. The assessment vendor sends results keyed on email. The verification service returns a pass, but it lands on the wrong application because the recruiter merged duplicates in the old system. Two hours later, Sales Ops is asking why start dates slipped, Legal is asking for evidence that identity checks ran before interviews, and your brand team is responding to a candidate complaint about being asked to re-verify twice. This is not a technical nuisance. For a CRO, it is time-to-productivity, trust, and revenue risk caused by schema drift and brittle integrations.
What you will ship by the end
You will leave with a practical standard for portable candidate data using HR-Open concepts: a canonical schema, a mapping layer per tool, an append-only event log, and idempotent webhooks. You will also have rollout controls (canary, kill switch, replay) so changes do not strand candidates mid-funnel.
Why RevOps should care about schemas
RevOps usually inherits hiring data problems as downstream symptoms: broken attribution, inconsistent funnel stage definitions, and surprise compliance work when an audit or incident happens. Fraud makes this worse because the evidence has to line up across systems: who the candidate is, when verification ran, what was reviewed, and what decision was made. If those records are split across vendors with mismatched IDs, you cannot prove process integrity without manual forensics. Checkr reported that 31% of hiring managers say they have interviewed a candidate who later turned out to be using a false identity. Directionally, that implies identity risk is showing up in normal hiring workflows, not just edge cases. It does not prove your org has the same rate, and it is based on a specific survey population and period.
Time-to-fill increases when candidates are forced to repeat steps (re-verification, re-assessment) because data cannot be matched.
Cost per hire rises through reviewer fatigue: humans become the dedupe engine.
Reputation risk spikes when the same candidate receives conflicting decisions across tools.
Ownership and flow before you touch the schema
If you do not name owners and sources of truth, schema work turns into endless debate. Keep it simple and operational. Owner: Recruiting Ops owns the canonical hiring schema and stage definitions. Security owns verification policy thresholds and retention controls. Hiring Managers own interview feedback quality, not identity decisions. Automation vs review: identity verification and fraud signals should be automated with an SLA-bound manual review queue for exceptions. Schema validation and mapping should be automated in the integration layer, not left to recruiters. Sources of truth: the ATS is the system of record for Candidate and Application state. IntegrityLens (or your verification service) is the system of record for Verification events and Evidence Packs. Assessment platforms are the system of record for attempt-level results, but must reference the ATS Application ID.
One canonical candidate identifier internally, plus a table of external IDs per tool.
All downstream events reference an Application ID, not just email.
Every decision is an event with timestamp, actor type (system or human), and evidence pointer.
A practical HR-Open aligned schema model
HR-Open is useful because it forces you to separate candidate identity from application context. In operator terms: the same person can generate multiple applications, and your fraud controls must be attached to the right one. Start with six objects that map cleanly to most ATS and hiring tools: Candidate, Application, Verification, Interview, Assessment, Offer. Key design choices that prevent pipeline leakage: - Stable IDs: create an internal UUID for candidate and application. Store vendor IDs as attributes, never as primary keys. - Append-only events: do not overwrite verification outcomes. Add new events (verified, review_requested, verified_failed, verified_passed) so audits are reconstructable. - Evidence pointers: store references to Evidence Packs, not raw artifacts, and enforce Zero-Retention Biometrics where possible. - Risk tiering: store a required verification tier per requisition and a satisfied tier per application (Risk-Tiered Verification).
If a field changes frequently (stage, status), treat it as an event.
If a field is used to join systems (IDs), treat it as immutable.
If a field creates legal exposure (documents, biometrics), store only controlled references and retention metadata.
Implementation steps that survive real production constraints
Inventory joins and breaks: list every join key currently used (email, phone, ATS candidate ID, assessment invite ID). Rank them by collision risk. Email is high-risk because aliases and shared addresses exist.
Define the canonical schema: publish JSON Schema (or equivalent) for the six objects. Include required fields, enumerations for statuses, and validation rules.
Build a translation layer: for each vendor, map inbound and outbound payloads to canonical objects. Reject payloads that do not validate, and route them to an ops queue instead of silently dropping.
Add an event log with replay: store every inbound and outbound event with an idempotency key and correlation ID. This is how you recover when the ATS is down or a webhook delivery fails.
Ship with canary and kill switches: release schema changes to a small set of requisitions first. Add feature flags to stop outbound updates to a specific vendor without stopping the whole funnel.
Instrument observability: trace a candidate from Source candidates - Verify identity - Run interviews - Assess - Offer using one correlation ID. The test is whether an operator can answer, in minutes, "what happened to application X" without asking three vendors.
Governance sign-off: document retention, access controls, and the appeal flow for verification failures. Package it as an Evidence Pack template so Legal and Security can approve the process, not ad hoc screenshots.
Queue events locally with backoff and retry, do not block candidate experience screens.
Use idempotent upserts so replays do not create duplicate applications.
Expose a status page internally so Recruiting Ops sees integration lag before candidates feel it.
A deployable schema contract and webhook policy
This is an example policy you can hand to your integration engineer and your vendor. It defines canonical IDs, required event fields, and idempotency rules so candidate data stays portable during tool changes.
Anti-patterns that make fraud worse
- Using email as the primary key across tools, then "fixing" duplicates by manual merges without an audit trail. - Overwriting verification status fields in place instead of recording append-only decision events tied to Evidence Packs. - Letting each vendor invent its own stage names and pass/fail semantics, then trying to reconcile them in dashboards.
Where IntegrityLens fits
IntegrityLens AI is built for teams that want one defensible pipeline instead of duct-taped tools. It combines a full ATS workflow with advanced biometric identity verification, fraud detection, AI screening interviews, and coding assessments in a single platform. For schema portability, IntegrityLens helps by standardizing the objects and events you need (Candidate, Application, Verification, Assessment) and emitting clean, idempotent webhooks you can map to HR-Open aligned records. Used by TA leaders and recruiting ops teams to keep throughput high, and by CISOs to keep controls audit-ready. - ATS workflow from source to offer - Identity verification in under three minutes before interviews - Evidence Packs and Risk-Tiered Verification decisions - 24/7 AI interviews and 40+ language assessments - Secure controls: 256-bit AES encryption, GDPR/CCPA-ready, runs on Google Cloud SOC 2 Type II and ISO 27001-certified infrastructure
Sources
External stats referenced in this article:
Related Resources
Key takeaways
- Treat candidate data as a revenue-critical asset: define a canonical HR-Open aligned schema and enforce it at every integration boundary.
- Use stable IDs and an append-only event log to prevent duplicates, attribution loss, and audit gaps during tool swaps.
- Implement idempotent webhooks, kill switches, and canary rollouts so verification and assessment integrations fail safely.
- Use Evidence Packs to make fraud controls defensible without exposing raw biometrics to broad teams.
Use this as a contract between your ATS, IntegrityLens, and downstream interview or assessment vendors.
It enforces stable IDs, idempotent delivery, append-only decisions, and Evidence Pack references instead of raw biometric artifacts.
version: 1
owner:
business: RecruitingOps
security: Security
engineering: Integrations
canonicalIds:
candidateId:
format: uuid
source: "generated"
immutability: immutable
applicationId:
format: uuid
source: "generated"
immutability: immutable
externalIds:
allowList:
- system: "greenhouse"
fields: ["candidate_id", "application_id", "job_id"]
- system: "lever"
fields: ["candidate_id", "opportunity_id", "posting_id"]
- system: "workday"
fields: ["candidate_id", "requisition_id", "submission_id"]
schema:
objects:
Candidate:
required: ["candidateId", "primaryEmail", "createdAt"]
pii:
restrictedFields: ["primaryEmail", "phone"]
Application:
required: ["applicationId", "candidateId", "jobId", "status", "createdAt"]
statusEnum: ["sourced", "verified", "interviewing", "assessing", "offered", "rejected", "withdrawn"]
VerificationEvent:
required:
- "eventId"
- "occurredAt"
- "applicationId"
- "tierRequired"
- "tierSatisfied"
- "decision"
- "evidencePackRef"
decisionEnum: ["pass", "fail", "manual_review"]
biometrics:
storage: "zero-retention"
persistOnly:
- "decision"
- "reasonCodes"
- "qualitySignals"
- "evidencePackRef"
AssessmentResult:
required: ["eventId", "occurredAt", "applicationId", "vendor", "attemptId", "result"]
webhooks:
delivery:
auth:
method: "OIDC"
note: "Do not use long-lived API keys for outbound webhooks. Prefer OAuth/OIDC with rotation."
idempotency:
header: "Idempotency-Key"
rule: "Reject duplicate keys within 30d; return 200 to stop retries."
correlation:
header: "X-Correlation-Id"
rule: "Propagate end-to-end across ATS, IntegrityLens, and vendors."
retries:
maxAttempts: 12
backoff: "exponential"
deadLetterQueue: true
rolloutControls:
canary:
enabled: true
scope:
jobIds: ["REQ-10291", "REQ-10305"]
killSwitches:
- name: "disable-assessment-vendor-x"
action: "stop_outbound_events"
- name: "disable-ats-updates"
action: "stop_outbound_events"
observability:
eventLog:
required: true
retentionDays: 365
fields: ["eventId", "objectType", "applicationId", "candidateId", "externalIds", "occurredAt", "deliveredAt", "deliveryStatus"]
slos:
verification_to_ats_update_minutes:
target: "illustrative: <= 5"
note: "Set your own target based on hiring SLAs; this is not a performance claim."Outcome proof: What changes
Before
Tool swaps and vendor additions caused duplicate records, mismatched verification outcomes, and manual reconciliations that delayed offers and complicated audits.
After
A canonical HR-Open aligned schema plus an event log and idempotent webhooks made candidate data portable across tools, with replayable history and consistent decision semantics.
Implementation checklist
- Pick a canonical candidate ID strategy (internal UUID + external IDs).
- Define an HR-Open aligned schema for Candidate, Application, Verification, Interview, Assessment, and Offer.
- Stand up an event log with idempotency keys and replay capability.
- Map each tool to the canonical schema with strict validation.
- Implement rollback and kill switch flags for each outbound integration.
- Instrument tracing so any candidate ID can be followed end-to-end in under 2 minutes.
Questions we hear from teams
- Do we need full HR-Open compliance to get value?
- No. Use HR-Open as the naming and modeling spine, then standardize the few objects that cause the most breakage: Candidate, Application, and VerificationEvent. You can expand coverage over time.
- What is the single most important ID decision?
- Always join systems on an internal applicationId and candidateId, not on email. Store external vendor IDs as attributes so you can swap tools without rewriting your truth.
- How do we keep candidate experience fast while adding schema validation?
- Fail closed for data integrity, not for the candidate. If an event fails validation, route it to an ops queue and keep the candidate moving, then reconcile asynchronously with replayable events.
Ready to secure your hiring pipeline?
Let IntegrityLens help you verify identity, stop proxy interviews, and standardize screening from first touch to final offer.
Watch IntegrityLens in action
See how IntegrityLens verifies identity, detects proxy interviewing, and standardizes screening with AI interviews and coding assessments.
