Framework Crosswalks and Levelling

Where corporate and education alignment meet.

Course ID: ICB-A04. Framework alignment: ICoBC Credentialing Skills Framework (ICSF), skill SKTX "Skills taxonomies and alignment", VRITE pillar Rigor, level L4 "Assure", stage A "Ability".

At this level you create crosswalks between frameworks and you govern an organisational skills taxonomy and its versioning. This is an Ability course: you practise on realistic tasks in a controlled setting, using the knowledge you already have from the prerequisite course ICB-P05 Aligning Credentials to Skills Frameworks.

Who this course is for

• L&D and corporate academy leads
• HR, talent acquisition and mobility teams
• Programme and micro-credential leads
• Professional bodies and sector associations
• Policy makers and public agencies

Learning outcomes

1. Build a crosswalk between two frameworks with documented decisions.
2. Level credentials against responsibility-based and learning-based scales.
3. Govern an organisational taxonomy: ownership, versioning and change requests.
4. Validate a crosswalk with subject experts.

Workload. 10 hours notional learning in a blended cohort. This file covers the self-paced part. Live or workshop elements are described in facilitator notes.

Assessment. You submit a crosswalk for one domain with validation notes. A person assesses it with the rubric in the section "Assessment and badge". The final knowledge check in the same section is a separate quiz that supports the task.

Badge. "Framework Crosswalks and Levelling (Ability, L4)", alignment code ICSF-SKTX-L4-A. Evidence: the crosswalk and the validation notes. The badge records that you completed the assessed task to the stated standard. It does not prove competency in any job.

How the examples work. Worked examples run in two contexts. The first is a corporate academy and HR department (called "Northgate Group" here, a fictional organisation). The second is a professional body, sector association or public agency (called "the Regional Skills Agency", also fictional). All numbers are illustrative.

How AI is used in this course. AI similarity matching can suggest candidate links between two frameworks quickly. A subject expert decides whether each link is accepted. You will practise using suggestions as a starting point and recording the human decision.

Crosswalk methods

A crosswalk is a documented mapping between the elements of two frameworks. It states which element in framework A relates to which element in framework B, how strong the relation is, and who decided it. This module teaches you to build one with decisions on record.

Scope, purpose and framework versions

Start with the purpose. A crosswalk built to help employees find learning is different from one built to recognise a qualification for a regulatory purpose. The purpose sets how strict you must be.

Before you map anything, write a scope note with these items:

• The source framework and the target framework, each with its owner and exact version.
• The domain you will map, for example data analysis or customer service.
• The direction of the mapping: from source to target, or both ways.
• The purpose and the people who will use the result.
• The licence terms of both frameworks.

Version details matter. ESCO is a public framework, and you should use the current ESCO version and record its version identifiers in every alignment. SFIA 9 is the current version at the time of writing, and SFIA 10 is in consultation. The SFIA Foundation targets release around Q4 2027. Check SFIA licence terms before reproducing descriptors in course material, and apply the same caution to any framework that has a licence. DigComp 3.0 is current and is relevant for earner-facing courses and citizen digital competence alignment.

Status as of November 2026; check before publishing.

A crosswalk that does not name its framework versions cannot be checked later. Treat the version as part of the data, not as a footnote.

Relation types and match strength

Not every link is an exact match. Use a small, fixed set of relation types so that every mapper uses them the same way. A common set is:

Add a confidence field (for example high, medium, low) and a rationale field with one or two sentences. Keep the rationale short and factual. "Both describe querying relational data; the target adds data modelling" is a good rationale. "Looks similar" is not.

Allow "No match". Forcing every element to match produces false links and damages trust in the crosswalk. Gaps are findings, and they tell the framework owners something useful.

Decision log and AI similarity matching

A decision log turns a mapping into evidence. Each row records the source element, the target element, the relation, the confidence, the rationale, the decider and the date. When a decision is disputed, you can trace it.

AI similarity matching compares the text of framework elements and proposes likely links. It is fast and it surfaces candidates you might miss. It also makes errors: it can link elements that share vocabulary but differ in meaning, and it can miss links where the wording differs. Treat each suggestion as a candidate. A subject expert accepts, changes or rejects it, and the log records the human decision and the fact that the candidate came from a tool.

