The JobCannon Knowledge Graph
2,521 careers. 1,863 skills. 57,490 career–skill links. This is how it is built, where the numbers come from, and what the graph can and cannot tell you about a person's career.
What the knowledge graph is
A knowledge graph is a structured network in which the nodes are the things you care about and the edges are the recorded relationships between them. Our knowledge graph has two principal node types — careers (2,521 leaf-level occupations like ML engineer, physical therapist, arborist) and skills (1,863 atomic competencies like Python, manual dexterity, active listening). The 57,490 edges counted above each record one statement — "this career's profile names this skill" — and they carry no weight. A second build merges that layer with O*NET's importance ratings to produce the weighted graph behind our skill pages, where every edge additionally says which source admitted it and, if O*NET did, at what score. Both artifacts are described below; the counts on this page are the first one's.
The point of structuring career matching this way — rather than running a black-box similarity model — is auditability. Every result a user sees on a career page can be traced back to a specific edge, and that edge to the thing that produced it: either a public O*NET rating with a score attached, or the sentence in our own published career profile that named the skill. The weighted graph is stamped with a hash of every input file it was built from, so a given edge can be re-derived rather than taken on trust.
Where the data comes from
Three inputs. Two are public datasets; the third is our own published career corpus. All three are committed to the repository, so any build of the graph can be reproduced exactly.
Our own career and skill profiles. The base layer of the graph is not bought data — it is the writing behind every career page and every skill page on this site. A build pass reads those profiles and records which skills a career's profile actually names. Because prose matching is noisy, a hand-maintained alias file sits on top of it: it adds matches the pass missed and drops ones it got wrong, per skill and globally. This layer is unweighted by construction — it establishes that a skill belongs in a career's picture, not how much it matters.
O*NET 29.0 (2024). The U.S. Department of Labor's Occupational Information Network is the canonical occupational database in the English-speaking world. It rates 35 skill elements across 879 occupations on two scales — importance (how essential the skill is) and level (how proficient you need to be) — and separately catalogues Detailed Work Activities per occupation. O*NET supplies every number in the weighted graph. Its occupations are broad SOC parents, so a crosswalk file maps our leaf-level career titles onto them with a confidence score rather than assuming a clean one-to-one match.
Bureau of Labor Statistics OEWS. The BLS Occupational Employment and Wage Statistics survey provides the wage and employment attributes shown on every career page — median salary, percentile bands, growth projections, geographic concentration. OEWS is keyed to SOC, so it bolts cleanly onto the O*NET spine.
What we do not use. No job postings, from any source. No scraped or purchased hiring data, no LinkedIn or Indeed corpus, and no European ESCO import. Until this revision this page described a posting-ingestion pipeline with a 15% co-occurrence threshold and an ESCO node import, and neither existed — the claims are gone rather than softened. The practical consequence is stated plainly in the limitations below: we have nothing that surfaces a brand-new role faster than O*NET codifies it.
How an edge gets admitted
An edge enters the weighted graph by one of two paths, and it is tagged with which one — so a reader can tell a measured claim from a written one instead of seeing them averaged into a single number.
- Corpus mention. The skill is named in that career's published profile, after alias normalization and the manual drop-list. The edge carries no score, because a mention is not a measurement.
- O*NET importance. O*NET rates the skill at 3.0 or higher on its 1–5 importance scale for the matching occupation. The edge enters carrying that score. The same 3.0 floor is applied to edges derived from O*NET Detailed Work Activities, and DWA mappings whose category does not match the target skill's category are dropped rather than forced through.
A commodity-skill filter then runs over the result, and it is worth being precise because the two builds set it differently. In the corpus-mention build behind the counts on this page, a skill that matches more than 300 careers is dropped from the career-facing side of the index; in the weighted build it is more than 2,000. Either way the reasoning is the same — communication being relevant to nearly every job is true and useless, and leaving it in would crowd out the skills that actually separate one career from another.
The filter is one-directional, which explains a number you can find in the data. A skill above the threshold is still listed on its own page with the careers it reaches; it is only removed from the career pages' skill lists. So the raw index legitimately contains skills touching most of the corpus, while no career page shows them.
How the graph is refreshed
The graph is a build artifact, not a live feed. It is regenerated on demand and committed. The corpus-mention build stamps its output with the build date and its totals; the weighted build adds the thresholds it ran with and a hash of each of its seven input files, so that graph can be tied to the exact sources behind it and rebuilt identically — a separate check refuses to pass if any input has changed since. There is no nightly job and no rolling window. What is genuinely periodic is upstream:
- O*NET importance and level scores: a new database release roughly annually. We rebuild after one lands.
- BLS wage and employment attributes: annually, in spring, based on the previous May reference period.
- The career and skill corpus: whenever a profile is written or edited, which is continuous but not scheduled.
How careers connect to assessments
The knowledge graph is the substrate on which our career-matching layer runs. Personality and interest assessments — Big Five, RIASEC, DISC, and the cognitive-reasoning composite — produce trait profiles, which are then matched against career nodes. The match score is a transparent weighted similarity, never a black-box embedding. The inputs that scoring layer uses, and how it weights them, are documented on its own page rather than summarized second-hand here.
The matching logic is detailed on the dedicated Career Fit Score methodology page. The skills sub-graph and how it surfaces course recommendations is on the Skills Graph page.
What the graph cannot do
Honest limitations matter for an evidence-first product. We disclose four.
It does not predict individual outcomes. The graph encodes population-level career–skill fit. Any individual's actual career success depends on motivation, market timing, geographic constraints, network access, and other factors the graph does not see. We treat recommendations as a structured starting point for exploration, not a forecast.
Emerging roles lag, and we have nothing that closes the gap. O*NET takes years to codify a genuinely novel occupation. A page that ingested job postings could partly compensate; we do not, so for a role that is months old the weighted graph has no scores at all and the career rests on whatever its written profile names. That is a real limitation, not a softened one.
It reflects U.S. labor structure, and only that. O*NET and BLS are U.S. agencies, and they are the only occupational authorities in the graph. There is no European crosswalk — no ESCO mapping, despite an earlier version of this page claiming one. A user outside the United States is reading a U.S. occupational structure, and where no federal figure exists for a role we show no pay figure rather than an estimate.
The layer counted on this page is all mentions, and prose matching is noisy. Every edge behind the totals above was produced by reading our own profiles, so it inherits both our editorial coverage and the failure modes of text matching: a broadly-worded skill can end up attached to thousands of careers before the filters run, and a skill nobody happened to name in a profile is simply absent. The alias file and the commodity-skill thresholds exist because of this, and they reduce the problem rather than solve it. In the weighted build the mention layer is joined by O*NET-derived edges, and where O*NET rates the occupation the score on the edge is the trustworthy part.
Citations
- U.S. Department of Labor / Employment and Training Administration (2024). O*NET OnLine — Occupational Information Network. https://www.onetonline.org · Database release O*NET 29.0 (2024). link
- U.S. Bureau of Labor Statistics (2024). Standard Occupational Classification System (SOC 2018). https://www.bls.gov/soc/ link
- Holland, J. L. (1997). Making vocational choices: A theory of vocational personalities and work environments (3rd ed.). Psychological Assessment Resources. link
Three inputs, all committed to the repository so any build of the graph can be reproduced exactly. (1) Our own career and skill corpus — the written profiles behind every career and skill page. A build pass reads that prose and records which skills a career profile actually names, corrected by a hand-maintained alias file that adds missed matches and drops false ones. (2) O*NET 29.0 (2024) from the U.S. Department of Labor, which rates 35 skill elements across 879 occupations on importance (1–5) and level (0–7), plus its Detailed Work Activities. (3) The Bureau of Labor Statistics SOC 2018 taxonomy and BLS Occupational Employment and Wage Statistics for the wage and employment attributes shown on career pages. We do not buy, scrape or ingest job postings, and no link in the graph comes from one.
O*NET's canonical occupations are SOC categories — broad parents like "Software Developers" (15-1252.00). Our catalogue is written at the level people actually search ("backend engineer", "ML engineer", "DevOps engineer"), so it is finer-grained than O*NET by design. A crosswalk file maps our titles onto O*NET occupations and records a confidence score for each mapping, because the match is often approximate rather than exact. That confidence is what decides whether a career inherits O*NET scores. Titles that map to no occupation carry no O*NET-derived numbers at all — not an estimated stand-in.
Two independent paths, and the merged graph tags every edge with which one produced it. (1) Corpus mention — the skill is named in that career's written profile, after alias normalization and a manual drop-list for false matches. This path is unweighted: it records that the skill was named, not how important it is. (2) O*NET importance — O*NET rates the matching occupation's skill elements, and we admit the edge when importance reaches 3.0 ("important") on the 1–5 scale, carrying that score as the edge weight; the same 3.0 floor applies to edges derived from O*NET Detailed Work Activities. A commodity-skill filter then strips any skill that reaches too many careers from the career-facing side of the index — more than 300 careers in the corpus-mention build, more than 2,000 in the weighted one — because a skill that fits everything distinguishes nothing. There is no expert-review path and no posting-frequency path — earlier versions of this page described both, and neither was ever built.
On demand, not on a timer. The graph is a build artifact, regenerated from the committed inputs and committed alongside a stamp of its own build: the corpus-mention build records its date and totals, and the weighted build additionally records the thresholds it ran with and a hash of each of its seven input files, so that graph can be tied back to the exact sources that produced it and rebuilt identically — a separate freshness check fails if any input has moved since. What is genuinely periodic is upstream: O*NET publishes a new database release roughly annually, and BLS OEWS follows a May reference month published the following spring. We regenerate after those releases rather than claiming a monthly cadence we do not run.
Yes, in three ways we openly disclose. First, the graph maps interests and traits to occupational fit at a population level — it does not predict individual outcomes (motivation, market timing, geographic constraints, and luck matter more for any single person). Second, a large share of links record only that a skill was named in a career profile, not that it was measured as important there — the counts printed on this page are that layer in full, and none of those edges carry a score. A link of that kind is evidence of relevance, not a ranking. Third, novel occupations are under-resolved: O*NET takes years to codify a genuinely new role, and because we do not ingest postings we have nothing that fills that gap faster. We treat career recommendations as a structured starting point for exploration, not a deterministic forecast.
A research subset is published at /research/dataset under a permissive license, intended for academic and journalistic use. The full edge-weighted graph is part of the JobCannon product and is not redistributed wholesale. Enterprise and white-label partners can access targeted slices under a data-processing agreement.