HR Data Architecture and Information Management

Introduction

Human resource information systems (HRIS) are often described as software platforms, but their effectiveness depends less on the interface than on the quality and structure of the data beneath it. Payroll, workforce planning, recruitment, talent management, learning, compensation, employee relations, and people analytics all rely on information that is accurate, consistently defined, appropriately governed, and available to authorised users.

HR data architecture is the organised design of data entities, relationships, standards, technologies, processes, and controls through which people-related information is created, stored, integrated, used, retained, and deleted. Information management is the broader discipline of ensuring that information remains useful, secure, reliable, accessible, and compliant throughout its lifecycle.

At postgraduate level, HR data should be viewed simultaneously as an operational resource, an organisational representation, a legal responsibility, and a source of strategic insight. A poorly designed employee record can create payroll errors; an ambiguous job structure can distort pay equity analysis; an uncontrolled skills taxonomy can undermine workforce planning; and unclear data ownership can make accountability impossible.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain the principal entities and relationships in HR data architecture.
2. Distinguish employee, person, worker, job, position, organisation, and assignment data.
3. Design appropriate organisational, job, position, and skills models.
4. Apply metadata, data-quality, ownership, lineage, retention, and lifecycle principles.
5. Evaluate the governance, ethical, privacy, and regulatory implications of HR data.
6. Propose a practical HR data-governance approach for an organisation.

1. The Foundations of HR Data Architecture

1.1 Data, information, and knowledge

Data are recorded representations of entities, events, or observations. Examples include an employee identifier, a hire date, a job code, or a training completion status. Information results when data are placed in context and interpreted—for example, identifying that turnover is higher in a particular job family. Knowledge involves tested understanding that supports judgement, such as recognising that turnover is associated with limited career mobility rather than simply with a particular manager.

The distinction matters because an HRIS may contain large volumes of data without producing reliable information. A dashboard cannot compensate for inconsistent definitions, missing history, duplicate identities, or weak controls.

1.2 Architectural layers

A useful HR data architecture contains several related layers:

A mature architecture aligns these layers. For instance, the business rule that every employee must belong to an approved organisation should be reflected in the information model, enforced by applications, transmitted through integrations, and monitored through governance controls.

1.3 Master, reference, transaction, and analytical data

Master data describe relatively stable, high-value entities shared across processes. Employee, person, organisation, job, position, location, and supplier records are common examples. Reference data provide controlled lists or classifications, such as employment-status codes, country codes, currency codes, or absence types. Transaction data record events, such as a promotion, payroll payment, absence request, or learning enrolment. Analytical data are structured for reporting and analysis, often in a warehouse or lakehouse.

The categories are connected. A promotion transaction changes an employee’s assignment to a position; the position belongs to a job and organisation; the resulting history becomes an input to workforce analytics. Confusing master data with transaction data can lead to overwriting history or treating a temporary event as a permanent attribute.

2. The Core HR Information Model

2.1 Person, worker, and employee

A person is an individual known to the organisation. A person may be an employee, contingent worker, applicant, former worker, dependent, emergency contact, or contractor. A worker is an individual performing work under an organisational relationship. An employee is a worker employed under a particular legal or contractual arrangement.

Separating person identity from employment relationships is important. One individual may have multiple assignments, successive employments, or concurrent roles. A robust model therefore avoids assuming that one person always equals one employee record. A conceptual relationship is:

Person → Worker relationship → Employment or assignment → Job/position → Organisation and location

The model should support effective dates, status history, source-system identifiers, and legal-entity context. It should also distinguish a global person identifier from local employee numbers, because local identifiers may change across countries, acquisitions, or employing entities.

2.2 Employee master data

Employee master data commonly include:

• Unique identifiers and identity attributes;
• Contact and communication details;
• Demographic information, where lawful and necessary;
• Employment status and worker type;
• Hire, service, probation, and termination dates;
• Legal employer and payroll relationship;
• Work location and time zone;
• Manager and reporting relationships;
• Job, position, grade, organisation, and cost-centre assignments;
• Compensation and benefits eligibility;
• Work authorisation or regulatory information, where applicable.

Not all information should be treated as equally sensitive. Identity, bank, health, disability, biometric, performance, and diversity data may require different access controls and retention rules. Data minimisation requires collecting only what is necessary for a specified purpose.

2.3 Organisations and hierarchies

