Credential earning criteria explain what a person had to do to receive an award. Write them from the program’s approved requirements, using actions a reviewer can understand and an administrator can check. A phrase such as \u201csuccessfully participated\u201d leaves the reader guessing whether the person attended, completed coursework or passed an assessment.<\/p>\n
In Sertifier, Earning Criteria is an optional field in credential details. The official credential details guide<\/a> describes it as the place to explain requirements such as course completion or passing an exam. The wording patterns below are suggested editorial examples, not requirements imposed by Sertifier or claims about a real training program.<\/p>\n A description explains what a program covers. Earning criteria explain what the recipient was required to do. \u201cIntroduction to project planning\u201d describes a topic; it does not say whether the person watched a lesson, submitted a plan or demonstrated a skill.<\/p>\n Keep these questions separate when drafting:<\/p>\n For a wider evidence model, use the skill badge evidence guide<\/a>. Here, the task is to turn an already approved rule into readable credential text.<\/p>\n Try this working structure: To earn this credential, the recipient [required action] for [defined activity or task], meeting [approved completion or assessment rule].<\/strong> Remove any element that does not apply rather than inventing an assessment to fill the sentence.<\/p>\n Choose a verb that matches the source record. \u201cAttended\u201d can describe verified participation. \u201cCompleted\u201d should point to the required activities. \u201cDemonstrated\u201d needs an assessment decision about the stated skill. Avoid substituting impressive language for information the program actually records.<\/p>\n If the program uses a score, threshold or mandatory set of tasks, copy the approved rule accurately. Do not choose a convenient passing score while writing the certificate. If the rule is unclear, return it to the program owner before issuing.<\/p>\n These examples show editing decisions for synthetic programs. Adopt a pattern only when it matches your own approved conditions and available records.<\/p>\n Attendance<\/strong> Course completion<\/strong> Assessed performance<\/strong> The last example would be inappropriate for a program that only records lesson completion. A submission is also not automatically a passing assessment: the rule must say whether submission alone is sufficient or whether the work must meet defined requirements.<\/p>\n Read the draft as someone outside the training team. Replace internal shorthand, undefined level names and phrases such as \u201call requirements\u201d with enough detail to explain the award.<\/p>\n Do not make the public field a transcript of private assessment notes. Explain the common requirement; keep personal scores, assessor comments and sensitive details in the appropriate record system unless sharing them has been specifically reviewed.<\/p>\n Ask the program owner and credential operator to review the same draft. The owner should confirm that it describes the award correctly. The operator should be able to identify the source record used to establish that each recipient met it.<\/p>\n A useful review question is: \u201cCould someone satisfy our sending trigger without satisfying this sentence?\u201d For example, registration may trigger a record in another system, but the credential text may require attendance. Resolve that gap in the approved workflow before sending; changing the sentence is not a substitute for deciding eligibility.<\/p>\n Entering text into an Earning Criteria field should not be treated as proof that an assessment was performed or an automated eligibility check was configured. Verify the actual issuing process separately.<\/p>\n Prepare a synthetic sample and read the title, description and criteria together. Check that they make the same claim. Open any linked rubric or supporting material as the intended reader and confirm that it matches the applicable version. Use the supporting-document link checklist<\/a> for that review.<\/p>\n Keep the approved wording and its program version in your internal record. If the course requirements change later, decide which cohort the new wording applies to before editing issued credentials. Do not silently describe an earlier cohort as having completed new requirements.<\/p>\n Only when the awards share the same requirements. A reusable writing structure is useful; a generic claim that ignores the underlying program is not.<\/p>\n Include enough information to make the conditions clear. A maintained program or rubric reference can provide detail, provided the relevant audience can access the intended version.<\/p>\n Describe the requirement actually used to award the credential. If learning or performance was assessed, explain the relevant assessment rule. If only attendance was verified, keep the wording within that scope.<\/p>\nSeparate the description from the conditions<\/h2>\n
\n
Draft an action, a scope and a decision rule<\/h2>\n
Fictional wording examples<\/h2>\n
Vague: \u201cSuccessfully participated in the workshop.\u201d
Clearer: \u201cAttended the project-planning workshop, with participation confirmed against the event attendance record.\u201d<\/p>\n
Vague: \u201cCompleted all learning.\u201d
Clearer: \u201cCompleted the required project-planning lessons and submitted the final planning exercise.\u201d<\/p>\n
Vague: \u201cProven project-planning expert.\u201d
Clearer: \u201cPrepared a project plan and met the published rubric requirements for scope, dependencies and risk identification, as reviewed by the course assessor.\u201d<\/p>\n<\/div>\nRemove ambiguity before the text reaches a recipient<\/h2>\n
\n
Check the wording against the issuing workflow<\/h2>\n
Review the final credential page<\/h2>\n
Frequently asked questions<\/h2>\n
Can I use the same criteria for every award?<\/h3>\n
Do I need to include every lesson?<\/h3>\n
Should the criteria describe what the person learned?<\/h3>\n
Build a sample before your next send<\/h2>\n