A practical routine:

1. Run the similarity matching on the scoped domain only.
2. Sort candidates by score, but review all of them, not only the high ones.
3. For each candidate, choose a relation type and write the rationale.
4. Record rejected candidates too, with the reason.
5. Flag every row where the expert and the tool disagree.

Check that you have the right to process framework text with a tool, because licence terms may limit it.

Worked example: Northgate Group maps a data skills taxonomy to ESCO

Northgate Group is a fictional manufacturing company. Its academy lead, Amara, owns an internal taxonomy of 40 data skills (illustrative number). HR wants to link the taxonomy to ESCO so that internal mobility searches can use a shared vocabulary.

Amara writes the scope note: source is the Northgate Data Skills Taxonomy v2.1, target is ESCO (version identifier recorded from the current release), domain is data analysis, purpose is internal mobility search, direction is source to target.

A similarity tool proposes 40 candidate links. A senior analyst, Jonas, reviews all of them. He records these decisions:

Jonas rejects one high-scoring suggestion because the shared word "model" refers to statistical models in one framework and data models in the other. He records the rejection and the reason. Amara publishes the crosswalk as v1.0 and notes the ESCO version used.

Practice activity: Map five elements and log your decisions

Choose a domain you know well, for example project coordination or customer service. Choose two frameworks, one of which may be an internal list of skills.

1. Write a scope note with the five items listed above.
2. Pick five elements from the source framework.
3. Find the best target element for each, or decide there is no match.
4. Record the relation type, confidence and a one or two sentence rationale for each.
5. If you use an AI tool, add a column "Suggested by tool (yes/no)" and a column "Expert decision".
6. Check one row where you are least sure and write down what evidence would settle it.

Keep this table. You will extend it in the later modules and in the assessed task.

Levelling

Levelling places a credential or a skill on a scale of levels. Two kinds of scale are common. A responsibility-based scale describes what a person does and how much autonomy and impact they have. A learning-based scale describes what a learner knows and can do as a result of learning. A crosswalk often needs both, because employers speak about responsibility and education providers speak about learning.

Two kinds of scale

A responsibility-based scale describes levels of work. It uses attributes such as autonomy, influence, complexity and business skills. SFIA is an example of a responsibility-based approach. A level on such a scale says something about the work performed in a role.

A learning-based scale describes levels of learning outcome. National and regional qualifications frameworks are typical examples. A level on such a scale says something about the knowledge, skills and responsibility a learner can show after completing a qualification.

These scales are built for different purposes. A level 4 on one scale is not automatically equal to a level 4 on another, even when the numbers are the same. Matching numbers is a trap. You compare level descriptors, not level numbers.

For each scale, collect the level descriptors and read them as a whole. Note the descriptor attributes: for example, autonomy, complexity, knowledge depth, or accountability. Mark which attributes appear in both scales. Where an attribute appears in only one scale, that is a limit on how far the levels can be aligned.

Levelling a credential: evidence and method

To level a credential, work from evidence. Gather the credential's learning outcomes, its assessment method, its workload and, where relevant, the context in which it is used. Then compare these with the level descriptors.

A reliable method has four steps:

1. List the evidence. Learning outcomes, assessment type (for example a project or a knowledge test), supervision during assessment, and notional hours.
2. Pick the descriptor attributes that matter most for the scale.
3. Judge each attribute against the level descriptors and write one sentence per attribute.
4. Decide the level and record the confidence and the alternative level you considered.

Write down the alternative level. "Level 4, considered level 3 because the assessment was supervised throughout" shows that you weighed the evidence. This note is valuable when someone challenges your decision.

Levelling should reflect the credential, not the provider's wish. A credential with knowledge-only assessment is hard to place at a level whose descriptors require applied performance. Be ready to say so. If you cannot find evidence for an attribute, state that the evidence is missing instead of guessing.

Bridging responsibility and learning scales

