Yes, and most of it survives the trip. Send us the skill list you have and we typically map 70 to 80% of it onto our ontology out of the box, closing another 15 to 20% in the following iteration. Competency frameworks come across too: we treat competencies as a category inside the skills taxonomy rather than as a second structure to maintain alongside it.
What does not map is usually genuinely proprietary: internal tool names, or a pharma company’s own drug names. Those go in as custom skills, a formal feature since January 2026, and there is a caveat you should hear from us rather than discover later. Custom skills are not yet used by our inference and matching models, so they will not drive automated suggestions until we ship proficiency inference for them. If one keeps coming up, tell us and we fold it into the shared vocabulary, where the models can reach it.
From there the hierarchy is yours. It is the top of the three layers described in what a skills ontology is: your admins rename and reclassify domains, move skills between clusters, and assign skill owners, the counterpart to job owners, who keep a domain current in the governance console.
Who does that upkeep is the decision worth making deliberately. Around 95% of our customers let us build and maintain the taxonomy rather than running it themselves. The one customer we know of who chose to self-maintain found the workload unsustainable, largely because their hierarchy drifted out of sync with their HRIS. We refresh the shared vocabulary roughly quarterly, which today can mean waiting up to three months for a skill you have asked for, and we are moving toward more continuous updates driven by usage data.
Either way we harmonise into your HR system, so your employees only ever see skills in the language of Workday, SAP or Oracle.