Do not ask AI to find workforce truth in unreconciled records

“Clean data” is not a release decision

SHRM's September 25 guidance makes a timely point: incomplete, inconsistent, outdated, or duplicate workforce data can make sophisticated AI and people-analytics systems produce misleading conclusions. The operational question is harder. Clean enough for which decision, for which workers, on which date, using which fields, under whose authority?

A payroll contact detail can be current while a job code is stale. A worker may correctly have two employments. A manager relationship may change next Monday. A skill can be self-declared, manager-validated, inferred from work, or expired. A position can exist without an incumbent, while one person can occupy more than one position. Flattening these facts into a “golden row” can destroy the exact history an HR decision needs.

At the same time, vendor roadmaps are moving from insight to action. Microsoft's September 23 Dynamics 365 roadmap describes candidate assessment, onboarding, and hire-to-retire business skills that can be initiated from Copilot. SAP's current People Intelligence materials describe joining worker, skills, business, and operational data for workforce decisions. These are product statements, not proof that every customer's source records are reconciled. They make the readiness gate more important because an agent can act on a bad join faster than a dashboard can display it.

The right unit of governance is a decision-use packet, not a permanent stamp saying “HR data is clean.” A dataset may be fit for a headcount trend and unfit for internal-mobility matching. It may be adequate for drafting a learning inventory and prohibited for performance action. Readiness must travel with purpose, snapshot, fields, population, exclusions, conditions, approvers, and expiry.

Build a decision-use contract before running quality scores

Start with the action the AI output could influence. “Workforce planning” is too broad. “Identify engineering capacity gaps for the approved 2027 scenario; do not rank individuals or recommend termination” is testable. Name the population, geography, as-of date, user, fields, materiality, human owner, prohibited uses, and expiry.

decision_use: workforce-capacity-gap-v1
supported_action: aggregate role-and-skill scenario planning
prohibited_actions:
  - individual performance decision
  - redundancy selection
  - candidate or employee ranking
population: active_employees_in_engineering_entities
as_of: 2026-09-30T23:59:59Z
required_fields:
  - worker_status
  - position_id
  - job_profile
  - org_unit
  - location
  - capacity_fte
  - validated_skill_evidence
blockers:
  - unresolved_identity
  - conflicting_active_employment
  - missing_effective_date
  - unknown_skill_provenance
approvers: [hris_data_owner, workforce_planning_owner]
expires: 2026-10-31

Next, define field-level authority. An HRIS may own employment status, but finance may own cost center, identity may own account state, and a learning platform may own completed certifications. Source precedence should be explicit and narrow. “HRIS always wins” can be wrong when an approved downstream system owns a specialized fact. The AI may surface disagreement; it must not rewrite the governance contract.

Represent unknown, not collected, not applicable, pending verification, disputed, and stale separately. A model should not turn a blank skill field into “no skill,” or a future-dated manager into the current manager. Null semantics are business logic.

Reconcile identity, time, definition, and lineage

1. Freeze reproducible extracts

Record query or report IDs, extraction time, schema and code-set versions, row counts, control totals, and hashes. Keep the transformation code or workbook version. If a reviewer cannot reproduce the snapshot, they cannot prove which records shaped the recommendation.

2. Build an identity graph, not a name match

Separate person, worker, employment, position, and account. Use approved stable keys and explicit one-to-many relationships. Detect duplicate active employments, orphan positions, overlapping incumbents, reused identifiers, and uncertain cross-system links. Names and emails change; fuzzy similarity can join different people.

3. Reconcile effective dates

HR data describes events through time. A late interface may deliver a retroactive correction after the snapshot. A reorganization can be loaded today but become effective next month. For each field, compare business effective time, source update time, extraction time, and decision as-of time. Preserve the prior record and explain which version was active.

4. Validate business definitions and code sets

Two systems may both contain job_level while using different scales. “Location” may mean contractual workplace, payroll jurisdiction, office assignment, or observed login region. Publish field definitions, allowed values, units, locale, time zone, and version. A perfectly complete column can still be unusable if its meaning changed.

5. Run deterministic quality checks

Test completeness, validity, uniqueness, consistency, timeliness, and lineage per decision-critical field. Keep denominators visible. Do not average 100 percent email completeness with 80 percent legal-entity accuracy and call the dataset 90 percent ready. Critical fields are gates.

for record in workforce_snapshot:
    assert stable_identity(record.worker_id)
    assert active_at(record.employment, decision_as_of)
    for field in contract.required_fields:
        result = validate(field.definition, record[field])
        if result.is_conflict or result.is_stale:
            exceptions.add(record.token, field, result, field.owner)

