# Framework Crosswalks and Levelling *Where corporate and education alignment meet.* ## About this course **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. | Outcome | Module | How it is assessed | |---|---|---| | 1. Build a crosswalk between two frameworks with documented decisions | Crosswalk methods | Practice activity, module quiz, crosswalk in the assessed task, knowledge check | | 2. Level credentials against responsibility-based and learning-based scales | Levelling | Practice activity, module quiz, levelling rationale in the assessed task, knowledge check | | 3. Govern an organisational taxonomy: ownership, versioning and change requests | Governance | Practice activity, module quiz, governance and version note in the assessed task, knowledge check | | 3. Govern an organisational taxonomy: ownership, versioning and change requests | Maintenance when frameworks change | Practice activity, module quiz, maintenance plan in the assessed task, knowledge check | | 4. Validate a crosswalk with subject experts | Validation | Practice activity, module quiz, validation notes in the assessed task, knowledge check | **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.

Facilitator notes

**Cohort rhythm (suggested, about 10 hours in total).** - Self-paced, in this file: about 5 hours (five modules, roughly 1 hour each). - Live workshop 1 (90 minutes, after Modules 1 and 2): crosswalk clinic. Learners bring their draft mapping and levelling rationale. - Live workshop 2 (90 minutes, after Modules 3 and 4): role-play of an expert validation session. - Assessed task: about 2 hours, completed after Module 5. - Reserve time for feedback and resubmission. Agree before the course which two frameworks each learner will use. Learners from corporate settings often use an internal skills taxonomy against ESCO. Learners from professional bodies often use a competency framework against a qualifications framework. Check licence terms for every framework a learner proposes.

## 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: | Relation | Meaning | |---|---| | Equivalent | The two elements describe the same skill at the same scope | | Broader | The source element is wider than the target element | | Narrower | The source element is more specific than the target element | | Partial overlap | Some content is shared, some is not | | No match | No suitable element exists in the target | 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: | Source element | Target element | Relation | Confidence | Rationale | |---|---|---|---|---| | Write SQL queries | Query databases with a query language | Equivalent | High | Same activity and scope | | Build dashboards | Create data visualisations | Partial overlap | Medium | Dashboards add interactivity and audience design | | Data storytelling | (none) | No match | High | No ESCO element covers narrative presentation of data | 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.

Facilitator notes

Pair learners from different sectors for the practice activity so that they test each other's rationales. Ask pairs to swap tables and mark any rationale that a stranger could not follow. A rationale that needs context in the author's head is too thin. Watch for learners who map every element: ask them to find at least one honest "No match". Remind learners to check licence terms before they copy framework text into their tables; short identifiers and their own paraphrases are usually safer than long quotations.

**Question 1.** Why does a crosswalk need to record the exact version of each framework? [( )] So that the crosswalk looks more professional [(X)] So that the mapping can be checked and updated when either framework changes [( )] Because framework owners require a fee for each version [( )] Because version numbers show how good a framework is [[?]] Think about what happens a year after you publish. **** The version is part of the data. Without it, nobody can tell which text your decisions refer to, and you cannot see what has changed when a new release appears. **** **Question 2.** A similarity tool gives a candidate link a very high score, but the expert sees that the two elements use the same word with different meanings. What should happen? [( )] Accept the link, because the score is high [( )] Delete the candidate without recording anything [(X)] Reject the link and record the reason in the decision log [( )] Change the target framework so the meanings agree [[?]] The tool suggests; a person decides. **** A tool score is a signal, not a decision. The expert rejects the link and logs the reason, so the same candidate is not re-suggested without context later. **** **Question 3.** Which entry is the best rationale for a "Partial overlap" relation? [( )] "Looks similar to me" [( )] "The tool gave a score of 0.8" [(X)] "Both cover querying data; the target also covers data modelling, which the source does not" [( )] "Approved by the team" [[?]] A good rationale says what is shared and what is not. **** A rationale states the shared content and the difference in plain facts. Scores, opinions and approvals do not explain the relation. **** **Question 4.** What is the correct way to treat an element in the source framework that has no suitable counterpart in the target? [( )] Link it to the closest element anyway [( )] Remove it from the source framework [(X)] Record "No match" with a rationale and share it as a gap finding [( )] Wait until the target framework adds a matching element [[?]] Gaps are findings. **** Forced matches create false links and reduce trust. A documented "No match" is accurate and tells the framework owners where coverage may be missing. **** ## 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: | Attribute | Evidence | Judgement | |---|---|---| | Knowledge depth | Outcomes cover operating procedures and basic regulation | Fits level 3, not level 4 | | Application | Project requires planning a maintenance schedule with some choices | Fits level 3 to 4 | | Autonomy | Project is supervised by a mentor | Fits level 3 | 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.

