Learning and Employment Records: an issuer implementation and data handoff guide
Learning and Employment Records can connect achievements from education, training and work into a portable record. The hard part is not choosing a new file format. It is deciding which source system may make each claim, what the issuer is willing to sign, what the learner controls and how another system can verify the result without receiving unnecessary personal data.
This guide is for registrars, workforce-program owners, credential teams and implementation leads. It covers the issuer-side operating model for building and handing off an LER. It does not certify a product, replace legal review or promise that every receiving system will accept every record.
Short answer: Assign an authoritative source to every learner-record field, issue evidence-backed claims, define learner disclosure and test the complete handoff to the intended verifier.
Short answer
To implement an LER, inventory the records you intend to include, assign an authoritative source and accountable owner to every field, issue only claims supported by evidence, define learner access and disclosure rules, and test the complete issue, transfer, presentation and verification path. Preserve stable identifiers, status information and version history so a verifier can distinguish the current record from an old or corrected one.
What an LER is, and what it is not
Learning and Employment Record is an ecosystem term for portable records of a person’s learning, skills and work-related achievements. A Comprehensive Learner Record, or CLR, is a specific 1EdTech standard that can be used within that ecosystem.
The 1EdTech CLR overview describes CLR 2.0 as a secure, verifiable record for courses, competencies, skills and workplace achievements. A CLR can bundle multiple achievement credentials, including achievements from more than one issuer, while the bundle and its component credentials remain verifiable.
Keep these concepts separate during planning:
| Concept | Primary purpose | Who controls the authoritative record |
|---|---|---|
| Source-system record | Stores the event or evidence that supports a claim | Registrar, LMS, HRIS, assessment or other source owner |
| Digital credential | Makes one bounded, issuer-backed claim | Issuer |
| CLR | Bundles related achievement credentials and associations | CLR issuer, subject to its governance and learner-control model |
| Wallet or host | Stores or presents credentials on behalf of a learner | Learner and service operator under the selected arrangement |
| Transcript | Communicates an institution’s academic record | Institution or registrar |
| Verifiable presentation | Lets a holder present selected credentials to a verifier | Holder, within the capabilities and policies of the system |
An LER is not automatically complete because it contains many records. It is useful when each record has clear meaning, provenance and a verification path.
Decide the use case before choosing fields
Write one sentence describing the decision the record should support. Examples include admitting a learner to an advanced program, recognizing prior learning, screening a candidate for a role or documenting progress through a workforce pathway.
Then identify:
- The person or organization that will use the record.
- The minimum claims needed for that decision.
- The source allowed to create or correct each claim.
- The evidence the issuer must inspect before signing it.
- The period for which the claim remains meaningful.
- The path through which the learner can access and share it.
- The verifier response when the record is expired, revoked, unavailable or unsupported.
This keeps an LER from becoming a general-purpose data dump. The W3C Verifiable Credentials Data Model 2.0 recommends data minimization: issuers should limit credential contents to what expected verifiers require, and verifiers should limit what they request.
Build a record inventory
Do not begin with a list of database columns. Begin with the claims a person may need to reuse, then map each claim back to its authoritative evidence.
| Record class | Example claim | Potential authoritative source | Issuer decision before inclusion |
|---|---|---|---|
| Course or program | Completed a named program | Student information system or LMS | Completion rule, version and completion date |
| Assessment | Met a defined performance threshold | Assessment platform or approved evaluator | Rubric, result, attempt policy and evidence retention |
| Skill or competency | Demonstrated a bounded capability | Approved assessment plus governed skill framework | Skill identifier, level, evidence and mapping version |
| License or authorization | Is authorized for a defined activity | Licensing or compliance system | Jurisdiction, validity period and status-check method |
| Employment milestone | Completed a role, project or supervised experience | HRIS or accountable employer record | Employer authority, dates and disclosure boundary |
| Third-party credential | Holds a credential issued elsewhere | Original issuer’s verifiable record | Whether to embed, reference or exclude it |
Keep unsupported self-reported experience distinct from an issuer-verified achievement. A learner may be able to add context, but a verifier should not mistake that context for a claim signed by the education provider or employer.
Create an authority map for every field
One team should not silently become authoritative for data it merely copies. Use an authority map to show who creates, approves, corrects and discloses each field.
| Field or object | Creates | Approves for issuance | Can correct | Can disclose |
|---|---|---|---|---|
| Learner identifier | Identity source | Issuer identity owner | Identity source under policy | Learner or authorized system |
| Achievement definition | Program owner | Credential governance owner | Program owner through version control | Issuer |
| Completion result | LMS, SIS or evaluator | Authorized program approver | Source owner with audit trail | Learner after issuance |
| Skill alignment | Framework steward or program owner | Credential governance owner | Steward through a new mapping version | Issuer and learner as permitted |
| Evidence reference | Evidence repository | Issuer under evidence policy | Evidence owner | Only under declared access rules |
| Credential status | Issuer system of record | Issuer | Issuer only | Verifier through supported status method |
For each row, record the source identifier, last-updated time and error route. If two systems disagree, the workflow should stop or enter review. It should not select whichever value arrived last.
Preserve identity without oversharing
The issuer must reliably connect a source record to the intended recipient. That does not mean every internal identifier belongs in the portable record.
Define:
- Which identifier links the learner across internal systems.
- Which identifier, if any, appears in the issued credential.
- How name or email changes are handled.
- How duplicate people and merged accounts are resolved.
- What proof is required before a record is reissued to a new account.
- Which personal fields a verifier actually needs.
Use test accounts with synthetic data during integration and acceptance tests. Do not place real learner evidence in screenshots, sample payloads or public technical documentation.
Design for learner control and bounded disclosure
The 1EdTech CLR model is designed for records used, curated and controlled by the learner. Its API supports transport among systems that issue, host and verify records under learner control. Translate that principle into explicit product and policy decisions rather than assuming that portability creates consent.
Document:
- How a learner receives and retrieves the record.
- Whether the learner may select individual credentials or must share a complete bundle.
- What the recipient can see before the learner confirms sharing.
- Whether evidence links reveal grades, work samples or personal information.
- How consent is recorded and withdrawn where applicable.
- What happens if the wallet, host or learner account becomes unavailable.
Avoid adding private evidence directly to a portable record when a controlled reference or an abstract claim is sufficient. The 1EdTech implementation guide has dedicated guidance for privacy, grades and evidence. Apply those controls to the actual program context and governing requirements.
Specify the data handoff
A handoff is successful only when the receiving system can process the record and the verifier can understand the result. Define the contract for each stage.
1. Prepare the achievement
Freeze the achievement definition, criteria, issuer identity and source evidence used for this issuance. Assign stable identifiers and record the relevant schema or standard version.
2. Issue the component credential
Create the learner-specific claim, link the approved achievement and include only permitted evidence. Apply the supported proof and status mechanisms.
3. Assemble the record
Bundle only credentials that have passed the inclusion policy. Preserve the original issuer and proof context for third-party achievements. Do not re-sign another organization’s claim as though your organization created it.
4. Transfer to the learner-controlled destination
Test authorization, recipient selection, error handling and retry behavior. The 1EdTech implementation guide documents issuer, host and API roles for Open Badges 3.0 and CLR 2.0. A standards document defines the exchange model, not the operational support of a particular product pair.
5. Present to a verifier
Test the view a real recipient receives. Confirm that it communicates issuer, achievement, recipient binding, dates, criteria, evidence boundaries and current status without requiring an undocumented manual explanation.
6. Record acceptance evidence
Store the exact test case, payload or object identifiers, standard versions, system versions, result, timestamp and reviewer. A screenshot alone cannot prove a machine-readable exchange worked.
Test failure states, not only the happy path
An integration demo with one valid record is not an acceptance test. Include negative and lifecycle cases.
| Test | Expected behavior | Evidence to retain |
|---|---|---|
| Valid current record | Receiver processes the record and verifier validates supported proofs | Object identifiers, result and verifier version |
| Unknown achievement identifier | Receiver rejects or quarantines it without inventing a label | Error code and review route |
| Recipient mismatch | Record is not attached to the wrong learner | Rejection record without exposed personal data |
| Missing required field | Issuance or import stops with an actionable error | Schema validation output |
| Unsupported version | System rejects safely or uses a documented compatibility path | Version matrix and outcome |
| Revoked or suspended credential | Verifier surfaces the current status under the shared mechanism | Status response and timestamp |
| Corrected credential | New version is distinguishable and the old record follows policy | Old and new identifiers plus change reason |
| Unavailable status endpoint | Verifier returns an indeterminate or policy-defined result, not a false valid result | Timeout result and escalation path |
| Restricted evidence | Unauthorized viewer cannot retrieve the evidence | Access-control result |
The W3C data model provides the credentialStatus property for discovering whether a credential is suspended or revoked. The 1EdTech guide also notes that issuers and verifiers need a common status mechanism. Therefore, “we publish status” and “the target verifier can evaluate our status method” are two separate tests.
Version the record and its source decisions
An LER can outlive the system release that created it. Keep a change record for achievement definitions, skill mappings, source fields, proof methods, schemas and exchange endpoints.
Use these rules:
- A label correction does not silently rewrite the historical claim.
- A material criteria change creates a new achievement version.
- A corrected learner credential is linked to the reason and prior state under the program’s privacy policy.
- A retired source or endpoint has a migration and verifier-continuity plan.
- An imported third-party credential retains its original provenance.
- The issuer can reproduce which source data and policy version supported an issuance decision.
When moving from an older standard version, test existing consumers before removing the old path. The 1EdTech implementation guide recommends establishing a CLR 2.0 API channel with relying parties before removing CLR 1.0 endpoints.
Define operating ownership
Assign names or roles to these responsibilities before launch:
- Program owner for achievement meaning and eligibility.
- Data steward for source quality and identity resolution.
- Issuer administrator for credential templates and issuance controls.
- Security owner for keys, proofs and incident response.
- Privacy owner for disclosure, consent and evidence access.
- Integration owner for transport, monitoring and retry behavior.
- Support owner for learner corrections and access recovery.
- Governance owner for versioning, status and retirement decisions.
Also define service expectations. State how quickly a failed issuance, incorrect identity, status change or inaccessible record must be investigated. An LER program becomes operational when these exceptions have owners, not when the first demonstration succeeds.
Evaluate product fit without assuming conformance
Sertifier’s current public Comprehensive Learner Records page describes CLR use for capturing formal and informal learning, mapping outcomes to skills, tracking progress and integrating with learning and student systems. Use that page to start a product-fit conversation, then verify the exact issuance, exchange, status and verifier workflow required by your program.
Do not infer standards certification, universal wallet compatibility or receiver acceptance from a general feature description. Ask for a test against your selected source system, record design and receiving environment. If your team is still defining the underlying credential, use Sertifier’s verification-ready credential structure guide before assembling a broader learner record.
Issuer acceptance checklist
Before launch, confirm that:
- The target decision and minimum necessary claims are documented.
- Every field has an authoritative source, accountable owner and correction path.
- Achievement, skill and schema versions are preserved.
- Issuer identity, proof and credential status can be evaluated by the target verifier.
- Learner retrieval, control and disclosure behavior has been tested.
- Private evidence is protected and data minimization is applied.
- Third-party credentials retain their original issuer and provenance.
- Valid, invalid, revoked, corrected, unsupported and unavailable cases have passed.
- Monitoring can distinguish issuance, transfer and verification failures.
- The rollback plan preserves audit history and does not erase issued records.
- Product claims are limited to capabilities verified in current documentation or an accepted implementation test.
Evaluate your learner-record workflow
Map your source records, learner controls and receiving systems against Sertifier’s current CLR capabilities.
Frequently asked questions
Is an LER the same as a CLR?
No. LER is the broader ecosystem concept for portable learning and employment records. CLR is a specific 1EdTech standard for verifiable learner records. A program can discuss LER outcomes while evaluating whether CLR 2.0 is the right technical model for its use case.
Can an LER include credentials from multiple issuers?
The CLR standard supports records containing achievements from multiple issuers. Your implementation still needs a rule for preserving the original issuer, proof and provenance and for explaining what the CLR issuer did or did not independently verify.
Should an LER include grades and evidence files?
Only when the use case, permission and risk controls justify them. Prefer the minimum claim and a controlled evidence reference when that satisfies the verifier’s need. Test who can retrieve the evidence after the record is shared.
Who owns an LER after it is issued?
The learner-control model covers use, curation and sharing, while the issuer remains accountable for the claims it issued and their status. Hosting or wallet custody should be defined separately from claim authority.
Does standards alignment guarantee that another system will accept the record?
No. Standards reduce ambiguity, but two systems can support different roles, versions, proof methods, status mechanisms or optional fields. Run an issuer-to-receiver acceptance test and keep the evidence.
How should corrections work?
Define whether a correction creates a new credential, an updated representation or a status change. Preserve the audit trail, prevent both versions from appearing current and tell the learner how the correction affects previously shared records.
