Building an LMS With Certification and Recertification Tracking

What certification tracking looks like once real users touch it

A safety manager opens the compliance dashboard on 3 March and exports the list of forklift-certified operators. In August, an inspector asks for that same list as it stood on 3 March. If your credentials table has an expiry column that gets overwritten every time someone recertifies, the question has no answer. You can produce today's truth and nothing else.

Now the ordinary version of worse. In May the client shortens the recert cycle from 24 months to 12. Someone edits the requirement record. Every operator's expiry recalculates overnight and 400 people are marked expired retroactively, including a dozen who certified under the old rule and had eight months left. Payroll blocks their shifts at 6am. That is not a rare failure. It is the default behaviour of a schema where the rule and the credential live in the same row.

The content standard is a decision, not a checkbox

"We'll support SCORM" hides three incompatible answers, and the one you pick determines whether you can host content on a CDN and whether the system can even tell you someone passed.

• SCORM 1.2 is still what most legacy vendor content ships as. It reports completion through cmi.core.lesson_status, and its suspend_data field is capped at 4096 characters, which real courses overflow, silently losing bookmark state mid-module.
• SCORM 2004 4th Edition raises suspend_data to 64000 characters and adds sequencing and rollup, at the cost of a specification most authoring tools implement partially.
• The deployment trap in both: the run-time environment is a JavaScript API the content discovers by walking the opener and parent chain looking for window.API (1.2) or window.API_1484_11 (2004). That means content must run in a same-origin frame. Push your packages to a CDN on another domain and tracking silently stops while the course still plays, which is the single most common "the LMS (Learning Management System) isn't recording completions" ticket.
• xAPI sends statements to a Learning Record Store and gives you rich data and no verdict. Nothing in xAPI tells you a person is done. Something in your code still has to decide what counts.
• cmi5 is the one to choose for new content, because it defines both launch and an explicit moveOn criterion per assignable unit: Passed, Completed, CompletedAndPassed, CompletedOrPassed, or NotApplicable. That single field is the completion verdict SCORM makes you infer and xAPI makes you invent.

Decide this before the estimate. Supporting SCORM 1.2 and 2004 and cmi5 is three run-times, three test matrices, and it is a real fraction of the build. If your content is all authored in-house, cmi5 alone is defensible and cheaper.

The rules engine is the product

Certification requirements are effective-dated data, not configuration. Store each requirement as a version with a valid-from date, and have every awarded credential reference the exact version it satisfied. When the cycle changes from 24 months to 12, you publish version 2 with an effective date and a transition policy, and version 1 credentials keep their original expiry until they renew. Without that, a rule edit is a retroactive mass expiry.

Then the credential history has to be append-only. Award, renew, revoke, suspend and reinstate are events, and the current state is a projection over them. That is the only structure that answers "who was certified on 3 March" in August, and it is the difference between passing an audit and rebuilding the system after one.

The expiry maths is where requirements meet reality, and every one of these is a decision someone has to make in writing:

• What does the expiry anchor to? Completion date plus 24 months, the end of the birth month, or a fixed organisational anniversary. All three exist in real compliance regimes and they are not the same code path.
• Early recertification. Someone recerts 30 days before expiry. Does the new expiry run from today, or from the old expiry? Anchor from today and you silently shorten every diligent person's cycle by a month, compounding every renewal. Almost every regulated body anchors from the old expiry if you renew inside the window. Pick, and write it down.
• The recert window. "Opens 90 days before expiry" means a completion outside the window is a fresh certification, not a renewal, with a different anchor.
• Grace periods. Is a person in grace certified, or not certified but not blocked? That is a different state, and downstream systems ask about it.
• Equivalency. An external certificate or a prior role counts toward an internal requirement. That is a mapping table plus a reviewer, not a checkbox, and it arrives in month three of every project.

The credential state machine and the notification pipeline

The states worth modelling explicitly: not_started, in_progress, awarded, expiring_soon, in_grace, expired, revoked, suspended. If a vendor shows you a boolean called is_certified, that is the whole review.

Notifications are where this goes wrong operationally. Do not enqueue delayed jobs at award time, because a rule change, an early renewal or a revocation invalidates every queued job and most job runners give you no reliable way to find and cancel one by business key. Run a sweeper that queries credentials falling inside each notification offset (90, 30, 7 days out, then overdue), and dedupe on a key of credential id plus rule version plus offset. Without that key, one re-run after a deploy blasts several thousand people twice, and the second most common consequence is that the client turns notifications off entirely.

Deliverability is a real engineering constraint here, not an afterthought. Certification lists are pulled from HRIS data full of stale addresses for people who left, and a bulk expiry blast to thousands of them spikes bounces. Amazon SES expects bounce rates under 5% and complaint rates under 0.1%, and crossing those puts sending under review, which means the compliance emails stop precisely when you need them. Validate against the HRIS on every sync, suppress hard bounces permanently, and never send an expiry blast from the same identity as transactional login mail.

Evidence, proctoring and the things that happen outside the LMS

Plenty of certifications are not earned by finishing a module. Someone uploads a photo of an external certificate, a supervisor signs off on an observed competency, or a training day happens in a room with no computers. Each of those needs a submission with its own review states (submitted, needs_info, approved, rejected), a named reviewer, a reason, and an expiry that comes from the evidence document rather than the completion date. That workflow is routinely a quarter of the build and is almost never in the brief.

If the credential has real value, someone will ask about proctoring. Integrate a vendor (Proctorio, Honorlock, ProctorU) rather than building it. The work on your side is a session handshake, a results webhook, and a decision nobody wants to make: what happens to an award when a proctoring flag lands after the certificate was already issued. You need the revoke path anyway.

