Career Role/Competency Frameworks & Job-skill Extraction

The same title can describe a different job

A vacancy titled AI Product Engineer asks for Python, experimentation, stakeholder communication and “agent orchestration.” Python is a must-have, experimentation is preferred, and the employer-specific phrase has no clean taxonomy match. A second employer later uses the same title but makes experimentation optional and adds cloud-cost ownership.

If a system collapses title, vacancy text, taxonomy label and learner evidence into one vocabulary, it can manufacture a competency gap that the source never justified. This lesson builds Career Role-to-Skill Evidence Map v1: it preserves the exact job snapshot and text span, records occupation and skill candidates against a versioned taxonomy, keeps alternatives and unmatched terms, separates required/preferred/unknown, and binds every learner gap to visible source and learner evidence.

Core rule: normalization may organize evidence; it must not erase ambiguity.

For: learning-platform engineers, career/skills product teams, taxonomy integrators, reviewers and evidence-governance owners. Not for: scraping live vacancies, making a live employment decision, declaring learner mastery from taxonomy membership, or forcing every phrase into ESCO/O*NET.

Route orientation and ownership boundary

MKN-018 owns only career-role/competency frameworks and job-skill extraction. MKN-017 is the hard prerequisite; MKN-019 owns matching/fairness/explainability. This lesson may produce bounded role-to-skill evidence for downstream matching, but it does not rank people or decide opportunity eligibility.

Foundation learners follow a field map and one synthetic vacancy. Repair learners isolate the first broken evidence field. Experienced learners must defend versioning, ambiguity, unmatched language and gap provenance under a changed employer.

Checkpoints: F1 identify source/taxonomy/learner evidence as separate layers; F2 reject one forced normalization; F3 recompute the map for the second employer rather than copying the first profile.

Mental model: snapshot → spans → candidates → taxonomy → requirement class → learner evidence → bounded gap

Use this flow:

job source snapshot → raw title/text hash → occupation candidate → skill span extraction → taxonomy lookup + alternatives → required/preferred/unknown → learner evidence comparison → gap/unknown/review → versioned provenance

A title is only a clue. The decisive evidence is the vacancy snapshot and the exact span that supports a skill mention. A taxonomy candidate is a normalization proposal, not proof that the employer meant that concept. An unmatched phrase is legitimate evidence and must remain unmatched when no defensible mapping exists.

Useful states include REVIEW_REQUIRED, HOLD_SOURCE_SNAPSHOT, HOLD_SOURCE_SPAN, HOLD_OCCUPATION_MAPPING, HOLD_LOW_CONFIDENCE_REVIEW, HOLD_FORCED_NORMALIZATION, HOLD_STALE_TAXONOMY_MAPPING, HOLD_LEARNER_EVIDENCE, HOLD_PROVENANCE, and HOLD_BASELINE_ORACLE_REUSE.

Foundation contract: seventeen evidence dimensions before a gap

The frozen critical dimensions are career_case_id, job_source_ref, raw_job_title, raw_job_text_hash, occupation_candidate, occupation_uri_or_code, taxonomy_version, skill_span_ref, skill_candidate, skill_uri_or_code, requirement_class, confidence_label, ambiguity_state, unmatched_term, learner_evidence_ref, gap_state, and provenance.

Minimum invariants:

1. Source snapshot and hash are immutable evidence for the extraction run.
2. Every extracted skill keeps an exact span reference.
3. Occupation and skill mappings name taxonomy and version.
4. Alternative candidates remain visible when meaning is ambiguous.
5. required, preferred, and unknown are not interchangeable.
6. A low-confidence extraction cannot silently create a learner deficiency.
7. Employer-specific language may remain unmatched.
8. A learner gap requires learner evidence as well as job evidence.
9. A taxonomy upgrade invalidates stale mappings until reviewed or migrated.
10. Provenance must reconstruct source, extractor/rule version, taxonomy version and reviewer state.

Deep explanation: external vocabularies help organize evidence, not decide meaning

ESCO — FACT. The European Commission exposes ESCO through APIs and downloadable datasets. Its concepts use identifiers/URIs and the current site reports ESCO v1.2.1, last updated 10 December 2025. ESCO is intended for uses including job matching, skills intelligence and career guidance. That makes it a useful external vocabulary, not an oracle for employer intent.

**O*NET — FACT.** The O*NET Content Model separates worker requirements such as skills/knowledge from job-side occupational requirements such as work activities/context. The current production database is 31.0 (August 2026). It is an occupational information model, not MAKNOW learner mastery evidence and not a universal taxonomy for every jurisdiction.

MAKNOW inference. Preserve raw spans, versioned identifiers, alternatives and unmatched terms because normalization can hide ambiguity or employer-specific semantics.

MAKNOW design. Confidence labels, ambiguity states, review thresholds and gap policy are local authority. No ESCO/O*NET page decides when MAKNOW may call something a learner gap.

Worked examples

Example A — baseline AI Product Engineer

The snapshot contains Python as required, experimentation as preferred, stakeholder communication as required, and “agent orchestration” as employer-specific wording. Python and communication map to defensible concepts; experimentation is mapped but classified preferred; “agent orchestration” remains UNMATCHED_REVIEW with alternatives recorded. Because one important phrase is unresolved, the strongest bounded state is REVIEW_REQUIRED, not a complete competency profile.

Example B — tempting shortcut

A parser sees “agent orchestration,” chooses the nearest taxonomy concept with confidence 0.54, and marks a learner gap. This is invalid. Low confidence plus employer-specific wording requires review; the raw span and alternatives must remain visible.

