Mastery Engine RFC

Status

Draft

Context

The Spread11 platform currently supports the following learning flow:

Activity
    ↓
Session
    ↓
Interaction
    ↓
Evidence
    ↓
Assessment
    ↓
Progress
    ↓
Analytics

The Progress Engine stores assessment history, while the Analytics Engine produces reports from accumulated progress.

The Mastery Engine introduces a new domain responsibility: estimating a learner's long-term mastery of a skill from historical progress records.

Objective

The Mastery Engine is responsible for deriving long-term learner mastery from historical assessment records. Unlike the Assessment Engine, which evaluates a single interaction, the Mastery Engine reasons about accumulated performance over time.

Initial Scope

The first iteration will support:

• mastery computation from Progress records;
• learner × skill aggregation;
• immutable mastery snapshots;
• read-only queries.

Domain Types

The package is expected to introduce the following domain types:

• MasteryRecord
• MasteryLevel
• MasterySummary

Additional supporting types may be introduced as the implementation evolves.

Proposed API

The engine is expected to expose operations for:

• calculating mastery from historical progress;
• retrieving mastery by learner;
• retrieving mastery by skill.

The public API will continue to evolve through TDD while preserving backward compatibility.

Data Source

The Mastery Engine will consume historical data produced by the Progress Engine.

It will not perform assessments directly or inspect learner interactions.

Initial Algorithm

The first implementation should use a simple deterministic algorithm based on accumulated assessment history.

More sophisticated approaches may be introduced in future iterations without changing the public API.

Mastery Levels

The initial design considers the following mastery levels:

• novice
• developing
• proficient
• mastered

The criteria for transitioning between levels will be defined incrementally through TDD.

The initial implementation treats learners without recorded progress as novice.

This behavior intentionally keeps the initial mastery model simple.

Future iterations may introduce an explicit unassessed state if the domain requires distinguishing learners with no assessment history from learners with observed low mastery.

Persistence

Mastery records should be stored independently from Progress records.

Progress represents historical events, while Mastery represents a derived state computed from that history.

Error and Boundary Behavior

The engine should define behavior for situations such as:

• learners without assessment history;
• unknown skills;
• incomplete progress records.

A learner without recorded progress is considered unassessed.

The engine must not infer a mastery level when no progress records exist. In this situation, calculateMastery() returns null.

The novice mastery level represents the lowest observed mastery after at least one recorded assessment.

Additional boundary behaviors will continue to be specified through TDD as the implementation evolves.

Future Capabilities

Possible future extensions include:

• mastery decay over time;
• confidence scores;
• adaptive thresholds;
• prerequisite relationships between skills;
• recommendations for future learning activities.

These capabilities are intentionally outside the scope of the initial implementation.

First TDD Cycle

The first RED cycle should validate that the engine can compute an initial mastery state for a learner from recorded progress.

Subsequent cycles will evolve the algorithm while preserving the public contract defined in this RFC.