AI SCORM quiz generator: how scores and answers reach your LMS
Your quiz works in the browser. Learners answer every question, the summary screen shows a percentage, and the LMS gradebook stays empty. The cause is structural: building an assessment and reporting its result are two separate jobs, and only the second one writes the SCORM fields a gradebook reads.
LMSable splits the work along that line. An AI assistant, ChatGPT, Claude, Gemini or Microsoft Copilot, writes the questions, answer options and feedback from a copy-and-paste prompt and returns them as structured JSON. LMSable checks that JSON, lets you edit every question, then builds the quiz and the SCORM 1.2 package on its own server. A fixed player inside the package calculates the final percentage, writes SCORM 1.2 data and commits it to the LMS.
The reporting path from a click to an LMS report
The data flow is short. A failure at any step can leave the gradebook with an incomplete record:
Learner selects an answer
|
v
Quiz records response and correctness
|
v
SCORM player writes cmi.interactions.n.*
|
v
Quiz sends the final score
|
v
Player writes the percentage and passed or failed status
|
v
Commit sends the values to the LMS
SCORM communication happens through a JavaScript API that the LMS exposes in the launch window, described in the SCORM run-time reference. That is why opening index.html directly cannot test reporting: outside an LMS player, there is no SCORM API to receive the calls.
Layer 1: the course score and status
For a SCORM 1.2 quiz, the fields most LMS gradebooks understand are:
| Field | Example | Purpose |
|---|---|---|
cmi.core.score.raw |
75 |
The raw score, here on a 0 to 100 scale, so it reads as a percentage |
cmi.core.score.min |
0 |
Lower bound of the score scale |
cmi.core.score.max |
100 |
Upper bound of the score scale |
cmi.core.lesson_status |
passed |
Final status against the pass mark |
cmi.core.session_time |
0000:07:42.50 |
Time in the current launch session |
LMSable calculates round(correct answers / questions * 100) and clamps the result to the 0 to 100 range. It compares that percentage with the pass mark selected before export, then writes passed or failed.
The pass mark also appears as adlcp:masteryscore in imsmanifest.xml. The runtime still writes the final status itself because LMS implementations differ in how they apply the manifest threshold. Moodle exposes a separate Mastery score overrides status setting, which shows why relying on one path can produce different results between installations.
Layer 2: one interaction record per answer
A score of 60 percent tells you how the learner performed. It does not tell you which concept caused the failure. SCORM's cmi.interactions collection can carry that detail.
For each answer, the current standalone quiz exporter writes:
id, containing a stable question identifier and a shortened question label;type, currently set tochoicefor every question;time, recording when the response occurred;weighting, set to1for an ordinary question;student_response, containing the learner's answer;result, usingcorrect,wrongorneutral.
The player also fills in correct_responses.0.pattern when the question has a correct answer. How much of this your LMS shows depends on the platform, so check one test attempt in its reports before you rely on them.
SCORM 1.2 does not define cmi.interactions.n.description, so the package cannot rely on that later SCORM 2004 field. LMSable places a shortened question label in the interaction ID instead. The exact presentation still depends on the LMS report.
One property of SCORM 1.2 explains most of the confusion around interaction reports: the cmi.interactions collection is write-only. Content can send responses to the LMS but cannot read them back, and the standard does not require the LMS to display them anywhere. Two platforms can receive byte-identical data while only one shows a question-level report. If your interactions appear to vanish, check what the LMS exposes before assuming the package failed to send them.
Why the AI returns questions, not HTML
The AI never writes the quiz page itself. It returns the questions as JSON: the question text, the type (single choice, multiple choice or true/false), the answer options with the correct ones marked, and optional feedback. LMSable validates that JSON against a fixed schema. If the answer does not match, it is rejected before anything is built, and you can ask your chat to correct it.
From the validated questions, LMSable renders the quiz HTML with its own code. The quiz runs inside an iframe in the package and, after the summary screen appears, sends a defined completion message with the score to the surrounding player.
The player, not the quiz, converts that score into SCORM calls. Because the same code builds every quiz and the same player reports it, the reporting does not depend on an AI assistant reproducing an LMS integration correctly in every answer.
The player accepts the first complete event and then terminates the SCORM session. A retry shown after the summary cannot replace that recorded score. If the quiz offers retries, decide whether they occur before final submission or as a new LMS attempt.
Build an assessment the LMS can interpret
Before generating questions, define:
- one measurable learning objective;
- an exact number of questions;
- the allowed question formats;
- the source material the answers must follow;
- a passing score from 0 to 100;
- whether the learner may retry;
- what feedback appears after each answer and at the end.
The AI Quiz Generator creates a prompt with the selected question count and pass mark. Paste it into ChatGPT, Claude, Gemini, Microsoft Copilot or another assistant, then paste the returned JSON back into LMSable. The generator checks every question against the schema, opens the questions in an editor where you can fix the wording and the correct answers, and shows a preview before you create the package.
Test the package, not only the preview
The browser preview checks layout and question logic. Reporting can only be checked in an LMS or in SCORM Cloud, using two controlled attempts with a known answer pattern: one result above the pass mark and one below it. After each attempt, confirm that the grade equals the expected percentage, that the status moved from incomplete to passed or failed, and that the detailed report holds one interaction per answer with the response you actually selected. The complete attempt script and release checklist are in the guide on how to test a SCORM package before publishing it.
One caution is specific to this exporter: do not rely on the interaction report to reveal the correct answer after a wrong response.
Moodle's current SCORM report includes basic, graph, interactions and objectives views, reached through the activity's Reports screen as described in the guide to uploading SCORM to Moodle and verifying completion tracking. Its Using SCORM guide also notes that tracked details depend on what the package sends. Other LMSs may store the same interaction data but expose it only through an administrator report or export.
Common reasons a grade stays empty
Start with the first failing layer:
| Symptom | Likely check |
|---|---|
| Quiz works only in preview | Launch the ZIP from a SCORM activity, not as local HTML |
| LMS stays on incomplete | Confirm the final complete event fires after submission |
| Status appears but score is blank | Check writes to cmi.core.score.raw, min and max |
| Score appears but answers do not | Check cmi.interactions writes and the LMS interaction report |
| Data disappears after closing | Check LMSCommit and a single LMSFinish call |
| Correct attempt gets marked failed | Compare the runtime threshold with the manifest and LMS mastery settings |
Do not change five settings at once. Use a known answer pattern, inspect the runtime log and correct the first missing value.
Create a scored SCORM 1.2 quiz and test the exported ZIP with a learner account before assigning it to a cohort.