Core Model

Intent

Define a generic, flexible, person-centric learning model that supports:

• Independent lifelong learning
• One-on-one instruction
• Teacher-to-class delivery
• Multi-teacher and MOOC-scale delivery

The model is designed so learning history follows the person, not only the institution.

Non-Goals

This document does not define:

• Final physical table names for every feature
• UI workflows
• Final standards protocol payloads

Those are defined in companion documents once core semantics are stable.

Terminology

Internal terms are intentionally neutral to avoid early lock-in.

Internal term	Typical LMS alias	Notes
Person	User/Learner/Teacher	A human identity that can hold multiple roles over time
Organization	Institution/School/Provider	Administrative context
Learning Container	Program/Course Path	Optional long-lived grouping of offerings
Offering	Course Run/Class/Instance	Deliverable context where participation happens
Membership	Enrollment/Teaching Assignment	Time-bounded person participation in an offering
Learning Unit	Lesson/Module/Activity	Structured instructional element
Assessment	Quiz/Exam/Checkpoint	Evaluative or diagnostic instrument
Attempt	Submission/Try	A person execution of an assessment
Competency Framework	Outcomes Framework/Skills Map	Versioned competency graph used for alignment and mastery
Qualification	Credential/Badge/Certificate	Award or achievement record

Design Principles

1. Person-first history All durable learning history is attached to person identity and can be exported.

2. Contextual institutions Organizations scope permissions and administration, not person identity existence.

3. Time-bounded everything Memberships, role grants, and many statuses are temporal with effective windows.

4. Unified participation model Learner and teacher participation share one membership model with role/capability dimensions.

5. Extension-safe core Core entities stay small and stable; specialization is added through typed extension surfaces.

6. Event-oriented interoperability Core model must map cleanly to xAPI/LRS/CLR/LTI events and records.

Core Entity Set

The following entity categories are baseline requirements for v1.

Identity and Context

• person
• person_profile
• identity_binding (external identity mapping: LTI/SIS/IdP)
• organization
• organization_affiliation (person in organization over time)
• person_role_grant (learner/teacher/admin capability grants over time)

Learning Structure

• learning_container (optional umbrella for long-lived tracks)
• offering (the actual delivery context)
• offering_membership (unified participation: learner/teacher/assistant/co-teacher)
• learning_unit (sequence of units within offering)
• unit_release_rule (availability logic)

Assessment and Evidence

• assessment_definition
• assessment_attempt
• assessment_score (rubric-ready, not only numeric)
• submission_artifact (attachments, references, rich responses)
• feedback_entry

Progress and Qualification

• progress_snapshot
• competency_framework
• competency_node
• competency_alignment (maps assessments/units to competency nodes)
• person_competency_evidence
• person_competency_state
• qualification_definition
• qualification_award

Auditing and Portability

• activity_event (internal event ledger)
• change_audit_entry
• export_import_batch

Relationship Skeleton

Minimum relationship direction:

• Person can have many affiliations and role grants
• Offering belongs to an organization context, with optional container parent
• Offering has many memberships
• Membership links one person to one offering with role and status
• Offering has many learning units
• Assessment definition belongs to learning unit or directly to offering
• Attempt belongs to person and assessment definition
• Score belongs to attempt
• Competency node belongs to a competency framework version
• Competency evidence links person evidence to one competency node
• Competency state belongs to person and competency node, derived from evidence
• Qualification award belongs to person and qualification definition

Unified Membership Baseline

Decision

Use one time-bounded membership relation for both learner and teaching participation.

Why

• Supports role transitions without data migration
• Supports co-teaching and assistant patterns
• Handles independent learning through a persistent personal offering
• Simplifies auditing and export logic

Shape (conceptual)

offering_membership should include:

• id
• offering_id
• person_id
• membership_role (learner, teacher, assistant, observer, mentor)
• membership_status (invited, active, suspended, completed, withdrawn)
• effective_from
• effective_until
• created_by_person_id
• meta

Lifelong and One-Shot Learning Support

Both modes are first-class in the same model:

• Lifelong mode: long-lived container and recurring offerings
• One-shot mode: short-lived offering with narrow objective
• Independent mode: personal default offering for self-paced progress continuity

No mode requires special-case identity semantics.

Assessment Baseline With Mixed Complexity

Initial baseline includes:

• Generic assessment definitions
• Structured attempts and scores
• Rubric-capable scoring shape
• Concrete competency framework entities and alignment model

This keeps v1 implementable while avoiding schema dead ends.

Concrete Competency Framework Model

The initial version includes a concrete competency model as part of the core architecture.

See Competency Framework Model for the full relational and inference blueprint.

Core competency entities:

• competency_framework
• competency_framework_version
• competency_node
• competency_node_edge (prerequisite, parent-child, related)
• competency_alignment (links learning units and assessments to competency nodes)
• person_competency_evidence (attempt outcomes, rubric signals, instructor validations)
• person_competency_state (derived state per person and competency)

Competency state baseline:

• not-started
• in-progress
• demonstrated
• mastered
• regressed (explicitly tracked when later evidence lowers confidence)

Model rules:

• Framework versions are immutable once published
• Competency nodes are stable within a published framework version
• Evidence is append-oriented and provenance-rich
• Current competency state is derived from evidence, not manually overwritten
• Alignments are time-aware so curriculum changes do not rewrite historical evidence meaning

This model supports language-learning specialization while remaining domain-agnostic.

Person-Portable History Boundary

Portable by default:

• Progress snapshots
• Full assessment attempt-level history
• Full feedback-level history (automated and instructor feedback entries)
• Assessment scores and rubric dimensions
• Competency evidence and competency-state history
• Qualification awards
• Learning activity events relevant to learner record

Usually institution-bound:

• Internal staffing assignments not tied to learning achievements
• Organization-specific administrative notes
• Internal moderation workflow artifacts

Extension Seams in Core Model

Core entities should reserve extension seams without converting everything to untyped JSON.

Recommended seams:

• Stable primary keys and timestamps in core tables
• Optional meta JSONB for low-criticality attributes
• Typed extension tables for high-value specialization
• Registry-based extension declaration and governance

See Extension Architecture for details.

Implementation Anchors

• Domain types and validation contracts: packages/domain
• Relational schema and migrations: packages/db
• Offline projection and collection boundaries: packages/offline-data
• API boundary enforcement: apps/api

Confirmed Decisions

1. Internal terms remain neutral (learning_container, offering, membership) with LMS aliases documented for interoperability.
2. Person-portable exports include full attempt-level and feedback-level history by default.
3. A concrete competency framework model is part of the initial architecture baseline.