Designing a Credential: Claim, Criteria, Evidence and Metadata

Turn a learning or work activity into a credential that means something to a reader.

Course ID: ICB-P01 | Framework alignment: ICoBC Credentialing Skills Framework (ICSF), skill CRDS "Credential design" (VRITE pillar: Rigor), level L2 "Operate", stage A "Ability".

At this level you draft credential specifications from templates, including outcomes, criteria and required metadata. The Ability stage means you practise on realistic tasks in a controlled setting. In this course the setting is a set of cases and a project: you design one credential from start to finish.

Who this course is for

• L&D and corporate academy leads
• Programme and micro-credential leads
• Learning designers and teaching staff
• Professional bodies and sector associations

Prerequisite: ICB-F01 Digital Badges and Credentials Essentials.

Learning outcomes. After this course you can:

1. Write a credential claim and outcomes that state what the earner can do.
2. Define criteria and the evidence that proves each of them.
3. Complete the metadata needed for portability, including alignment, level and workload.
4. Test a specification with a reader outside the issuing team and revise it.

Workload. 10 hours notional learning in a blended cohort. This file covers the self-paced part. Live and workshop elements appear as facilitator notes.

How it is assessed. You submit a complete credential specification for a real or realistic credential. A person assesses it with the ICoBC design rubric, and a peer reviews it. A final knowledge check supports the assessment.

Badge. "Designing a Credential: Claim, Criteria, Evidence and Metadata (Ability, L2)", alignment code ICSF-CRDS-L2-A.

Quality focus. VRITE Rigor (criteria and evidence) and Value (meaning to readers).

How the course works. Each module has short units, one worked example, one practice activity and a quiz. Keep one working document open. Every practice activity adds a section to your credential specification, so by Module 6 you hold a full draft.

Choose your credential. Before you start, pick one real or realistic credential to design. Good choices are a short course in a college, a workplace skills programme in a corporate academy, a professional body's practice award, or a project-based micro-credential. Choose something you know well enough to describe in detail.

Start from the claim

Why a credential needs a claim

A credential is a statement about a person. The issuer says: this earner can do this, and here is how we know. The first half of that sentence is the claim. Everything else in the specification exists to support it.

Many credentials begin with an activity: a course, a workshop, a project, a shift rotation. The activity tells a reader what the earner attended or completed. A claim tells the reader what the earner can do afterwards. Readers such as employers, admissions teams and professional bodies make decisions on the second kind of information.

Start your design from the claim, then work backwards to the activity. That order protects you from a common problem: a credential that lists topics covered and leaves the reader to guess the capability.

The parts of a claim

A good claim has four parts. You can check any draft against them.

1. An earner. Who the statement is about. Usually "the earner".
2. An action verb. A capability a reader can picture, such as "plan", "calculate", "facilitate" or "review".
3. An object. What the action applies to, such as "a project budget" or "a customer complaint".
4. A context or standard. The conditions or quality level, such as "for a team of up to ten" or "following the organisation's data protection policy".

Compare two drafts for the same credential:

• Weak: "Understands project management."
• Stronger: "Plans a small project with a scope statement, a schedule and a risk register, and reports progress to a sponsor."

The weak draft uses "understands", which a reader cannot observe. The stronger draft names things the earner produces and does. You can check them against evidence later.

Avoid verbs such as "know", "understand", "appreciate" and "be aware of" in a claim. They describe an inner state. If awareness is the real aim, ask what the earner does differently because of it, and claim that.

Who reads the claim

A credential has at least three kinds of reader: the earner, a reader who decides something based on it (an employer, a selector, a regulator), and the issuer's own team. Decide who the primary reader is before you write. A claim for a hiring manager reads differently from a claim for an internal audit team.

Write down this reader context in one line:

The primary reader is a [role] who needs to decide [decision] and has [time or knowledge limit].

For example: "The primary reader is a site supervisor who needs to decide whether a new hire may operate a pallet truck unsupervised, and has two minutes to read the credential."

Keep that line next to your draft. In Module 6 you test it with a real reader.

Worked example: Two claims from one activity

University or training provider. A training provider runs a two-day workshop on writing grant proposals for community organisations. The original description reads: "Covers funding sources, proposal structure and budgeting." The designer rewrites it as a claim: "Writes a grant proposal of up to ten pages that states need, activities, outcomes and a budget, and submits it against a funder's published guidelines." The primary reader is a charity manager deciding whom to ask to lead an application.

