Skills Intelligence Governance: Who Owns What?

The meeting begins with a definition. HR wants to add "AI leadership" to the enterprise skills taxonomy. Learning wants the term because executives are asking for a programme. Technology leaders say it is too vague to assess. A platform supplier can map it to several existing concepts. Employee representatives want to know whether the label will affect promotion or redundancy decisions.

This looks like taxonomy housekeeping. It is not. The organisation is deciding whose language becomes official, which evidence will count, who may act on it, and who bears the cost when the definition is wrong.

That is the real work of skills intelligence governance:

Governance is the allocation of authority over meanings, evidence, uses, and consequences.

HR has an essential role, but it cannot own that system alone. The business understands work and its changing context. Employees are the subjects of many claims and need an effective route to challenge them. Data and technology teams operate the machinery. Risk functions set boundaries. Managers make decisions. Finance and operational leaders own the results. A platform can support all of them; it cannot resolve their legitimate disagreements.

If skills intelligence is the discipline of turning capability evidence into decisions, as the practical definition explains, governance determines who may make each turn in that chain.

A taxonomy decision is rarely just semantic

Changing a skill label can alter who appears in a search. Merging two concepts can make a capability gap appear smaller. Adding a proficiency level can change eligibility for a project. Mapping a local certification to a broad external skill can make experience look portable when it is not. Retiring a concept can break historical reporting.

The words therefore distribute opportunity, investment, and risk. "Strategic thinking" may become a leadership gate. "Cloud engineering" may determine who receives scarce training. "Maintenance" may hide the equipment-specific authorisation that makes a person safe to schedule on a shift. People who control the definitions can influence decisions even if they never make those decisions directly.

The OECD's work on a common skills language describes shared definitions as foundational, but also identifies granularity, duplication, interoperability, local institutional fit, and continuous updating as persistent challenges. It notes that real systems commonly combine external frameworks, expert judgement, data, AI, and stakeholder consultation. That is a governance problem, not a one-off content-cleaning exercise.

Treating it as an HR data project creates three predictable failures:

The language becomes detached from work. Central teams cannot continuously judge the meaning of every specialist capability, asset, regulation, and customer context.
Local truth becomes enterprise noise. Domains create private spreadsheets and aliases when the central model cannot express what matters, destroying comparability.
The vendor becomes the de facto governor. Product updates, proprietary mappings, and default scores quietly change organisational meaning because nobody inside the enterprise owns the decision.

The answer is not to move ownership from HR to IT or to create a larger committee. It is to separate the rights that have been bundled together.

Six rights that should never be collapsed into one owner

"Who owns skills?" is the wrong question. There are at least six different objects to govern.

1. The semantic owner owns meaning

The semantic owner approves a concept's definition, scope, exclusions, relationships, and place in the enterprise language. This owner should be close enough to the work to distinguish a useful capability from fashionable vocabulary.

For an enterprise-wide construct such as people management, the owner might sit in a cross-functional job architecture or workforce standards group. For a specialist skill such as sterile process validation, ownership belongs in the relevant professional or operational domain. HR should steward the overall architecture and consistency rules, not claim expertise it does not possess.

2. The evidence owner owns what may support a claim

A definition does not decide how somebody demonstrates the skill. The evidence owner specifies permitted sources, validation methods, recency, access, and retention for a class of evidence.

An assessment team may own an instrument. A certification function may own licence records. An engineering organisation may define what delivered work qualifies as evidence of production experience. Data protection and employee relations should set constraints on collection and reuse. The evidence owner must preserve the difference between an observation, an assertion, and a verified result.

3. The model owner owns transformation

The model owner is accountable for rules or algorithms that extract, normalise, map, rank, or infer claims. This includes non-AI logic: a spreadsheet lookup that maps titles to skills is still a model. The owner controls versions, tests, thresholds, monitoring, and rollback.

This role belongs with the team able to evaluate the transformation, but it cannot approve its own business use. The NIST AI Risk Management Framework Core is helpful beyond AI here: it calls for clear roles, multidisciplinary perspectives, executive responsibility, and governance throughout the lifecycle. Technical operation and permission to act should remain separate.

4. The workflow decision owner owns use

The workflow decision owner decides which claims may inform a specific action: recommending learning, shortlisting for a project, identifying succession risk, or approving safety-critical work. This owner sets the decision threshold, human review, exceptions, prohibited uses, and escalation path.

They cannot delegate accountability to the data team or platform. The same skill claim may be acceptable for optional discovery and unacceptable for selection. Governance must attach permission to the use, not merely to the record.

5. The employee owns a correction right

An employee need not own the enterprise definition to have rights over claims about them. They should be able to see relevant claims and sources, distinguish inference from verified evidence, correct a factual error, add context, and seek human review when a claim influences a material decision.