Facilitator notes

Ask learners to exchange their levelling notes and challenge the alternative-level sentence. A good challenge asks "what evidence would move this up a level?" Expect resistance from learners who want to level generously for commercial reasons. Name this early: a defensible level protects the credential's reputation. Remind public agency participants to check any statutory use of national scales before using the wording "equivalent".

**Question 1.** Why is it risky to match a level 4 on one scale to a level 4 on another scale? [( )] Level numbers are always random [(X)] The scales may measure different things, so you must compare descriptors, not numbers [( )] Level 4 is not allowed in crosswalks [( )] Only learning-based scales have a level 4 [[?]] Think about what each scale describes. **** Responsibility-based and learning-based scales are built for different purposes. Matching numbers hides these differences. Compare the descriptors and state the link as indicative. **** **Question 2.** Which evidence is most useful for levelling a credential? [( )] The provider's marketing description [( )] The number of people who enrolled [(X)] Learning outcomes, assessment method, supervision and notional hours [( )] The price of the credential [[?]] Level descriptors speak about what learners know and can do. **** Levelling compares what the credential asks of learners with the level descriptors. Outcomes, assessment, supervision and workload are direct evidence of that. **** **Question 3.** Why record the alternative level you considered? [( )] To make the note longer [(X)] To show how the evidence was weighed and to help in later challenges [( )] Because every credential must have two levels [( )] To allow the provider to choose the higher level [[?]] Someone may question your decision later. **** The alternative level shows the reasoning. When a decision is challenged, the note explains why one level was chosen over the other. **** **Question 4.** Which sentence describes a link between a credential and a responsibility scale in the safest way? [( )] "Holders of this credential are Level 4 professionals." [( )] "This credential equals Level 4." [(X)] "This credential supports capability described at levels 3 to 4; the link is indicative." [( )] "This credential proves job competence at Level 4." [[?]] Choose the wording that is honest about the difference in scales. **** A band with an indicative label respects what each scale measures and avoids a claim that completing a credential proves job competence. **** ## 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: | Change | Example | Version change | |---|---|---| | Major | Elements removed or meaning changed; mappings may break | 2.0.0 from 1.4.2 | | Minor | New elements added; existing meanings unchanged | 1.5.0 from 1.4.2 | | Patch | Typos, label fixes, clarified wording without change of meaning | 1.4.3 from 1.4.2 | 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: - Fix a spelling error in an element label. - Merge two elements into one and remove both old elements. - Add a new element for a new technology. 4. Write a release note for one of them, including the impact on crosswalks.

Facilitator notes

Use the second live workshop to test the governance notes. Ask pairs to try to break each other's process with an awkward request, for example an urgent change from a senior manager outside the approval group. Discuss what the note says to do. Participants from public agencies may need to align the note with existing statutory or procurement rules; allow time for this. Remind learners that the governance note should be short enough to be read.