An organisation model represents the structure within which work is performed and decisions are made. It may include legal entities, business units, divisions, departments, teams, cost centres, supervisory organisations, and project structures.

Different hierarchies serve different purposes. A legal-entity hierarchy supports taxation and employment law. A supervisory hierarchy supports managerial approvals. A financial hierarchy supports budgeting. A geographic hierarchy supports local reporting. Treating all of these as one hierarchy creates ambiguity and weakens reporting.

Organisational records should have stable identifiers, effective dates, parent-child relationships, ownership, and status. Historical reporting requires the system to preserve the structure that existed at the time of a transaction. If an organisation is renamed or moved, the change should not silently rewrite historical facts.

3. Job and Position Models

3.1 Job versus position

A job is a standardised category of work defined by purpose, responsibilities, capabilities, and often a career level. A position is an authorised instance of a job in a specific organisation, location, and budgetary context.

For example, “Senior Financial Analyst” may be a job. “Position 10482, Senior Financial Analyst, Finance Transformation, London, reporting to the Finance Director” is a position. Several positions may share one job, while each position may be vacant, occupied, frozen, or abolished.

The distinction supports workforce planning. A job describes the work; a position describes the approved organisational capacity to perform that work. If an organisation records only employee titles, it cannot reliably distinguish approved vacancies from informal roles or identify structural workforce gaps.

3.2 Job architecture

A job architecture typically contains job families, subfamilies, job profiles, career streams, levels, grades, and market-reference relationships. A sound architecture should balance standardisation with local relevance. Excessive variation produces incomparable data; excessive standardisation can erase legitimate differences in regulation, professional practice, or labour markets.

Important design questions include:

• What differentiates one job from another?
• Are levels based on scope, complexity, accountability, expertise, or a combination?
• How are managerial and specialist career paths made comparable?
• How are jobs mapped across countries and acquired businesses?
• Which attributes are authoritative for pay, recruitment, learning, and analytics?

Job architecture is not merely an HR catalogue. It influences pay structures, career mobility, workforce segmentation, reporting, and algorithmic decisions. Poorly designed levels may reproduce historical inequalities or make equal-work comparisons unreliable.

3.3 Position management

Position management should define who may create, modify, approve, freeze, or close positions. Position records may include budget status, headcount type, funding source, work location, reporting relationship, and occupancy dates. The architecture should prevent an employee from being assigned to a position that is inactive, belongs to the wrong legal entity, or exceeds approved controls—unless an authorised exception exists.

Effective-dated modelling is essential. A position can have one manager for part of a year and another later. A worker can move between positions without losing previous assignment history. Such history is central to analysing promotions, mobility, pay, and organisational change.

4. Skills Taxonomies and Capability Data

4.1 From skills lists to capability architecture

A skills taxonomy is a controlled classification of capabilities. It may include technical skills, behavioural competencies, knowledge domains, certifications, tools, languages, and proficiency levels. A simple list of skill names is not enough: “Python,” “Python programming,” and “Python development” may be duplicates unless their meanings are governed.

A more mature capability model distinguishes:

• Skill: a capability that can be developed or demonstrated;
• Knowledge: understanding of a domain, method, or subject;
• Competency: an integrated pattern of behaviour or capability;
• Certification: externally or internally validated evidence;
• Proficiency: the degree of mastery;
• Evidence: an observable basis for claiming capability;
• Criticality: the importance of a capability to a role or strategy.

Skills can be linked to jobs, positions, projects, learning resources, assessments, and career pathways. This creates a foundation for skills-based workforce planning, internal mobility, and targeted learning.

4.2 Taxonomy, ontology, and graph

A taxonomy organises concepts in a hierarchy, such as “Information Technology → Data → Data Engineering.” An ontology represents richer relationships, including equivalence, prerequisite, broader-than, and associated-with relationships. A skills graph can represent connections among people, skills, jobs, projects, learning, and labour-market signals.

These models support different uses. A taxonomy is easier to govern and implement. An ontology or graph can support more sophisticated matching, but it requires stronger semantics, data stewardship, and explainability. AI-generated skill extraction should therefore be treated as a classification aid, not unquestioned truth.

4.3 Proficiency and evidence

Proficiency scales should be defined behaviourally. “Level 3” has little meaning unless the organisation specifies what a person can independently perform, under what conditions, and with what evidence. Evidence may include assessment results, work samples, manager validation, certification, project history, or self-report. Self-reported skills are useful for discovery but should not automatically be treated as verified capability.

