How the four-view MELMAP skills app (Ministerial / Dean / Lecturer / Student) matches what universities teach to what employers demand, in the language of the UK Standard Skills Classification (UKSSC) and SIC codes. Every number below is a real value produced by the code on 2026-08-10 — nothing is illustrative.

All code lives in melmap-companies-house\skills\. The app is skills\app.py (Flask, http://127.0.0.1:5000); computation is skills\views_data.py; the shared matching engine is skills\ukssc.py.


0. Plain-English guide — how the matching works (no technical background needed)

Read this section first if you don't write code. Everything here is the same logic described technically in §1–§4, with the real numbers the system uses.

The task

The computer holds the government's official dictionary of work skills (the UK Standard Skills Classification — thousands of entries like “Inspect construction materials” or “Design steel beams”). Its job is to read a piece of text from a university website — a module title, a learning-outcome sentence — and decide: which of these official skills is this text talking about?

It judges every candidate skill with two tests, then combines them 50/50 into one score between 0 and 1.

Test 1 — Do they share distinctive words? (50% of the score)

The computer compares words in the text with words in the skill's name — but not all words count equally. A rare, specific word like “hydraulics” is worth a lot: very few skills contain it, so sharing it is strong evidence. A common word like “skills” or “develop” is worth almost nothing: thousands of entries could match it. Think of identifying a person — sharing the surname “Fothergill-Baxter” nearly settles it; sharing the first name “John” tells you nothing. (Technically this weighting is called IDF; word pairs like “sustainable materials” also count as extra-strong evidence.)

Test 2 — Do they mean the same thing? (50% of the score)

Separately, the computer has learned from reading huge amounts of text which words live near each other in meaning — “aircraft” near “aeroplane”, “surveying” near “measurement”. It turns the whole text into an average of the meanings of its words — picture mixing paints: every word adds its colour, the final colour is the blend. It then measures how close the text's blend is to each skill's blend, on a 0-to-1 scale.

The score, and the bars it must clear

final score = 50% × word-overlap test + 50% × meaning test

Real example — module “Construction Materials” vs skill “Inspect construction materials”: word test 0.54, meaning test 0.68 → score 0.61.

The key numbers the system lives by:

Number What it means in plain terms
0.40 The “covered” bar. A demanded skill counts as taught only if some part of the curriculum matches it at 0.40 or better.
0.25 – 0.40 The “nearly” band. Not taught, but close — this feeds the Dean view's “could embed” advice: a small change to that module would close the gap.
0.15 The sanity-check bar: a word-overlap match is thrown out unless the meaning test at least weakly agrees (stops coincidental word matches).
0.52 The bar for matches with no shared words at all — meaning alone can carry a match, but only if it's this strong (0.58 if the skill's name contains a distinctive word the text never mentions).

How “coverage %” is then calculated

Each sector skill comes with an official importance weight (e.g. health & safety in construction = 0.98, near the maximum). Coverage is not “how many skills matched” but “how much importance matched”: missing one 0.98-importance skill costs more than missing three 0.30 ones. That's why Aston Civil BEng's single biggest hole — health & safety, which no module or outcome reaches (best match 0.37, under the 0.40 bar) — drags its coverage down more than any other miss. Its final figure: 61.3% of importance-weighted sector demand covered.

Why short module titles often beat long outcome sentences