How an E-Learning Course Is Built: Tools, SCORM and What Reaches the Platform

The course is ready, it has been paid for, and it arrives as a single zip file with a version number in the name; someone uploads it to the platform, presses save, and the next day it turns out that a hundred and twenty people’s completion records have disappeared, even though nobody deleted anything. That is not a myth and it is not rare, and the platform even warned about it, only the warning appeared for half a second before the button had already been pressed, and it said something that at that moment nobody understood.

This article is about the path from material to package and about what the platform that receives the package does with it, because it is at this handover point that two sides meet who usually cannot see each other’s work. What a learning management system is, and when a company needs one at all, we have written about separately, as we have about how to choose a learning platform. Here the subject is the step that comes after the choice: the course is built outside the platform, packed, and then comes in, and it is in this transition that almost all of the trouble later taken for platform bugs actually arises.

One thing is worth saying first, and it sets this subject apart from most others: almost all of the problems here are documented, named and publicly described, so they do not have to be discovered with your own money. The platform documentation contains the warnings, their causes and the remedies, and the only thing that is usually missing is a person who reads them before the order, not after the first mishap.

What the package contains and what the platform does with it

A SCORM package is a zip archive with a file named imsmanifest.xml at its root, and it is this file that makes the package a package rather than a folder of files. The manifest describes the course structure, lists the learning objects (SCOs) and says which files belong to them, so the platform reads it first and from it learns what to display and in what order.

From there the split is simpler than people usually think, and it is worth saying at once because it explains almost everything else: the platform presents the package and stores data about what a person did in it, but it does not create the content itself and does not interfere with it. Moodle’s documentation says so directly, stating that the system presents the package and saves learning-interaction data, but does not generate SCORM content. So everything that happens inside the screen is the content author’s work, and everything that happens around it is the platform’s work.

Communication between the two runs through a narrow channel, in which the learning object calls the platform’s interface with commands such as initialise, set a value, commit and finish, and through which a handful of values travel: status, score, time, answers to questions and a small text field for saving state. This channel is the most important element in the whole subject, because everything you later want to see in a report has to be sent out through it, and what does not fit there will never reach the report.

What the platform stores is a specific and limited list, tied to one attempt in a particular activity: status, the score obtained together with the minimum and the maximum, time spent, answers to individual questions, and the state field already mentioned. There is no person’s name inside the course, nor how many times they rewound a video, nor which pages they skipped, unless the course itself has turned those facts into one of the listed values.

The failures that arise in this transition are also known and documented, so they do not have to be discovered again, and the most common of them is a missing manifest or one sitting in the wrong place in the archive, because it has to be at the root, not in a subfolder, while the second is identifiers that are not unique, which in the bug-tracking system is a separate ticket. Older courses add display problems on mobile devices, when the content has been placed in a frame of a fixed size, and those too have their own ticket numbers, so a supplier can be asked about them directly.

So the first question for the content author is not about the authoring tool the course will be built with, but about the format in which it will be delivered and what exactly it will report. Two courses that look the same on screen can report entirely differently, and the difference becomes visible only when somebody needs proof that a person really did complete the course.

Four abbreviated names that are not the same thing

The words SCORM, xAPI, cmi5 and AICC are used in the market as if they were interchangeable, but they name different things and they have different maintainers. SCORM is a package format together with a run-time environment, and its last version is the 2004 4th Edition, which came out in 2009; there is no later edition and none is expected.

The organisation that created SCORM has ceased operating, and its repositories now carry a notice that they have been archived, but that must not be taken to mean the standard has been left without a maintainer, because the SCORM run-time data model is maintained by the Institute of Electrical and Electronics Engineers as standard 1484.11.1, whose latest edition is from 2022, and beside it stands 1484.11.2 on the interface. At the same time a detail that misleads is worth knowing: on the organisation’s repository page its name is written as Advanced Digital Learning, although the historic name is Advanced Distributed Learning.

