SGQuill Learn · 2026
A standalone SCORM 1.2 / 2004 runtime
A spec-complete SCORM runtime with per-launch origin isolation and an ADL conformance gate in CI, so broken third-party content can’t take the platform down.
Senior Fullstack · architect
- SCORM versions, spec-complete
- 1.2 + 2004SCORM versions, spec-complete
- conformance gate in CI
- ADLconformance gate in CI
- learner presence via Redis + SSE
- Livelearner presence via Redis + SSE
Context
The situation
Courses on the platform include third-party SCORM packages: content the team does not control, running inside the learning experience.
The problem. Running SCORM content inside the main app meant a misbehaving package could break sessions or leak across launches, and progress commits were easy to lose silently.
Approach
Key decisions
- 01
Separate service, separate origin
The runtime is its own service, and every launch gets its own subdomain origin, isolating third-party content from the platform and from other launches.
- 02
Spec-complete adapters
Full SCORM 1.2 and 2004 API adapters with suspend/resume sequencing state, rather than the subset most packages happen to use.
- 03
Conformance as a merge gate
An ADL conformance suite runs in CI, so regressions are caught before release.
How it works
- 1
Learner opens course
On the main platform
- 2
Per-launch origin
Unique subdomain per launch
- 3
SCORM runtime
1.2 / 2004 adapters, suspend/resume
- 4
Commit store
Progress persisted per session
- 5
Presence monitor
Redis + SSE for staff dashboards
Outcome
Results
- Third-party content failures no longer affect the main platform.
- Root-caused a silent method rename that dropped an entire session’s commits, and missing wildcard DNS behind per-launch subdomains.
- Real-time learner presence and mastery monitor on Redis + SSE for non-technical staff.
Next case study
RAG document repository for an industrial enterprise
Fortech Indotama × Krakatau Jasa Industri