Interoperability stack

Reference patterns for interoperable competency data.

The OSC reference framework separates key concepts: ontologies describe terms, classes, relations, rules and semantics; knowledge graphs connect instances, sources and evidence objects; embeddings provide derived vector signals for search, matching, clustering, recommendations and forecasting. Model outputs remain supporting signals, not competency evidence.

Submit standardization requirements Check API work status

Orientation

A reference framework for skill data in piloting and review.

The standards page describes the current OSC work status. It separates ontology, knowledge graph, embeddings, evidence, interfaces and governance so that HR, product management and development can check the same requirements.

Semantics

Stabilize terms and relationships technically

Ontologies describe terms, classes, relations, rules and semantics. Knowledge graphs connect concrete skill instances, roles, learning opportunities, sources and evidence objects.

Evidence

Classify competence signals in a verifiable manner

Credentials, projects and assessments are linked to origin, version, context and evaluation logic. Model values ​​and embeddings remain auxiliary signals, not proof of competence.

Pilot integration

Plan exports and API as work status

Planned export profiles, stable identifiers, mandatory fields and documented error cases make interfaces in pilots testable without deriving productive API commitments from them.

Knowledge Graph Ontology

What the model means in simple language.

The reference model does not treat every vector as a standard. Ontology gives meaning to concepts. The knowledge graph connects concrete instances and evidence. Embeddings and LLM vectors help to find patterns, but remain technical signals that require review.

Structure before automation

A skill node needs an identifier, name, relations, source reference, version and status before downstream AI functions can use it responsibly.

Behavioral patterns remain context-bound

Behavioral indicators can be observed or derived. They require source, time reference, context and uncertainty and do not replace tested evidence of competence.

Four levels

Four separate levels for connectable skill data.

The OSC work status separates ontology, knowledge graph, embeddings and evidence. API/Export Profiles and Governance describe how these layers are exchanged, audited, and versioned in Pilots.

Level 1

Ontology

Controlled terms, classes, relations, rules and semantics form the versioned technical language.

  • stable skill IDs and preferred labels
  • Classes, relations, synonyms and rules
  • Versions, languages and change history
Level 2

Knowledge Graph

The knowledge graph connects skill instances, roles, learning offers, sources, relations and evidence objects.

  • concrete instances instead of just term catalogs
  • Source references, relations and context
  • Links to evidence and profiles
Level 3

Embeddings

Embeddings are derived vector representations for search, matching, clustering, recommendations and predictions.

  • Similarity, search and cluster auxiliary signals
  • Model version, data basis and update
  • clear separation of evidence and releases
Level 4

Evidence

Evidence objects classify evidence from learning, work, assessment and certification with provenance.

  • Issuer, source, context and time
  • Evaluation logic, level, validity and test status
  • Releases, purposes and documented decisions

Assignment

Artifacts, quality criteria and applications in a grid.

The table shows what is specifically tested in pilot projects: which artifacts are present, how quality is recognized and in which applications the level should be used.

Assignment of interoperability levels to artifacts, quality criteria and typical applications of the OSC reference model.
Level Artifact Quality criterion Application
Ontology Skill catalog, taxonomy, ontology, mapping table Unique IDs, defined terms, maintained classes, relations, rules and versions Subject-specific examination, search, role comparison and learning offer mapping
Knowledge Graph Graph reference pattern, relation table, source reference, evidence link Traceable instances, relations, sources, context and updates Skill gaps, profile comparison, portfolio views and system integration
Embeddings Vector representation, model metadata, similarity value, evaluation findings Documented model version, data basis, update and clear identification as an auxiliary signal Similarity search, matching suggestions, clustering, recommendations and forecasts
Evidence Credential profile, portfolio entry, assessment data set, audit note Verifiable origin, context, validity, evaluation logic, purpose limitation and verification status Recognition processes, talent profiles, qualification paths and audit preparation

API and export note

JSON/CSV profiles, REST paths and error catalogs are planned working statuses for pilot integrations. Binding productive addresses, authentication, rate limiting and SLAs only arise in a released specification.

Quality

Quality arises through separation, origin and pilot findings.

A work status only becomes reliable when mandatory fields are complete, provenance is traceable and real system data has been checked. Results from pilot tests are documented as findings, not as automatic standard release.

Testability

Every statement needs an origin

Version, publisher, update, data source and evaluation logic belong to the artifact. Instances, relations, evidence objects, sources and connections are stored in a comprehensible manner in the knowledge graph.

Usability

Auxiliary signals remain separated

Semantic HTML, tabular references and planned export profiles intertwine. Derived model values ​​can support matching and search, but remain clearly separated from verified evidence and release decisions.

Service Compliance Test

A practical test for connectable skill services.

The service compliance test is intended as a pilotable testing framework for digital services. It supports teams in checking data, interfaces and evidence against the OSC work status. It is not a certificate and does not replace a final standard release.

Compliance here means a documented check against the OSC work status. It includes data fields, proof of competence, interfaces and governance. It is not a certification or a productive release.

Data model

Understand mandatory fields and terms

It is checked whether skill IDs, labels, relations, languages, versions and sources are documented in such a way that a service can clearly process them.

Interface

Make export and error cases pilotable

A pilot can demonstrate whether sample payloads, field formats, updates and error notices are understandable. This does not result in productive SLAs or binding API commitments.

Evidence

Separate evidence from auxiliary signals

Credentials, assessments and portfolio entries are checked with origin and context. Matching values ​​or embeddings remain supporting signals, not conclusive evidence.

Result of the check

The result is a finding with open points, assumptions and possible adjustments for the next pilot. A statement of conformity is only created when an approved standard and a test process defined for it are available.