xAPI (Experience API) is something else: not a package format but a statement model and an interface through which a system sends records of what a person did to a separate learning record store. Since 2023 it has been a published standard numbered 9274.1.1, and the same text is also available as an international standard, so this is one thing with two numbers, not two versions.

The fourth name is cmi5, and it is an xAPI profile for launch from a learning platform, not another separate standard; this profile’s current edition is from 2016, and international standardisation is under way but not yet finished, so it is correct to say that the work has been approved as a project, not that the standard already exists. AICC, the Aviation Industry Computer-Based Training Committee, is the oldest of them all, and the committee that maintained it dissolved in December 2014, handing cmi5 and its archive on.

The boundary you need to know before you commission a course

Here is one of the most practically important facts in the whole article, and it surprises almost everyone who hears it for the first time: Moodle supports SCORM 1.2 and AICC, but it does not support SCORM 2004, and that is neither a misunderstanding nor neglect but a deliberate choice, written into the platform’s own documentation and not hidden there. It states that 1.2 passes all the tests in the conformance suite, whereas of the 2004 version only certain basic parts of the interface have been implemented, so some packages can look as if they work even though there is no full conformance.

This boundary matters because content authors often offer the 2004 version as the newest and the best, and formally it is, because it has two separate status fields and a scaled score. For a buyer who will work with Moodle, the newest version nevertheless turns out to be the worse choice, and this is one of the few times when an older edition of a standard is the right answer, not a concession to circumstances.

Next comes a sentence worth reading twice, because it decides how to act from here: work on SCORM 2004 support has been stopped, and bug reports about it are closed as won’t fix. That means some 2004 packages can look as if they work, but you cannot rely on it, and nobody will fix them if they stop working, while the certified path, if the 2004 version is mandatory, runs through a commercial external service with its own plugin.

The practical sequence from that is simple: before you commission a course you tell the content author which format the package is needed in, and in most cases the answer will be SCORM 1.2. If the author offers only the 2004 version, that is not automatically bad, but it changes the choice of platform or requires an extra component, and this conversation has to be had before the work, not on the day of handover. In the case of cmi5 you need to know that Moodle does not include it by default and that it needs a separate plugin, as well as a separate learning record store.

One field that has to hold everything

SCORM 1.2 knows one lesson status field, and it can hold one of six values, which in Moodle’s English interface appear as Passed, Completed, Failed, Incomplete, Browsed and Not attempted. That means you cannot report at the same time that a person went through the course to the end and that they failed the test, because the two things compete for the same field, and for a company that needs exactly this distinction it is a real limitation, not a technical detail.

SCORM 2004 solves this problem by splitting the status into two independent fields, one of which speaks of completion and the other of the result, and by adding a scaled score; that is exactly why some content authors offer it. But because Moodle does not support the 2004 version, this solution is not available to most readers, and instead you have to plan that in place of one course you may need two activities: one for reviewing the material, the other for the assessment.

The second limitation is more specific still: the field in which the learning object stores its internal state, so that a person can continue from the same place, holds four thousand and ninety-six characters in SCORM 1.2, and this limit is also written in Moodle’s data-model file. For a long course with many questions that is little, and when the limit is reached the state simply stops being saved, so the person returns to the start of the course, and it looks like a platform bug, but it is a limit in the standard.

The third limitation is one that can turn a completed course into a failed one without anyone taking part: if a mastery score is set in the manifest, conformance requirements oblige the platform to recalculate the status against the score obtained, and Moodle even offers this behaviour as a separate setting — Mastery score overrides status. A course that reports completion but shows a score below the threshold can therefore appear in the report with the status Failed, and that is documented, not invented.

What disappears when the package is replaced

Now to what this article opened with. If a new package is uploaded over the old one in the same activity and the manifest item identifier differs from the previous one, then the tracking data for that package in Moodle is deleted, and that is written in the documentation in exactly that form; it even says what to do: make sure the identifier is the same.

