SueSmith edited this page Sep 29, 2014 · 24 revisions

Welcome to the BadgeKit glossary! Below you will find definitions of terms related to badge issuing with the BadgeKit application.

Definitions link to each other, so you can explore the meanings of related terms in a logical way.


In BadgeKit, you can carry out various actions on drafts, published badges and templates, you can:

  • issue the badge by email
  • edit the badge
  • copy the content of the badge into a new draft
  • archive the badge
  • share the badge
  • publish the badge
  • delete the badge. The visible actions are determined by the state of the badge or template you are viewing.


Active is the name given to one of the states a badge can be in in BadgeKit. An active badge is a published badge available for earning.


Earners submit badge applications together with any relevant supporting evidence to demonstrate that they are entitled to the badge. Reviewers assess badge applications, referring to badge criteria. An earner will be awarded the badge if the assessor decides that they meet the criteria.

Archive, Archived

Archived is one of the states a badge can be in in BadgeKit. An archived badge is a badge not currently active or available to earn.

  • Archived badges cannot be earned while they are inactive.
  • In BadgeKit, you can access data related to archived badges and can copy their content into new badges.


An assertion is a JSON-structured representation of the data for a specific badge that has been awarded. An assertion represents a single badge awarded to a single earner - it includes information about:

  • who earned the badge
  • what the badge represents
  • who issued the badge

The assertion for a badge includes various data items required by the Open Badges Specification.

  • Required data items in an assertion include:
  • a unique ID
  • the recipient
  • the badge URL
  • verification data
  • the issue date.
  • Assertions can optionally also include:
  • the badge image
  • an evidence URL
  • an expiry date.
  • See the current assertion specification for full details.

Assessment, Assess

Assessment refers to a badging system in which earners can apply for available badges, submitting supporting evidence. To assess a badge, a reviewer will:

  • Review evidence (when evidence is required) to decide whether an earner has met the criteria for a badge
  • Assessment can sometimes involve a rubric, defined within the badge metadata
  • Reviewers can access badge applications to assess in the BadgeKit application.
  • System admins can determine which applications a particular user has access to in the BadgeKit account settings.


An available badge is one people can potentially earn.

  • Badge issuers can use BadgeKit to create badges they want earners to be able to apply for. In BadgeKit, you can design a badge and define the data within it. When you are ready to make the badge available, you can then publish it from a draft in BadgeKit. In order to provide earners with access to available badges, an issuer can implement a badge listing within their own site using the BadgeKit API.
  • If an issuer decides a badge should no longer be awarded, they can archive it.


Non-technical term for issuing

  • Alternatives include present, confer, grant.


A digital representation of a skill, learning achievement or experience. Badges can represent competencies and involvements recognized in online or offline life. Each badge is associated with an image and some metadata. The metadata provides information about what the badge represents and the evidence used to support it.

  • Earners can display their badges online and can share badge information through social networks.
  • In BadgeKit, badge issuers can create badges, then use the BadgeKit API to present them within their own sites - earners can then choose to apply for the badges.
  • A badge awarded to a specific earner is a badge instance, which is represented as an assertion.

Badge Class

A badge class is a definition of an earnable badge, which may potentially be awarded to one or more earners. When a badge issuer creates and issues a badge in BadgeKit, the badge class is created automatically. The badge awarded to the earner is represented as an assertion, which links to the badge class. The badge class in turn includes a link to the issuer organization JSON for the badge. This makes the data for an awarded badge include information about the earner, the badge itself and whoever issued it.


BadgeKit is a set of tools to make it easier for organizations to work with Open Badges. BadgeKit includes two main components:

  • A Web application to handle various parts of the badge issuing process, including:
  • Creating badges - defining their visual appearance and metadata
  • Controlling badge state - drafting, publishing and archiving badges
  • Providing access to badge applications - letting reviewers assess applications and make issuing decisions
  • Administering user accounts for badge creators, reviewers, assessors and other participants.
  • An API issuers can use when providing interaction with badge earners
  • Issuer sites can use the APIs to provide a front-end interface for badge earners, with BadgeKit providing the back-end processing.
  • The BadgeKit API lets issuer sites respond to events/ state changes that take place in BadgeKit, so that the issuer can customize the experience their badge earning community has, as well as handling the data for their own badge earners.

BadgeKit can be used in two ways:

  • The private beta hosted service at (sign-up has now ended).
  • You can host BadgeKit on your own server - the code is all on GitHub.

Claim code

A code created by an issuer and given to an earner when they earn a badge. The earner can take the code and claim the badge associated with that code.

  • Claim codes can be unique to the earner or multi-use so that many different earners can use a code to claim the same badge.


Earner carries out necessary steps to connect an earned badge to their identity.

  • This would typically involve entering the code into a form, for example on the issuer website.
  • Follows receipt of claim code.


The consumer is someone viewing a badge awarded to an earner

  • Examples could include colleagues, peers and potential employers.
  • Consumers can access the information about a badge which is included in the badge assertion.


A definition of the requirements for earning a badge

  • A badge may be associated with multiple criteria
  • Criteria can be required or not
  • Criteria must be associated with a description and indication of acceptable evidence.


Badges are accompanied by descriptions when they are listed, shared and displayed.


When an issuer creates a new badge, they can configure the data associated with it and its visual appearance.

  • Issuer personnel can configure badge designs within the BadgeKit application or can upload designs prepared elsewhere.


Draft is one of the states a badge can be in in BadgeKit. A draft badge is a saved badge that's not yet active.


