AI Adoption GuideHRDevelop
Skills inference from work artifacts
Embeddings on messages, pull requests, and docs derive a live skills graph per employee without self-reporting.
HR processPlanSourceSelectHireOnboardDevelopRewardExit
By Don, DoneThat’s AI coach · updated
A skill tag is evidence the employee can open
A skills graph is only as good as the work it can point to. The quality bar for this use case is narrow: a skill tag that cites a licensed work artifact the employee can see. The cite is the product. The embedding is only a retrieval step. If the artifact is missing, deleted, ACL-blocked, or outside the systems counsel has licensed, the cell stays empty. Empty is correct. A label without a pointer is not a skill.
Until the employee confirms, the graph is an operator draft. It does not auto-publish into the HRIS, a talent marketplace, or a manager view that looks official. Confirmation is the publication gate, not a courtesy email after the fact.
A usable cite includes the system, an object the person can open, a timestamp, and a reason in plain language. A similarity score with no document id is not a cite. If they cannot inspect the source, you do not have a tag.
Do not scrape unauthorized inboxes or personal devices. Those stores may contain work. They are not systems of record counsel already allows, and they mix personal and professional context you cannot later separate.
Load only the repo, approved wiki, and LMS counsel named
Inventory licensed sources before you embed anything. The in-scope set for this pattern is the company repository, the approved wiki, and the LMS. Record the legal basis, retention window, and who may access the raw objects. That list is a boundary, not a completeness target. Side channels, personal drives, and unsanctioned chat exports stay out even when they would make the graph look fuller.
Map identity only through existing HRIS-to-system identifiers. Do not enrich from personal email or device IDs. Snapshot metadata you will show next to the tag: title or path, time, system, and a deep link the employee can use without asking IT for a dump. If a person has no licensed artifacts in a source, write nothing for that source. Do not backfill from teammates or from role averages.
Chat is the usual expansion request. Tone is not competence. An embedding that reads as "confident about Kubernetes" from stand-up affect is not evidence they shipped Kubernetes. If counsel has not licensed a messaging system of record, leave it out. If they have, still require a durable object (merged change, published page, completed course) before a tag is eligible. Chat may hint where to look. It does not fill the cite.
Talent platforms in the skills-cloud class, including Workday, Gloat, Eightfold, and Lattice, can hold or route skills once you have them. They do not relax the quality rule. Do not import an inferred vendor taxonomy as if it were cited work. Do not push draft tags into those systems as published profile data. If a vendor graph arrives without an employee-visible artifact pointer, treat it as a suggestion list.
Infer as triples, keep blanks, wait for confirmation
After the corpus is loaded, infer per employee against only that employee's licensed artifacts. Emit candidates as triples: skill label, cite (system, object id, link), and a one-line reason ("merged pull request that adds Terraform modules for the payments VPC"). If you cannot fill the cite, do not emit the tag. The cell stays empty.
Blanks prevent invented coverage. Someone with a dense repo history and no wiki or LMS record should show engineering tags the pull requests support, and empty cells for facilitation or domain knowledge that never appeared in licensed objects. Filling empties from chat tone, job title, or "people in this role usually know X" recreates self-reporting with extra confidence.
Illustrative path, not a measured case: a people-analytics lead prepares a snapshot for a data platform group. For one engineer, the licensed corpus is merged pull requests in the analytics-platform repo plus LMS completions in SQL. Inference proposes "dbt modeling" citing a merged change that adds incremental models, and "SQL performance" citing a completion the engineer can open in the learning portal. It does not propose "executive storytelling" because the only signal was upbeat phrasing in messages. "Stakeholder management" stays empty. The engineer reviews each proposal beside the artifact: accept, reject, or ask for a better cite. Rejected tags stay rejected until new licensed work appears and they are asked again. Operators may see a watermarked draft. Nothing is exported as official.
Do not auto-publish on a schedule. A nightly write into the employee profile or a manager pack treats the draft as production. Managers will staff from whatever sits next to a name. You will not walk that back with a footnote.
Catch the three leaks before anything leaves the workspace
A tag with no artifact cite. Block export when the cite is null, the link fails, the ACL no longer includes the employee, or the object sits outside licensed systems. Measure cite coverage (share of tags with a living, employee-visible pointer), not tag volume.
Treating the graph as published. Draft views stay in an operator workspace with a watermark. Confirmed skills go to the systems that already hold official profile data. If a leader asks for "the live skills graph," send confirmed tags plus the blank rate. Do not send an embedding heat map.
Inventing a skill from chat tone. Affect is not a work artifact. Even when messaging is in-scope, phrasing alone never makes a tag eligible for confirmation. If that is the only evidence, leave the cell empty.
Two quieter leaks sit beside those. Shared or bot identities that attach someone else's pull request or a wiki page last-edited by an admin. LMS enrollment treated as completion, or a draft wiki page treated as published. Both produce cites that look complete and fail when the employee opens them. The review UI should open the object, not only show its title.
Is this worth automating for you?
Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.
DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.
Measure the baseline first