Competencies are distributed.
Profiles, learning paths, courses and certificates are in separate systems. Decisions are then based on incomplete data.
Transparent skill profiles and verifiable evidence are needed.Open Skills Consortium
Open skills data for understandable skills decisions.
OSC bundles work statuses for skill profiles, proof of competence and interoperable skills data. The goal is a reliable reference template for HR, education, technology and product teams.
- Skill profiles
- Proof of competence
- Open APIs
- Skills Graph
Work status of the Open Skills Consortium
Work status
Reference template for skill profiles, evidence and skills graph.
Interoperable
IDs, versioning and export profiles are taken into account right from the start.
Limitable
Start with clearly limited use cases in HR, education, technology and product teams.
Initial situation
Skills are often available but cannot be used reliably.
Many organizations work with course data, job profiles, certificates and internal terms. Without a common structure, matching, further training, product functions and evidence remain difficult to verify.
Terms are not stable.
Skill names change. IDs are missing. Versions and exports are not clear enough for robust integrations.
Clear data contracts, IDs and export profiles are required.Rollout questions come too late.
Governance, target groups and connectivity often only become visible after the pilot. This makes scaling difficult.
Limited pilots with clear acceptance criteria are needed.Why OSC
The USP: structured skills data plus verifiable AI signals.
The OSC approach combines knowledge graphs, ontology rules, evidence objects and optional embeddings. This means that skill definitions remain understandable for HR, implementable for development teams and controllable for product decisions.
From individual terms to skill nodes with context.
A knowledge graph links skill instances with roles, learning opportunities, evidence objects, sources and relations. The ontology defines the terms, classes, relations, rules and semantics behind them.
Use similarity signals without confusing them with evidence.
Embeddings and LLM-generated vectors can support search, matching, clustering and recommendation suggestions. They remain derived auxiliary signals and do not prove a person's competence.
Make behavior patterns testable before they are used.
Observed or derived behavioral indicators need source, time reference, context and uncertainty. You can prepare skill definitions, but final competency statements need evidence, assessments, credentials or documented projects.
Benefits
OSC describes a common foundation for skills data.
The consortium is working on reference templates that organizations can use to describe, exchange and check competency data. The benefit arises where data from HR, education, technology, product and verification systems need to be brought together.
Transparency about capabilities.
Skill profiles are intended to make it clear which skills are available, which evidence is included and where further training or recognition makes sense.
Reliable integrations.
A skills graph needs clear nodes, stable relationships and traceable changes. OSC outlines contract areas for this.
Plannable pilots.
Product teams can start with limited data spaces, define acceptance criteria and clarify connection points for later rollouts.
Next step
Start with a testable skills data room.
A limited pilot shows which data is already usable and which standards are missing.
Mechanics
From concept to usable competency data set.
OSC does not describe a loose taxonomy. The focus is on data, evidence and exchange formats that remain technically readable and can be technically integrated into existing systems.
- Capture, normalize and assign stable IDs to skill terms.
- Link proof of competence, micro-credentials and sources in a comprehensible manner.
- Map relationships in the Skills Graph and update them in a versioned manner.
- Define export profiles and API contracts for HR, learning and product systems.
- Document quality, provenance and changes for audits and governance.
- Test pilot data against real matching, further training or verification processes.
Governance
Open skills data needs rules, not just interfaces.
A common standard must be technically readable and technically verifiable. That's why OSC clearly separates the data model, verification logic and operational issues.
Comprehensible.
Every skill data set needs origin, meaning and validity. Without this information, matching cannot be relied upon.
Connectable.
OSC works towards open standards, APIs and export profiles. Existing HR and learning systems should not have to be replaced.
Can be introduced step by step.
Organizations can start with a clear use case and derive requirements for data, roles and operations from this.
Testable.
Proof of competence and micro-credentials must be machine-readable, but also be technically understood by HR and Audit.
Pilot pattern
Concrete entry points for HR, development and product.
The following patterns describe possible pilots for HR, education, engineering, and product teams. They are deliberately limited so that the benefits, data quality and connectivity become apparent early on.
Skill matching for internal roles.
- Problem
- Role requirements and existing competencies are not consistently described.
- OSC response
- Skill profiles with IDs, evidence and defined assessment levels are modeled as a pilot data set.
- Verifiable result
- HR can explain matching rules, see deviations and determine the need for further training.
Micro-credentials in learning paths.
- Problem
- Courses generate confirmations of participation, but rarely conclusive proof of competence.
- OSC response
- Evidence is linked to skills, validity, issuer and evaluation logic.
- Verifiable result
- Education and L&D teams can align learning paths more closely with roles, projects, and audit requirements.
API profile for skills data.
- Problem
- HR, learning and product systems use different terms and exchange formats.
- OSC response
- An export profile describes fields, IDs, versions and minimum quality for data exchange.
- Verifiable result
- Technical and development teams receive a clear contract area for integration, testing and operation.
AI support for skill definitions.
- Problem
- Teams often derive skill terms, synonyms and relationships from role profiles, learning content or project evidence.
- OSC response
- AI can prepare drafts for definitions, labels and relations. Source, meaning, version and release status remain subject to technical review.
- Verifiable result
- Skill definitions are created more quickly as work status, without treating model outputs as proof or final standard.
Chatbots also need skill definitions.
- Problem
- Chatbots answer questions about roles, learning paths or evidence. Without defined skills, they can mix up terms, sources and validity.
- OSC response
- A maintained skills data model provides terms, IDs, relations, sources and release status as a usable context for chatbot answers.
- Verifiable result
- Answers can refer to well-maintained definitions and remain assistance, not proof of competence.
Pilot test
Which data section is suitable for starting?
A good pilot starts with a few skill profiles, clear evidence and a concrete, verifiable process.
How it works
From reference model to resilient pilot.
OSC formulates statements as a work status. This creates space for testing without deriving ready-made standards from early samples.
Technically readable.
HR, education and departments need to understand why a skill, credential or matching result is used.
Technically verifiable.
Data model, IDs, versions and interfaces are described so that development teams can test them.
Governance capable.
Roles, releases, sources and change processes are documented early on so that a pilot does not fail in operations.
Contact
Check an OSC pilot for your skills data.
Briefly describe which competence data, evidence or interfaces are relevant. We decide whether a limited pilot or a technical workshop makes sense.