A Course Review Needs Three Artifacts, Not One

Sending everyone the same course file mixes three decisions: whether the explanations are correct, whether the learner experience works and whether the agreed source material is covered.

In an anonymised technical-financial module delivery, stakeholders received a gamified course, a full-text export and a source-coverage review. They could inspect explanations without entering the CMS and see which operational details were deliberately outside the educational scope.

Plain text isolates the explanation

The plain-text artifact should preserve every explanation, example, question, answer and feedback message, including alternative branches. It removes presentation, not substance.

For SME course review, the question becomes precise: does this explanation preserve the product’s meaning? Stable lesson and block IDs let reviewers flag an ambiguous term or missing condition without describing where they clicked.

The rendered course exposes the experience

The learner-facing artifact carries a different review job: sequence, visual hierarchy, mobile layout, quiz behaviour and feedback timing. GOV.UK’s guidance favours working prototypes for realistic interaction testing, rather than relying on static representations.

For a gamified financial module, reviewers should inspect whether a reward interrupts an important explanation or a visual implies something the text does not. Stakeholder approval still is not evidence of learner understanding; usability testing observes people attempting relevant tasks.

Coverage makes omissions reviewable

The source coverage matrix connects supplied documentation to learning content. It adapts the traceability principle described in NASA’s systems engineering guidance: a reviewer can follow an output back to its source and inspect the relationship.

Each source item needs a location and version, a disposition, a destination where applicable, and a reason.

• Included means the course directly represents the material.
• Transformed means it becomes an explanation, example or assessment.
• Deferred means it belongs in a later learning stage.
• Excluded means it sits outside the agreed educational scope.

For example, an internal administration procedure might be excluded from customer onboarding. A condition essential to understanding the product should not disappear under the same label.

One course model owns all three outputs

Three manually maintained files would create another reconciliation job. The architectural precedent is single-source publishing in the OASIS DITA standard, which separates content from presentation and supports multiple deliverables.

The proposed course review workflow applies that principle to lessons, interactions, source mappings and scope decisions. All exports carry the same revision. For App-Learning, the architectural goal is to make these first-class authoring outputs, not documents assembled afterwards.

Review ownership follows the question

Learning content QA needs named decision owners, not identical assignments for everyone.

• Product specialists own factual and conceptual accuracy.
• Design and learning reviewers own flow and interaction quality.
• The product lead owns scope decisions and unresolved trade-offs.

Everyone can access all three artifacts. The assignment defines their primary responsibility, not a boundary around what they may notice.

Approval belongs to a version

Each course content review finding should become a change request with an artifact revision, content ID, issue, owner and resolution. Accepted changes update the model before regeneration and targeted re-review. An LMS approval workflow should record which revision was accepted, by whom and with which open exceptions.

The point is not more review paperwork. It is a review system in which correctness, experience and scope remain distinct but connected. Approval then means something more precise than everyone having seen the course.