This must be an operating right, not a feedback button. A correction needs a service level, an independent escalation route, and propagation to every downstream workflow and aggregate where the incorrect record was used. Legal duties differ by jurisdiction, but the UK's Information Commissioner's Office, for example, tells employers to keep worker information accurate, consider accuracy challenges carefully, and let workers explain or challenge results, especially where analytics may affect them. It also makes clear that buying a third-party product does not transfer the employer's responsibility. Read the ICO guidance on worker data.

6. The outcome owner owns whether it worked

The outcome owner holds the budget or operational result the skills intervention is meant to change: time-to-staff, internal fill, readiness, service quality, resilience, or another agreed measure. They validate the baseline, accept the result, and decide whether the intervention should scale.

Without this owner, the programme reports activity to itself. Profiles, mappings, and recommendations can grow while the decision remains no better. The outcome owner should normally sit outside the skills programme.

Use a federated model, not a universal master taxonomy

An enterprise needs enough shared language to compare and coordinate, but enough local authority to represent real work. A practical model has three layers.

The enterprise core

The core defines the rules that must travel across domains:

stable identifiers and object types;
minimum definitions and scope notes;
standard relationship types;
evidence states and provenance fields;
proficiency and recency conventions where commonality is justified;
version, deprecation, and audit rules;
a small set of genuinely enterprise-wide concepts.

The core should be deliberately thin. It is constitutional infrastructure, not an attempt to describe every job from the centre.

Domain extensions

Domains add the detail required for their decisions: technologies, methods, equipment, products, customer contexts, licences, or specialist practices. Each extension follows the core contract but has a named semantic owner, review cycle, and local evidence rules.

A domain may refine "data engineering" into platform- and task-specific capabilities without forcing the whole enterprise to adopt that granularity. A plant may represent equipment authorisation that has no useful equivalent in the corporate model. Local extension is legitimate; silent redefinition of a core concept is not.

Governed mappings and versions

Interoperability comes from explicit mappings, not from pretending two models are identical. Every mapping should record whether the relation is exact, broader, narrower, or merely related, together with source and target versions, reviewer, confidence or rationale, effective date, and permitted uses.

ESCO provides a useful public example of the underlying mechanics: its concepts have unique URIs, the API exposes different classification versions, and its published approach distinguishes minor changes from major changes that affect concepts or the data model. The ESCO web-service documentation describes the identifiers and selectable versions, while its versioning explanation shows why mappings and downstream systems must be managed when concepts change.

An enterprise need not copy ESCO's content to adopt the lesson: identifiers, meanings, and mappings require separate lifecycle control. Store the vendor label, external identifier, enterprise concept, mapping relation, and version. Then a supplier update becomes a reviewable change instead of an unannounced rewrite of organisational truth.

A decision-rights matrix

The exact titles will vary. The separations should not.

Decision	Responsible owner	Approval or authority	Required consultation	Non-delegable record
Create or materially redefine an enterprise-core concept	Enterprise semantic steward	Cross-functional skills governance council	Domain experts, job architecture, employee representation where impact is material	Definition, exclusions, rationale, effective version
Create a domain extension	Domain semantic owner	Domain authority operating under core rules	Enterprise steward and affected neighbouring domains	Local scope, owner, relationship to core
Approve an external or cross-domain mapping	Mapping steward with both domain owners	Semantic owners of source and target	Data integration and workflow owners	Mapping type, versions, rationale, permitted uses
Accept a source as evidence	Evidence owner	Evidence governance or relevant risk authority	Domain expert, privacy, security, employee relations	Source, method, permission, recency and validation rule
Release a model or ruleset change	Model owner	Change authority proportionate to impact	Semantic, evidence and affected workflow owners	Evaluation result, version, known limits, rollback plan
Permit claims in a workforce workflow	Workflow decision owner	Accountable business executive; risk or legal review where required	Model, evidence, HR, employee relations and domain owners	Decision contract, threshold, human review, prohibited uses
Resolve an employee correction	Evidence owner or independent case owner	Employee data policy; appeal outside the original decision chain	Employee and source owner	Original claim, challenge, resolution, propagation status
Declare the intervention successful	Business outcome owner	Programme sponsor or investment authority	Finance, workflow owner, affected population	Baseline, outcome, limitations, distributional effects

This matrix prevents two common evasions. "The model said so" cannot replace workflow accountability, and "the business wanted it" cannot excuse an ungoverned source or transformation.

Four conflicts governance must be able to resolve

Governance becomes real only when reasonable parties disagree.

Conflict 1: one label, two meanings

Sales uses "solution architecture" for discovery and commercial design. Technology uses it for technical authority over production systems. The answer is not a vote on the preferred definition. Create distinct scoped concepts, preserve both source terms, define their relationship, and stop workflows from treating them as equivalents.

Conflict 2: local precision breaks enterprise comparison

A business unit wants twelve levels of a capability while the enterprise uses four. The domain may retain its scale, but it must publish a mapping with known information loss. Enterprise reporting uses the common bands; local staffing uses the detailed scale. Neither side silently overwrites the other.

Conflict 3: the vendor changes the map