Corporate academy. An HR department runs a programme for new team leaders. The original description reads: "Introduction to feedback conversations." The designer's claim: "Prepares and holds a structured performance feedback conversation with a team member, and records agreed actions in the HR system within two working days." The primary reader is a department head deciding which team leaders may run appraisals alone.

In both cases the activity stays the same. Only the statement changes, and the reader can now picture what the earner does.

Practice activity: Draft your claim

Open your specification template and write section 1. Do the following:

1. Write the reader context line for your chosen credential.
2. Draft one claim sentence with an action verb, an object and a context or standard.
3. Check it against the four parts. Underline each part in your draft.
4. Rewrite the claim if it uses "understand", "know" or "be aware of".

Keep your draft to one or two sentences. Illustrative template headings for your specification: 1 Claim, 2 Outcomes, 3 Criteria, 4 Evidence, 5 Metadata, 6 Name and description, 7 Reader test log.

Check your understanding

Outcomes and criteria

From claim to outcomes

A claim gives the overall statement. Learning outcomes break it into parts that can be taught and checked. Think of the claim as the headline and the outcomes as the main points under it.

Aim for three to six outcomes for a small credential. More than that is a sign that the credential is too large, or that the outcomes list tasks, not capabilities. Each outcome should follow the same pattern as the claim: an action verb, an object and a context or standard.

For the grant proposal claim above, outcomes could be:

1. Identifies a funder whose published priorities match a project.
2. Writes a need statement supported by at least two sources.
3. Builds a budget that matches the planned activities.
4. Checks a draft against the funder's guidelines before submission.

Outcomes describe what the earner can do. They do not describe what the course covers. "Covers budgeting" is a topic; "Builds a budget that matches the planned activities" is an outcome.

What criteria are

Criteria are the conditions the earner must meet to be awarded the credential. In the Open Badges standard, criteria describe what is required, and they are a core part of the achievement description. A reader uses criteria to judge how demanding the credential is. An assessor uses them to decide who passes.

An outcome says what the earner can do. A criterion says what must be shown, and to what standard, for the award. Often one outcome leads to one criterion, but sometimes an outcome needs two criteria, or two outcomes share one.

Good criteria have these qualities:

• Observable. An assessor can see or read something that shows it.
• Specific. The standard is stated, for example "all three sections complete" or "within the agreed tolerance".
• Independent. One criterion does not depend on another to be judged.
• Proportionate. The demand matches the level and workload of the credential.
• Complete. Together the criteria cover the claim, with no outcome left without a criterion.

Add an award rule. State whether the earner must meet all criteria or a defined number of them. If some criteria are optional, say so.

Writing criteria that an assessor can use

Write each criterion as a short sentence that starts with the earner or an action. Include the standard. Compare:

• Weak: "Demonstrates good budgeting skills."
• Stronger: "Submits a budget in which every planned activity has a cost line and the total matches the sum of the lines."

The stronger version tells an assessor exactly what to check. Two assessors would reach the same decision.

Watch for these common faults:

• Vague quality words. "Good", "appropriate", "effective" and "sufficient" need a definition. If you keep one, say how it is judged, for example "appropriate, as defined in the checklist".
• Attendance as criterion. "Attends all sessions" shows presence. Use it only if presence is itself part of the claim, such as a safety induction.
• Too many criteria. A long list makes the credential hard to award and hard to read. Group related checks into one criterion with a checklist as supporting material.
• Hidden criteria. If the assessor uses a standard that is not written down, the criteria are incomplete. Write it down.

Criteria also tell the earner what to aim for. Publish them before the learning starts.

Worked example: From outcomes to criteria

College or training provider. A college offers a micro-credential in "Producing accessible documents". The claim: "Produces a document that meets the college's accessibility checklist." Outcomes and criteria (illustrative):

Award rule: all three criteria must be met. The earner may resubmit once.

Corporate academy. An HR department awards "Onboarding buddy". The claim: "Supports a new colleague through their first 30 days using the onboarding plan." Criteria (illustrative):

Award rule: all three criteria must be met.

Practice activity: Break your claim into outcomes and criteria

Continue your specification with sections 2 and 3.

1. Write three to five outcomes that together make up your claim.
2. For each outcome, write at least one criterion with a stated standard.
3. Replace any vague quality word, or define it.
4. Write the award rule in one sentence.
5. Swap your table with a peer. Ask: "Could two assessors reach the same decision from this criterion?" Mark any criterion that fails and revise it.

Check your understanding

Evidence that proves the claim

What counts as evidence

