A candidate record can look finished and be mostly invented. In one staffing operation, 84 percent of the skills that should have sat on a candidate record were not on it. The answer written into the case was not a campaign to go and collect them. It was a set of models, with a recommendation engine to predict the missing entries and write them in, so that every record arriving at the matching engine would arrive full.
That is a model doing the data entry the process never did. Taken on its own terms the decision holds up, and it was probably the right one. What makes it a finding is the record it leaves behind. A repaired record and an original record are the same object. Nothing on the row says which entries a person put there and which a model guessed, and every match, ranking and shortlist downstream inherits the guess as though it had been told.
A global staffing and HR services group was running a short data accelerator, the kind that takes an unfiltered wish list from the business and cuts it to a handful of projects worth funding. Repairing the candidate dossier was one of the four that survived. Two business concepts sat behind it, one built on a continuing relationship with the individual and one on automated throughput, and the throughput concept was defined in the programme's own words by high data quality enabling automated matching and near-real-time job suggestions. Both read the same records.
The challenge
Eighty-four percent missing is not a data-quality problem in the ordinary sense. At two or three percent you clean, at ten you chase, at eighty-four you are deciding whether the dataset ever existed. The source records the sparsity and never says where in the process the skill field went empty: the number was known, its cause was not.
Set against that, a collection campaign is a bad plan and everyone in the room knew it. Asking a large candidate population to complete a structured skills profile is a multi-year effort aimed at people with no particular reason to comply, and the answers decay from the day they are given. Prediction gives you a usable record on the first day. Every incentive points at the model.
The cost lands somewhere the business case does not look. Matching does not sample a record, it reads it. A query for a skill hits the field where that skill lives, and the field does not carry a note about where its contents came from. With roughly five entries in six supplied by a model, a query landing anywhere on the record lands on an inferred value about five times in six. The ratio is not a subtlety in the tail of the distribution. It is the ordinary case.
Read the sweep once and the sequencing question answers itself. Any downstream improvement in ranking, recommendation or shortlist quality is an improvement in how well the system uses fields that are mostly its own output. That can still be worth doing. It cannot be evaluated as though the inputs were observations.
The approach
The taxonomy is listed first, and the ordering matters. The group chose to build its own structured skills and occupations taxonomy rather than license one, with the stated goal of being internally competitive with what external suppliers sell. On a slide that reads like a make-or-buy footnote. In practice it decides whether the repair is inspectable at all. A taxonomy you own is a vocabulary you can version, audit and argue with. A rented one means your matching quality belongs to whoever supplies it, and when a match looks wrong there is nowhere to go and look.
With the vocabulary in place, the imputation mechanism was comparison. The programme describes finding missing profile elements by comparing a record against similar records, and computing likeness between peers from self-declared skills and preferences. Reasonable, and also a closed loop worth naming: the population the model learns from is the same sparse, self-declared field it is being asked to repair. The direction of the risk is predictable. Commonly recorded skills get predicted onto people who never claimed them, rarely recorded ones stay rare, and nothing in the loop rewards a prediction nobody can check. The source measures none of this, and it is exactly the sort of thing that has to be measured rather than reasoned about.
None of that argues against imputing. It argues for one column the design never added. A field that came from a model is a different kind of field from one a person entered, and the record is the only place that difference can live. Mark each entry as attested, inferred or stale. Carry the model version and the features that produced it on a lineage trail. Keep the two kinds apart in the feature store, so a matching engine can weight them differently and a recruiter looking at a shortlist can see which claim on the page is the model's opinion.
The engineering cost of that column is trivial next to the models themselves, so effort is not what stops it. What stops it is the framing: imputation gets commissioned as a data-cleaning task, and cleaning implies the output is data. Call it a prediction instead and the provenance question becomes unavoidable, which turns a finished deliverable into one that needs monitoring.
The outcome
What this case was scoped to produce was a taxonomy database, cleaning and imputation models, and a repaired dossier feeding the matching engine. The improved taxonomy is named as the deliverable. Better matching is named as the purpose.
It is not named as a result. The 84 percent is a baseline measured before the work, not an improvement measured after it. No match-quality number appears in the source, no count of records in scope, no per-field confidence from the engine. That absence is the same one you find in most enrichment projects: the sparsity gets measured because it justifies the budget, and the thing the budget was meant to fix does not.
The programme did name the right instinct once. Among its stated ambitions was to predict the value of incorrect or missing data held across the group, which is an attempt to put a number on data-quality debt rather than describe it. That is the measurement the rest of the work needed and did not have.
Three things we would do differently now. First, measure where capture fails before modelling around it. A neighbouring case in the same accelerator was already scoped to fuse four sources, clickstream, two internal systems and raw load balancer logs, to follow a candidate from registration through to placement. Process mining over that event stream shows at which step the skill field goes empty, turning an eighty-four percent hole into a handful of named process defects with owners. Fix two and the surface the model has to cover shrinks permanently.
Second, treat the imputation as a deployed model rather than a completed clean-up: a monitored input distribution, a version, a rollback, and a periodic check against ground truth wherever ground truth is cheap. In staffing that means placements, which are real observations about what a person can do, arriving continuously and for free.
Third, hold the line on provenance even when the field looks harmless. The current wave of cautious language-model pilots in document handling makes that more pressing, not less: a model that reads a CV well produces more fields, faster, with the same silence about where they came from. Our Consult engagements now open by asking which fields in a record the organisation can prove it was told, because that question is cheap to ask and expensive to answer late.
Nobody here set out to build a system that invented skills for people. They set out to make matching work on a record that was more than five-sixths empty, which is a real problem with a defensible answer. The record was the only place the distinction between told and guessed could have been kept, and nothing in the design gave it room.