Example C — same title, different employer

Employer B uses the same title, makes experimentation optional and adds cloud-cost ownership. The first employer’s map is not reusable as an oracle. Re-extract the new text, assign new source hash/span refs, classify requirements again, and map or preserve the new term independently.

Failure modes that must fail closed

• Same title, different source, old map copied → HOLD_BASELINE_ORACLE_REUSE or HOLD_SOURCE_SNAPSHOT.
• Raw span missing → HOLD_SOURCE_SPAN.
• Source hash no longer matches the reviewed vacancy → HOLD_SOURCE_SNAPSHOT.
• Occupation candidate has no traceable identifier/version → HOLD_OCCUPATION_MAPPING.
• Low-confidence skill becomes a gap automatically → HOLD_LOW_CONFIDENCE_REVIEW.
• Employer-specific phrase is forced into a canonical skill → HOLD_FORCED_NORMALIZATION.
• Taxonomy version changes but old URI/meaning is reused silently → HOLD_STALE_TAXONOMY_MAPPING.
• Required becomes preferred but the old gap remains → recomputation required.
• Learner evidence is missing yet gap_state=GAP → HOLD_LEARNER_EVIDENCE.
• Provenance cannot reconstruct source/version/reviewer → HOLD_PROVENANCE.

Alternatives and trade-offs

Exact phrase only. Maximum fidelity, weak interoperability. Best when employer language is novel or disputed.

Taxonomy normalization. Better search, analytics and portability, but can overstate certainty if alternatives and original spans are hidden.

Multiple candidate mappings. Preserves ambiguity and supports reviewer choice, at the cost of larger evidence records.

Unmatched state. Less convenient for dashboards, but safer than inventing a semantic match.

Model-assisted extraction. Useful for candidate generation and span detection, but confidence is not proof. Deterministic evidence gates still decide whether a mapping can support a gap.

Experienced bridge: three separations worth defending

First, separate surface language from normalized concept. Store both. The raw text is evidence; the taxonomy concept is an interpretation.

Second, separate requirement classification from skill existence. A skill may appear in the text but be preferred, optional, contextual or negated.

Third, separate job evidence from learner evidence. A role requirement does not prove the learner lacks the skill; a learner portfolio does not prove the employer requires it.

An experienced design should also distinguish taxonomy migration from ordinary re-extraction. If ESCO/O*NET changes version or meaning, preserve the old mapping as historical evidence and create a reviewed new mapping rather than rewriting the past.

Guided and independent practice

Guided pass. Open lab://MKN-018/MKN-018-LAB1. Inspect the synthetic baseline, identify each exact span, candidate mapping, taxonomy version, requirement class, learner evidence and provenance field. Keep “agent orchestration” unmatched when evidence is insufficient.

Repair pass. Mutate one dimension at a time: remove the source span, change required to preferred, upgrade the taxonomy version, or force the unmatched phrase into a canonical code. Rerun only the affected gate.

Independent pass. Build the transfer fixture for Employer B from its own snapshot. Do not read or reuse Employer A’s final mapping or gap label. The shared title is not evidence that the role profile is shared.

Verification evidence: what a reviewer must reproduce

A reviewer must be able to reconstruct: the exact source snapshot/hash; raw title and skill spans; occupation candidate and identifier; taxonomy/version; skill candidate and identifier or unmatched state; requirement class; confidence and ambiguity; learner evidence; gap state; reviewer state; and provenance.

The reviewer should also be able to prove that a low-confidence/unmatched mention did not create a gap, that required→preferred mutation caused recomputation, and that taxonomy-version change did not silently rewrite historical evidence.

If any decisive field is absent, stale or contradictory, the record remains typed non-success. Verification means reproducible evidence—not agreement with hidden model reasoning.

Assessment and transfer

S1 — retrieval. Explain the MKN-018 boundary and one non-goal. S2 — application. Build Career Role-to-Skill Evidence Map v1 for the baseline vacancy. S3 — diagnosis. Replace the employer while retaining the same title. Identify which evidence becomes invalid and the smallest repair. S4 — transfer. Re-extract Employer B, where experimentation is optional and cloud-cost ownership is added. Recompute from the new source rather than copying Employer A.

Blocking misconception: “If the title and nearest taxonomy label match, the competency checklist is definitive.”

AI may organize synthetic source text, propose candidate concepts and run deterministic checks. It may not invent job requirements, silently normalize unmatched language, fabricate learner evidence, create a career gap from low-confidence extraction, or mutate live employment/learner records.

References, freshness, and authority boundaries

• ESCO API/version pages — FACT. Current official pages report ESCO v1.2.1 (10 December 2025), expose versioned classification services, and identify job matching/skills intelligence/career guidance as use cases. They do not prove unique mapping from arbitrary vacancy text.
• **O*NET Content Model / database — FACT.** Current official pages describe worker requirements and job-side occupational requirements; production database 31.0 is dated August 2026. O*NET does not define MAKNOW learner mastery or universal career-fit policy.
• MAKNOW inference. Raw spans, alternatives, taxonomy versions and unmatched states are retained because normalization can erase material ambiguity.
• MAKNOW design. Confidence labels, review thresholds, gap states and role-fit policy remain local authority.

Freshness checked 2026-09-13. Re-review by 2027-01-15 or earlier if ESCO/O*NET identifiers, versions, taxonomy semantics or extraction practice materially change.