A New Answer Key Is a New Scoring Release

A corrected answer key can look like a small editorial change. In a scored test, it is often a change to the scoring system itself.

That distinction matters to organisations running diagnostics, certification checks, internal knowledge tests or assessments that inform a human decision. If an item or its key is edited in a shared bank, a later score may no longer mean what the original score meant. A participant took one test under one set of scoring rules; the report may silently begin describing that attempt under another.

The practical rule is simple: a new answer key is a new scoring release. Historical results should not drift because somebody improved a question bank. They should change only through an explicit, attributable decision to rescore named attempts.

The hidden failure in a shared question bank

The usual before-state is deceptively orderly. Questions live in a shared bank or a spreadsheet. A subject-matter expert corrects wording, adds an answer choice, changes a key or adjusts a score. A quiz pulls questions from that common source. Reports are exported later, often without a durable record of the precise content and key used for each attempt.

This becomes dangerous when the delivery configuration follows the current version by default. Moodle, for example, lets a quiz select an exact question version or use “Always latest.” Its documentation warns that changes in a shared question bank can propagate to usages, while selecting a numbered version prevents subsequent bank changes from appearing in that specific quiz. The product feature is useful; the operating question is whether the organisation has decided which meaning of a score it intends to preserve.

A score is not merely a number. It is the outcome of an item set, a delivery configuration and a scoring key at a point in time. Without that context, teams cannot reliably answer basic questions: Which key was applied? Did an item correction affect this cohort? Can two cohorts be compared? Was a participant’s grade changed, and on what basis?

Treat the test as a released scoring package

The remedy is not to freeze all improvement. It is to distinguish authoring from released delivery. Each published test should receive a release identifier that binds together the selected question versions, scoring key, delivery rules and effective date. A release is the package against which an attempt is scored—not simply the current state of a question bank.

1. Create question and key changes as draft versions. Moodle distinguishes Draft from Ready questions; that separation is a useful operational boundary between work in progress and material eligible for delivery.
2. Require a methodologist to mark a version ready and approve its inclusion in a named test release. The subject expert may propose a correction, but should not silently redefine the interpretation of completed assessments.
3. Bind new attempts to the approved release and its selected question versions, rather than to an unqualified latest version wherever score stability matters.
4. Keep every completed attempt attached to the release actually delivered. For random selection, retain an attempt-level record of the items delivered: Moodle’s random-question slots select from the latest Ready versions, so the pool can otherwise evolve beneath the process.
5. Preserve the release identifier in exports, data warehouses and downstream reports. A release boundary must survive the learning platform if it is to remain useful in analysis.
6. Compare cohorts only within an equivalent release, or display the release boundary plainly. Versioning alone does not establish equal difficulty, fairness or psychometric equivalence.

This design is compatible with the way assessment systems separate concerns. The 1EdTech QTI specification addresses exchange of assessment content and results data among authoring tools, item banks, delivery platforms and scoring systems. It does not prescribe this release process, but its separation of content and results supports keeping a delivered assessment distinct from later authoring changes.

A correction is a regrade decision, not a background update

Sometimes history should change. An answer key may contain a genuine error. A scoring rule may have been applied incorrectly. In those cases, preserving history does not mean refusing correction. It means treating correction as a separate operation with a stated scope and accountable owner.

A controlled regrade has six steps: identify the relevant release and attempt population; select the proposed question and scoring version; calculate the score difference without changing records; have a methodologist review the differences and the rationale; approve or reject the change; and, if approved, preserve the prior score, adjusted score, reason, approver and notification decision.

Moodle provides a concrete example of capabilities that support this pattern. Its regrading workflow can use the newest question version or a specifically selected version, and a dry run can show proposed grade changes before attempts are modified. Those functions create a useful preview. They do not decide whether the proposed version represents an error correction or a substantively different question. That is a methodological judgment.

“Correct history explicitly; never rewrite it implicitly.

Automation can calculate the difference. It cannot define the construct.

Automation is well suited to packaging a release, recording delivered items, calculating score deltas, generating a regrade diff and flagging unusual item-response patterns. Moodle’s statistics report can analyse individual questions and response frequencies. Its documentation also cautions that fairness across variants must be investigated rather than inferred from one aggregate score.

The human boundary therefore remains substantial. A methodologist decides whether a change corrects an error or changes the construct being measured; whether prior attempts should be rescored; whether two releases remain comparable; and how affected participants should be informed. For manually graded responses, expert review remains necessary. A structural change can also make automatic regrading impossible: Moodle notes, for example, that changing the number of choices may leave an earlier response incompatible with the revised question.

The business consequence is less reconstruction, not automatic fairness

This is a workflow design, not an AES deployment or a claim of achieved savings. Its business value is operational clarity. Teams can correct a scoring error without losing the record of what happened before. They spend less effort reconstructing which key was used. Managers receive historical reports whose changes have a named cause rather than an invisible dependency on today’s question bank.

The design has limits. Permissions must restrict access to attempts and results. Downstream exports must carry release identifiers. Randomised assessments need delivered-item records, not just a reference to a changing pool. And not every change should be carried back into history: a more precise question can still be a different question.

For the owner of an assessment process, the next useful exercise is small: take one completed cohort and ask whether the team can reconstruct its exact question versions and scoring key without relying on memory. If the answer is no, the next answer-key correction is already a release-management problem.

Primary sources

• Moodle Docs, Question Bank and Question Banks: https://docs.moodle.org/501/en/Question_Bank and https://docs.moodle.org/501/en/Question_banks
• Moodle Docs, Quiz grades report: https://docs.moodle.org/501/en/Quiz_grades_report
• Moodle Docs, Quiz statistics and random questions: https://docs.moodle.org/501/en/mod/quiz/statistics and https://docs.moodle.org/501/en/question/type/random
• 1EdTech, QTI standard: https://www.1edtech.org/standards/qti/index