The platform warns about this, and in the English interface the warning reads, almost word for word: the package seems to be changed or modified, and if the package structure is changed, some users tracks may be lost during update process. The second warning is more direct still and says that the tracking data of this package will be lost. The problem is that both appear at the moment when the upload is already happening, and the person who sees them usually does not know whether the identifier has changed, because that is decided by the content author’s tool, not by them.

From that follow two practical rules worth setting before the first version is handed over, and the first of them is a requirement that the content author keep the same identifier in all later versions and confirm it in writing. The second is a simple check: before upload, open the zip archive, find the manifest file and compare the identifier with the previous one, which takes two minutes and protects against a loss that cannot be undone.

It is also worth understanding where these data live at all, because that explains the rest and answers the next question, which usually follows at once. Attempts and results belong to the platform activity, not to the package, so deleting the activity deletes the results as well, and creating a new activity for the new version means the old completion records stay with the old activity and will not be seen in the new one. That is a usable solution if the old activity is hidden rather than deleted, but then the course completion conditions have to be relinked to the new activity, otherwise the course suddenly becomes incomplete for some people.

The last thing worth knowing about attempts concerns when the platform will offer to start again at all, because that is not the user’s choice but behaviour fixed by the standard. In SCORM 1.2 a new attempt is offered only if the previous one ended with the status Completed, Passed or Failed, whereas in the case of an Incomplete, Browsed or not-yet-attempted attempt the person returns to the same attempt, and a package without its own internal logic simply overwrites the previous score and status.

Around this behaviour the platform has two settings worth understanding before the course is launched, not after the first complaints. One, Force new attempt, forces a new attempt to start, and the other, Lock after final attempt, locks the activity after the last allowed attempt; the attempt-count limit itself works only with SCORM 1.2 and AICC, because the 2004 version has its own separate definition. There is also a reporting subtlety that changes the numbers: the figure for the last completed attempt does not include those that ended with the status Failed, so two reports on the same course can honestly show different numbers.

H5P is a different thing, not an easier SCORM

H5P, short for HTML5 Package, is often named in the same breath as SCORM, and that creates the impression that these are two solutions of the same kind, one of which is simply easier to use. That is not true, and the mix-up costs, because the two are bought in different cases: H5P is a type of interactive content that runs in the browser and is handed over as a separate file, but it uses neither a manifest nor the SCORM interface, and so it reports to the platform differently.

H5P reaches Moodle by three different paths, which must not be mixed because they behave differently, and the first of them is the platform’s own built-in facility with the content bank and a separate activity that is graded and keeps attempts. The second is an older plugin, still installed in many installations, which for some content types handles the grade differently, while the third is a paid cloud service that connects to the platform as an external tool, and its vendor’s forum says outright that you can do without it, because the paid part is extra content types and import options.

Grade behaviour is where unpleasant surprises arise, because in the built-in activity’s attempts report the success column means the person scored 100%, while the completion column means only that they went through the content to the end, and the documentation states clearly that this report is not linked to the activity’s grade to pass or to its activity completion conditions. A company that expects the H5P result itself to fill in course completion can therefore find that the course is formally incomplete for everyone.

There is also a detail about the content types themselves worth checking before you choose, because not every H5P type reports grade and completion in the same way, and there are documented cases where particular types did not set completion and success statements at all, so you have to check exactly the types you plan to use in the course. As to licence, the software is under a permissive licence with an exception for part of the code, but what matters more is that the content you create is not licensed by that automatically, and its licence is chosen by the author.

Course content has its own accessibility requirements

The accessibility question is usually asked about the platform, but most of the answer sits in the content, because that is where videos without captions, images without a description and interactive tasks that cannot be completed from the keyboard live. The platform can be flawless, and the course on it can still be unusable for a person who cannot see the screen or does not use a mouse.