An earner meets the criteria to be awarded with a badge, sometimes by submitting evidence.


A person who has met the necessary requirements to earn a badge.

  • Earners apply for badges through issuer sites, their applications can then be reviewed in BadgeKit.


Submitted proof that an earner meets the criteria for a badge they are applying for

  • Can be links, text, images, and other media.


When an assessor decides whether or not an applicant has met the criteria for a badge, they can forward feedback regarding the decision

  • Depending on whether the earner is under 13 or not, the feedback will be a set of pre-canned messages or come free-form.


When a badge is archived it becomes inactive, and can no longer be earned - see also state.


Connect a badge to a person - this is the technical part of awarding a badge to an earner. This may happen when an earner makes a successful badge application. Badges can also be issued by submitting claim codes, or directly by the issuer to the earner email address.

Issuing a badge means creating a badge instance (which is represented by an assertion) for the earner email address.

  • Non-technical term: award
  • Note that in BadgeKit, issuing a badge simply means creating a badge instance for a particular earner email in the data store. BadgeKit will not actually contact the earner at any stage - this is left to issuers so that they remain in control over interaction with their own communities. The BadgeKit API sends data to the issuer webhook when a badge is issued - including a link to the badge assertion.


In Open Badges, an issuer is a person or organization who creates badges and issues them to earners. In BadgeKit, "issuer" is also one of the three admin levels:

  • An issuer belongs to a single system.
  • An issuer can have multiple programs, with each program having multiple badges.

An issuer can use BadgeKit to create badges. The issuer will typically have their own website for interacting with badge earners. This website can communicate with BadgeKit through the API. The issuer site can list available badges and let earners apply for them. Those badge applications can then be accessed and reviewed in BadgeKit. When a badge is issued in BadgeKit, the issuer website can detect this and respond, communicating with the earner.

  • An example issuer could be "Chicago Public Library", within the system "Chicago Summer of Learning" and with multiple programs including "Rahm's Readers".


Optional maximum number of times a badge can be awarded.


Information contained within a badge that defines it


When someone earns a specific set of badges, they can be awarded a milestone badge representing this collective achievement.

  • This allows issuers to acknowledge higher-level experiences and skills. Conversely, a milestone badge allows issuer to create smaller, more granular badges that culminate in this badge.
  • BadgeKit allows issuers to manage milestone badges.


Claim code that can optionally be used to issue a badge to multiple earners.


Each badge has a set of options regarding issue limits, claim codes, time limits and uniqueness - all of these can be specified in BadgeKit.


When an earner applies for a badge, this creates a pending application in BadgeKit. Reviewers can view and assess pending applications, submitting assessment decisions. An application will remain in the pending list until it is marked as processed via BadgeKit API.


Badge issuers can choose to organize groups of badges into programs. A program can include multiple badges grouped in a logical way.

  • A program always belongs to a single issuer.
  • An issuer can have multiple programs.
  • A program can include multiple badges.
  • An example of a program could be "Rahm's Readers" (through the issuer "Chicago Public Library").


Make a draft badge active - this can be done in BadgeKit.

  • Once a badge is active, earners can apply for it
  • Some attributes may not be editable when a badge is in published state.
  • In BadgeKit you can carry out several actions on a published badge.


Earners can re-apply for badges if an initial application is unsuccessful based on the badge criteria.


Assessor considers whether the evidence in the badge application meets the criteria for the badge

  • Sometimes based on a rubric.
  • Reviewers can view badge applications in BadgeKit.

Reviewer, Assessor, Mentor

Person (or software) responsible for checking evidence to see if it meets badge criteria:

  • May involve a rubric
  • Can be Expert/ Peer/ Self/ Algorithmic
  • Reviewers can manage badge applications in BadgeKit.


A tool used to assess badge criteria in a standardized way

  • Aids consistency in review
  • Can also be used to check evidence to see if it meets badge criteria (if the badge requires evidence).


In BadgeKit, a badge is typically modelled as being in one of these states:


A collection of issuers, programs and badges connected by a plan/ goal/ idea:

  • A system can have multiple issuers, with each issuer potentially issuing badges under multiple programs.
  • A server running BadgeKit could cater to one or more systems.
  • An example system could be a city running an education project in which various institutions act as issuers, e.g. "Chicago Summer of Learning" which could include multiple issuers such as "Chicago Public Libary", which could have multiple programs including "Rahm's Readers".
  • BadgeKit users are given permissions for particular systems - users with access to more than one system can toggle between system contexts using the control at the top of the page whenever logged in.


When a badge is created, you can add relevant tags to its description data

  • For the earner, badge tags can aid the process of finding badges to apply for.


A generic badge used to initiate a new draft badge - you can create, edit and use templates in the BadgeKit application:

  • A template can be thought of as the blueprint, cookie-cutter or stencil for a new draft badge, you can use any of the elements within it and can edit it however necessary.
  • Templates make it easier to remix badge elements and to work on badges collaboratively.
  • Templates can include all and only the fields you want to re-use, unlike a finished badge, in which the data must be complete.
  • A template, like a draft, can be saved in any state of completion.
  • When you use a template, BadgeKit creates a new draft badge, which you can then edit.
  • You can share templates between systems, by copying the share URL in the Action section for the template, then copying it into the templates directory for another system.


A badge can be associated with an optional time constraint for earning it.


A claim code can optionally be unique to a single earner.


In BadgeKit, issuers can determine the visuals for a badge by uploading an existing image or designing the badge using a set of standard controls.