{"id":19884,"date":"2026-09-17T22:32:59","date_gmt":"2026-09-17T22:32:59","guid":{"rendered":"https:\/\/sertifier.com\/blog\/?p=19884"},"modified":"2026-09-17T22:32:59","modified_gmt":"2026-09-17T22:32:59","slug":"learning-employment-records-issuer-implementation","status":"publish","type":"post","link":"https:\/\/sertifier.com\/blog\/learning-employment-records-issuer-implementation\/","title":{"rendered":"Learning and Employment Records: an issuer implementation and data handoff guide"},"content":{"rendered":"

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.<\/p>\n

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.<\/p>\n

\n

Short answer:<\/strong> 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.<\/p>\n<\/div>\n

Short answer<\/h2>\n

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.<\/p>\n

What an LER is, and what it is not<\/h2>\n

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.<\/p>\n

The 1EdTech CLR overview<\/a> 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.<\/p>\n

Keep these concepts separate during planning:<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n
Concept<\/th>\nPrimary purpose<\/th>\nWho controls the authoritative record<\/th>\n<\/tr>\n<\/thead>\n
Source-system record<\/td>\nStores the event or evidence that supports a claim<\/td>\nRegistrar, LMS, HRIS, assessment or other source owner<\/td>\n<\/tr>\n
Digital credential<\/td>\nMakes one bounded, issuer-backed claim<\/td>\nIssuer<\/td>\n<\/tr>\n
CLR<\/td>\nBundles related achievement credentials and associations<\/td>\nCLR issuer, subject to its governance and learner-control model<\/td>\n<\/tr>\n
Wallet or host<\/td>\nStores or presents credentials on behalf of a learner<\/td>\nLearner and service operator under the selected arrangement<\/td>\n<\/tr>\n
Transcript<\/td>\nCommunicates an institution’s academic record<\/td>\nInstitution or registrar<\/td>\n<\/tr>\n
Verifiable presentation<\/td>\nLets a holder present selected credentials to a verifier<\/td>\nHolder, within the capabilities and policies of the system<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

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.<\/p>\n

Decide the use case before choosing fields<\/h2>\n

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.<\/p>\n

Then identify:<\/p>\n

    \n
  1. The person or organization that will use the record.<\/li>\n
  2. The minimum claims needed for that decision.<\/li>\n
  3. The source allowed to create or correct each claim.<\/li>\n
  4. The evidence the issuer must inspect before signing it.<\/li>\n
  5. The period for which the claim remains meaningful.<\/li>\n
  6. The path through which the learner can access and share it.<\/li>\n
  7. The verifier response when the record is expired, revoked, unavailable or unsupported.<\/li>\n<\/ol>\n

    This keeps an LER from becoming a general-purpose data dump. The W3C Verifiable Credentials Data Model 2.0<\/a> recommends data minimization: issuers should limit credential contents to what expected verifiers require, and verifiers should limit what they request.<\/p>\n

    Build a record inventory<\/h2>\n

    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.<\/p>\n

    \n\n\n\n\n\n\n\n\n\n\n
    Record class<\/th>\nExample claim<\/th>\nPotential authoritative source<\/th>\nIssuer decision before inclusion<\/th>\n<\/tr>\n<\/thead>\n
    Course or program<\/td>\nCompleted a named program<\/td>\nStudent information system or LMS<\/td>\nCompletion rule, version and completion date<\/td>\n<\/tr>\n
    Assessment<\/td>\nMet a defined performance threshold<\/td>\nAssessment platform or approved evaluator<\/td>\nRubric, result, attempt policy and evidence retention<\/td>\n<\/tr>\n
    Skill or competency<\/td>\nDemonstrated a bounded capability<\/td>\nApproved assessment plus governed skill framework<\/td>\nSkill identifier, level, evidence and mapping version<\/td>\n<\/tr>\n
    License or authorization<\/td>\nIs authorized for a defined activity<\/td>\nLicensing or compliance system<\/td>\nJurisdiction, validity period and status-check method<\/td>\n<\/tr>\n
    Employment milestone<\/td>\nCompleted a role, project or supervised experience<\/td>\nHRIS or accountable employer record<\/td>\nEmployer authority, dates and disclosure boundary<\/td>\n<\/tr>\n
    Third-party credential<\/td>\nHolds a credential issued elsewhere<\/td>\nOriginal issuer’s verifiable record<\/td>\nWhether to embed, reference or exclude it<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

    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.<\/p>\n

    \"Source<\/a>
    Assign each field to the role allowed to create, approve, correct or disclose it.<\/figcaption><\/figure>\n

    Create an authority map for every field<\/h2>\n

    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.<\/p>\n

    \n\n\n\n\n\n\n\n\n\n\n
    Field or object<\/th>\nCreates<\/th>\nApproves for issuance<\/th>\nCan correct<\/th>\nCan disclose<\/th>\n<\/tr>\n<\/thead>\n
    Learner identifier<\/td>\nIdentity source<\/td>\nIssuer identity owner<\/td>\nIdentity source under policy<\/td>\nLearner or authorized system<\/td>\n<\/tr>\n
    Achievement definition<\/td>\nProgram owner<\/td>\nCredential governance owner<\/td>\nProgram owner through version control<\/td>\nIssuer<\/td>\n<\/tr>\n
    Completion result<\/td>\nLMS, SIS or evaluator<\/td>\nAuthorized program approver<\/td>\nSource owner with audit trail<\/td>\nLearner after issuance<\/td>\n<\/tr>\n
    Skill alignment<\/td>\nFramework steward or program owner<\/td>\nCredential governance owner<\/td>\nSteward through a new mapping version<\/td>\nIssuer and learner as permitted<\/td>\n<\/tr>\n
    Evidence reference<\/td>\nEvidence repository<\/td>\nIssuer under evidence policy<\/td>\nEvidence owner<\/td>\nOnly under declared access rules<\/td>\n<\/tr>\n
    Credential status<\/td>\nIssuer system of record<\/td>\nIssuer<\/td>\nIssuer only<\/td>\nVerifier through supported status method<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

    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.<\/p>\n

    Preserve identity without oversharing<\/h2>\n

    The issuer must reliably connect a source record to the intended recipient. That does not mean every internal identifier belongs in the portable record.<\/p>\n

    Define:<\/p>\n