5. Metadata, Semantics, and Data Lineage

5.1 Metadata

Metadata are data about data. In HR, metadata can describe a field’s definition, format, owner, sensitivity, source, permitted values, effective dating, refresh frequency, and retention period.

A practical data catalogue entry for “Employment Status” should state its business definition, valid values, authoritative source, update process, downstream uses, privacy classification, and quality thresholds. Without such metadata, two analysts may interpret “active employee” differently and produce apparently conflicting results.

Metadata categories include:

• Business metadata: meaning, policy, owner, and permitted interpretation;
• Technical metadata: table, field, type, interface, and storage location;
• Operational metadata: refresh time, processing status, error counts, and service levels;
• Security metadata: classification, access restrictions, and encryption requirements.

5.2 Data lineage

Data lineage records the origin, transformations, movement, and destinations of data. For example, a headcount metric may originate from employment assignments, exclude terminated records according to a rule, aggregate by effective date, and appear in an executive dashboard.

Lineage supports impact analysis, auditability, troubleshooting, regulatory response, and confidence in analytics. It should capture both technical lineage—how fields move through systems—and business lineage—how definitions and rules affect interpretation.

A lineage statement should answer: Where did this data originate? What transformations occurred? Which systems used it? Who approved the transformations? What happens if the source field changes?

6. Data Quality and Quality Management

Data quality is fitness for a defined purpose, not an absolute property. The same record may be adequate for payroll but inadequate for strategic skills analysis. Common dimensions include:

Quality rules should be explicit, measurable, and connected to business impact. A rule might require every active employee to have one valid employment status and one effective-dated legal entity. Exceptions should be categorised, assigned, corrected, and monitored rather than simply deleted.

A useful operational metric is a completeness rate:

The numerator counts required fields that contain acceptable values; the denominator is the total number of required field instances in scope. The measure assumes that requiredness has been defined and that blank, invalid, and not-applicable values are distinguished. It should be reported with its population, time period, and rule definition.

For example, if 1,920 of 2,000 active-worker manager fields are valid, completeness is (1,920 ÷ 2,000) × 100% = 96%. This does not prove that the manager relationships are accurate; it measures only the defined completeness condition.

Quality management is best treated as a continuous control cycle: define standards, profile data, identify defects, prioritise risks, remediate causes, monitor trends, and review standards. Root causes often include unclear process ownership, poor user interfaces, conflicting systems, weak training, and incentives that reward speed over accuracy.

7. Ownership, Stewardship, and Governance

7.1 Governance roles

Data governance allocates decision rights and accountability. Typical roles include:

• Data owner: accountable for a domain’s meaning, risk, policy, and quality expectations;
• Data steward: manages definitions, standards, issue resolution, and day-to-day control;
• Data custodian: operates technical storage, access, backup, and security controls;
• Data producer: creates or changes data through a process;
• Data consumer: uses data for an approved purpose;
• Governance council: resolves cross-functional conflicts and prioritises policy.

Ownership should follow decision authority, not merely technical possession. Payroll may store bank information, but legal, finance, security, and HR may share accountability for its use and protection.

7.2 Governance principles

A practical HR data-governance framework usually includes:

1. Purpose limitation: use data for specified and legitimate purposes.
2. Data minimisation: collect and retain only what is necessary.
3. Accountability: assign named owners and document decisions.
4. Standardisation: use common definitions and reference values.
5. Transparency: explain data uses and significant automated decisions.
6. Security by design: protect data through layered controls.
7. Quality by design: prevent defects at the point of capture.
8. Lifecycle discipline: manage creation, use, archiving, and deletion.
9. Fairness and contestability: allow people to question consequential records or decisions.

Governance should not become an approval bureaucracy. Controls should be proportionate to risk, with rapid operational routes for low-risk changes and stronger review for sensitive or consequential uses.

8. Privacy, Security, Ethics, and Regulation

HR data can affect employment, livelihood, dignity, and equality. Governance must therefore address more than technical confidentiality. It must consider whether collection is lawful, necessary, fair, transparent, and proportionate.

Controls commonly include role-based access, least privilege, segregation of duties, encryption in transit and at rest, authentication, logging, periodic access review, secure interfaces, incident response, and vendor oversight. Access should be based on job responsibility and purpose, not curiosity or organisational seniority.

