# 1. Education Board Management

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

---

## 1. Education Board Management

### 1.1 Create, Edit, and Delete Education Boards
**What it does:** Manages the education boards the platform supports (e.g., CAPS, Cambridge, IB) as first-class entities: the Super Administrator creates a board with its identity and details, edits it as it evolves, and deletes or archives it when it is no longer offered. Boards are the top of the academic curriculum hierarchy (board → grade → subject → topic), so board management anchors the structure that courses and content map to.

**Sub-features:**
- Create a board: name, description, region/context, and status
- Edit a board's details (name, description, status)
- Delete or archive a board (archive preferred where content is mapped to it)
- Board list with status and the count of grades/subjects mapped to it
- Dependency check before delete: boards with mapped content are flagged for archive instead
- Board status: active boards are selectable; inactive boards are not offered for new mapping
- Audit logging of board create/edit/delete

**Super Administrator User Journey:**
1. The platform will offer Cambridge curriculum content. Super Admin opens Curriculum Organization → Education Boards and creates the board: name "Cambridge", a description, and its region/context.
2. Saves; the board appears in the list as active and is now selectable for grade and subject mapping.
3. Later, the board's description needs updating (a syllabus revision note). Super Admin edits the board's description and saves; the change is recorded.
4. For a board the platform is retiring (no longer offering new content under it), Super Admin reviews its dependency: 3 grades, 12 subjects, and mapped courses exist.
5. Because content is mapped, deletion is not offered cleanly; Super Admin archives the board instead. The board becomes inactive: not selectable for new mapping, but existing mapped content and its history remain intact.
6. For a board created in error with no mappings, Super Admin deletes it; the dependency check passes (nothing mapped) and the board is removed.
7. Reviews the board list: active boards are available for mapping; the archived board is shown as inactive with its mapped counts.
8. Each board create, edit, archive, and delete is audit-logged with the acting admin and timestamp.

**Rules & Edge Cases:**
- A board with mapped grades/subjects/content is archived, not deleted; deletion is reserved for boards with no dependencies.
- Archiving a board stops new mapping to it but preserves existing mappings and history; it is reversible (re-activation).
- An active board is selectable for mapping; an inactive/archived board is not offered for new mapping.
- The board list shows the mapped counts so the dependency state is visible before acting.
- Board identity (name) changes are recorded; existing mappings reference the board, not its old name.
- All board changes are audit-logged with the acting admin and timestamp.

### 1.2 Board-Specific Curriculum Mapping
**What it does:** Maintains the mapping of the curriculum structure to each board: which grades, subjects, and topics exist under a board, and how they relate to the board's syllabus. The Super Administrator organizes the board's curriculum tree (board → grades → subjects → topics) so that content and courses can be tagged to the board's specific structure, and so board-appropriate material is surfaced to the right learners.

**Sub-features:**
- Board curriculum tree: grades, subjects, and topics organized under the board
- Mapping of grades and subjects to the board (a board's grade set and subject set)
- Syllabus alignment: topics organized to reflect the board's syllabus structure
- Tagging of content/courses to the board's structure (board + grade + subject + topic)
- Board-specific views: the curriculum as it is for that board
- Consistency: a course tagged to a board's subject appears in that board's context
- Audit logging of mapping changes

**Super Administrator User Journey:**
1. With the Cambridge board created, Super Admin maps its curriculum: adds the board's grades (per Cambridge's year structure) and, under each grade, the subjects Cambridge offers.
2. Organizes the topics under each subject to reflect the Cambridge syllabus structure, so the tree mirrors the board's curriculum.
3. Tags a course to the board's structure: Cambridge → Grade 10 → Mathematics → the relevant topics. The course now appears in the Cambridge context for that grade and subject.
4. Reviews the board-specific view: the Cambridge curriculum tree with its grades, subjects, topics, and the courses/content mapped to each node.
5. For a learner in the Cambridge board, the platform surfaces the board-appropriate material: the courses and content tagged to their board, grade, and subject.
6. When the board's syllabus is revised, Super Admin updates the topic structure (adds/renames topics) and re-tags the affected content; the mapping change is recorded.
7. Checks consistency: a course tagged to Cambridge Grade 10 Mathematics appears in that context and not in the CAPS Grade 10 Mathematics context (board-specific separation).
8. The mapping changes are audit-logged with the board, the nodes changed, and the timestamp.

**Rules & Edge Cases:**
- The curriculum tree is board-specific: the same grade/subject name under different boards are distinct nodes with distinct mappings.
- Content and courses are tagged to the board's structure (board + grade + subject + topic); the tag is what places them in the board's context.
- A syllabus revision is a mapping update: topics are adjusted and content re-tagged, with the change recorded.
- Board-specific separation is enforced: material mapped to one board's node does not appear under another board's node.
- The board view shows the full tree with mapping counts, so gaps (unmapped nodes) are visible.
- Mapping changes are audit-logged with the board, the nodes, and the timestamp.

### 1.3 Board-Wise Certification
**What it does:** Supports certification at the board level: when a learner completes the requirements for a board's program (a grade's subjects, or a board-defined qualification), the platform issues a board-wise certification. The Super Administrator configures the certification requirements per board and manages the issuance, so completions are recognized with a board-specific credential.

**Sub-features:**
- Certification requirements per board: the completion criteria (subjects, assessments, thresholds)
- Completion evaluation: a learner's progress checked against the board's requirements
- Certification issuance: a board-wise certificate generated on completion
- Certificate content: the board name, the program/grade, the learner, and the outcome
- Certification records: issued certificates per board with the learner and date
- Re-issue and revocation (per policy) with a record
- Audit logging of certification configuration and issuance

**Super Administrator User Journey:**
1. For the Cambridge board, Super Admin configures the certification requirements: completion of the grade's subjects with the defined assessment thresholds.
2. Saves; the requirements are live for the board's programs.
3. A learner completes the requirements. The platform evaluates their progress against the board's criteria and, on meeting them, issues the board-wise certification.
4. Super Admin reviews the issued certificate: it shows the board name, the program/grade, the learner, and the outcome — a board-specific credential.
5. Reviews the certification records for the board: the issued certificates with learners and dates, confirming they match the completions.
6. For a certificate that must be re-issued (a correction), Super Admin re-issues it with the correction; the re-issue is recorded against the original.
7. For a revocation (a completion invalidated per policy), Super Admin revokes the certificate with the reason; the revocation is recorded and the learner is notified per policy.
8. The certification configuration and each issuance, re-issue, and revocation are audit-logged with the board, the learner, and the timestamp.

**Rules & Edge Cases:**
- Certification is board-wise: the credential reflects the specific board and program, not a generic completion.
- Issuance is automatic on meeting the configured requirements; the requirements are the single source of the criteria.
- A certificate shows the board, program, learner, and outcome; it is a board-specific credential.
- Re-issue and revocation are recorded against the original certificate; the history is intact.
- A revocation is reason-recorded and the learner is notified per policy.
- Certification configuration and all issuance events are audit-logged with the board, learner, and timestamp.