Evidence is what the earner shows, and what the issuer checks, to prove that a criterion is met. A criterion says what must be true. Evidence is the thing you look at to see that it is true.

Evidence takes many forms:

• A work product, such as a report, a design file, a lesson plan or a spreadsheet.
• A performance record, such as an observation checklist completed by an assessor.
• A test result, from a knowledge test or practical test.
• A log or portfolio, such as a reflective journal with dated entries.
• A third-party statement, such as a manager's confirmation or a client's feedback.

Choose the type that fits the verb in the criterion. A criterion with "builds" needs a product. A criterion with "facilitates" needs observation or a recording. A criterion with "explains" can use a short written or oral task.

Evidence must also be authentic: it is the earner's own work, produced under the conditions the issuer states. Say how authenticity is checked, for example through supervised tasks, a signed declaration, or a short viva.

Matching evidence to each criterion

Build an evidence table. Each criterion gets a row. For each row, state the evidence, who judges it, and the standard of judgement.

Rigor: the quality of the proof

Rigor means that the evidence really supports the claim and that different assessors judge it in the same way. Four checks help you test your design.

1. Validity. Does this evidence show the criterion, or something near it? A multiple-choice test about giving feedback does not show that someone gives feedback well.
2. Sufficiency. Is there enough evidence? One short task may not show a skill that must hold across situations.
3. Authenticity. Is it the earner's own work?
4. Consistency. Is there a rubric or checklist so that assessors reach the same decision?

Add proportion. A credential of five hours does not need a portfolio of thirty items. A credential that supports a safety-critical decision needs stronger proof than one that marks participation in a community event.

Also decide how evidence is stored and shared. Open Badges 3.0 allows evidence to be linked from a credential. Be careful with personal data: if evidence contains information about other people, such as client names or learner work, get consent or use anonymised samples. Check your organisation's data protection rules.

State the assessor. Who is allowed to judge the evidence, and what training do they need? An assessor who knows the earner personally may need a second marker.

Worked example: Evidence plan

University or training provider. A university short course awards "Conducting a literature search". Criterion: "Submits a search record showing at least three databases, the search terms used and the number of results at each stage." Evidence: a one-page search log, plus a short screen recording of one search, produced during a supervised session. Judged by: the course tutor, using a four-line checklist. Authenticity: the supervised recording. Sufficiency: one full search on a topic chosen from a list. Storage: the log is linked as evidence; the recording is kept by the university for twelve months (illustrative).

Corporate academy. An HR department awards "Facilitating a team retrospective". Criterion: "Facilitates a retrospective for a team of at least five people, covering what went well, what did not and agreed actions." Evidence: an observation form completed by a trained observer, and the action list produced by the team. Judged by: the observer, using the form. Authenticity: the observer attends in person. Sufficiency: one full session. Storage: the action list is shared only with the team's consent.

Practice activity: Build your evidence table

Continue your specification with section 4.

1. Create a table with one row per criterion from Module 2.
2. For each row, name the evidence, who judges it and the standard.
3. Add a line on authenticity and a line on sufficiency.
4. Mark any evidence that contains personal data and note how you handle it.
5. Check each row for validity: would the evidence still be convincing if you did not know the earner?

Check your understanding

Metadata for portability

Why metadata matters

Metadata is structured information about a credential. It travels with the credential so that other systems, and other people, can read it. If the claim, criteria and evidence are the content of the specification, metadata is the label on the outside that lets a credential move between a learning platform, a wallet, an employer's system and a profile page.

Two standards help with this:

• Open Badges 3.0 describes how to issue and verify digital badges as verifiable credentials. It carries information about the issuer, the achievement, the earner and the evidence.
• Comprehensive Learner Record (CLR) Standard 2.0 describes how to package several achievements, with fuller detail, into a learner record.

Status as of November 2026; check before publishing. Both are current specifications. Platform support is still uneven, so check the conformance certification of any tool before you rely on it.

You do not need to write code to complete this part. Your task is to decide the content of each field. A technical team or a tool can then place it in the correct format.

The fields to complete

Complete each of these fields in your specification. Use plain language first. A technical team can map it later.