Privacy regimes differ by jurisdiction, but recurring principles include lawful processing, transparency, purpose limitation, accuracy, retention limitation, rights of access or correction, security, and accountability. Cross-border transfers, employee monitoring, biometric data, health information, and automated employment decisions require particular care. Organisations should consult applicable law rather than assume that a general HR policy is sufficient.

Ethically, an organisation should ask whether a data use would be reasonable from the employee’s perspective, whether vulnerable groups could be disadvantaged, whether proxies reveal protected characteristics, and whether people can challenge inaccurate information. A legally permissible use may still be ethically unacceptable.

AI creates additional risks. Automated skill inference, attrition prediction, candidate ranking, and sentiment analysis may embed historical bias, confuse correlation with cause, expose sensitive information, or create opaque decisions. Appropriate controls include documented purpose, representative validation, bias and performance testing, human review, explanation, appeal, monitoring for drift, and prohibition of uses that exceed the original purpose.

9. Retention and Information Lifecycle Management

The information lifecycle normally includes creation or acquisition, validation, active use, sharing, archival, review, and secure disposal. Retention should be based on legal requirements, business need, operational value, litigation holds, historical importance, and privacy risk.

A retention schedule should specify the record class, trigger event, retention period, responsible owner, storage location, access controls, archival treatment, and disposal method. Retention periods may begin at termination, transaction completion, contract expiry, or the end of a reporting period. The trigger must be explicit.

Deletion is not always the only outcome. Records may be securely destroyed, anonymised for legitimate analytical purposes, archived with restricted access, or retained under legal hold. Anonymisation must be assessed carefully: removing a name does not necessarily eliminate re-identification risk if combinations of location, role, dates, and demographics remain unique.

Lifecycle controls should also cover backups, replicas, data warehouses, extracts, spreadsheets, integration queues, and vendor environments. Deleting an HRIS record while leaving unrestricted copies in analytics or email systems does not achieve effective disposal.

10. Designing an HR Data-Governance Operating Model

An organisation beginning or renewing governance can proceed through the following sequence:

1. Define critical data domains: identify person, worker, organisation, job, position, payroll, skills, and reporting data.
2. Map high-value processes: connect data to hiring, movement, pay, learning, performance, and exit processes.
3. Assign accountability: name owners, stewards, custodians, and escalation forums.
4. Create a glossary and catalogue: agree definitions, metadata, classifications, and lineage.
5. Profile and prioritise quality: assess defects by business, legal, financial, and employee impact.
6. Establish controls at source: use validation, duplicate detection, workflow approvals, and reference-data controls.
7. Integrate deliberately: define authoritative sources, synchronisation rules, error handling, and reconciliation.
8. Implement access and lifecycle controls: apply least privilege, logging, retention, and disposal.
9. Monitor and improve: publish quality measures, issue trends, ownership performance, and audit findings.

The authoritative source may differ by attribute. Core HR may own legal employer and employment status, payroll may own payment execution, identity management may own account credentials, and a skills platform may own verified capability evidence. “One source of truth” should therefore mean one authoritative source for each defined data element or business purpose—not necessarily one application for everything.

Illustrative Case: Northstar Services’ Workforce Data Renewal

Background

Northstar Services, a fictional international professional-services organisation, had grown through acquisitions. Its HRIS, payroll applications, recruitment system, learning platform, and finance system used different employee identifiers and job titles.

Problem

The executive dashboard reported different headcounts depending on the report used. Managers could not identify approved vacancies, skills data contained thousands of near-duplicate labels, and former workers continued to appear in learning extracts. A pay-equity analysis also produced unstable results because job levels were inconsistently mapped.

Analysis

A diagnostic review found four root causes. First, there was no global person identifier. Second, organisational and job structures were locally maintained without shared definitions. Third, no formal owners had been appointed for critical data domains. Fourth, extracts and spreadsheets were not included in retention or access controls.

The organisation distinguished three questions that had previously been conflated: Who is the person? What employment relationship exists? What work and position are associated with that relationship? It then documented business definitions for active worker, headcount, job level, position, and verified skill.

Approach and solution

Northstar established a data-governance council and appointed domain owners. A global person identifier was introduced, while local employee numbers were retained as source-system keys. Core HR became authoritative for worker status and organisational assignment; payroll remained authoritative for payment execution; finance controlled cost-centre structures; and the skills platform controlled validated skill evidence.

