Skip to main content
DoneThat

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.

Use confirmed tags in gap, learning, and mobility work

A confirmed, cited tag is reusable. Unconfirmed embeddings are not. Send quality objects into processes that can tolerate blanks and still expect human judgment.

strategic skills-gap analysis should read confirmed skills and explicit empties. A gap that is "no licensed evidence yet" is a data-quality finding, not a training mandate. Raw embeddings in a gap model create learning demand for skills the work never required.

role-based learning auto-assignment can use a confirmed miss (the role requires the skill, the employee confirmed they do not have it, or the cell is empty and the role profile demands evidence) as a candidate LMS assignment. Do not assign courses because a model was unsure. Uncertainty is a blank, not a learning need.

internal opportunity matcher and internal mobility supply forecaster need supply hiring managers can defend. A match that points at a pull request the employee accepted as evidence is a conversation you can have. A match that points at a confidence score is not. Keep unconfirmed graphs out of marketplace ranking and out of headcount forecasts. Treat blanks as unevidenced, not as zeros and not as skills. Report confirmed supply separately from demand that still has no artifact.

Refresh licensed artifacts on the cadence counsel accepts. Re-infer against new or changed objects only. Present deltas to the employee. Publish only what they confirm. The live part of the graph is the artifact stream, not an unsupervised write to the profile.

If the employee can open the cite, the cell is empty when evidence is missing or out of policy, and nothing is published until they confirm, you are running inference as a quality process.

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