**Question 1.** What is the main benefit of naming one accountable taxonomy owner? [( )] The owner can change the taxonomy without telling anyone [(X)] Someone is responsible for quality and decisions, so the taxonomy does not drift [( )] The owner removes the need for subject experts [( )] The owner can avoid version numbers [[?]] Think about what happens when nobody is accountable. **** A named owner makes decisions and answers for quality. Experts advise, but accountability sits with one role. **** **Question 2.** An element is removed and its meaning is replaced by a new one. Which version change is the best fit? [( )] Patch [( )] Minor [(X)] Major [( )] No change is needed [[?]] Removed elements can break existing mappings. **** Removing elements or changing meaning can break existing crosswalks and records. This is a major change and needs a release note with impact. **** **Question 3.** Why keep deprecated elements visible with a pointer to a replacement? [( )] To make the taxonomy longer [( )] Because deprecated elements are still approved for new use [(X)] So that existing records and credentials stay readable and users can move to the replacement [( )] To avoid writing release notes [[?]] Think about records created last year. **** Deprecation gives users time to move. The old element stays visible, marked as deprecated, and points to its replacement. **** **Question 4.** What should happen to a rejected change request? [( )] It should be deleted to keep the log clean [( )] It should be accepted later without review [(X)] It should be kept with the reason for rejection [( )] It should be sent to a different taxonomy [[?]] The same request often returns. **** Keeping rejected requests with reasons saves time and builds trust, because users see that decisions are explained. **** ## 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): | Result | Rows | |---|---| | Agree | 14 | | Agree with change | 4 | | Disagree | 2 | | Cannot judge | 0 | 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.

Facilitator notes

Workshop 2 can include a role-play: one learner plays the mapper, two play experts who disagree about a row, and one observes the decision log. Ask the observer to check whether the final record would persuade a stranger. Encourage learners to find real experts for their assessed task. If a learner cannot reach any expert, they may use two peers from the cohort as a minimum and must state the limit in their notes. Remind learners to ask experts' consent before naming them in submitted evidence.

**Question 1.** Which rows should always be included in an expert review, even when you sample the rest? [( )] Only the rows with the highest tool scores [(X)] Rows with low confidence, partial overlaps and rows where tool and mapper disagree [( )] Only the first ten rows [( )] Only rows that nobody questioned [[?]] Review effort belongs where risk is highest. **** Risky rows are the most likely to contain errors. Reviewing them in full gives more assurance than reviewing only easy rows. **** **Question 2.** Two experts disagree about a link and the framework text does not settle it. What is the best action? [( )] Accept the view of the more senior expert without a record [( )] Delete the row from the crosswalk silently [(X)] Record the disagreement and choose a cautious relation such as partial overlap with low confidence, or no match [( )] Ask the AI tool to decide [[?]] Be honest about what is not settled. **** Where evidence does not settle a question, a cautious relation and an honest record serve users better than a confident but unsupported link. **** **Question 3.** Why should validation notes record the framework versions and the experts' domains? [( )] To meet a formatting standard only [( )] To make the notes longer [(X)] So that a reader can judge what was checked, by whom and against which texts [( )] Because experts must be named in public [[?]] Think about someone reading the notes a year later. **** Notes without versions and expert domains cannot be assessed. A reader needs to know what was checked, by whom and against what. **** **Question 4.** How should AI similarity suggestions be treated in expert validation? [( )] As final decisions that experts only sign [( )] As unreliable and not worth recording [(X)] As candidates that experts accept, change or reject, with the human decision recorded [( )] As replacements for the decision log [[?]] The tool suggests; a person decides. **** Similarity matching speeds up discovery, but accountability stays with people. The log shows which rows came from the tool and what the experts decided. **** ## 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: | Impact | Meaning | Action | |---|---|---| | None | Element unchanged | Update the version identifier only | | Wording | Text changed, meaning unchanged | Re-read, update rationale if needed | | Meaning | Scope or level changed | Re-map and re-validate | | Removed | Element retired | Find the replacement or record "No match" | | New | New element in your domain | Consider mapping; follow the change request process | 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: | Impact | Rows | |---|---| | None | 28 | | Wording | 7 | | Meaning | 3 | | Removed | 1 | | New | 1 candidate | 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.

Facilitator notes

Use the simulated change as a quick team exercise: give each pair a different simulated change and ask them to decide the version number and the people to inform. Compare answers. Stress the distinction between a released version and a consultation draft, and ask learners to find where in their own organisation draft texts are quoted as if final. Remind learners to check current framework status in official sources before using any version statements in their assessed submission.