The job architecture was redesigned into job families, profiles, and levels. Positions were separated from jobs and given approval and effective-date controls. The skills taxonomy merged duplicates, defined proficiency evidence, and linked capabilities to job profiles. A catalogue recorded definitions, classifications, lineage, and retention rules.

Data-quality dashboards monitored duplicate identity, missing manager, invalid organisation, unmatched job, and stale skill evidence. High-risk exceptions were routed to named stewards. Access was redesigned around role and purpose, and historical extracts were reviewed for deletion or restricted archiving.

Outcome

After implementation, the organisation had a reconciled headcount definition, clearer vacancy reporting, more stable job-level analysis, and a defensible process for correcting employee records. The principal benefit was not simply cleaner data; it was clearer accountability for decisions involving data.

Learning points

1. A single application does not create a single truth.
2. Identity, employment, job, and position should be modelled as related but distinct concepts.
3. Data quality improves when controls are placed at the point of creation.
4. Skills data require semantics and evidence, not only labels.
5. Governance is effective when decision rights, lineage, and lifecycle controls are explicit.

Challenges and Limitations

HR data architecture involves unavoidable trade-offs. Standardisation can conflict with local law and practice. Detailed history improves analysis but increases storage, privacy, and interpretation demands. Skills inference can improve discovery but may create false confidence. Central governance can improve consistency but may slow legitimate innovation. Data-quality scores can encourage gaming if organisations measure completeness while ignoring accuracy and relevance.

Architectures also degrade over time. Acquisitions introduce new identifiers, reorganisations invalidate hierarchies, vendors change interfaces, and emerging work arrangements challenge employee-centred models. Governance must therefore be treated as an adaptive organisational capability rather than a one-time implementation project.

Contemporary Developments

Several developments are reshaping HR information management:

• Cloud and composable HR architectures increase integration options but make lineage and vendor accountability more complex.
• Skills-based organisations require capability models that connect people, work, learning, and opportunity.
• Data products and semantic layers aim to provide trusted, reusable information for reporting and analytics.
• Privacy-enhancing techniques such as aggregation, pseudonymisation, and controlled analytical environments can reduce exposure, although they do not remove all risk.
• Generative AI can assist with metadata creation, duplicate detection, classification, and natural-language access, but outputs require validation and human accountability.
• Algorithmic governance is becoming essential as jurisdictions and organisations scrutinise automated employment decisions.

The strategic question is not whether HR should collect more data. It is whether the organisation can demonstrate that its data are necessary, meaningful, reliable, secure, fair, and governed across their full lifecycle.

Chapter Summary

HR data architecture provides the structural foundation for HRIS ecosystems. It defines entities, relationships, meanings, systems, integrations, controls, and responsibilities. Employee master data should distinguish person identity from worker relationships, employment assignments, jobs, positions, organisations, and transactions. Organisational hierarchies must serve distinct legal, managerial, financial, and analytical purposes.

Job architectures classify work, while position models represent authorised instances of work. Skills taxonomies become more valuable when they include definitions, proficiency levels, evidence, and relationships to jobs and learning. Metadata and lineage make data understandable and traceable. Data quality should be assessed through dimensions such as accuracy, completeness, validity, timeliness, uniqueness, consistency, and integrity.

Effective governance assigns owners, stewards, custodians, and decision rights. Privacy, security, ethics, retention, and lifecycle controls are integral rather than optional additions. AI can support HR data management, but it requires transparency, validation, fairness controls, and human accountability. Ultimately, a trustworthy HRIS ecosystem depends on the alignment of architecture, processes, people, technology, and governance.

Key Terms

Analytical data: Data structured for reporting, analysis, and decision support.

Data architecture: The organised design of data entities, relationships, systems, standards, and controls.

Data catalogue: An inventory describing data assets, meanings, ownership, sensitivity, and technical details.

Data governance: The framework of decision rights, policies, roles, and controls for managing data.

Data lineage: The record of data origin, movement, transformation, and use.

Data owner: The person or function accountable for a data domain’s meaning, policy, and risk.

Data quality: The fitness of data for a defined purpose.

Data steward: The role responsible for operational management of definitions, standards, and quality issues.

Employee master data: Core, relatively stable data describing employees and their employment relationships.