• Name. A short, specific title. See Module 5.
• Description. The claim in one or two sentences a reader can follow without extra context.
• Issuer. The organisation that vouches for the credential, with a contact route.
• Criteria. The criteria and award rule, in a form that can be published and linked.
• Evidence. What the earner submits, and whether it is attached or linked.
• Alignment. The framework, standard or competency description the credential relates to. Alignment lets a reader place your credential in a wider system, for example a national qualifications framework, an occupational standard or a professional competence framework. Name the specific framework and the specific item, not only the framework in general.
• Level. The level of the credential on a stated framework, such as the European Qualifications Framework (EQF) or a national framework. State the framework as well as the number. Do not assign a level you cannot support with evidence. If the credential is not formally levelled, say so.
• Workload. The typical learning time. State whether it is notional learning hours, contact hours or both. If credit applies, name the credit system, for example ECTS, and state the amount only if an institution has confirmed it.
• Dates and validity. Issue date and, if relevant, expiry or renewal rule.
• Language. The language of the credential and the assessment.

The EU Council Recommendation of 2022 on a European approach to micro-credentials is a stable reference for what such credentials should describe. It lists elements such as the identification of the learner, title, issuing body, date, learning outcomes, notional workload in ECTS credits where possible, level and type of assessment. Check the text for the exact list. Status as of November 2026; check before publishing. Watch for Commission implementation reporting and national transpositions, because national practice may add or change requirements.

Honest metadata

Metadata is a promise. Check each field against what you can support.

• Do not claim alignment to a framework unless you have compared your criteria with it. Record who did the comparison and when.
• Do not state a level or credit amount because it sounds more valuable. State it only where a body with the authority to set it has done so, or say "not formally levelled".
• Keep workload honest. Count what a typical earner needs, including assessment time. If the figure is an estimate, say so.
• Keep metadata consistent with the description and criteria. If the description promises more than the criteria check, readers will notice.

Worked example: Filling the metadata card

University or training provider. A university continuing education unit issues "Conducting a literature search". Metadata (illustrative): Issuer: the unit's name and contact email. Alignment: the university's own information literacy statement, items 2 and 3, compared by the librarian on a stated date. Level: "Not formally levelled; designed at the level of first-year undergraduate study." Workload: "Notional learning 6 hours, including 1 hour of assessment." Credit: "None." Validity: "No expiry." Language: English.

Corporate academy. An HR department issues "Facilitating a team retrospective". Metadata (illustrative): Issuer: the academy and a named programme owner. Alignment: the company's internal leadership competency model, competency "Enable team learning", compared by the HR business partner. Level: "Internal level 2 of 4 in the company model." Workload: "Notional learning 8 hours including one observed session." Validity: "Two years, then renew by observed session." Language: English.

Note that both examples say what a field does not claim, as well as what it does.

Practice activity: Complete your metadata card

Continue your specification with section 5.

1. Fill in every field in the list above for your credential.
2. Name one framework or standard for alignment, name the specific item, and note how you compared it. If you cannot name one, write "none yet" and note what you would need to do.
3. State level on a named framework or write "not formally levelled".
4. State workload in hours, say what the hours include, and mark it as an estimate if it is one.
5. Highlight any field where you are unsure, and list who could confirm it.

Check your understanding

Naming and description

Names that readers can use

The name of a credential is the first thing a reader sees. It appears on a profile page, in a CV, in a search result and in a wallet. Often it is the only thing a reader sees. A weak name sends the reader away.

A good name is:

• Specific. It names the capability, not just the subject. "Facilitating a team retrospective" tells more than "Agile level 1".
• Short. Aim for six words or fewer where you can, and keep it readable in a narrow list.
• Honest. It does not suggest more than the criteria check. Avoid words such as "master", "expert" or "professional" unless the criteria support them.
• Free of internal code. "ACAD-204" means nothing to an outside reader. Keep codes in the identifier field.
• Consistent. If you issue a family of credentials, use a common pattern.

A name that starts with a verb, such as "Planning a small project" or "Writing accessible documents", often reads well and ties to the claim.

Descriptions that carry the claim

The description is the claim in a form that fits a profile card. Two or three sentences are enough. A reader should learn who the credential is for, what the earner can do and how it was checked, without opening any link.

A useful structure:

1. What the earner can do. The claim, in plain words.
2. How it was checked. One sentence on the evidence and assessment.
3. Context. Who issues it, and the workload or level if it helps.

Example (illustrative): "The earner plans a small project with a scope statement, a schedule and a risk register, and reports progress to a sponsor. Assessed through a submitted project plan judged against a four-point checklist. Issued by the academy's project office after about eight hours of study."

Keep the description consistent with the criteria. Do not add promises, such as job outcomes, that the criteria do not check. Never state that holding the credential proves competency in a job. Say what was assessed and how.

Use words the reader knows. Spell out abbreviations on first use. Write in active voice and keep sentences short.

