Readable reference page
The page names the competency identifier, name, description, publisher, version, source and status. It remains usable for technical review, search and accessibility.
Developer
Cleanly model competency data and exchange it in a pilotable way.
This page describes the intended working status for OSC-compatible data models, export profiles and interface contracts in pilots. Example paths are not shared production API addresses.
Integration path
From readable catalog to verifiable data exchange.
An OSC implementation begins with technically tested content. The same mandatory fields should be reused in exports and interfaces: unique identifiers, designations, versions, sources, statuses and references.
Stable identifiers
Each competency receives a permanent identifier. Names, synonyms and relations may change; the identifier remains the technical reference.
Export profiles
Planned JSON and CSV profiles describe field names, data types, mandatory fields, allowed values and error cases for pilot imports and quality assurance.
Release and versioning
Changes need status, release, change notice and version reference. Integrations can specifically differentiate between draft, pilot version and tested recommendation.
Principles
Readable, versioned, technically verifiable.
Technical integration must not replace technical testing. Ontology, knowledge graph, embeddings and evidence objects remain separate data types; Model outputs and similarity values provide clues, but not proof of competence.
Core fields before model values
Identifier, label, description, source, version and evidence status remain required information.
Sources and versions
Every change to skills data, relations or evidence should be reproducible and dated.
HTML, export and API consistent
Readable pages, planned JSON/CSV exports and API responses use the same core fields.
Developer USP
A contract for graph data, vectors and evidence status.
OSC separates fields that are often mixed in AI projects. The API contract can designate graph relations, embedding metadata, LLM-generated design signals, and evidence references as different data types. This makes integrations more testable and reviews more reliable.
Graph payload
Skill IDs, relation types, sources, language, version and status become visible so systems can check the meaning of a node.
Vector metadata
Model version, input scope, update date and purpose belong to embeddings. A vector without metadata is not a verifiable statement of competence.
Evidence reference
Assessments, credentials, projects and source documents remain in explicit evidence fields, separate from matching values or behavioral indicators.
Data model
Mandatory fields for competency records in the pilot.
The fields form a reference pattern for pilots. They are not a final published schema and need to be reviewed depending on the integration context, data source and release status.
- stable competency identifier and record type
- Main name, language and optional synonyms
- short, technically verifiable description
- Ontology reference: class, relation, rule or mapping
- Publisher, Source, License and Terms of Use
- Version, change date, status and release status
- Relationships to clusters, roles, learning offers or evidence objects
- Test status and earmarking if evidence is referenced
Separation
Keep ontology, knowledge graph, embeddings and evidence separate.
An interface should clearly indicate which data describes technical semantics, which relationships are in the graph, which values were technically derived and which evidence has been checked.
- Ontology: Terms, classes, relations, rules and semantics.
- Knowledge graph: skill instances, roles, sources, relations and evidence references.
- Embeddings and model values: similarities, clusters, recommendations and normalization suggestions as auxiliary signals.
- Evidence objects: assessments, credentials, project artifacts and documented sources with audit status.
- Evaluation logic, source, time, validity and intended purpose belong in their own fields.
Service Compliance Test
Practical matching for fields, identifiers and contracts.
The service compliance test is intended as a pilotable test. It compares sample data, export profiles and interface contracts with the agreed mandatory information, without anticipating productive API addresses or releases.
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.
Mandatory fields
It is checked whether the identifier, data record type, name, language, description, status and version are clearly and completely present in the sample data.
Contracts and exports
JSON, CSV or API contracts are checked against field names, data types, mandatory logic, allowed values and documented error cases.
Evidence and origin
Evidence, source, license and version metadata remain comprehensibly separated. A test status describes the status of the work, not automatically recognition.
Exports and API
Example paths for planned pilot APIs and exports.
The following paths are working examples of pilot integrations. Productive addresses, authentication, rate limiting, error codes and versioning only become binding in the respective specification.
GET /osc/api/v1/skills/?language=de-DE
GET /osc/api/v1/skills/{skill_id}/
GET /osc/api/v1/evidence/{evidence_id}/
GET /osc/api/v1/graphs/relations/?skill_id={skill_id}
GET /osc/api/v1/embeddings/similar-skills/?skill_id={skill_id}
POST /osc/api/v1/pilots/evidence-check/API note on the work status
HTML pages provide canonical content. JSON and CSV exports should contain the same mandatory fields: identifier, name, description, version, source, language, status, license and documented error cases.
Endpoints for evidence review are to be understood as pilot work status: They reference evidence and return a review status, but do not replace professional recognition or governance approval.