If you plan to issue portable credentials, Open Badges 3.0 aligns with W3C Verifiable Credentials, which means you are signing assertions with a key. Now you own key rotation and a revocation mechanism, because a badge you cannot revoke is a badge you cannot audit. Do not add this in version one unless someone external actually consumes the badge.

Audit trails and regulated environments

If you are in pharma, medical devices, food or aviation, the compliance regime changes the cost shape rather than the feature list.

Under 21 CFR Part 11, an electronic signature must carry the printed name of the signer, the date and time, and the meaning of the signing (review, approval, authorship), and it must be linked to the record so it cannot be excised or copied. That is not a checkbox column. It also means the append-only ledger stops being an architectural preference and becomes a requirement.

The bigger number is validation. A GxP deployment needs IQ, OQ and PQ documentation, a traceability matrix from requirement to test, and a change control process that makes every future release slower. In our delivery experience that adds roughly 30 to 50% on top of the build, and it is documentation and process work, not code.

What this costs and what moves the number

Digital Heroes delivery bands from 2,000+ projects, not market averages.

Focused module inside an existing product: $15,000 to $60,000, roughly 5 to 9 weeks. You already have users, auth, org structure and an admin surface. We add the effective-dated rules engine, the append-only credential ledger, the state machine, the expiry sweeper with idempotent notifications, and audit reporting. Rules in code at the low end, admin-configurable at the high end.

Part of a first release: $50,000 to $130,000 over 10 to 16 weeks. Content playback for one standard, learner UI, admin, assignment rules by role or location, certification and recertification tracking, reporting, and one integration such as an HRIS.

Full platform: $150,000 to $350,000 over 6 to 12 months. Multi-tenant with per-tenant rule authoring, evidence review workflows, proctoring, multiple content standards, verifiable credentials, external reporting integrations, and the operational tooling to run it.

What drives this capability up, in order of impact:

1. Regulated validation. 21 CFR Part 11 or GxP adds roughly 30 to 50%, almost all of it IQ/OQ/PQ documentation and change control rather than features.
2. Per-tenant configurable rules. Rules in code are cheap. A rule-authoring UI that a non-engineer can use without retroactively expiring 400 people needs versioning, preview, an impact report and a dry run. It roughly doubles the rules engine cost.
3. Evidence review workflows. External certificates, supervisor sign-off and offline training each bring their own submission states, reviewer queue and expiry source.
4. Content standard count. Each additional run-time (SCORM 1.2, SCORM 2004, cmi5) is its own player, its own tracking semantics and its own QA pass.
5. External reporting integrations. Pushing completions to a body such as CE Broker, or pulling org hierarchy from Workday or BambooHR, is 2 to 4 weeks each, and the org hierarchy is what your entire reporting model depends on.

When you should not build this

If your need is assigning courses to a few hundred employees and tracking who is out of date, buy. Absorb, TalentLMS, Docebo and Litmos all do assignment, expiry and reporting out of the box, and Moodle with Totara covers the open-source end. If you are already on Workday, Workday Learning is one procurement conversation rather than a project. Any of them is live in about three weeks and none of them will lose you a customer.

The honest test: if certification is an obligation your business carries rather than a thing your business sells, buy it.

Build when one of these is true. Certification depends on data that lives inside your own product, so the requirement is "certified operators can only be dispatched to jobs of type X", and round-tripping through a vendor API costs more than the build. The credential is what you sell, meaning learners pay for the certificate and your brand is on it. Or every tenant defines its own rules, which no packaged LMS models without becoming a consulting engagement.

Middle path most teams miss: buy the LMS for content delivery, build only the credential ledger and rules engine on top, and let the LMS post completions into it via xAPI or a webhook. That is the $15,000 to $60,000 band, and it is usually the right call.

How to brief and vet a developer for this

Bring these answers to the first call, because the estimate is fiction without them. What anchors an expiry: completion date, birth month, or a fixed anniversary. Does an early renewal run from today or from the old expiry. Is there a grace period, and is someone in it certified. What happens to existing credentials when a rule changes. Which content standards you must ingest and who authored them. Whether anything is signed under 21 CFR Part 11.

Then ask these:

• "The client changes the cycle from 24 months to 12. What happens tonight to the people already certified?" You want effective-dated rule versions and a transition policy. "Their expiry recalculates" is the whole answer you need to walk away.
• "An auditor asks who was certified on 3 March. Show me the query." Only an append-only ledger answers this. A current-state table with an expiry column cannot, at any price.
• "Someone recertifies 30 days early. What is their new expiry date?" If they have not thought about it, they will anchor from today and silently shorten everyone's cycle.
• "How does the expiry notification job avoid double-sending after a redeploy?" You want a sweeper with a dedupe key of credential, rule version and offset. Delayed jobs enqueued at award time is the wrong answer.
• "We host course packages on a CDN. Does SCORM tracking still work?" No, not without a same-origin proxy, because the content finds the API by walking the frame chain. Anyone who has shipped SCORM says this instantly.
• "SCORM 1.2 or cmi5, and why?" Listen for suspend_data limits and for moveOn. If they have no preference, they have not shipped either.
• "Show me the credential state machine." Count the states. If revoked, suspended and in_grace are missing, they have modelled a boolean.
• "Where does the expiry date come from when someone uploads an external certificate?" From the document, not the upload date. Silence here means evidence review was never scoped.
• "What's your plan when the HRIS sync brings in 300 dead email addresses?" You want suppression, separate sending identities, and an awareness that bounce rates gate deliverability.

One free filter: ask them to price the module with and without configurable rules. Anyone who quotes the same number for both has not built the configurable version.