Using AI to draft descriptions, with a human edit log

You may use an AI writing tool to draft a name or description. This is optional. If you do, follow three rules.

1. Give it your specification, not a topic. Provide the claim, criteria and evidence plan. Ask for a description that restates them in plain language. A tool given only a topic will invent content.
2. Edit as a human. Check every sentence against your criteria. Remove anything the criteria do not support. Check names, numbers and framework references; a tool may state them wrongly.
3. Keep a human edit log. Record what the tool produced, what you changed and why. Add your name and the date. The log is part of your evidence.

Do not paste personal data, confidential material or learner work into a tool unless your organisation's policy allows it. Check the policy first.

A simple edit log (illustrative):

Worked example: Rewriting a name and description

College or training provider. A college's draft: Name: "Digital Skills Module 3". Description: "Learn about spreadsheets and data." Rewritten: Name: "Analysing data in a spreadsheet". Description: "The earner cleans a data set, builds a summary table and a chart, and explains one finding in two sentences. Assessed through a submitted spreadsheet judged against a checklist. Issued by the college's digital skills team after about ten hours of study." Changes: the name states the capability, the description restates the claim and says how it was checked.

Corporate academy. An HR draft: Name: "Feedback Champion". Description: "Recognises excellence in giving feedback." Rewritten: Name: "Holding a feedback conversation". Description: "The earner prepares and holds a structured feedback conversation with a team member and records agreed actions within two working days. Assessed by a trained observer using a checklist. Issued by the academy after about six hours of learning including one observed conversation." Changes: "Champion" and "excellence" suggest more than the criteria check, so they are removed.

Practice activity: Name and describe your credential

Continue your specification with section 6.

1. Write three possible names. Choose one and note why.
2. Write a description of two or three sentences following the structure above.
3. Check that every statement in the description is supported by a criterion or evidence row.
4. Optional: ask an AI writing tool to draft the description from your specification. Keep an edit log with at least three entries, as in the table above. If you do not use a tool, write "No AI used" in your log.
5. Read the name and description aloud to a colleague. Ask them what the earner can do. If the answer differs from your claim, revise.

Check your understanding

Testing with readers

Why test with someone outside the team

The people who design a credential know what they mean. That knowledge hides problems. They fill gaps without noticing, and they read their own text as they intended it. A reader outside the team has no such help. They show you what the credential says to someone who was not in the room.

Testing is part of rigor, and it also checks value: does the credential mean something to the people who will read it? A short test with one or two readers often finds problems that review within the team does not.

Choose readers who match the primary reader you defined in Module 1: for example an employer, a selector, a supervisor from another department, or a person from a partner organisation. Do not choose someone who helped design the credential. Avoid using only friendly colleagues who will not challenge you.

How to run a reader test

A reader test can be short. Thirty minutes with one reader is a good start. Follow these steps.

1. Prepare what the reader sees. Give them only what a real reader would see: the name, description, criteria summary and metadata card. Do not explain it first.
2. Ask them to tell you in their own words. "What can this earner do?" "What did the earner have to show?" "How demanding is this, compared with others you know?"
3. Ask a decision question. "Would this help you decide whether to [the decision you named in Module 1]? What else would you need?"
4. Watch for confusion. Note where the reader hesitates, rereads or asks a question. Each is a point to fix.
5. Do not defend. Your task is to listen. If you explain or argue, you lose the information.
6. Record the results. Keep a short log: reader role, what they said, what you changed.

Include a question on fairness and access. Ask whether any criterion could disadvantage a group of earners for reasons that have nothing to do with the claim, such as a time limit that is not part of the skill, or a format that needs equipment not everyone has. Adjust where the barrier is not part of the claim.

Revising and recording

Sort the reader's comments into three groups.

• Must fix. The reader misunderstood the claim, could not tell what was required, or found a statement that the criteria do not support.
• Should fix. The reader found wording that is unclear or too long.
• Note. A reader preference that does not affect meaning.

Revise the must-fix items first. Change the specification, not only the description. If a reader cannot tell what the earner can do, the claim or criteria may need work, and polishing the description alone will not help.

Keep a revision log with the original text, the reader's comment, your change and the date. A second round with a different reader shows whether your changes worked.

Peer review in this course follows the same logic. Your peer is outside your issuing team, so they act as a reader. Give feedback as observations ("I read this as...") instead of verdicts ("this is wrong"), and base it on the rubric.

Worked example: A reader test and a revision

