# 4. Version History

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

---

## 4. Version History

### 4.1 Maintain Content Version History
**What it does:** Maintains the version history for each piece of content: every significant change to a content item (a re-cut, a metadata revision, a re-upload) is recorded as a version, so the content's history is preserved. The Super Administrator can see the versions of a content item, understand how it evolved, and trace any change back to its version.

**Sub-features:**
- Version creation: a new version recorded when the content changes significantly
- Version record: the version's content, the change, the actor, and the timestamp
- Version list: the versions of a content item in order
- Version detail: a version's specifics (the change, the actor, the time)
- Current version: the learners always see the current (latest) version
- History retention: the versions retained per the platform's policy
- Audit logging of the version creation

**Super Administrator User Journey:**
1. A content item is updated (a re-cut, a metadata revision). The platform records a new version (the change, the actor, the timestamp).
2. Super Admin opens the content item's version history: the versions in order, so the evolution is visible.
3. Opens a version: the specifics (the change made, the actor, the time), so the version is understood.
4. Confirms the current version: the learners always see the current (latest) version; a stale version is not shown.
5. For a content item with a long history, Super Admin reviews the key versions (the significant changes) to understand its evolution.
6. Reviews the history retention: the versions retained per the platform's policy (the older versions available for the retention period).
7. For a content item whose history is questioned (a change disputed), Super Admin traces the change to its version (the actor, the time, the change); the trace is the answer.
8. The version creation is audit-logged with the content, the version, and the timestamp.

**Rules & Edge Cases:**
- A version is recorded on a significant change; the version captures the change, the actor, and the timestamp.
- The version list is in order; the evolution is visible, not a jumble.
- The learners always see the current (latest) version; a stale version is not shown.
- The history retention is per the platform's policy; older versions are available for the retention period.
- A disputed change is traced to its version (the actor, the time, the change); the trace is the answer.
- Version creation is audit-logged with the content, version, and timestamp.

### 4.2 Track Changes Across Versions
**What it does:** Tracks the changes across the versions of a content item: the Super Administrator can compare versions to see what changed between them (the content delta, the metadata delta), so a change is understood precisely. Change tracking supports the review (what did this re-cut change?), the audit (who changed what?), and the restore (what would reverting undo?).

**Sub-features:**
- Version comparison: two versions compared (the change between them)
- Change detail: the specific changes (the content delta, the metadata delta)
- Change attribution: the change attributed (the actor, the time)
- Change review: the change reviewed (the what and the why)
- Change impact: the impact of the change (the learners affected, the context)
- Restore preview: the change a restore would undo (the revert understood)
- Audit logging of the change tracking (where applicable)

**Super Administrator User Journey:**
1. For a content item, Super Admin compares two versions (the current and the prior); the change between them is shown (the content delta, the metadata delta).
2. Reviews the change detail: the specific changes (what was added, removed, or modified), so the change is understood precisely.
3. Checks the change attribution: the actor and the time of the change, so the change is accountable.
4. Reviews the change impact: the learners affected (the ones who had the prior version) and the context (the course/topic), so the impact is understood.
5. For a restore decision, Super Admin previews the change the restore would undo (the revert understood); the restore is a confident act.
6. For a disputed change, Super Admin reviews the change (the what and the why) and the attribution; the review is the resolution.
7. Confirms the change tracking works end-to-end: the versions compared, the change shown, the attribution clear; the tracking is reliable.
8. The change tracking is audit-logged where applicable (the content, the versions, the change, the timestamp).

**Rules & Edge Cases:**
- The version comparison shows the change between two versions; the delta is the content and the metadata.
- The change is attributed (the actor, the time); it is accountable, not anonymous.
- The change impact is reviewed (the learners affected, the context); the impact is understood, not assumed.
- A restore preview shows the change the restore would undo; the revert is a confident act.
- A disputed change is resolved via the review (the what, the why, the attribution); the tracking is the evidence.
- Change tracking is audit-logged where applicable.