Choose Learning Standards by the Boundary They Cross

Choose Learning Standards by the Boundary They Cross

“Supports LMS interoperability standards” is not a useful acceptance criterion on its own. The comparison SCORM vs xAPI vs LTI vs cmi5 becomes useful only after the team names what must cross a system boundary. An imported course, a remote tool, an activity record and a governed learning session are different integration objects.

For a fintech product lead, the test is whether an interface supports onboarding, partner delivery or reporting without pulling the core team into unnecessary integration work.

One learner journey exposes four boundaries

Consider a customer who opens a wallet-safety lesson, enters a partner simulator, retries a quiz and returns to onboarding. The lesson might need importing, the simulator needs launching, the retries might need recording, and completion needs an agreed meaning. These are separate requirements, not a mandatory four-standard stack.

SCORM crosses the course boundary

ADL’s SCORM guidance describes course packaging and runtime communication between learning content and an LMS, including status, scores and resume data. (adlnet.gov) In this journey, SCORM is a candidate when a partner supplies a packaged lesson that must run inside the academy. The acceptance test should cover import, launch, resume and recorded results. Content portability should not be mistaken for learner-history migration; that needs a separate export and identity plan.

LTI crosses the external-tool boundary

1EdTech defines LTI 1.3 for secure remote-tool integration and distinguishes related LTI Advantage services, including grade return and deep linking. (1edtech.org) For the partner simulator, the integration boundary is the launch and its learner context. A secure launch should not be treated as a detailed analytics specification. For embedded academy integration, mobile launch and return behavior also belong in the acceptance tests.

xAPI crosses the activity-record boundary

IEEE’s implementation guide describes xAPI statements through actor, verb and object, with records stored in a learning record store. (sagroups.ieee.org) Quiz retries could become records for cross-system analysis. Useful reporting still needs shared event definitions, identity mapping and a clear decision that the data will inform.

ADL’s repository directs implementers to xAPI 2.0 rather than its older 1.0.3 specification. (github.com) A procurement requirement should therefore name the supported version, not just “xAPI”.

cmi5 governs launch and tracking together

The cmi5 specification defines an xAPI-based LMS runtime contract covering launch parameters, session statements and satisfaction rules; its Quartz release references xAPI 1.0.3. (github.com) It fits a requirement for consistent launch-and-completion behavior rather than event collection alone. The profile and underlying xAPI version need an explicit compatibility check. An “xAPI supported” claim is not enough evidence for this requirement.

The decision belongs in the product architecture

A short decision tree keeps standards tied to business requirements rather than a vendor checklist.

1. Define the reporting decision. If completion is enough, defer richer event collection.
2. Check the partner ecosystem. If neither partners nor reporting need a standard interface, defer it.
3. Verify vendor support through versioned test cases, including mobile launch and return behavior.
4. Set privacy limits for learner identifiers, partner access, retention and deletion before exchanging records.

At App-Learning, this is the product decision behind embedded and standalone academies. Each interface should have an owner, acceptance tests and a measurable integration benefit. The right architecture is not the one with the most standards. It is the one that crosses the required boundaries without creating unnecessary ones.