Managing a badge programme once it stops being small

The first dozen badges belong to one team. At eighty, somebody needs to know which version of the assessment last year's recipients took, why two badges have almost identical names, and whether a signing key from the old platform still resolves. These are tractable questions if the answers exist outside one administrator's memory.

Build a catalogue you can export

Before choosing another platform feature, export your badge definitions into a simple register. Keep one row per achievement version, not just one row per badge image. Include its stable identifier, claim in plain language, owner, issuer identity, criteria and rubric version, whether it is still being issued, last issuance date, next review date, and a link to a test credential. Keep the source file somewhere your organisation can access after a vendor change.

Open the example catalogue record at full size.

If a field is currently blank, the catalogue has already found useful work. An owner should be a person or maintained team role with a named backup, not a department with no inbox. Add the approval date and a link to the decision record if your badges affect hiring, licensing, or credit. Track published URL ownership separately from platform ownership: a platform migration should not accidentally delete the criteria pages linked from old credentials.

A workable creation rule fits on one page: the kind of claim that merits a badge, what assessable criteria look like, how names are formed, where evidence belongs, who approves, and what needs a new version. Place that rule next to the badge creation form, not only in a policy wiki.

Stop near-duplicates at intake

Before approving a proposal, compare it with the catalogue on claim, evidence, and assessment. Suppose a unit requests "Advanced Data Analyst" while another already issues "Data Analysis Project." If both certify the same project against the same rubric, changing the icon or name creates confusion, not a new capability. If the proposed badge requires a different assessed task, spell out the difference in its public criteria.

Open the duplicate-decision example at full size.

Have a reviewer from outside the proposing team read both badge descriptions without being told which is new. If they cannot say what extra work earns the proposed badge, return it for revision. Record a rejection or consolidation in the register so the same suggestion does not restart from scratch next term. This small intake step works better than a yearly cleanup of two hundred overlapping badges.

Version the claim, preserve old criteria

A new colour, typo fix, or clearer explanation of an unchanged assessment rarely needs a new achievement. A changed pass threshold, additional required task, or different assessor may change what holders actually demonstrated. Make a new achievement identifier or immutable criteria version for that cohort, and record which version each credential asserts. Do not silently replace a page saying "three assessed tasks" with one saying "four" when existing badge holders only completed three.

Open the cohort-version example at full size.

When a badge stops being issued, leave its old definition and rubric readable. If a domain must change, preserve the old path with a permanent redirect to the same historical criteria, not to the current version's requirements. Save a snapshot of the decision and assessment standard for each cohort. A relying party should be able to understand a 2024 credential in 2030 without asking which version of a live page was visible six years earlier.

If your issuing system does not support versioned definitions, publish versioned criteria pages under stable organisational URLs and attach the version identifier to your internal issuance record. Check the actual exported credential to see which identifier or URL the verifier will read. A version label in a spreadsheet alone does not repair a credential that points to a mutable claim.

Keep definition state separate from credential state

Retiring an achievement means stop issuing new credentials against it. It does not make past earners dishonest or invalidate what they earned. Revoking a credential means withdrawing a specific issued claim. Expiry means its defined period of validity ended. Suspension, where supported by the issuer's status mechanism, is a temporary state under your policy.

Open the two-lifecycle diagram at full size.

Put the change types in the support runbook, with an approval path for each. A course redesign triggers a new definition and retirement of the old one. A duplicate award to the wrong recipient triggers investigation and potentially revocation of that credential. A required annual renewal triggers a new issuance process and a clear expiration date, not an unexplained revocation of an earned badge.

Open Badges 3.0 can include a credentialStatus reference to mechanisms such as the W3C Bitstring Status List. If withdrawal must be possible, configure status before you issue your first cohort; adding a status pointer to existing signed copies requires reissuing them. Write down who can authorise a withdrawal, who informs the holder, what is logged internally, and what a public verifier will actually see. Avoid publishing private allegations as a status reason unless you have a specific legal and privacy basis.

Keep verification working through migrations

Signing-key rotation and platform migrations are two of the few operational changes that can break every historical badge at once. Inventory each key or verification method: who controls it, where its public material is published, when it was used to issue credentials, and where a credential signed with it can be found for testing. After rotation, issue new badges with the new key while keeping the old public verification method available for earlier badges.

Open the signing-key register at full size.

Plan the migration in this order: export the catalogue and sample credentials, identify issuer IDs and old criteria URLs, verify the destination can serve the same historical resources, change the issuance path, then test both a newly issued badge and a badge signed years ago in an independent validator. A green result for the new badge does not establish that old keys or status URLs survived the move. If the old private key has been compromised, do not treat this as routine rotation; follow an incident plan and assess the affected credentials.

Ask your platform vendor a concrete exit question: "If we stop paying next year, which issuer profiles, historical criteria pages, public keys, and status lists will remain available, at what URLs, and for how long?" Get an answer in writing before you depend on hosted URLs for multi-year credentials. Exporting a CSV of recipients alone is not enough to preserve verification.

Replace vanity numbers with an operations cadence

Issuance volume is useful for capacity planning, but it does not tell you whether anyone can check the credentials. Set a small schedule with a named owner and a place to log failures:

Open the operations-cadence diagram at full size.

• Weekly: independently check at least one newly issued credential from each active export path (email, platform download, and public link if you provide all three). Record format, proof, status result, and broken external resources. If a check fails, assign a person and a deadline.
• Monthly: review badges with zero issuance, unexpectedly high issuance, or a sudden increase in support complaints. Check new proposals against the register before approving them. A badge with zero issuance may be intentionally seasonal; ask the owner before retiring it.
• Quarterly: test one historically issued badge from an old signing key, a disposable revoked credential, and the criteria URLs for retired versions. Confirm owners and review dates. If the status service is offline, treat the outage as a verification incident, not just a broken dashboard.

Measure failure rates with a denominator: "3 of 40 sampled exports failed proof checks" gives somebody a fixable problem; "three errors this month" does not. Track how long broken verification remains unresolved and which export path produced it. Recipient acceptance and social shares can be interesting, but neither makes a credential more verifiable. If the programme has multiple teams, publish a short internal report listing the decisions taken, not just the number of badges created.

Run a 30-minute quarterly review

Pull the register, overdue review dates, sample validation reports, and the key inventory into one meeting. Ask the owner of each overdue badge whether the assessment still matches its published criteria. Decide which proposed badges are duplicates, which definitions need new versions, and who will fix failed proof, key, criteria, or status checks. Close with a dated list of changes, responsible people, and a retest date.

If the register is incomplete, start with your ten most-issued badges, then the oldest live ones. That order protects the most recipients while exposing historical failures. For help writing claims and criteria that outside readers can interpret, see designing badges people can understand.