**Question 1.** What is the best treatment of a framework version that is still in consultation? [( )] Map to it as if it were final [( )] Claim alignment to it in published material [(X)] Read it and plan for impact, but keep mappings and claims based on the released version [( )] Ignore it completely, including in the register [[?]] A consultation text can change before release. **** Consultation drafts may change. Track them in the register and prepare, but base published mappings and claims on released versions. **** **Question 2.** A new framework release changes the scope of an element you mapped. How do you classify the impact? [( )] None [( )] Wording [(X)] Meaning, so the row needs re-mapping and re-validation [( )] New [[?]] Scope changed, not only the words. **** A change in scope changes what the element means, so your relation and rationale may no longer hold. The row needs a new decision and validation. **** **Question 3.** Why keep the previous crosswalk version available after publishing a new one? [( )] To confuse users on purpose [( )] Because old versions are more accurate [(X)] So that credentials and records issued under the old version stay interpretable [( )] Because the framework owner requires it in all cases [[?]] Think about a credential issued last year. **** Records refer to the version in force when they were issued. Keeping the old version available, clearly labelled, preserves their meaning. **** **Question 4.** Which release note content is most useful for crosswalk users after an update? [( )] "Updated." [( )] "Now much better." [(X)] The framework version change, the number of rows affected by impact class, the actions taken and a link to the validation notes [( )] A list of the staff who worked on it, only [[?]] Users need to know what changed and what it means for them. **** A good release note states what changed, how large the change is, what was done and where the evidence is. **** ## 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: - A scope note: frameworks, owners, exact versions, domain, purpose, direction, licence notes. - For each row: source element, target element or "No match", relation type, confidence, rationale, decider, date, and whether a tool suggested it. - 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. - A short governance note: owner, steward, version policy, change request path. - A short maintenance plan: framework register entry, check rhythm and one simulated change with its impact classification. 2. **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 | Criterion | Not yet | Meets standard | Strong | |---|---|---|---| | 1. Scope and versions (Outcome 1) | Frameworks or versions missing or unclear | Frameworks, owners, versions, domain, purpose and licence notes stated | Also explains direction and intended users, with a clear boundary of what is out of scope | | 2. Mapping quality and decision log (Outcome 1) | Few rows, relations missing or forced, rationales vague | At least 15 rows with relation, confidence, rationale, decider and date; includes at least one honest "No match" or partial overlap | Rationales are specific and checkable; tool suggestions and rejections are logged; gaps are reported as findings | | 3. Levelling (Outcome 2) | Levels matched by number only; no evidence | Evidence listed; attribute judgements on both scale types; level or band with alternative considered | Clear indicative wording that states what the link does not claim; limits and missing evidence stated | | 4. Governance (Outcome 3) | No named roles or version policy | Owner, steward, experts, version policy and change request path described | Includes status labels, release note example and a rule for urgent changes | | 5. Validation (Outcome 4) | No expert review, or review without records | Plan, named expert domains, results per reviewed row, disagreements resolved with evidence, summary counts | Risk-based sampling explained; expert independence considered; limits stated honestly | | 6. Maintenance (Outcome 3) | No plan for framework change | Register entry, check rhythm and one simulated change classified with action and version decision | Distinguishes released from consultation versions and shows a version timeline | | 7. Clarity and integrity | Hard to follow; unsupported claims about competence or equivalence | Clear, organised, claims proportionate to evidence | Easy to reuse by another team; wording is cautious and precise | **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.

Facilitator notes

**Assessor guidance.** Assess with the rubric only. Do not grade inside this file. Read the decision log first: it reveals the quality of the work faster than the summary. Check that framework versions are stated and plausible for November 2026. Look for evidence that experts really reviewed the rows and for honest limits. A small, well-documented crosswalk is better than a large one with vague rationales. **Moderation.** Sample at least one in five submissions for a second assessor. Compare decisions on criteria 2 and 5. **Feedback.** Give feedback per criterion with one specific example from the submission and one next step. **Integrity.** If tools were used to generate rows or text, the log must show it and the human decision. Treat unlogged tool output presented as expert judgement as a reason to ask for revision.