A crosswalk between a responsibility scale and a learning scale cannot be a simple table of equal levels. A better approach is a band mapping with a rationale. For example, a credential may be placed at a level on the learning scale, and a role that typically requires that capability may sit in a band on the responsibility scale. State clearly that the link is indicative.

Use wording that protects the reader. "This credential supports capability described at level 3 to 4 of the responsibility scale" is better than "This credential equals level 4." The first statement is honest about the difference in what the scales measure. Never claim that completing a credential proves a person can do a job at a given level.

Keep the following in your levelling note: the scale and version used, the evidence reviewed, the attribute judgements, the level or band, the confidence, the alternative considered, the person who decided and the date.

Worked example: A professional body levels a certification

The Regional Skills Agency (fictional) and a professional body for facilities managers want to place a "Facilities Operations Certificate" on a national learning-based scale and show how it relates to a responsibility-based scale used by employers.

The credential reviewer, Ines, collects the evidence: eight learning outcomes, a workplace project assessed by an external assessor, a short knowledge test, and 120 notional hours (illustrative).

She judges three attributes on the learning scale:

Ines decides on level 3, confidence medium, and records that level 4 was considered because of the project but rejected because of mentor supervision. For the responsibility scale she writes: "The certificate supports capability described at levels 2 to 3. This is an indicative link and does not describe any person's job performance." The note names the scale versions, her name and the date.

Practice activity: Level one credential on two scales

Choose one credential you know. It can be a course badge, a certificate or a micro-credential from your organisation.

1. Collect the evidence: learning outcomes, assessment method, supervision, notional hours.
2. Choose one learning-based scale and one responsibility-based scale. Record their versions.
3. Pick three descriptor attributes for each scale.
4. Write one sentence of judgement for each attribute.
5. State the level on the learning scale and a band on the responsibility scale. Add the alternative you considered for each.
6. Write one sentence that tells a reader what the link does not claim.

Governance

A crosswalk and a taxonomy are living assets. Without clear ownership, they drift: elements are added without checks, versions multiply, and users stop trusting the result. Governance gives the asset an owner, a version policy and a way to change.

Ownership and roles

Good governance names people, not only committees. Define these roles in writing:

• Taxonomy owner. Accountable for the content and its quality. Approves releases.
• Steward or editor. Maintains the data, prepares releases and keeps the change log.
• Subject experts. Advise on content in their domain and take part in validation.
• Users and consumers. Teams or systems that use the taxonomy, for example the learning platform, the HR system or the credential catalogue. They are consulted on changes that affect them.
• Approval body. A small group that decides on significant changes. Name its members and its decision rule.

Write down who can propose a change, who reviews it, who approves it and how quickly each step happens. A clear decision rule, for example "the owner decides after consulting the experts, and the owner records the reasons", is better than an unclear consensus rule.

In a corporate setting the owner is often a head of learning or a talent function. In a professional body the owner is often a standards committee. In a public agency the owner may be a unit with a statutory remit. The structure differs, but the principle is the same: one named accountable owner.

Versioning policy

A version number tells users what to expect. A common approach is semantic versioning adapted for taxonomies:

Define each category in your policy and give examples from your own taxonomy. Add status labels such as draft, approved, deprecated and retired. A deprecated element stays visible with a pointer to its replacement, so that existing credentials and records do not break.

Every release needs a release note: version, date, summary of changes, list of added, changed and deprecated elements, and impact on crosswalks. Keep identifiers stable. If an element's meaning changes, create a new identifier instead of reusing the old one.

Change requests

A change request process keeps change orderly. Use a short form with these fields: requester, date, element affected, proposed change, reason, evidence, impact on crosswalks and credentials, and urgency.

A simple workflow:

1. Submit. Anyone in the agreed group submits a request.
2. Triage. The steward checks completeness and classifies it as major, minor or patch.
3. Review. Subject experts and affected users comment.
4. Decide. The owner or approval body accepts, defers or rejects, and records the reason.
5. Release. Accepted changes go into the next release with a release note.
6. Inform. Users and crosswalk holders receive the release note.

Set a regular release cycle, for example twice a year, with a fast track for urgent patches. Keep rejected requests on record with reasons, because the same request will come back.

Worked example: Northgate Group sets up governance for its taxonomy

