# 4. AI Score Prediction

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*

---

## 4. AI Score Prediction

### 4.1 Prediction Model Configuration
**What it does:** Configures the AI score prediction model: the model type, the prediction target (exam score, subject score), the prediction horizon, and the model version control.

**Sub-features:**
- Model type (regression, ensemble, per-exam-type models)
- Prediction target (overall exam score, per-subject score, per-section score)
- Prediction horizon (current level, 1-month, 3-month, exam-day)
- Model version control (active version, rollback)
- Model enable/disable per exam type
- Available on web
- Event logging (action performed)
- Audit logging of prediction model configuration

**Super Admin User Journey:**
1. Super Admin opens AI Feature Configuration → AI Score Prediction → Model.
2. Sets the model type (regression, ensemble, per-exam-type models).
3. Configures the prediction target (overall exam score, per-subject score, per-section score).
4. Sets the prediction horizon (current level, 1-month, 3-month, exam-day).
5. Manages the model version (active version, rollback) and enables/disables the model per exam type.
6. Saves; the configuration applies to all score predictions.
7. Each configuration change is event-logged and audit-logged.

**Rules & Edge Cases:**
- A disabled exam type produces no score prediction; the feature is hidden for that exam type.
- A model rollback restores the previous version's predictions for new requests; historical predictions are not rewritten.
- Only one model version is active per exam type at a time.
- Configuration changes are audit-logged with the setting, the change, and the timestamp.

### 4.2 Confidence Interval Settings
**What it does:** Configures the confidence interval settings for score predictions: the interval width, the confidence display, and the low-confidence handling.

**Sub-features:**
- Confidence interval width (e.g., ±5, ±10 points)
- Confidence display (range, probability band, high/medium/low label)
- Low-confidence threshold (below which the prediction is flagged)
- Data-volume requirement (minimum data points for a prediction)
- Confidence trend (narrowing/widening over time)
- Available on web
- Event logging (action performed)
- Audit logging of confidence interval settings

**Super Admin User Journey:**
1. Super Admin opens AI Feature Configuration → AI Score Prediction → Confidence Intervals.
2. Sets the confidence interval width (e.g., ±5, ±10 points).
3. Configures the confidence display (range, probability band, high/medium/low label).
4. Defines the low-confidence threshold and the data-volume requirement.
5. Enables the confidence trend view (narrowing/widening over time).
6. Saves; the settings apply to all score predictions.
7. Each configuration change is event-logged and audit-logged.

**Rules & Edge Cases:**
- A prediction below the data-volume requirement is not shown (no false precision); the student is prompted to complete more practice.
- A low-confidence prediction is always displayed with the low-confidence label; it is never shown as a precise value.
- The confidence interval narrows as more data is collected; it never widens for the same data volume.
- Configuration changes are audit-logged with the setting, the change, and the timestamp.

### 4.3 What-If Scenario Parameters
**What it does:** Configures the what-if scenario parameters: the scenario inputs, the scenario constraints, the scenario comparison, and the scenario limits.

**Sub-features:**
- Scenario inputs (study hours per week, topic focus, mock test frequency)
- Scenario constraints (realistic bounds on inputs)
- Scenario comparison (current trajectory vs scenario trajectory)
- Scenario limits (max scenarios per student per period)
- Scenario validity window (how long a scenario prediction is valid)
- Available on web
- Event logging (action performed)
- Audit logging of what-if scenario parameters

**Super Admin User Journey:**
1. Super Admin opens AI Feature Configuration → AI Score Prediction → What-If Scenarios.
2. Sets the scenario inputs (study hours per week, topic focus, mock test frequency).
3. Configures the scenario constraints (realistic bounds on inputs).
4. Defines the scenario comparison (current trajectory vs scenario trajectory).
5. Sets the scenario limits (max scenarios per student per period) and the validity window.
6. Saves; the parameters apply to all what-if scenarios.
7. Each configuration change is event-logged and audit-logged.

**Rules & Edge Cases:**
- A scenario input outside the realistic bounds is clamped to the bound with a notice; it is not rejected silently.
- A scenario prediction is valid only within the validity window; after the window it is marked stale, not auto-refreshed.
- A student at the scenario limit cannot create further scenarios until the period resets.
- Configuration changes are audit-logged with the parameter, the change, and the timestamp.

### 4.4 Data Input Sources
**What it does:** Configures the data input sources for the score prediction model: the assessment data, the practice data, the attendance data, and the data freshness requirements.

**Sub-features:**
- Assessment data sources (mock tests, practice quizzes, assignments)
- Practice data sources (SRS recall, flashcard performance, video completion)
- Attendance data sources (live sessions, study plan adherence)
- Data freshness requirement (max age of input data)
- Data weighting (recency weighting, source reliability weighting)
- Available on web
- Event logging (action performed)
- Audit logging of data input sources

**Super Admin User Journey:**
1. Super Admin opens AI Feature Configuration → AI Score Prediction → Data Inputs.
2. Sets the assessment data sources (mock tests, practice quizzes, assignments).
3. Configures the practice data sources (SRS recall, flashcard performance, video completion).
4. Defines the attendance data sources (live sessions, study plan adherence).
5. Sets the data freshness requirement and the data weighting (recency, source reliability).
6. Saves; the sources apply to all score predictions.
7. Each configuration change is event-logged and audit-logged.

**Rules & Edge Cases:**
- A data source older than the freshness requirement is excluded from the prediction; the prediction is marked lower-confidence if too much data is stale.
- A source with no data for a student is omitted (not zero-filled); the prediction reflects the available sources.
- Data weighting changes apply to new predictions; they do not recompute historical predictions.
- Configuration changes are audit-logged with the source, the change, and the timestamp.

### 4.5 Model Retraining Schedule
**What it does:** Configures the model retraining schedule: the retraining frequency, the retraining data window, the validation gate, and the deployment approval.

**Sub-features:**
- Retraining frequency (weekly, monthly, per exam cycle)
- Retraining data window (training data period)
- Validation gate (min accuracy improvement to deploy)
- Deployment approval (auto-deploy, manual approval)
- Retraining history (model versions, accuracy, deployment status)
- Available on web
- Event logging (action performed)
- Audit logging of retraining schedule

**Super Admin User Journey:**
1. Super Admin opens AI Feature Configuration → AI Score Prediction → Retraining.
2. Sets the retraining frequency (weekly, monthly, per exam cycle).
3. Configures the retraining data window (training data period).
4. Defines the validation gate (min accuracy improvement to deploy).
5. Sets the deployment approval (auto-deploy, manual approval) and enables the retraining history.
6. Saves; the schedule applies to the prediction model.
7. Each configuration change is event-logged and audit-logged.

**Rules & Edge Cases:**
- A retrained model failing the validation gate is not deployed; the current model remains active.
- A manual-approval retraining waits for approval; it does not auto-deploy on schedule.
- Every retraining run is recorded in the retraining history with the version, accuracy, and deployment status; the history is immutable.
- Configuration changes are audit-logged with the setting, the change, and the timestamp.