Making skills recognition portable beyond one platform

A learner should not lose proof of a skill because the issuing organisation changed vendors. Yet "downloadable" and "portable" are not synonyms. The file might be an image with no credential in it. It might contain a signed claim whose public key disappears when the old vendor closes your account. The skill itself might be described in terms only your own staff understand.

Treat portability as a test that a person outside your organisation can complete, not a feature on a sales page.

Define the handoff before choosing software

Start with one example: a learner earns Validate SQL joins by submitting a query against two related datasets, explaining duplicate rows and passing a review. Six months later, they send the credential to a new employer. The employer should be able to retrieve the original signed credential, check who issued it, see what was assessed, and decide whether that evidence fits the job. They should not need an account on your learning platform.

Four things make that possible: the recipient keeps an original export; another verifier can interpret its format and proof; the issuer's public verification method and relevant URLs stay available; and the achievement is described in language an outsider can use. Open Badges 3.0 provides a standard credential format. It does not keep your DNS, keys, criteria or status service alive for you.

Ask a vendor for an export demonstration using issued credentials, not a catalogue CSV. Check whether the holder can download their own credential without being given everyone else's data. Keep a private inventory mapping achievement IDs to criteria versions, issuer IDs, signing keys and status sources. This is an operational record; it should not become a public recipient directory.

Test exports from both new and old cohorts

A useful export acceptance test is concrete: pick one recently issued badge and one from the oldest cohort. Export both through the mechanism you would have after terminating the contract. Can a new team associate each signed file with the right achievement definition, original criteria version and signing key without opening the old dashboard? If the export gives you badge names but no immutable achievement IDs, ask how historical credentials will be interpreted after a rename. If it gives you images but no signed payloads, request the original credentials before approving the export.

Inventory what still lives outside the file

The signed credential travels with the holder. Some things it depends on may not: a URL used to obtain the public verification method, a DID document, a JSON-LD context, achievement criteria, and a status list if you use one. A file can remain in a recipient's inbox while these dependencies silently break. A cached public key may make one verifier work while a fresh verifier fails.

Put each dependency in a register with owner, URL, last successful outside check and exit plan. Test old signing keys as well as the current one. Rotating the private signing key for new badges should not make older badges unverifiable: the public verification method referenced by each old badge still needs to resolve. A lost or compromised key needs a separate incident plan, including decisions about affected credentials.

Where possible, own the issuer identity and criteria URLs on a domain you control. If the vendor hosts the signing key or status list, make the post-contract service obligation explicit. Ask who can update a revoked entry after termination, how long verification endpoints stay live, and whether you can move them without changing existing identifiers. Do not assume you can simply rewrite a signed issuer URL inside credentials already issued.

Put verification dependencies in the exit agreement

Put those questions in the exit terms, with a named owner on your side too. Specify the format of a full export, how long recipients can download previously issued files, which URLs the vendor will keep serving, and a way to test the obligations before the contract ends. If a third party hosts the keys, ask whether routine rotation preserves verification of older credentials and what happens if the provider fails entirely. A promise to "retain access to badges" is too vague to test: access to a branded dashboard is different from verification of an already issued file.

Publish a narrow, inspectable skill claim

A badge labelled "Data Skills" is hard to use elsewhere. A badge that says "Can detect join duplication in a two-table dataset; assessed through a submitted query and review" gives a hiring manager a question to ask. Limitations improve the claim: a single reviewed exercise does not demonstrate production database administration.

An alignment to a published competency can help another organisation recognise the skill. Point to a specific competency URI, not the homepage of a giant framework. Record which version of the target you used and explain how your assessment maps to it. The alignment connects meanings; it does not outsource your assessment or turn course completion into proficiency.

Write the external-reader test on the back of the badge definition: "What task would you trust this person to attempt, and what would you still need to check?" For the SQL example, a reviewer may be confident the learner can diagnose duplicate rows in a small query. They should not conclude the learner can optimise a large production database. If different people reading the same criteria draw wildly different conclusions, narrow the title or publish the assessment threshold before issuing to a larger cohort.

When no suitable external framework exists, publish a stable definition yourself and version it when the assessed scope changes. Keep old criteria available for old credentials. An employer evaluating a badge issued two years ago should see what was required then, not your current, silently rewritten rubric. The badge design guide covers claims and rubrics in more depth.

Deliver the file in a way recipients can use

The delivery email should contain a genuine download route, a short description of the assessed skill and a link to the criteria. Say plainly that saving the badge picture from a social post is not a reliable way to preserve the credential. Give the learner a sentence they can paste into a profile: "Assessed on identifying duplicate rows in SQL joins using a submitted query and review." That is more informative than an icon.

Sharing also exposes data. An issued credential can include an identifier, dates and links to work samples. Publish generic achievement criteria, not a list of everyone who earned them. Make detailed evidence available only to authorised readers or include a consent-aware description of how it was assessed. Do not put a learner's private work into a public evidence URL merely because the badge supports it.

An employer still has to connect the credential's subject to the person presenting it. A matching name alone is weak; use the issuer's supported process for an email, hashed identifier or holder-controlled key if the decision needs stronger assurance. Keep the matching procedure separate from the public skill description.

Run a platform-exit drill while the vendor still answers calls

Take a real test credential out of the issuing system, log out, and validate it from a separate machine with an independent validator. This is the same file a learner receives, not an admin preview. The validator's file upload is a useful starting point; a screenshot or flattened badge image cannot prove that the original export works.

Then check the issuer key URL or DID, the original achievement criteria and any configured status source. Repeat with an older credential signed before your most recent key rotation. If revocation is part of your programme, test a revoked sample too. Record which dependency failed, who owns it and when the fix was retested. An offline dashboard is not the same thing as an offline public key; test the specific vendor services you intend to leave.

Ask procurement to attach that drill to the contract: full-fidelity export, recipient delivery, verification-method hosting, status continuity, and what happens at the end of the agreement. If the vendor cannot let you test those commitments before launch, reduce the scope of the programme until you can.

What if the drill fails after badges are already issued?

Do not conceal the failure behind a new badge design. First identify its reach: which cohorts share the broken key, issuer identifier, criteria URL or status service? Preserve examples of both working and failing credentials. Repair the external dependency where you can, then rerun an independent check against an affected older badge. If old credentials cannot be restored, tell holders what stopped working and provide a replacement path with the issuer. Reissuing creates a new credential; it does not silently repair the signed bytes people already saved.

For each incident, record an owner, the number of affected recipients, a remediation date and a recipient message. This is especially important when a public badge appeared to verify yesterday. Technical failure has a human cost when somebody needs to present that badge for a job or a licence today.

Portability does not force an employer to value the skill. It gives them a checkable account of who made the claim and what was assessed. The Open Badges and verifiable credentials guide explains the signature model; the programme management guide covers ownership after you scale.