Northgate Group's academy lead, Amara, finds that three teams edit the data skills taxonomy in different spreadsheets. A learning platform and an HR mobility tool both read from it.

She writes a one-page governance note:

• Owner: Head of Learning (Amara).
• Steward: a learning operations analyst, who holds the master file.
• Experts: one senior analyst per skill family.
• Approval: the owner decides twice a year, after expert review; urgent patches are approved by the owner within five working days.
• Versioning: major, minor and patch as in the table above, with statuses draft, approved, deprecated and retired.

A change request arrives: split "Data visualisation" into "Data visualisation" and "Dashboard design". The steward classifies it as minor because the old element stays and a new one is added. Experts agree. The owner approves, and release 2.2.0 lists the new element and its impact on the ESCO crosswalk: one new row to map. The release note goes to the learning platform and HR tool teams.

Practice activity: Draft a governance note and classify three changes

Take the taxonomy or crosswalk from Module 1, or any list of skills you maintain.

1. Write a one-page governance note with owner, steward, experts, users, approval rule and version policy.
2. Add a change request form with the eight fields listed above.
3. Classify the following changes as major, minor or patch, and write one sentence of reasoning for each:
4. Fix a spelling error in an element label.
5. Merge two elements into one and remove both old elements.
6. Add a new element for a new technology.
7. Write a release note for one of them, including the impact on crosswalks.

Validation

A crosswalk made by one person or one tool is a draft. Validation checks it with subject experts who know the domain in both frameworks. Validation is the main Rigor activity of this course: it separates a plausible mapping from a dependable one.

Plan the validation

Plan before you invite anyone. A validation plan has these parts:

• Purpose. What decision will the validated crosswalk support?
• Sample or full review. For a small crosswalk, review all rows. For a large one, review a sample and all rows that are risky.
• Risk rows. Rows with low confidence, rows where tool and mapper disagree, partial overlaps, and rows that affect high-stakes uses.
• Experts. Who they are, what domain they know, and how independent they are of the mapper.
• Method. Individual review, group review, or both.
• Criteria. What the experts must check for each row.
• Records. What is documented, where and who keeps it.

Choose experts for the right reasons. You need domain knowledge in the source and the target frameworks. In a corporate academy, that may be practitioners and team leads. In a professional body, that may be senior members and assessors. In a public agency, that may be sector representatives and standards specialists. Avoid relying only on the people who built the crosswalk.

Run the review

Give experts a simple review sheet. For each row they see the source element, the target element, the proposed relation and the rationale. They respond with one of four options: agree, agree with change, disagree or cannot judge. They add a comment when they do not agree.

Brief the experts before the review. Explain the relation types, the meaning of the confidence field and the purpose of the crosswalk. Show one example row with a good comment. Tell them that disagreement is useful.

Use a structured session for disputed rows. The facilitator asks each expert to state the evidence for their view, then looks for the wording in the framework text that settles the question. If no settlement is possible, record the disagreement and choose a safe relation type, usually "Partial overlap" with a low confidence, or "No match".

Handle AI suggestions carefully. Tell experts which rows came from a tool, but ask them to judge the content first. Record when experts reject tool suggestions, because the pattern helps you improve the matching setup later. Checking only high-scoring tool suggestions leaves missed links undiscovered, so ask experts to look for links the tool did not suggest as well.

Record decisions and measure agreement

Validation notes are the evidence that the crosswalk is dependable. They include:

• The plan: scope, experts, method and criteria.
• The date of each review and the framework versions used.
• The result for each reviewed row and any change made.
• Disagreements and how they were resolved.
• Open issues and who will follow them up.
• A short summary with simple counts, for example the number of rows agreed, changed and disputed.

A simple agreement figure is useful. Count how many rows experts accepted without change, how many were changed and how many remain open. Report counts, not impressive percentages from very small samples. Be honest about limits: a small number of experts and a sample review give limited assurance.

Update the crosswalk and its version after validation. A validated version is a new version, for example v1.0 draft becomes v1.0 validated, and the validation notes are linked from the release note.

Worked example: A public agency validates a crosswalk with sector experts