if exceptions.any(contract.blockers):
    readiness = "NOT_READY"
elif exceptions.any_material():
    readiness = "CONDITIONALLY_READY"
else:
    readiness = "READY_FOR_NAMED_USE"

6. Trace derived labels separately

Skills, potential, fit, performance, attrition risk, productivity, and sentiment are often derived rather than observed. Record the source fields, method, time window, model or rule version, confidence, validation, owner, and permitted use. Do not let a derived score flow back into a source field where it can later appear as fact.

7. Route exceptions and corrections

An exception packet needs the conflicting evidence, affected use, containment, owner, deadline, correction source, and retest. Employees and managers need a correction route when policy or law requires it. Proposed fixes stay outside the source system until an authorized owner approves and records them.

Worked example: internal mobility recommendations after a reorganization

An HR team wants AI to suggest employees who may fit twelve new data-engineering roles. The initial extract joins workers to jobs by email, imports skills from self-service profiles, and uses the current manager hierarchy. The output looks plausible and ranks several people highly.

The readiness workflow finds four material problems. Two workers changed email after acquisition and were joined to stale profiles. Three positions moved to a new legal entity next month, but the extract mixed future and current records. The “advanced Python” value combines self-declaration, course completion, and manager validation without showing provenance. One employee has an approved correction pending after disputing an inferred skill label.

The team does not “clean” every workforce field. It rebuilds the identity links, freezes an as-of hierarchy, limits eligible skill evidence to defined sources, excludes disputed records, and reruns the recommendation. HR then follows the separate internal-mobility review workflow for calibration, opportunity exposure, human review, communication, and appeal. Data readiness permits that next review; it does not approve a match.

Failure modes that a green dashboard can hide

Microsoft's onboarding preview describes confirmed actions writing back to the HR system of record, which is a useful design principle. Even so, a write-back does not prove the source value was correct, the field was necessary, or the action was permitted. Keep source validation, decision-use review, and action authorization as separate gates.

Pilot one decision, not the entire employee lifecycle

Choose a reversible, low-volume use such as an aggregate learning-needs inventory or a manager-reviewed internal directory correction. Limit the population to one entity and a stable field set. Run the workflow in read-only mode, compare exceptions with HRIS and process owners, and test disputed, future-dated, multiple-employment, and reorganization cases.

Track identity-match exceptions, duplicate rate, critical-field completeness, invalid-code rate, effective-date conflicts, stale records, cross-system disagreement, source-to-fix time, correction recurrence, disputed-record handling, downstream override, affected-population size, and readiness expiry. Segment quality by source, location, worker type, and process without asking the model to infer attributes.

Stop or narrow the pilot if it links the wrong person, silently fills an unknown, collapses valid history, exposes unnecessary sensitive data, changes a source record, hides a blocker inside an average, uses a disputed label, expands the decision purpose, or cannot reproduce an output from the frozen packet. The success metric is not a higher cleanliness score. It is fewer preventable decision errors with clearer ownership and less unnecessary data movement.

1. Approve one decision-use contract and prohibited-use list.
2. Publish field definitions, authority, effective-date rules, and owners.
3. Freeze extracts, transformations, model/configuration, and quality rules.
4. Run deterministic checks and resolve identity before fuzzy analysis.
5. Send exceptions to source owners; preserve correction and appeal routes.
6. Test the downstream AI with adversarial record states.
7. Require named data and decision owners to release the exact packet.
8. Monitor, expire, and reopen after material change.

FAQ

How is this different from new-hire readiness?

The new-hire workflow checks Day-1 dependencies such as identity, device, payroll, learning, workplace, and manager readiness. This guide covers the wider workforce and asks whether source records are fit for a named AI-assisted decision such as planning, mobility, learning, or employee service.

Do we need one master system for every field?

No. Use a field-level authority matrix. HRIS may own employment status, finance may own cost center, learning may own certification completion, and identity may own account state. Reconcile them through approved keys and effective-date rules.

Can the AI fix duplicates automatically?

It can propose likely duplicate groups and explain evidence. An authorized owner should confirm identity, merge or preserve records, update the authoritative system, notify downstream consumers, and retest. False merges can be harder to repair than duplicates.

Does passing data checks make an AI employment decision compliant?

No. Data readiness is one prerequisite. Separate legal, equality, accessibility, privacy, labor, employee-relations, model-validation, process, notice, human-review, and appeal controls may apply. Qualified owners determine them.

How long should readiness last?

Set an explicit expiry based on update cadence and decision risk. Reopen earlier after material source, schema, code-set, policy, population, model, integration, organization, or decision-use changes.