A skills taxonomy is a photo. A context graph is a film.
Why the wrong data structure keeps your workforce invisible, and what the right one computes instead
The reason most enterprise skills taxonomies fail is not that they go stale. The answer that usually follows, refresh it more often, buy a better ontology, hire a vendor with a deeper competency library, is not wrong. But it treats a rounding error as the root cause. Taxonomies go stale because they were already the wrong data structure. The thing that got built was a photo. A photo cannot answer a question about movement.
A photo of a person tells you where they were standing at the moment the shutter clicked. It tells you nothing about the trajectory that brought them there, the sequence of moves that built their capability, or the distance between where they are now and where they could go next. A skills taxonomy is a photo. A context graph is a film. The difference is not resolution or refresh rate. The difference is whether time runs through the structure at all.
What a taxonomy stores
The data structure underneath every skills taxonomy is a set of label assignments. Someone, the employee, a manager, an HR system, a vendor model, attaches strings to a person node. The strings are labels: commercial underwriting, portfolio pricing, claims management, bilingual Spanish. The taxonomy's job is to make those strings consistent across the organization so the same label means the same thing in every department.
The structure: person node with a list of attached labels.
No time axis. No relationship between any label and demonstrated behavior. No sequence connecting what a person did to what the label claims about them. No provenance on which system recorded what and when. A label arrives and sits there, inert, until someone updates it at the next review cycle, which in most enterprises means annually.
Query the taxonomy and the only question it can answer is: who currently has this string attached to their node? The answer includes everyone with the string, regardless of how recently they demonstrated the capability, regardless of whether they ever demonstrated it at all beyond a self-report or a manager's checkbox. Observed capability and claimed capability live in the same structure because the taxonomy has no time-stamped edges connecting a label to any underlying work event.
This is not a maintenance problem. A more frequently refreshed taxonomy, updated quarterly rather than annually, still cannot answer a question about trajectory. Refresh cycles do not add a time axis to a data structure that has none. The gap is the absence of events, and no ontology upgrade closes it.
What a film knows
A context graph stores events. An edge says: this person made this coverage determination, on this date, citing these policies, with this settlement outcome. Another edge: this renewal call was conducted, this duration, this client behavior in the subsequent quarter. Edges are typed, time-stamped, and carry a source: which system, which record, what confidence on the match. The structure is not a node with a label list. It is a node embedded in a web of dated, sourced, typed relationships.
Time runs through all of it. Because every edge is stamped, the graph can be queried as of a date. What was true about this person when a hiring decision was made, not what is true now. A system that can only answer from the present tense cannot explain a decision from last spring. Regulators ask about decisions from last spring, and they notice when the answer changes with the season.
The difference between a label and an event is the difference between "negotiation skills" and a record of settlements negotiated over two quarters, resolution rates that trended upward through the period, and the pattern of issues that generated escalations. The label collapses the trajectory into a string. The event preserves it. A label says a person was standing somewhere. An event says how they got there, what they did when they arrived, and what the outcome was.
From four years of data at a Fortune 500 insurance carrier, we parsed 8,181 unique skills from applicant records and measured 3,597 testable keywords against post-hire production outcomes. After Bonferroni correction, zero keywords predicted sustained performance. The keyword, the label, is the weakest unit of measure for what a person can do in a role. What a person demonstrably did, in what sequence, with what outcomes, is the strong material. A taxonomy assembles the weak material on the slowest possible cycle.
The cost shows in what label-based screening logic produces. The industry-experience filter at that carrier eliminated 80% of eventual top performers from the candidate pipeline. The cumulative screening funnel eliminated 98%. A label-to-label matching system running on one of the weakest predictive signals in the dataset was removing most of the company's top-performer supply before any human reviewed a name. The photo said these people did not belong. The film would have said otherwise, because the work events already in the company's systems recorded what the label list missed.
The questions only a film can answer
None of this means the taxonomy is useless. The taxonomy as a controlled vocabulary serves a real function. Organizations need agreed terms for roles, capabilities, and structure. Planning, auditing, and development conversations all require shared language. The problem is assigning the taxonomy jobs that require a film.
Four questions a graph answers that a taxonomy cannot:
Who has demonstrated the prerequisite behaviors for this role, in the sequence role incumbents acquired them? A graph walks the careers of everyone who has held a seat and extracts what they carried on day one against what they built in the first quarter. This is computable adjacency, with derivation attached. The mechanics are in the internal mobility piece, which works through a specific role-pair. The taxonomy asks who has the label. The graph asks who has the trajectory.
Which capabilities in the taxonomy are load-bearing on day one, and which are learned in the seat? A required-skills checklist cannot distinguish these; a two-state list has two states. The incumbents-trajectory view on the graph can, because it observes when in a career each capability appeared in people who succeeded, and whether it showed up before the hire or built up in the first two quarters.
What changed in this person's profile in the last quarter that makes them worth recommending for a role now? A photo from last year can only answer "who had the label last year." A graph updated as each work event posts to the source system answers "who has become capable recently, and the evidence is here."
Which labels in the taxonomy correspond to early departure, which to sustained performance, and which to nothing at all? The taxonomy can tell you who has each label. Only the graph closes the loop on what followed the label and whether it earned its place in the screening model.
Why the HRIS will not close this gap
Most enterprise HRIS platforms now ship a skills module. Workday Skills Cloud and similar offerings carry a genuine pitch: the taxonomy becomes richer, updated more frequently, better aligned across the organization. These are real improvements to the controlled vocabulary. They do not change the data structure.
A dynamic skills cloud still produces a person node with a list of labels. The labels are of higher quality and on a shorter refresh cycle. The structure has no time axis, no event edges, and no provenance on how any label was assigned or what observed work it represents. A more current photo is still a photo.
The HRIS does hold events. Performance reviews sit in it. So do job changes, department transfers, and manager assignments. The gap is that these events are not connected into a traversable structure with typed, time-stamped edges and source provenance on every hop. They live in separate tables, not in a graph that an agent can walk from a question about trajectory to an answer it can show its work for.
Connecting those events into a graph means resolving identities across systems that have never shared a schema: the ATS record for a candidate, the HRIS record for the same person as an employee, the CRM record for the same person as a producer in the field. One person, three records, no system knows they are the same individual. The matching requires confidence bands on every resolved entity, human verification of uncertain joins, and a log of every inference made during construction. What a context graph is, structurally, including how the edges carry provenance and why that matters to audits, is in the definition piece.
The skills module and the graph solve different problems and the distinction is worth naming in procurement conversations. A skills module improves the vocabulary. A graph connects the events. Treating them as substitutes is how organizations end up with a more current photo and the same blind spots.
Production evidence
At a Fortune 500 insurance carrier, four years of production data across 10,765 agents, with 850,000+ applicants scored over the same period. The label-based screening systems eliminated 80% of eventual top performers with a single filter and 98% through the cumulative funnel. The methodology behind those numbers is published on arXiv: Decision Traces.
The graph-based view moved outcomes. Hire rate rose from 14.0% to 27.7% across 6,053 hires. First-year retention in the producer cohort moved from 64% to 91%. The argument here is narrower than the full methodology: what drove the gap was not a better algorithm or a more capable model. The model was fine from the start. What changed was the data structure doing the reasoning.
A workforce is not a list of labels
Build the taxonomy. A workforce needs shared vocabulary, and a taxonomy is the right tool for exactly what a photo is the right tool for: confirming an attribute, locating someone in a reference system at a moment in time, establishing consistent language.
For questions about trajectory, adjacency, capability development, and prediction, the taxonomy is the wrong instrument, and no refresh cycle or ontology upgrade makes it the right one. The events are already in the systems. The film exists in fragments across the HRIS, the ATS, and the CRM. Whether you connect those fragments into something an agent can traverse, with a receipt on every step, is an architecture decision.
No controlled vocabulary makes that decision for you.
Saad Bin Shafiq is the founder of Nodes. Anchor pilot: Fortune 500 insurance carrier, four years of production data, 10,765 agents. Methodology: Decision Traces.