Competencies are distributed.
Profiles, learning paths, courses and evidence sit in separate systems. Decisions then rely on incomplete data.
Transparent skill profiles and reviewable evidence are needed.Open Skills Consortium
Open skills data for traceable skills decisions.
OSC brings together working drafts for skill profiles, competency evidence and interoperable skills data. The goal is a reliable reference pattern for HR, education, technical teams and product teams.
Working status of the Open Skills Consortium
Working draft
Reference patterns for skill profiles, evidence and skills graph.
Interoperabel
IDs, versioning and export profiles are considered from the start.
Begrenzbar
Start with clearly bounded use cases in HR, education, engineering and product teams.
Ausgangslage
Skills often exist, but they are not reliably usable.
Many organizations work with course data, job profiles, certificates and internal terms. Without a shared structure, matching, learning, product features and evidence remain hard to review.
Terms are not stable.
Skill names change. IDs are missing. Versions and exports are not clear enough for reliable integrations.
Clear data contracts, IDs and export profiles are needed.Rollout questions arrive too late.
Governance, audiences and interoperability often become visible only after the pilot. That makes scaling harder.
Bounded pilots with clear acceptance criteria are needed.Why OSC
The USP: structured skills data plus reviewable AI signals.
The OSC approach combines a knowledge graph, ontology rules, evidence objects and optional embeddings. This makes skill definitions understandable for HR, implementable for development teams and governable for product decisions.
From isolated terms to contextual skill nodes.
A knowledge graph connects skill instances with roles, learning offers, evidence objects, sources and relations. The ontology defines the terms, classes, relations, rules and semantics behind those links.
Use similarity signals without confusing them with proof.
Embeddings and LLM-generated vectors can support search, matching, clustering and draft recommendations. They remain derived support signals and do not prove that a person has a competency.
Make behavioral patterns auditable before using them.
Observed or derived behavioral indicators need a source, timestamp, context and uncertainty. They can inform skill-definition work, but final competency statements still need evidence, assessments, credentials or documented projects.
Value
OSC describes a shared foundation for skills data.
The consortium works on reference patterns that help organizations describe, exchange and review competency data. Value emerges where data from HR, education, engineering, product and evidence systems has to be connected.
Transparency about abilities.
Skill profiles should show which competencies exist, which evidence belongs to them and where learning or recognition can start usefully.
Reliable integrations.
A skills graph needs unambiguous nodes, stable relationships and traceable changes. OSC outlines contract surfaces for that work.
Planbare Piloten.
Product teams can start with bounded data spaces, define acceptance criteria and clarify connection points for later rollouts.
Next step
Start with a reviewable skills data space.
A bounded pilot shows which data is already usable and which standards are still missing.
Mechanics
From term to usable competency record.
OSC does not describe a loose taxonomy. The focus is on data, evidence and exchange formats that remain readable to domain experts and can be technically integrated into existing systems.
- Capture skill terms, normalize them and assign stable IDs.
- Connect competency evidence, micro-credentials and sources in a traceable way.
- Model relationships in the skills graph and update them with versions.
- 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, learning or evidence processes.
Governance
Open skills data needs rules, not only interfaces.
A shared standard must be readable to domain experts and technically reviewable. OSC therefore separates the data model, evidence logic and operating questions.
Traceable.
Every skill record needs provenance, meaning and validity. Without these details, matching remains unreliable.
Interoperable.
OSC works toward open standards, APIs and export profiles. Existing HR and learning systems should not have to be replaced.
Gradually adoptable.
Organizations can start with a clear use case and derive requirements for data, roles and operations.
Reviewable.
Competency evidence and micro-credentials must be machine-readable, while still being understandable to HR and audit teams.
Pilot patterns
Concrete entry points for HR, engineering and product.
The following patterns describe possible pilots for HR, education, engineering and product teams. They are intentionally bounded so value, data quality and interoperability become visible early.
Skill matching for internal roles.
- Problem
- Role requirements and existing competencies are not described consistently.
- OSC response
- Skill profiles with IDs, evidence and defined rating levels are modeled as a pilot data set.
- Reviewable result
- HR can explain matching rules, see deviations and derive learning needs.
Micro-credentials in learning paths.
- Problem
- Courses produce attendance confirmations, but rarely interoperable competency evidence.
- OSC response
- Evidence is connected with skills, validity, issuer and evaluation logic.
- Reviewable 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.
- Reviewable result
- Engineering and development teams get a clear contract surface for integration, testing and operation.
AI support for skill definitions.
- Problem
- Teams often derive skill terms, synonyms and relations from job profiles, learning content or project evidence.
- OSC response
- AI can prepare draft definitions, labels and relations. Sources, meaning, version and release status still need expert review.
- Reviewable result
- Skill definitions can start faster as working drafts, without treating model outputs as evidence or final standards.
Chatbots also need skill definitions.
- Problem
- Chatbots answer questions about roles, learning paths or evidence. Without defined skills, they can mix terms, sources and validity.
- OSC response
- A maintained skills data model provides terms, IDs, relations, sources and release status as usable context for chatbot answers.
- Reviewable result
- Answers can point to maintained definitions and remain assistance, not competency evidence.
Pilot review
Which data scope is suitable for the start?
A good pilot starts with a few skill profiles, clear evidence and a concretely reviewable process.
Working method
From reference pattern to reliable pilot.
OSC formulates statements as working drafts. This creates room for tests without turning early patterns into finished standards.
Fachlich lesbar.
HR, education and domain teams need to understand why a skill, evidence item or matching result is used.
Technically reviewable.
Data model, IDs, versions and interfaces are described so development teams can test them.
Governance-ready.
Roles, approvals, sources and change processes are documented early so a pilot does not fail in operations.
Contact
Review an OSC pilot for your skills data.
Briefly describe which competency data, evidence or interfaces matter. We will assess whether a bounded pilot or an expert workshop is useful.