Learning delivery workshop / 5 MIN READ
Keep a new learning session attached to the right enrollment
Prepare a synthetic cmi5 launch-context map that distinguishes enrollment continuity from a fresh session.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-07
A learner returning to an assigned course usually starts another session, not another enrollment. Confusing those identities can split progress across records or attach a later attempt to the wrong assignment even when the learning content itself works.
What you will leave with: Prepare a synthetic cmi5 launch-context map that distinguishes enrollment continuity from a fresh session.
Use this when
- A cmi5 course is integrated with an LMS.
- Repeated launches create confusing learning records.
Not identity inference, credential handling or transport deduplication.
Name the identities before comparing records
The cmi5 Quartz specification, referencing xAPI 1.0.3, distinguishes an enrollment registration from an AU launch session. It defines registration continuity through completion and review, while the LMS supplies a session identifier for a particular launch. This scope was checked on 7 November 2026 and does not describe every standalone xAPI activity.
Create four columns: synthetic learner, assigned course registration, launched assignable unit and launch session. Add the publisher’s unit label as a human-readable cross-reference, not a substitute for the actual launch context. Ask the integration owner where each value originates and how it appears in the authorized test report. Use fictional labels in planning documents; there is no need to copy live launch URLs or authentication material.
Write continuity and separation cases
Start with a learner opening one unit, leaving and returning under the same assignment. State which relationship should remain continuous and which launch should be distinguishable. Then add a second unit within that course and a genuinely new enrollment, such as a later recurrence assigned through the supported LMS process.
The expected map should let a reviewer tell whether a record belongs to the same course assignment, another unit or another session. Do not use a course title alone as the key: titles can be reused or translated. Do not generate a new enrollment identity simply because the learner refreshed a page. Conversely, a deliberately new enrollment must not inherit an old completion merely because the person and course title match.
Trace the supplied context without rewriting it
Have the technical owner inspect sanitized launch and resulting record evidence for the fixtures. Compare the enrollment and unit association before examining the outcome. If a result appears under the wrong assignment, a correct passed label does not make the integration acceptable. Identify the first point where the intended association changed.
Keep the LMS-supplied context under the implementation’s documented contract. Do not ask the content author to invent replacement identities to make reports line up. A launch URL is an operational instruction, not a reusable public bookmark or safe diagnostic attachment. Record only the non-sensitive fixture references needed for the comparison, and let the authorized integration owner manage any access mechanism through the approved process.
Accept reporting at the right level
Review a compact report showing the synthetic learner’s two sessions under one enrollment and the separate recurrence under another. The report should make the grouping understandable without collapsing every launch into one lifetime result or presenting every session as a newly assigned course. Confirm which level the learning administrator uses when answering whether an assignment is complete.
Retain the identity map with the LMS integration version and the cmi5 profile revision. Recheck it when launch construction, enrollment handling or reporting grouping changes. This test does not establish that every statement arrived, that retries execute exactly once or that a learner has gained workplace competence. Its narrow acceptance result is that the course’s launch records remain attached to the intended enrollment and unit while distinct sessions can still be recognized.
Make the reasoning concrete.
A fictional agency assigns the same claims-review course annually. Its integration generates a fresh enrollment label on every launch, so a returning learner’s progress appears as several unfinished annual assignments.
Treat every launch as an enrollment
Opening: Create a new reporting group whenever the content opens.
Hypothesis: Each technical launch is easy to distinguish.
Risk: The administrative assignment becomes fragmented and continuity is lost.
Separate enrollment and session
Opening: Map repeated launches to the assigned registration while keeping distinct session references.
Hypothesis: The administrator can distinguish return visits from a new annual enrollment.
Risk: The integration must preserve the correct context across launch and reporting.
The team validates same-assignment relaunch and genuine reenrollment separately using synthetic records, without copying credentials or rewriting production histories.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Assignment
Which synthetic course registration represents the enrollment?
Unit
Which assignable unit does this launch concern?
Session
What distinguishes this launch from the previous visit?
Recurrence
What evidence establishes a genuinely new enrollment?
Report
Can the administrator see the intended grouping without relying on titles alone?
Watch for the wrong conclusion.
- Creating a new enrollment identity for every page opening.
- Grouping records only by learner and course title.
- Sharing live launch URLs as debugging evidence.
Your next action
Draw the four-column identity map for two sessions in one enrollment and one session in a new enrollment before accepting the integration.
Sources & scope
Workflows, worksheets and fictional examples are original editorial analysis, not supplier implementation instructions or measured business results. Sources support only the specifically attributed platform facts. Supplier controls, contracts and local requirements can change; verify the actual placement and current provider guidance before implementation.
- AICC: cmi5 Quartz specification →Primary platform documentation · Supports: Supports registration/session distinction and LMS-provided session context under Quartz/xAPI1.0.3; the synthetic identity-map workflow is editorial.