University or training provider. A university designs "Conducting a literature search". The designer asks a librarian from another faculty to read the card. The librarian says: "I see 'search record' but I cannot tell how many databases are needed or whether a recording counts." Must fix: the criterion states "at least three databases" in the criteria but the description says only "a search record". The designer changes the description to include "in at least three databases" and adds the recording to the evidence list. Revision log entry: reader role, quote, change, date.

Corporate academy. An HR department designs "Holding a feedback conversation". The designer asks a department head who was not involved. The department head says: "Does this mean they can run appraisals on their own? I would not assume that." Must fix: the description implied more than the criteria check. The designer changes "ready to appraise" to "holds a structured feedback conversation with a team member" and adds a line "This credential does not authorise formal appraisals." The department head also asks about people who work night shifts and cannot be observed during the day; the designer adds an alternative observation slot.

Practice activity: Test and revise your specification

Complete section 7 of your specification, and finish your draft.

1. Choose a reader outside your issuing team who matches your primary reader.
2. Give them only the name, description, criteria summary and metadata card.
3. Ask the three questions in the steps above and the decision question. Take notes. Do not explain.
4. Sort comments into must fix, should fix and note. Revise the specification.
5. Write a revision log with at least three entries: the reader's comment, your change and the date.
6. Exchange your complete specification with your assigned peer. Review theirs using the rubric in "Assessment and badge" and write your peer review notes as observations.
7. Prepare your final submission: specification, reader test log and revision log, and peer review notes.

Check your understanding

Assessment and badge

The assessment task

You submit a complete credential specification for a real or realistic credential. A person assesses it with the ICoBC design rubric below. A peer also reviews it. The final knowledge check supports the assessment and covers all four learning outcomes.

What to submit (badge evidence)

1. Credential specification. Sections 1 to 6 of your template: claim, outcomes, criteria with award rule, evidence table, metadata card, and name and description.
2. Reader test and revision log. Section 7: the reader role, what the reader said, what you changed and when.
3. Peer review notes. The notes you wrote for your peer, based on the rubric, and a short note on how you used the notes you received.
4. Human edit log (if you used AI). Or the statement "No AI used".
5. Rubric result. Recorded by the assessor.

Length. The specification is usually three to five pages. Quality matters more than length.

ICoBC design rubric

The assessor rates each row as Not yet, Meets or Exceeds. The assessor writes a short comment on each row.

Pass rule. The earner passes when the assessor rates every row as Meets or Exceeds. If one or more rows are rated Not yet, the earner receives written feedback and may revise and resubmit once. The final knowledge check must also be completed. Passing the final check does not replace the rubric result.

Link to outcomes. Rows 1 to 3 assess outcome 1 and outcome 2. Row 4 assesses outcome 2. Rows 5 and 6 assess outcome 3. Rows 7 and 8 assess outcome 4.

Final knowledge check

Answer all questions. You may revisit modules before you answer.

Evidence for the badge

The badge is "Designing a Credential: Claim, Criteria, Evidence and Metadata (Ability, L2)", alignment code ICSF-CRDS-L2-A. It records that the earner completed assessed practice tasks on designing a credential specification. It does not show competence in any particular job.

Sources and further reading

Status as of November 2026; check before publishing. All sources below are official texts or documents from standards bodies and framework owners. Check each for the current version before you cite it.

• Open Badges 3.0. Specification published by 1EdTech Consortium. Search for "Open Badges 3.0" on the 1EdTech website.
• Comprehensive Learner Record (CLR) Standard 2.0. Specification published by 1EdTech Consortium.
• Conformance certification for Open Badges 3.0 and CLR 2.0. Published by 1EdTech Consortium; check which tools are certified before you choose a platform.
• Council Recommendation of 16 June 2022 on a European approach to micro-credentials for lifelong learning and employability. Official Journal of the European Union. Search for the title on EUR-Lex.
• European Qualifications Framework (EQF). European Union. Use the official EU pages to check level descriptors before you state an EQF level.
• ICoBC Credentialing Skills Framework (ICSF). Owned by ICoBC, Berlin. Use the current published version for skill CRDS "Credential design" and level L2 descriptors.
• W3C Verifiable Credentials Data Model. Published by the World Wide Web Consortium. Background for how Open Badges 3.0 relates to verifiable credentials.

Time-sensitive points to check before publishing

• Platform support for Open Badges 3.0 and CLR 2.0 is still uneven. Check conformance certification of tools.
• Watch for Commission implementation reporting and national transpositions of the 2022 Council Recommendation, because national requirements for micro-credentials may differ.