Understanding sequencing concepts is one thing.
⚙️ Implementing them correctly is another.
SCORM 2004 does not just define structure.
It defines rules that control behavior at runtime.
These rules determine:
- What the learner is allowed to access
- What happens after an activity
- How navigation decisions are made
They are the execution layer of sequencing.
🧩 The Three Core Rule Types
Pre, Post, and Exit
SCORM 2004 sequencing is built around three primary rule types:
- Precondition rules
- Postcondition rules
- Exit rules
Each operates at a different moment in the activity lifecycle.
Understanding when they trigger is just as important as understanding what they do.
🚫 Precondition Rules
Access Control Before Attempt
Precondition rules are evaluated before an activity is attempted.
They determine whether the learner is allowed to enter the activity.
Example:
- If a prerequisite is not completed → disable the activity
- If a condition is met → skip the activity entirely
These rules enforce structure.
They are often used for:
- Locking content behind prerequisites
- Preventing premature access
- Skipping optional or conditional modules
If preconditions are misconfigured, learners may never reach certain activities.
🔁 Postcondition Rules
What Happens After Attempt
Postcondition rules are evaluated after an activity attempt is completed.
They control what should happen next.
Example:
- If an activity is failed → move to remediation
- If passed → continue to the next activity
- If completed → exit the cluster
These rules define progression logic.
They often interact with:
-
success_status -
completion_status - Objective satisfaction
If postconditions are incorrect, navigation may appear inconsistent or unexpected.
🚪 Exit Rules
Behavior When Leaving an Activity
Exit rules are triggered when leaving an activity.
They influence how the system handles transitions.
Example:
- Force exit if a condition is met
- Prevent exit until requirements are satisfied
- Redirect navigation based on state
These rules are less commonly discussed, but they are critical in controlling edge cases.
They ensure that transitions respect defined constraints.
🔗 Conditions That Drive Rules
Sequencing rules rely on conditions derived from the data model:
-
completion_status -
success_status - Objective satisfaction
- Attempt counts
- Progress measures
These conditions are evaluated against the current activity and sometimes across the activity tree.
This creates a strong dependency between:
- Run-Time data
- Data model accuracy
- Sequencing configuration
If the data is inconsistent, the rules cannot behave correctly.
⚠️ Where Real Implementations Break
This is where most sequencing implementations fail:
⚠️ Rules conflict with each other
⚠️ Conditions are not aligned with the data model
⚠️ Developers expect LMS defaults to resolve logic
⚠️ Testing does not cover all rule paths
The result:
- Unreachable activities
- Infinite navigation loops
- Unexpected skips
- Broken learner flows
SCORM 2004 does not resolve ambiguity.
If rules are unclear, behavior becomes unpredictable.
🧠 Designing Behavior, Not Just Content
SCORM 2004 gives you full control over learning flow.
But with that control comes responsibility.
You are no longer just building content.
You are designing behavior.
That means:
- Thinking in state transitions
- Designing for all possible learner paths
- Validating rule interactions
- Testing edge cases intentionally
When sequencing rules are well designed, the system feels seamless.
When they are not, even simple courses can become impossible to navigate.
🔢 7 of 12 | SCORM 2004: The Sequencing Era of Learning Standard
