Learning platform: Product scope

Defines an initial learning-platform product boundary around catalog discovery, enrollment, structured content, progress, assessment attempts, completion evidence, instructor operations, and accessibility.

Package status: reference context ready for human review. The contract and test scenarios are complete, but no claim is made that an adopting implementation has passed them.

Decision

Build the first release around self-paced courses with immutable published course versions, explicit enrollments, learner-owned progress, bounded assessment attempts, and verifiable completion. Defer live classroom and marketplace complexity.

Scope

• Actors, catalog, course versions, modules/lessons, enrollment, progress, assessments, completion, certificates/evidence, instructor workflow, accessibility, notifications, analytics, and operations.
• Self-paced learning for individual learners and organization-assigned courses.
• MVP decisions and expansion boundaries.

Outside this block

• Live video classrooms, instructor payroll, public course marketplace, proctoring, or SCORM/LTI interoperability in the first profile.
• Claiming educational accreditation from platform completion.

Contract

• A published course version is immutable; material edits create a new version and enrollment policy determines migration or pinning.
• Enrollment records learner, course version, source, start, optional due date, state, and organization scope.
• Progress is derived from idempotent lesson/activity evidence and exposes both completion and last position without equating time spent with learning.
• Assessment attempts snapshot question/version, responses, scoring policy, start/submit time, and outcome; limits and accommodations are explicit.
• Completion uses versioned requirements and produces evidence that can be verified without exposing unnecessary learner data.
• Learners can navigate by keyboard, access captions/transcripts and alternatives, resume across devices, and understand locked or unavailable content.

Implementation guidance

• Suggested boundaries: identity/organizations, catalog, authoring, delivery, enrollment, progress, assessment, credentials, notifications, and analytics.
• Store large media privately with authorized streaming/download paths and publication checks.
• Use an outbox for progress/completion events and deduplicate client activity by attempt or activity ID.
• Keep content authoring draft/review/published states separate from learner delivery.

Failure handling and safeguards

• If offline progress conflicts, merge monotonic completion evidence and resolve non-monotonic responses by activity policy.
• If a course version is withdrawn, preserve authorized learner records and explain access or migration behavior.
• If scoring fails, keep the submitted attempt immutable and re-evaluate under the recorded scoring version.
• If certificate verification is revoked, show revocation state without leaking the learner's full profile.

Verification and operations

• Measure discovery-to-enrollment, activation, lesson completion, assessment attempts, completion, resume success, accessibility defects, content publication errors, and event reconciliation.
• Avoid treating completion rate alone as learning quality; pair it with assessment and user-goal measures.
• Run learner, instructor, organization-admin, and unauthorized journeys.

The executable-looking examples in this package are fixtures and acceptance contracts. Run python tools/validate.py from the collection root to check package structure and metadata; then implement and execute the scenarios in the target repository.

Adoption assumptions

• Names and numeric values in example.yaml are an adoption profile, not universal defaults.
• The adopting team must map actors, data classes, error vocabulary, and ownership to its system.

References

• wcag22