Recruiting Data Provenance: Know What You Know, Where It Came From, and What You Can Do With It
Modern recruiting systems combine public evidence, ATS records, licensed providers, recruiter notes, uploaded resumes, model outputs, and training datasets. Without provenance, those sources collapse into one opaque candidate record and the system loses the ability to explain what is true or what a workflow is allowed to do.
Last reviewed: 2026-09-06
Ask SourcingOS about this page
1. Provenance is more than a source URL
Useful provenance records the source, observed time, acquisition path, evidence type, relevant usage rights, confidence or verification state, and whether the claim was recruiter-confirmed.
This lets the application distinguish “the candidate wrote this on a public profile” from “a provider inferred this” or “a recruiter confirmed this after a conversation.”
2. Separate training data from production candidate evidence
A resume dataset used to test parsing or ranking should not become a live sourcing database merely because the schema looks similar. Training/evaluation has a different purpose, rights model, retention expectation, and risk profile.
Synthetic and licensed evaluation corpora are valuable when their boundary is explicit. The dangerous shortcut is letting development convenience silently create production candidate records.
3. Separate evidence from contactability
A GitHub contribution, publication, patent, public resume, or company page can support role research without supplying an appropriate outreach channel. Contact eligibility deserves its own policy and evidence.
That distinction becomes essential when SourcingOS combines open-web research with licensed contact providers.
4. Preserve assertion type
Observed, normalized, inferred, derived, and recruiter-confirmed assertions should not be flattened into identical facts. The application can still present a clean candidate experience while retaining those distinctions under the hood and in evidence views.
This creates better ranking, safer explanations, and more useful recruiter feedback because the system knows what kind of claim is being corrected.
5. Make provenance operational
Provenance should influence what the system can display, rank, export, contact, train on, or send to a model. Otherwise it becomes metadata that exists only for compliance paperwork.
The strongest design makes rights and evidence boundaries executable application rules.
Key takeaways
- Track source, timing, acquisition path, and assertion type.
- Keep training/evaluation corpora out of the live candidate graph by default.
- Do not equate public evidence with contact eligibility.
- Preserve observed, inferred, derived, and recruiter-confirmed states.
- Use provenance to enforce product behavior, not just document it.