Digital credentials for assessment providers: result-to-award workflow
Short answer: An assessment provider should trigger a digital credential only after it can send an authorized result package to the organization allowed to make the award. Keep test content, raw scores, appeals and regulatory authority in the systems that own them.
Short answer
An assessment provider should trigger a digital credential only after it can send an authorized result package to the organization allowed to make the award. That package needs a stable candidate identity, assessment and version, final result state, decision time, accountable authority and correction route. The credential layer can then issue and verify the approved claim without becoming the source of truth for test content, raw scores, appeals or regulatory authority.
This guide focuses on the assessment-to-award handoff. Training providers that also manage learning records should use the separate training-provider credential handoff. Organizations that own qualification authority should use the awarding-body workflow.
Define the assessment provider’s role first
An assessment provider may design an exam, schedule candidates, deliver a test, mark responses, moderate results or report an outcome. It does not automatically own the final award. In some programs one organization controls every step. In others, an assessment partner supplies evidence and a separate certification body, regulator, university or employer authorizes the claim.
The distinction matters because a passed assessment and an authorized credential are related but different records. A result can be provisional, subject to quality review or under appeal. Issuing before the final authority accepts the result creates a claim that the credential system cannot independently justify.
| Role | Record it owns | Decision boundary | Credential responsibility |
|---|---|---|---|
| Assessment delivery | Candidate session, accommodations and attempt | Was the assessment delivered under the approved conditions? | Supplies traceable evidence, not the award |
| Marking or scoring | Responses, rubric, score and marker | What result did the evidence produce? | Reports the result and rule version |
| Quality or moderation | Review, adjustment and exception record | Is the result ready for release? | Blocks provisional or disputed results |
| Awarding authority | Final award decision and policy | Is this organization authorized to approve the claim? | Authorizes the bounded credential |
| Credential operator | Issuance request, status and delivery | Was the approved claim issued correctly? | Creates and maintains the credential record |
Separate assessment, result and credential records
The assessment system may contain questions, responses, proctoring data, raw scores, accommodations, marker notes and appeal evidence. Most of this information should not be exposed in a public credential.
The result record explains the outcome under a named assessment version. The credential record communicates the approved claim to a recipient and verifier. It should contain only the information required to understand and verify that claim.
The 1EdTech Open Badges implementation guide describes an issuer as making a claim that a learner met the criteria for a defined achievement. Its conformance guidance also separates achievement, result, evidence, issuer and recipient properties. That separation is a useful operating model even when the final output is a digital certificate rather than an Open Badge.
Choose the claim from the evidence
The strength of the credential must not exceed what the assessment demonstrates. A knowledge test can support a bounded knowledge claim. It does not automatically establish current workplace authorization or observed performance.
| Assessment evidence | Defensible claim | Additional approval needed | Overclaim to avoid |
|---|---|---|---|
| Attendance check only | Participation | Program participation rule | Completion or proficiency |
| Completed assessment | Assessment completion | Confirmation that all required components were submitted | Passing or certification |
| Valid scored result | Knowledge or result level | Final result release | Applied skill not observed |
| Observed performance with rubric | Bounded applied skill | Authorized review and moderation where required | Broad professional competence |
| Multiple requirements and current authority decision | Certification or authorization | Final approval under the current policy | Permanent permission when status can change |
Sertifier’s public guide to choosing a credential type can support the format decision after the program has defined the evidence and claim. The platform does not decide what an assessment proves.
Build a result package, not a loose trigger
“Candidate passed” is not a complete integration contract. The handoff needs enough context for the award owner to accept, reject or hold the result without guessing which person, exam or rule produced it.
A controlled result package should include:
- a stable candidate identifier and the minimum recipient data needed for issuance;
- the assessment, program and version identifiers;
- the attempt identifier and completion time;
- the result state, score or level when appropriate;
- the criteria or passing-rule version;
- the assessment and quality-review authorities;
- the final release state and release time;
- an idempotency key for the intended award;
- a correction, appeal and reconciliation reference.
Do not use an email address as the only join key when it can change or be shared. Do not send raw assessment evidence to the credential platform merely because the integration can carry it.
Use explicit result states
A binary pass/fail field is rarely enough for operations. Define states that match the real decision path and make only one of them eligible for issuance.
| Result state | Credential action | Required owner | Safe next step |
|---|---|---|---|
| In progress | Do not issue | Assessment provider | Wait for completion |
| Provisional | Do not issue | Marking or moderation owner | Complete quality review |
| Approved pass | Eligible for one bounded credential | Awarding authority | Submit the controlled issuance request |
| Approved non-pass | Do not issue the target credential | Awarding authority | Communicate the result under program policy |
| On hold | Do not issue | Exception owner | Resolve identity, evidence or policy issue |
| Under appeal | Follow the program’s published rule | Appeals authority | Preserve the current record and decision trail |
| Corrected | Update or replace only with authorization | Result and credential owners | Reconcile the old and new records |
For a regulated example, Ofqual’s conditions from marking to issuing results require results to reflect sufficient evidence and describe controls for issuing and correcting results in England. Those rules should not be generalized to every jurisdiction. They demonstrate why moderation, release and correction need explicit owners before a credential is issued.
Select the right issuance connection
A small assessment program can begin with an approved file and a human release check. A stable repeated program may use scheduled automation, an integration or an API. The technical method should follow the governance and volume, not replace them.
Sertifier documents bulk credential creation, credential automation and an API reference. Use only the route that your team can monitor, reconcile and reverse safely.
| Connection | Suitable use | Minimum control | Stop condition |
|---|---|---|---|
| Reviewed file | Pilot or bounded exam window | Approved export, row count and second-person check | Version, identity or result count does not match |
| Scheduled transfer | Repeated batch release | Cutoff, complete-file marker and reconciliation | File is partial or late |
| Workflow integration | Stable event-driven program | Authorized release event and field contract | Event is provisional or missing required fields |
| API | High-volume or multi-program service | Authentication, idempotency, response logging and replay policy | Outcome is unknown or cannot be reconciled |
Prevent duplicate and early issuance
Create an issuance key from stable business identifiers such as program, assessment version, candidate and intended claim. A retry with the same key should return or reconcile the existing result rather than create a second active credential.
The release event must originate from the role authorized to approve the award. A test-completed event, raw score update or payment confirmation is not a substitute. When several components are required, issue only after the program’s aggregation rule has produced one final approved state.
Handle appeals and corrections deliberately
Keep appeals in the assessment or award system that owns them. The credential platform should receive only the authorized effect of the decision.
Define whether an incorrect recipient field can be corrected in place and whether a changed result requires replacement, withdrawal or another action supported by the program and platform. Preserve what changed, who authorized it, which prior record was affected and how a verifier sees the current status.
Never hide a result change by overwriting the source evidence. A correction should be explainable from the assessment decision through to the current credential.
Design the verifier experience
A verifier should be able to identify the issuer, recipient reference, achievement, criteria or scope, issue date and current status. The page should explain the claim without exposing questions, raw responses, accommodations or other unnecessary assessment data.
Sertifier’s public verification page guide explains the product route for displaying credential details. When a regulator, qualification register or separate certification body owns legal or professional status, link the verifier to that authoritative source for the decision it controls.
Test the complete result-to-award journey
Run controlled cases through the real handoff before a live assessment window. A clean pass is only one case. The release must also behave safely when data is late, duplicated, corrected or disputed.
| Acceptance test | Evidence to capture | Pass condition | Accountable owner |
|---|---|---|---|
| Approved result | Source result and release event | One correct credential is issued | Assessment and award owners |
| Provisional result | Blocked issuance record | No credential is created | Quality owner |
| Missing identity field | Actionable rejection | Record stays unissued | Data owner |
| Duplicate submission | Stable issuance key | Existing credential is returned or reconciled | Integration owner |
| Appeal or hold | Current decision state | No unauthorized replacement is issued | Appeals owner |
| Corrected result | Authorization and change trail | Current credential matches the approved decision | Award and credential owners |
| Logged-out verification | Public verification check | Claim, issuer, date and status are understandable | QA owner |
Measure each layer separately
Assessment completion rate, scoring time, moderation backlog and appeals belong to assessment operations. Approved result transfer, issuance success, duplicate prevention, recipient access and verification belong to the credential handoff.
Track at least the count of approved results submitted, accepted issuance requests, blocked records by reason, duplicate requests reconciled, credentials issued, delivery exceptions and credentials successfully verified. Do not treat a credential creation response as proof that the recipient received it or that a verifier understood it.
For acquisition and conversion analysis, keep search visibility, blog engagement, credential activity and qualified pipeline as separate evidence layers. Connect them only when the attribution path is verified.
Use this pre-release checklist
Before enabling a live assessment-to-credential workflow, confirm that:
- Assessment, quality, award, credential and verifier roles are named.
- The credential claim is no stronger than the assessment evidence.
- Candidate, assessment, attempt and rule versions use stable identifiers.
- Only one explicit final state is eligible for issuance.
- The result package includes an accountable release event.
- Duplicate requests return or reconcile the existing credential.
- Holds, appeals and corrections have controlled paths.
- Private assessment evidence stays in its authorized system.
- The verifier can understand the current bounded claim.
- Every tested failure produces a named next action.
Build a controlled assessment-to-award handoff
Map candidate identity, result states, award authority, exception handling and verification before connecting your assessment system.
Frequently asked questions
Can an assessment provider issue the credential directly?
Yes, when the same organization is authorized to make the claim and the final result has passed its required quality and release controls. When another organization owns the award, the assessment provider should supply evidence and an approved result package rather than imply that authority.
Should a pass event issue a credential immediately?
Only when “pass” is the program’s final authorized state. If moderation, aggregation, payment, identity review or another approval remains, the event is provisional and should not trigger issuance.
Should raw scores appear on the credential?
Only when the program has a clear reason, recipient expectation and data policy for publishing them. Often the bounded achievement or result level is enough, while detailed assessment evidence remains private.
What prevents duplicate credentials after a retry?
A stable business-level issuance key, an idempotent integration pattern and reconciliation against the existing credential record. A retry should not create a second active award for the same approved result.
What happens when a result changes after issuance?
Follow the assessment and award policy, record the authorized decision, then apply the supported credential correction or replacement path. The current state and relationship to the previous record should remain explainable.