Information lifecycle: The stages through which information is created, used, retained, archived, and disposed of.

Job: A standardised category of work with defined purpose, responsibilities, and requirements.

Job architecture: The structured classification of jobs, families, levels, grades, and career paths.

Metadata: Data that describe the meaning, structure, origin, sensitivity, or management of other data.

Ontology: A model representing concepts and the richer relationships among them.

Person record: A record representing an individual who may have one or more organisational relationships.

Position: An authorised instance of a job in a defined organisational and budgetary context.

Reference data: Controlled codes and values used consistently across systems.

Skills taxonomy: A governed classification of skills and related capabilities.

Worker relationship: The organisational relationship through which an individual performs work.

Review Questions

Short Answer Questions

1. Distinguish master data, reference data, and transaction data in an HRIS.
2. Why should a person record be separated from an employment assignment?
3. What is the difference between a job and a position?
4. Define data lineage and state two reasons it is important.
5. Name four dimensions of data quality.

Long Answer Questions

1. Explain how organisational, job, and position models support workforce planning and reporting.
2. Discuss the roles of data owners, data stewards, and data custodians in HR governance.
3. Explain how metadata and business definitions improve HR analytics.
4. Evaluate the privacy, ethical, and security issues associated with sensitive employee data.
5. Describe a complete information lifecycle and explain how retention and disposal should be governed.

Analytical / Application Questions

1. An organisation has three HR systems with different employee identifiers and conflicting headcounts. Design a diagnostic and remediation approach using identity, ownership, lineage, and reconciliation principles.
2. A company wants to use AI to infer employee skills from project records. Evaluate the proposal and specify controls for validity, fairness, transparency, privacy, and human review.
3. Design a minimum data-governance framework for a multinational organisation introducing a new global job architecture. Identify critical domains, owners, quality rules, lifecycle controls, and measures of success.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a job from a position?

A. A job is an individual employee record, while a position is a payroll transaction.

B. A job is a category of work, while a position is an authorised instance of that work.

C. A job is a legal entity, while a position is a country code.

D. A job is a historical record, while a position is always temporary.

Correct Answer: B. A job is a category of work, while a position is an authorised instance of that work.

Question 2

Which data type records events such as promotions, absence requests, and payroll payments?

A. Master data

B. Reference data

C. Transaction data

D. Metadata

Correct Answer: C. Transaction data

Question 3

What is the principal purpose of data lineage?

A. To replace access controls

B. To record data origin, transformations, movement, and destinations

C. To eliminate the need for data owners

D. To define employee compensation bands

Correct Answer: B. To record data origin, transformations, movement, and destinations

Question 4

If 1,920 of 2,000 required manager fields contain valid values, what is the completeness rate?

A. 90%

B. 92%

C. 96%

D. 98%

Correct Answer: C. 96%

Question 5

Which role is primarily accountable for a data domain’s meaning, policy, and risk?

A. Data owner

B. Data consumer

C. Database operator

D. Interface developer

Correct Answer: A. Data owner

Question 6

Which statement about a skills taxonomy is most accurate?

A. It is only a list of employee names.

B. It classifies capabilities and can link them to jobs, learning, and evidence.

C. It automatically proves that every self-reported skill is valid.

D. It replaces the need for job architecture.

Correct Answer: B. It classifies capabilities and can link them to jobs, learning, and evidence.

Question 7

Which principle requires collecting only information necessary for a specified purpose?

A. Data minimisation

B. Data duplication

C. Unrestricted retention

D. Open access

Correct Answer: A. Data minimisation

Question 8

Why are effective dates important in HR data models?

A. They prevent all organisational change.

B. They preserve historical states and changes over time.

C. They remove the need for unique identifiers.

D. They ensure every worker has only one job forever.

Correct Answer: B. They preserve historical states and changes over time.

Question 9

Which is the strongest example of a data-quality integrity rule?

A. Every report uses blue headings.

B. Every assignment references an existing position.

C. Every employee receives the same email format.

D. Every dashboard refreshes at midnight.

Correct Answer: B. Every assignment references an existing position.

Question 10

What is an appropriate control for AI-generated skill inferences?

A. Treat all inferences as verified facts without review.

B. Allow unrestricted use because the model is objective.

C. Use validation, bias testing, explainability, and human review.

D. Delete all historical skills data immediately.

Correct Answer: C. Use validation, bias testing, explainability, and human review.