Who is under a duty, rather than a choice, has to be answered precisely, because getting this wrong is easy and expensive. Requirements for public-sector websites and mobile apps are set by Directive (EU) 2016/2102 of the European Parliament and of the Council; for certain private-sector services, Directive (EU) 2019/882 applies from 28 June 2025. A reader’s actual duty comes from that Member State’s own transposing act, which this article does not pick. That does not mean that from that date every company website has to meet an accessibility standard: the directive’s scope is a listed set of consumer products and services, including e-commerce services aimed at concluding a consumer contract, not every site, and Article 4(5) of the directive itself exempts microenterprises that provide services — fewer than ten people, and turnover or a balance-sheet total of no more than €2 million. The United Kingdom is not a Member State, and this article does not treat UK regulations as a substitute; Norway has not taken the European Accessibility Act into the EEA Agreement.

For a company’s internal training a practical consequence follows that does not need a lawyer: if the training is for your own staff, there is usually no direct duty from those directives, because in-house staff training is not, as such, a consumer e-commerce service or a public-sector website. A separate duty to accommodate a particular disabled employee still exists in the reader’s own employment law, and that is a different, personalised question. If the training is sold as a service to consumers online, or if the client is a public body, the requirements have to be checked in earnest and before the procurement, not after it.

On the technical side the requirement usually takes the form of meeting the WCAG guidelines at AA level, and for the content author that means concrete things: captions on video, a transcript for audio, sufficient contrast, text alternatives for images, and a way to complete every interactive task from the keyboard. These requirements have to be written into the order, because adding captions after the course is finished means reworking the video, and that costs as much as it would have cost at the time, only later.

What a package never contains

Importing a package creates one activity, not a course, and this difference explains many later misunderstandings that appear exactly at handover. Everything in the course that sits around the content itself remains on the platform’s side and has to be created separately, however well the package has been prepared and however much it cost.

Specifically the package has no enrolment, so it does not know and cannot know who is allowed to take the course, and it has no course completion conditions, so it does not decide what the platform will count as a completed course. It has no role and permission settings, no gradebook calculation, no certificates and none of the rest of the course content. If a supplier promises to hand over a course, it is worth clarifying whether that means a package or a full course on the platform, because the difference in the volume of work is large.

Video is a separate case that appears on this list almost always, and learning platforms are not video-distribution systems, so large files are usually stored outside them and the course only contains a player, which means the fact of watching the video is not automatically known to the platform and becomes known only if the course turns it into one of the reportable values. A company that expects a report on how long each person watched usually discovers that there is none, because nobody had ordered it.

There is also a question of ownership that sits closer to this subject than it looks: if your subject-matter expert writes the course content and a supplier builds the course, then in the European systems this site writes for the copyright default is the same as for any commissioned work, and it does not mean that payment itself transfers the economic rights to the client. The practical conclusion here is short: the rights in the course, like the source project, need to be written into the contract before work starts.

There is also a boundary with a neighbouring subject that this article deliberately does not touch: the question of how to take a whole course out of one platform and into another is a portability question, and it has its own formats and its own answer, which we have described in the article on what a learning management system is. A package is a unit of one course, not an export mechanism, and mixing the two is expensive.

What to ask before a course is commissioned

All the previous sections lead to a small set of questions worth asking the content author before the contract, because after handover the answers no longer change anything, and the first of these questions is about format: in which standard the package will be delivered and whether that is SCORM 1.2, given that Moodle does not support the 2004 version. The second is about the identifier: whether in later versions the manifest item identifier will stay the same, and whether that can be written into the contract.

The third question is about what the course will report: whether it will set a status, whether it will pass a score, whether there will be a mastery score in the manifest, and what exactly you will see in the report for a person who reviewed the material but failed the test. The fourth is about volume: how much state data the course will store and whether it will fit in the standard field, because a long course with many questions reaches this limit quietly.

The fifth question concerns the source materials and is the one forgotten most often: whether you will also receive the course’s source project, not only the finished package, because without the source the next change can be made only by the same author with the same tool. That is the same question as in any commissioned work, and it has to be asked before work starts.

These questions do not take much time and they offend nobody, because a professional content author answers them at once, but they prevent a situation in which the company has paid for a course and a year later can neither update it nor prove that anyone completed it. If you would like us to have this conversation, or to check a package already received before it is uploaded, write to us, and we will do it together with implementing a learning platform.