The Regional Skills Agency (fictional) has mapped a competency framework for early years educators to a national qualifications framework. The mapper, Tomasz, has 30 rows (illustrative).

He writes a validation plan: review all rows with low confidence (6 rows) and all partial overlaps (9 rows), and a random sample of 5 further rows. Experts are two experienced educators, one assessor and one representative of the sector association.

He sends the review sheet with the framework versions and the relation definitions. He tells the experts which 12 rows came from similarity matching. Results (illustrative):

In the group session, the experts resolve the two disagreements by reading the descriptor text together. One link is changed from "Equivalent" to "Partial overlap". The other is changed to "No match" because the target framework does not cover safeguarding practice. Tomasz records both decisions, publishes crosswalk v1.1 and links the validation notes to the release note. He also records the limit: only four experts took part and only 20 rows were reviewed.

Practice activity: Plan and run a validation round on your Module 1 crosswalk

Use the five-row table from Module 1, or extend it to about ten rows.

1. Write a validation plan with purpose, rows to review, experts, method, criteria and records.
2. Create a review sheet with the columns: source element, target element, relation, rationale, expert response (agree, agree with change, disagree, cannot judge), comment.
3. Ask one or two colleagues or peers to review it. If you cannot, simulate: review your own rows after a break and mark where an outsider might disagree.
4. Resolve every disagreement and record the evidence you used.
5. Write a short summary with counts and one honest limit.

Maintenance when frameworks change

Frameworks change. Skills are added and retired, descriptors are reworded, and whole new versions appear. A crosswalk that is not maintained becomes wrong without anyone noticing. This module teaches you how to watch for change, assess its impact and update the crosswalk in a controlled way.

Watch for changes and keep a register

Keep a framework register: a simple list of every framework you depend on, with owner, current version, release date, licence notes, the person who watches it and the date of the last check. The register is short and valuable.

Examples of what to track from the topics in this course:

• SFIA. SFIA 9 is current. SFIA 10 is in consultation, and the SFIA Foundation targets release around Q4 2027. Check licence terms before reproducing descriptors in course material.
• ESCO. Use the current ESCO version and record version identifiers in alignments.
• DigComp 3.0. Current. Relevant for earner-facing courses and citizen digital competence alignment.

Status as of November 2026; check before publishing.

Do not treat a draft or consultation version as released. A consultation text may change before release. You can prepare by reading it and noting likely impacts, but you should not map to it as if it were final, and you should not claim alignment to a version that does not yet exist.

Set a check rhythm. For stable frameworks, a check every six months may be enough. Increase the frequency when a consultation is open or a release is announced.

Assess the impact of a change

When a framework changes, compare the old and new versions. Use any change log the owner provides, and add your own comparison of the elements you mapped. Classify the impact on each crosswalk row:

Count the rows in each class. This gives you the size of the update and helps you plan the effort and the validation.

Think about the effect downstream. Credentials, learning paths, job profiles and learner records may point to the crosswalk. List who uses it and who must be told. A release note that states the framework version change, the number of rows affected and the actions taken makes the update transparent.

Update, re-validate and version

Make the update in a controlled sequence:

1. Create a working copy and label it draft.
2. Apply the changes row by row, with new decisions logged.
3. Re-validate all rows classified as meaning, removed or new. Wording changes can be reviewed lightly by the steward.
4. Decide the crosswalk version change: usually minor if mappings are added or adjusted, and major if the structure changes or many rows break.
5. Publish with a release note linked to the validation notes.
6. Keep the old version available and labelled, so that credentials issued under it remain interpretable.

A version timeline helps users see what applies when. Show each framework version with its release date, and each crosswalk version with the framework versions it was built on. Where a framework is still in consultation, mark it clearly as not yet released.

Worked example: Northgate Group updates after a framework release

Northgate Group's taxonomy crosswalk (v1.1) was built on one ESCO version. A new ESCO release appears. The steward, Lena, records it in the framework register and compares the mapped elements.

Of 40 mapped rows (illustrative), she classifies them:

She re-validates the four rows in "Meaning" and "Removed" with two senior analysts. For the removed element she finds a replacement in the new release and records the decision. The new element is handled as a change request: the owner decides to map it. Lena publishes crosswalk v1.2 with the new ESCO version identifier, a release note stating the row counts and a link to the validation notes. The HR mobility team receives the release note. The old crosswalk version stays available for records created under it.

Worked example: A professional body prepares for a framework in consultation

A professional body (fictional) uses a responsibility-based framework for its member competence profiles. The framework owner announces a consultation on a new version with a release target some time ahead. The body's steward records the consultation in the register, reads the draft and lists elements that look likely to change. She does not update the published crosswalk and does not claim alignment to the new version. She schedules a check when the owner publishes the final text, and she warns the standards committee that a re-validation round will be needed after release.

Practice activity: Build a maintenance plan for your crosswalk

Use your crosswalk from the earlier modules.

1. Create a framework register entry for each framework you used: owner, version, release date, licence notes, watcher, last check.
2. Choose a check rhythm and say why.
3. Simulate a change: pick three rows and invent a plausible change (one wording change, one meaning change, one removed element). Mark these as simulated and illustrative.
4. Classify the impact, state the action and say whether re-validation is needed.
5. Decide the new crosswalk version number and write a three-line release note.
6. Draw or sketch a version timeline for your crosswalk with at least two framework versions.

Assessment and badge

The assessed task

Task: Crosswalk for one domain with validation notes.

Build a crosswalk between two frameworks for one domain of your choice. Your submission must include the crosswalk and the validation notes. Complete it after Module 5.

What to submit (badge evidence)

1. Crosswalk with at least 15 mapped elements (or all elements if the domain is smaller), containing:
2. A scope note: frameworks, owners, exact versions, domain, purpose, direction, licence notes.
3. For each row: source element, target element or "No match", relation type, confidence, rationale, decider, date, and whether a tool suggested it.
4. A levelling note for at least one credential or skill, against one responsibility-based scale and one learning-based scale, with evidence, attribute judgements and the alternative level considered.
5. A short governance note: owner, steward, version policy, change request path.
6. A short maintenance plan: framework register entry, check rhythm and one simulated change with its impact classification.
7. Validation notes, containing: plan, experts and their domains, review sheet results, disagreements and how they were resolved, summary counts, limits and open issues.

Rules. Use real frameworks that you may legitimately use. Check licence terms before copying descriptor text; paraphrase or use identifiers where licences are restrictive. Numbers in any example must be labelled as illustrative. Do not name individuals as experts without their consent. The task shows that you completed the work to the stated standard; it does not prove competency in any job.

Assessment. A person assesses your submission with the rubric below. The assessor provides written feedback. You may resubmit once after feedback.

Rubric

Pass rule. To earn the badge you must reach "Meets standard" or higher on all seven criteria, and you must complete the final knowledge check below with at least 8 of 10 questions correct. If you do not pass, you receive feedback and may resubmit once. Criteria 2 and 5 are essential: a submission without a decision log or without expert validation notes cannot pass.

Badge. "Framework Crosswalks and Levelling (Ability, L4)", alignment code ICSF-SKTX-L4-A. Evidence: crosswalk; validation notes.

Final knowledge check

Sources and further reading

Status as of November 2026; check before publishing.

• ESCO (European Skills, Competences, Qualifications and Occupations), European Commission. Use the current published version and record its version identifier in alignments.
• SFIA (Skills Framework for the Information Age), SFIA Foundation. SFIA 9 is current. SFIA 10 is in consultation; the SFIA Foundation targets release around Q4 2027. Check SFIA licence terms before reproducing descriptors.
• DigComp 3.0, European Commission, digital competence framework for citizens. Current; relevant for earner-facing courses and citizen digital competence alignment.
• ICoBC Credentialing Skills Framework (ICSF), International Council on Badges and Credentials, Berlin. Skill SKTX "Skills taxonomies and alignment".
• ICB-P05 Aligning Credentials to Skills Frameworks, ICoBC prerequisite course for this course.
• Documentation and licence terms published by the owner of any other framework you use in your assessed task. Read the owner's current text, version history and licence conditions before you map.