A product release merges two skills or changes an occupation-to-skill relationship. The model owner tests the change against affected records; semantic owners assess meaning; workflow owners inspect decision impact. Until approval, production remains on the previous version. "Continuous update" does not mean continuous permission.

Conflict 4: an employee disputes a claim

A manager-validated profile says an analyst lacks stakeholder management. The employee provides recent work evidence and argues that the rubric was applied inconsistently. The original manager should not be the final appellate authority. A case owner examines the source and rubric, records the resolution, and propagates any correction. If the claim affected access to an opportunity, the workflow owner assesses the decision, not only the database row.

A council that cannot resolve these cases is an advisory forum, not a governance system.

The operating cadence: govern change, not meetings

A viable cadence is light for ordinary change and explicit for material change:

Weekly triage: review proposed concepts, mappings, corrections, incidents, and urgent domain requests; route each item to an owner and risk tier.
Monthly domain forum: resolve semantic and evidence questions close to the work, review ageing concepts, and prepare cross-domain conflicts.
Monthly enterprise council: approve core changes, contested mappings, new consequential uses, and exceptions; publish decisions and dissent.
Quarterly outcome review: examine whether governed workflows changed business and employee outcomes, whether corrections or errors concentrate in particular populations, and whether a use should scale, change, or stop.
Scheduled releases: bundle non-urgent semantic changes into versioned releases with impact notes, compatibility rules, and migration windows.

Measure the operating system itself: median time to resolve a correction, share of production concepts with active owners, unmapped local terms, workflows using unsupported versions, overdue reviews, and decisions reversed because evidence or meaning was wrong. These are controls, not proof of business value; connect them to the outcome measures in the skills intelligence dashboard guide.

The first 90 days

Do not begin by convening an enterprise taxonomy board. Begin with one live workforce decision and make its authority visible.

Days 1–15: map the decision chain

Choose one workflow with a real owner and consequence. Inventory the concepts, evidence, mappings, models, thresholds, systems, and people already influencing it. Record where decisions are being made implicitly — especially vendor defaults and local spreadsheets.

Name the six owners. Where a role is vacant, mark it as a governance gap rather than assigning everything to the programme manager.

Days 16–30: establish the constitutional minimum

Define the enterprise core contract: identifiers, required metadata, relationship types, evidence states, version rules, correction route, and risk tiers. Set the boundary between core and domain extension. Approve a compact decision-rights matrix and an escalation path.

Avoid modelling the whole enterprise. Convert only the concepts required for the pilot decision.

Days 31–60: exercise disagreement

Build the domain extension and mappings for the chosen workflow. Process real change proposals and corrections. Test a vendor update or simulated mapping change. Ask two independent reviewers to interpret the same ambiguous concept; disagreement exposes missing scope faster than another taxonomy workshop.

Days 61–90: run, inspect, and publish

Operate the workflow with its approved version and decision contract. Trace several outputs back to definitions, evidence, transformations, and accountable decisions. Verify that a correction reaches search, matching, reporting, and any affected decision.

The outcome owner then decides whether the governance model reduced error, delay, or ambiguity enough to expand. Publish what remains unresolved. A credible first release includes limits and dissent, not only approved definitions.

Eight governance risks to name early

HR monopoly: a central function standardises meanings it cannot validate and mistakes policy authority for domain expertise.
Domain feudalism: every function declares itself unique, blocks comparison, and avoids common controls.
Vendor shadow governance: proprietary updates alter concepts or rankings without enterprise approval.
Committee theatre: many people are consulted, but nobody has a deadline, decision right, or accountable outcome.
Consensus laundering: disagreement is erased to produce one clean score instead of being represented and resolved for a particular use.
Correction without remedy: a record is edited, but previous recommendations, aggregates, or decisions remain untouched.
Version amnesia: current labels are applied retrospectively, making historical trends look comparable when meaning changed.
Control without value: governance becomes so slow and universal that domains route around it; risk tiers should make low-consequence changes easier, not equally bureaucratic.

The governance test

Ask six questions before calling the operating model complete:

Who can define this concept, and who can challenge the definition?
Who decides which evidence is sufficient for this exact use?
Who owns each transformation between source and decision?
Who has authority to act, override, pause, and accept the consequence?
Can an affected employee correct the claim and obtain a meaningful review?
Who owns the outcome and can stop funding the intervention when it does not work?

If every answer is "HR", the organisation has centralised a liability, not created governance. If every answer is "the business", it has replaced governance with local discretion. If any answer is "the platform", it has outsourced authority without outsourcing accountability.

The aim is not equal ownership of everything. It is explicit ownership of different things, joined by versioned contracts and a route for resolving conflict. That is how a shared skills language can remain both interoperable and true enough to the work.

If you need to design the ownership model, federation rules, decision-rights matrix, or first governed workflow, get in touch to discuss the implementation.

Skills intelligence governance: who owns the taxonomy, evidence, and decisions?