### Final knowledge check **Question 1.** Which statement describes the purpose of a decision log in a crosswalk? [( )] It replaces the need for expert validation [(X)] It records each decision with relation, rationale, decider and date, so mappings can be checked and updated [( )] It lists the framework owners' contact details [( )] It shows only the mappings that were accepted by a tool [[?]] Think about evidence a stranger could follow. **** The decision log makes mapping decisions traceable. It supports validation and later updates, and it does not replace expert review. **** **Question 2.** You find no element in the target framework for a source element. What is the most appropriate record? [( )] Link to the nearest element with high confidence [( )] Leave the row blank without a note [(X)] "No match" with a rationale, reported as a gap [( )] Delete the source element [[?]] Gaps are findings. **** An honest "No match" with a rationale avoids false links and gives framework owners useful information. **** **Question 3.** A credential's outcomes need applied performance, but its only assessment is a knowledge test. What should the levelling note say? [( )] Level it on the highest possible level to match the outcomes [( )] Ignore the assessment method because outcomes matter more [(X)] Record that evidence of applied performance is missing and level according to the evidence available, noting the alternative considered [( )] Remove the credential from the crosswalk [[?]] Levelling follows the evidence. **** Levelling must reflect what the credential actually assesses. Missing evidence is stated, and the alternative level shows the reasoning. **** **Question 4.** Which wording best expresses the link between a credential and a responsibility-based scale? [( )] "This credential equals Level 4." [( )] "Holders of this credential work at Level 4." [(X)] "This credential supports capability described at levels 3 to 4; the link is indicative." [( )] "This credential proves competence at Level 4." [[?]] The scales measure different things. **** An indicative band states the link honestly. Equality or proof statements go beyond what the evidence supports. **** **Question 5.** What makes an organisational taxonomy governance arrangement dependable? [( )] Everyone can edit the master file at any time [( )] Decisions are made by whoever is available [(X)] A named owner, a steward, a version policy and a change request process with recorded decisions [( )] Only version numbers, without roles [[?]] Think about accountability and traceability. **** Governance needs named accountability, a clear change path and records. Open editing and ad hoc decisions lead to drift. **** **Question 6.** A new element is added and existing elements keep their meaning. Which version change fits best? [( )] Major [(X)] Minor [( )] Patch [( )] No version change [[?]] Additions without breaking existing mappings. **** Adding elements without changing existing meanings is a minor change. A major change is for removals or changed meanings that can break mappings. **** **Question 7.** Why must a change request record include its impact on crosswalks and credentials? [( )] Because impact text makes the form look complete [( )] Because only the requester needs it [(X)] So that reviewers and users can see what will need updating before a decision is made [( )] Because the impact replaces the reason for the change [[?]] Decisions should consider consequences. **** Impact information supports a decision and lets affected teams prepare. Without it, changes can silently break mappings. **** **Question 8.** Which approach to expert validation gives the most useful assurance when you cannot review every row? [( )] Review only rows with the highest tool scores [( )] Review only the rows the mapper is most confident about [(X)] Review all risky rows (low confidence, partial overlaps, disagreements) plus a sample of the rest, and state the limits [( )] Skip review and publish with a high confidence label [[?]] Put effort where errors are most likely. **** Risk-based sampling concentrates review on the rows most likely to be wrong, and an honest statement of limits shows what the assurance does and does not cover. **** **Question 9.** How should AI similarity matching be used in crosswalk work? [( )] As an authority that makes final decisions [( )] Not at all, because it can make mistakes [(X)] To suggest candidates that experts accept, change or reject, with the human decision and tool involvement recorded [( )] Only for levelling decisions [[?]] The tool suggests; a person decides. **** Similarity matching speeds up discovery and has limits. Experts keep accountability, and the log shows where the tool contributed. **** **Question 10.** A framework owner has opened a consultation on a new version. What is the best action for your published crosswalk? [( )] Update the crosswalk to the draft and claim alignment to the new version [( )] Do nothing and never mention the consultation [(X)] Record the consultation in the framework register, plan for impact, and update only after the final release with re-validation [( )] Remove the framework from the crosswalk [[?]] A consultation text can change before release. **** Plan for the change, but base published claims on released versions. After release, classify impact, update, re-validate and publish a new crosswalk version. **** ## 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.