Credentials, Learner Data, and Why Verifiability Matters in EdTech
Credentials, Learner Data, and Why Verifiability Matters in EdTech
Here is something most people have never thought about: almost everything a system knows about what you have learned lives in a database you do not control, and disappears when someone else's contract ends.
Your completion records at a former employer. Your certifications from a training provider that got acquired. The detailed history of what you demonstrated and where you struggled. All of it sits in vendor systems, exportable at best as a PDF that proves nothing.
This community thinks about data ownership and verifiable claims more than most, so the edtech version of the problem is worth laying out — along with the fact that the tooling to fix it already exists and is barely used.
What a certificate actually proves
A PDF certificate proves that someone had access to a PDF generator.
Verification, where it happens at all, means emailing the issuing institution and waiting. Which means in practice it does not happen, which means credential fraud is trivially easy and widely suspected, which devalues genuine credentials for everyone.
The standards that fix this exist. Open Badges carries issuer, criteria, evidence and cryptographic verification in a portable format. The W3C Verifiable Credentials work generalises it — an issuer signs a claim, a holder stores it and presents it, and a verifier checks the signature without contacting the issuer.
The reason adoption is slow is not technical. It is that most platforms have no incentive to make their records portable. A learning record that the learner genuinely owns is one less reason to stay.
The deeper problem: what is actually being claimed
Even a cryptographically verifiable certificate has a content problem.
What does "completed Advanced Data Analysis" mean? It means someone reached the end of a sequence of content. It says nothing about what they can do, when they last did it, or whether they still could.
This points at something more fundamental about how learning platforms store information.
Completion is an event. It happened at a point in time and it never changes.
Knowing is a belief. It carries uncertainty, because it was inferred from limited evidence. It updates as more evidence arrives. And it decays, because people forget things they saw once and never revisited.
Nearly every platform stores the first and implies the second. A credential asserting a completion event is technically true and substantively misleading.
What a better record looks like
A platform that models knowledge properly maintains, per learner per concept, a probability of mastery — sitting on a graph of concepts with prerequisite relationships, updating on evidence, decaying with time.
That produces credentials that can say something meaningful: this person demonstrated mastery of these specific concepts, on these dates, evidenced by these artefacts, with this confidence, last reinforced then.
That is a claim with content. It is also considerably more honest, because it makes visible that a certification from four years ago with no reinforcement since means less than one from last month.
Interestingly, the honest version is more useful to employers, which is the argument for issuing it despite it being less flattering.
Why event logs matter here
There is an architectural point that connects to portability.
Platforms that store only current state — current progress, current score — cannot reconstruct how a learner got there. Platforms that store the interactions as an immutable event log can.
This has an internal benefit: when the mastery model improves, and it will, an event log lets you recompute estimates for existing learners rather than leaving them stuck with the old algorithm forever.
But it also has an ownership benefit. An event log is exportable in a way that a mastery number is not. The learner can take the underlying evidence, not just the platform's summary judgement of it.
The xAPI standard already specifies the format — actor, verb, object, context — and maps almost directly onto an event-sourced architecture. Emitting it natively costs very little when the architecture is already event-sourced, and it makes learner data genuinely portable.
The obstacle is again incentive rather than engineering.
The AI complication
Worth mentioning because it changes the verification question.
Any assessment measuring recall or routine procedure now measures whether the learner had a model available. Which means credentials issued on the basis of such assessments are asserting something they cannot support.
The response that works is not surveillance — proctoring is expensive, invasive and adversarial. It is changing what gets assessed: explanation under adaptive follow-up questioning, application to novel scenarios, critique of flawed work, and evidence captured during the production of work rather than after.
These produce richer evidence, which makes for better credentials, which makes verifiability more worth having. The pieces fit together, which is not usually how these things go.
Where this ends up
Three things, none of them technically hard:
Credentials should be cryptographically verifiable and portable — the standards exist and are well specified.
Credentials should assert capability with a date and a decay, not a completion event.
And learners should be able to export the underlying evidence, not just the summary, which requires an event-sourced architecture and the willingness to emit xAPI natively.
All three are blocked on incentive rather than engineering, which is a familiar shape of problem.
Full technical treatment of learning platform architecture: LMS Development in 2026: Architecting a Learning Platform Around AI. We build these systems — SaaS development.
Frequently Asked Questions
What is a verifiable credential?
A claim signed by an issuer that a holder stores and presents, and that a verifier can check cryptographically without contacting the issuer. Open Badges and the W3C Verifiable Credentials specifications both implement this, and both include issuer, criteria and evidence in a portable format.
Why are PDF certificates inadequate?
A PDF proves access to a PDF generator. Verification requires contacting the issuer and waiting, which in practice means it rarely happens — making fraud easy and devaluing genuine credentials.
What is wrong with credentials based on completion?
Completion is an event: someone reached the end of a sequence. It says nothing about what they can do, when they last did it, or whether they still could. A credential asserting completion while implying capability is technically true and substantively misleading.
How should a credential represent decaying knowledge?
By asserting mastery of specific concepts with dates, supporting evidence, a confidence level, and a last-reinforced timestamp. This makes visible that an unreinforced certification from years ago means less than a recent one — less flattering and more useful to employers.
Why does event sourcing support data portability?
Because an event log records the interactions themselves rather than only a derived summary. Learners can export the underlying evidence rather than the platform's judgement of it, and xAPI maps almost directly onto the event record shape.
How does AI affect credential validity?
Assessments measuring recall now measure whether a model was available, so credentials based on them assert something they cannot support. The fix is changing assessment formats to explanation, novel application, critique and process evidence — which also produce richer evidence for credentials.


Me llamó la atención que el post señala que un certificado PDF solo demuestra que alguien pudo generar el PDF, no la competencia real. También el dato de que los Open Badges incluyen firma criptográfica y evidencias es clave para la portabilidad. La diferencia se nota cuando la verificación ya no depende de un email al emisor 👍