# 4. Alert Configuration — Test Cases

User Type: **Super Administrator**
Source: *Mi Digital Academy - Education CRM Features Document*
Spec: alert_configuration.md — every feature, sub-feature, and rule covered

## Test Execution Policy

- Zero tolerance: any deviation from the documented behavior is a defect.
- Every failed test is logged with a Bug ID, the feature, the sub-feature, the expected vs actual result, and the severity; 100% of bugs are fixed before the group passes.
- 100% pass rate is required for the group to be marked complete.

## Coverage Matrix

| Feature | Sub-feature / Rule | Test IDs |
|---------|--------------------|----------|
| 4.1 Alert Type Definitions | Alert type creation: name, description, and category | TC-SA-AR-04-001 |
| 4.1 Alert Type Definitions | Severity levels: critical, warning, and informational severities | TC-SA-AR-04-002 |
| 4.1 Alert Type Definitions | Target audience: the recipients per alert type | TC-SA-AR-04-003 |
| 4.1 Alert Type Definitions | Data source: the metric or event that feeds the alert type | TC-SA-AR-04-004 |
| 4.1 Alert Type Definitions | Message template: the alert message template with placeholders | TC-SA-AR-04-005 |
| 4.1 Alert Type Definitions | Enable/disable: alert types toggled on or off | TC-SA-AR-04-006 |
| 4.1 Alert Type Definitions | Rule: an alert type cannot be deleted while active alerts reference it | TC-SA-AR-04-007 |
| 4.1 Alert Type Definitions | Rule: a message template with unresolved placeholders is rejected | TC-SA-AR-04-008 |
| 4.1 Alert Type Definitions | Rule: a disabled alert type raises no alerts but retains its history | TC-SA-AR-04-009 |
| 4.1 Alert Type Definitions | Rule: definition changes are audit-logged | TC-SA-AR-04-010 |
| 4.2 Threshold Settings | Numeric thresholds: value-based trigger conditions | TC-SA-AR-04-011 |
| 4.2 Threshold Settings | Temporal thresholds: time-based trigger conditions | TC-SA-AR-04-012 |
| 4.2 Threshold Settings | Per-alert-type thresholds: thresholds set per alert type | TC-SA-AR-04-013 |
| 4.2 Threshold Settings | Segment overrides: thresholds overridden per student segment | TC-SA-AR-04-014 |
| 4.2 Threshold Settings | Threshold preview: a simulation of which students would trigger | TC-SA-AR-04-015 |
| 4.2 Threshold Settings | Rule: invalid threshold values are rejected | TC-SA-AR-04-016 |
| 4.2 Threshold Settings | Rule: a segment override replaces the base threshold for that segment only | TC-SA-AR-04-017 |
| 4.2 Threshold Settings | Rule: the threshold preview does not raise actual alerts | TC-SA-AR-04-018 |
| 4.2 Threshold Settings | Rule: threshold changes take effect from the next evaluation cycle | TC-SA-AR-04-019 |
| 4.2 Threshold Settings | Rule: threshold changes are audit-logged | TC-SA-AR-04-020 |
| 4.3 Escalation Rules | Escalation path: the sequence of recipients for unacknowledged alerts | TC-SA-AR-04-021 |
| 4.3 Escalation Rules | Escalation delay: the time before escalation to the next level | TC-SA-AR-04-022 |
| 4.3 Escalation Rules | Maximum escalation level: the highest escalation level reached | TC-SA-AR-04-023 |
| 4.3 Escalation Rules | Acknowledgement tracking: alert acknowledgement state per recipient | TC-SA-AR-04-024 |
| 4.3 Escalation Rules | Escalation stop: escalation stops on acknowledgement | TC-SA-AR-04-025 |
| 4.3 Escalation Rules | Rule: informational alerts do not escalate by default | TC-SA-AR-04-026 |
| 4.3 Escalation Rules | Rule: reaching the maximum level stops escalation; the alert remains open | TC-SA-AR-04-027 |
| 4.3 Escalation Rules | Rule: an unavailable recipient is skipped to the next level | TC-SA-AR-04-028 |
| 4.3 Escalation Rules | Rule: escalation configuration changes are audit-logged | TC-SA-AR-04-029 |
| 4.4 Notification Channel Routing & Quiet Hours | Channel routing: the channel(s) per alert type and severity | TC-SA-AR-04-030 |
| 4.4 Notification Channel Routing & Quiet Hours | Severity-based routing: critical alerts routed to higher-priority channels | TC-SA-AR-04-031 |
| 4.4 Notification Channel Routing & Quiet Hours | Quiet hours windows: the quiet hours start and end times | TC-SA-AR-04-032 |
| 4.4 Notification Channel Routing & Quiet Hours | Quiet hours scope: per recipient timezone or platform-wide | TC-SA-AR-04-033 |
| 4.4 Notification Channel Routing & Quiet Hours | Deferral behavior: non-critical alerts deferred until quiet hours end | TC-SA-AR-04-034 |
| 4.4 Notification Channel Routing & Quiet Hours | Critical bypass: critical alerts delivered immediately | TC-SA-AR-04-035 |
| 4.4 Notification Channel Routing & Quiet Hours | Rule: a deferred alert is delivered once at the end of quiet hours | TC-SA-AR-04-036 |
| 4.4 Notification Channel Routing & Quiet Hours | Rule: an unrouted combination defaults to in-app only | TC-SA-AR-04-037 |
| 4.4 Notification Channel Routing & Quiet Hours | Rule: routing and quiet hours changes are audit-logged | TC-SA-AR-04-038 |

### TC-SA-AR-04-001 — Alert type creation: name, description, and category
**Type:** Positive
**Covers:** 4.1 → Alert type creation: name, description, and category
**Preconditions:** A Super Admin account is active.
**Steps:**
1. As a Super Admin, open Alert Configuration and create a new alert type with a name, description, and category.
2. Save.
3. Observe the result and verify the full behavior: the alert type appears in the catalog with its definition.
**Expected Result:** The alert type is created — it appears in the catalog with the defined name, description, and category, delivered exactly as documented.
**Priority:** Critical

### TC-SA-AR-04-002 — Severity levels: critical, warning, and informational severities
**Type:** Positive
**Covers:** 4.1 → Severity levels: critical, warning, and informational severities
**Preconditions:** A Super Admin account is active.
**Steps:**
1. As a Super Admin, create alert types with each severity (critical, warning, informational).
2. Save and open the catalog.
3. Observe the result and verify the full behavior: each alert type shows its assigned severity.
**Expected Result:** The severity levels are applied — each alert type carries its assigned severity, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-003 — Target audience: the recipients per alert type
**Type:** Positive
**Covers:** 4.1 → Target audience: the recipients per alert type (student, parent, teacher, admin)
**Preconditions:** A Super Admin account is active.
**Steps:**
1. As a Super Admin, create an alert type with the target audience set to parent.
2. Trigger the alert condition.
3. Observe the result and verify the full behavior: the alert is delivered to the parent audience only.
**Expected Result:** The target audience is applied — the alert reaches the configured audience only, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-004 — Data source: the metric or event that feeds the alert type
**Type:** Positive
**Covers:** 4.1 → Data source: the metric or event that feeds the alert type
**Preconditions:** A Super Admin account is active.
**Steps:**
1. As a Super Admin, create an alert type bound to a specific data source (e.g., assessment score).
2. Trigger the data source event.
3. Observe the result and verify the full behavior: the alert is evaluated from the bound data source.
**Expected Result:** The data source binding works — the alert is fed by the bound metric/event, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-005 — Message template: the alert message template with placeholders
**Type:** Positive
**Covers:** 4.1 → Message template: the alert message template with placeholders
**Preconditions:** A Super Admin account is active; an alert type with a message template exists.
**Steps:**
1. As a Super Admin, trigger the alert.
2. Open the delivered alert message.
3. Observe the result and verify the full behavior: the message is rendered from the template with placeholders resolved to actual values.
**Expected Result:** The message template is rendered — placeholders are resolved to actual values, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-006 — Enable/disable: alert types toggled on or off
**Type:** Positive
**Covers:** 4.1 → Enable/disable: alert types toggled on or off
**Preconditions:** A Super Admin account is active; an alert type is enabled.
**Steps:**
1. As a Super Admin, disable the alert type and save.
2. Trigger the alert condition.
3. Observe the result and verify the full behavior: no alert is raised for the disabled type.
**Expected Result:** The alert type is toggled off — no alerts are raised, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-007 — Rule: an alert type cannot be deleted while active alerts reference it
**Type:** Negative
**Covers:** 4.1 → Rule: an alert type cannot be deleted while active alerts reference it; it must be disabled first
**Preconditions:** A Super Admin account is active; an alert type has active (unacknowledged) alerts.
**Steps:**
1. As a Super Admin, attempt to delete the alert type.
2. Observe the result and verify the full behavior: the deletion is blocked with a message to disable it first.
**Expected Result:** The deletion is blocked — the alert type with active alerts cannot be deleted, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-008 — Rule: a message template with unresolved placeholders is rejected
**Type:** Negative
**Covers:** 4.1 → Rule: a message template with unresolved placeholders is rejected on save
**Preconditions:** A Super Admin account is active.
**Steps:**
1. As a Super Admin, create an alert type with a message template containing an unknown placeholder.
2. Attempt to save.
3. Observe the result and verify the full behavior: the save is rejected with a validation message.
**Expected Result:** The invalid template is rejected — the save fails with a validation message, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-009 — Rule: a disabled alert type raises no alerts but retains its history
**Type:** Positive
**Covers:** 4.1 → Rule: a disabled alert type raises no alerts but retains its history
**Preconditions:** A Super Admin account is active; a disabled alert type has historical alerts.
**Steps:**
1. As a Super Admin, trigger the condition for the disabled type.
2. Open the alert history for the type.
3. Observe the result and verify the full behavior: no new alert is raised; the historical alerts remain visible.
**Expected Result:** The disabled type raises no alerts — its history is retained, delivered exactly as documented.
**Priority:** Medium

### TC-SA-AR-04-010 — Rule: definition changes are audit-logged
**Type:** Positive
**Covers:** 4.1 → Audit logging of alert type definitions
**Preconditions:** A Super Admin account is active; the audit log is accessible.
**Steps:**
1. As a Super Admin, modify an alert type definition and save.
2. Open the audit log.
3. Observe the result and verify the full behavior: the change is recorded with the actor and timestamp.
**Expected Result:** The definition change is audit-logged — the actor and timestamp are recorded, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-011 — Numeric thresholds: value-based trigger conditions
**Type:** Positive
**Covers:** 4.2 → Numeric thresholds: value-based trigger conditions (score, rate, count)
**Preconditions:** A Super Admin account is active; an alert type with a numeric threshold (score < 40%) exists.
**Steps:**
1. As a Super Admin, confirm a student scores 35%.
2. Await the evaluation cycle.
3. Observe the result and verify the full behavior: the alert fires for the student.
**Expected Result:** The numeric threshold works — the alert fires when the value crosses the threshold, delivered exactly as documented.
**Priority:** Critical

### TC-SA-AR-04-012 — Temporal thresholds: time-based trigger conditions
**Type:** Positive
**Covers:** 4.2 → Temporal thresholds: time-based trigger conditions (days inactive, overdue)
**Preconditions:** A Super Admin account is active; an alert type with a temporal threshold (no activity for 7 days) exists.
**Steps:**
1. As a Super Admin, confirm a student has been inactive for 7 days.
2. Await the evaluation cycle.
3. Observe the result and verify the full behavior: the alert fires for the inactive student.
**Expected Result:** The temporal threshold works — the alert fires after the inactivity period, delivered exactly as documented.
**Priority:** Critical

### TC-SA-AR-04-013 — Per-alert-type thresholds: thresholds set per alert type
**Type:** Positive
**Covers:** 4.2 → Per-alert-type thresholds: thresholds set per alert type
**Preconditions:** A Super Admin account is active; two alert types exist.
**Steps:**
1. As a Super Admin, set different thresholds for each alert type and save.
2. Trigger conditions that cross one threshold but not the other.
3. Observe the result and verify the full behavior: only the alert type whose threshold was crossed fires.
**Expected Result:** The per-alert-type thresholds are applied — each type fires independently on its own threshold, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-014 — Segment overrides: thresholds overridden per student segment
**Type:** Positive
**Covers:** 4.2 → Segment overrides: thresholds overridden per student segment
**Preconditions:** A Super Admin account is active; a base threshold of 40% is set with a segment override of 50% for one segment.
**Steps:**
1. As a Super Admin, confirm a student in the overridden segment scores 45%.
2. Await the evaluation cycle.
3. Observe the result and verify the full behavior: the alert fires for the segment student (45% < 50% override) but not for a base-segment student at 45%.
**Expected Result:** The segment override is applied — the overridden segment uses its own threshold, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-015 — Threshold preview: a simulation of which students would trigger
**Type:** Positive
**Covers:** 4.2 → Threshold preview: a simulation of which students would trigger
**Preconditions:** A Super Admin account is active; thresholds are configured.
**Steps:**
1. As a Super Admin, run the threshold preview.
2. Observe the result and verify the full behavior: the preview lists the students who would currently trigger.
**Expected Result:** The threshold preview works — the would-trigger students are listed, delivered exactly as documented.
**Priority:** Medium

### TC-SA-AR-04-016 — Rule: invalid threshold values are rejected
**Type:** Negative
**Covers:** 4.2 → Rule: a threshold must be a valid value for its data source type; invalid values are rejected
**Preconditions:** A Super Admin account is active; an alert type with a percentage data source exists.
**Steps:**
1. As a Super Admin, set the threshold to a non-numeric value.
2. Attempt to save.
3. Observe the result and verify the full behavior: the save is rejected with a validation message.
**Expected Result:** The invalid threshold is rejected — the save fails with a validation message, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-017 — Rule: a segment override replaces the base threshold for that segment only
**Type:** Positive
**Covers:** 4.2 → Rule: a segment override replaces the base threshold for that segment only; other segments keep the base
**Preconditions:** A Super Admin account is active; a base threshold and one segment override are set.
**Steps:**
1. As a Super Admin, run the threshold preview.
2. Check students in the overridden segment and other segments.
3. Observe the result and verify the full behavior: only the overridden segment uses the override; others use the base.
**Expected Result:** The override is scoped — other segments keep the base threshold, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-018 — Rule: the threshold preview does not raise actual alerts
**Type:** Negative
**Covers:** 4.2 → Rule: the threshold preview is a point-in-time simulation; it does not raise actual alerts
**Preconditions:** A Super Admin account is active; thresholds are configured.
**Steps:**
1. As a Super Admin, run the threshold preview.
2. Check the alert inbox of the would-trigger students.
3. Observe the result and verify the full behavior: no actual alerts were raised by the preview.
**Expected Result:** The preview raises no alerts — it is a simulation only, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-019 — Rule: threshold changes take effect from the next evaluation cycle
**Type:** Positive
**Covers:** 4.2 → Rule: threshold changes take effect from the next evaluation cycle
**Preconditions:** A Super Admin account is active; an evaluation cycle is in progress.
**Steps:**
1. As a Super Admin, change a threshold mid-cycle and save.
2. Observe the in-progress cycle to completion.
3. Observe the result and verify the full behavior: the in-progress cycle uses the old threshold; the new threshold applies next cycle.
**Expected Result:** The threshold change applies from the next cycle — the in-progress cycle is unaffected, delivered exactly as documented.
**Priority:** Medium

### TC-SA-AR-04-020 — Rule: threshold changes are audit-logged
**Type:** Positive
**Covers:** 4.2 → Audit logging of threshold settings
**Preconditions:** A Super Admin account is active; the audit log is accessible.
**Steps:**
1. As a Super Admin, change a threshold and save.
2. Open the audit log.
3. Observe the result and verify the full behavior: the change is recorded with the actor and timestamp.
**Expected Result:** The threshold change is audit-logged — the actor and timestamp are recorded, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-021 — Escalation path: the sequence of recipients for unacknowledged alerts
**Type:** Positive
**Covers:** 4.3 → Escalation path: the sequence of recipients for unacknowledged alerts
**Preconditions:** A Super Admin account is active; an alert type has an escalation path (teacher → admin → super admin).
**Steps:**
1. As a Super Admin, trigger an alert that goes unacknowledged.
2. Observe the escalation over the delays.
3. Observe the result and verify the full behavior: the alert escalates teacher → admin → super admin in order.
**Expected Result:** The escalation path is followed — the alert escalates in the configured sequence, delivered exactly as documented.
**Priority:** Critical

### TC-SA-AR-04-022 — Escalation delay: the time before escalation to the next level
**Type:** Positive
**Covers:** 4.3 → Escalation delay: the time before escalation to the next level
**Preconditions:** A Super Admin account is active; an escalation delay of 24 hours is configured.
**Steps:**
1. As a Super Admin, trigger an unacknowledged alert.
2. Observe the timing of the first escalation.
3. Observe the result and verify the full behavior: the first escalation occurs after the configured delay.
**Expected Result:** The escalation delay is applied — escalation occurs after the configured time, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-023 — Maximum escalation level: the highest escalation level reached
**Type:** Positive
**Covers:** 4.3 → Maximum escalation level: the highest escalation level reached
**Preconditions:** A Super Admin account is active; the maximum escalation level is set to 2.
**Steps:**
1. As a Super Admin, trigger an alert that remains unacknowledged.
2. Observe the escalation to the maximum level.
3. Observe the result and verify the full behavior: escalation stops at the configured maximum level.
**Expected Result:** The maximum level is enforced — escalation stops at level 2, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-024 — Acknowledgement tracking: alert acknowledgement state per recipient
**Type:** Positive
**Covers:** 4.3 → Acknowledgement tracking: alert acknowledgement state per recipient
**Preconditions:** A Super Admin account is active; an alert has been escalated to two recipients.
**Steps:**
1. As a Super Admin, open the alert's acknowledgement tracking.
2. Observe the result and verify the full behavior: each recipient's acknowledgement state is shown.
**Expected Result:** The acknowledgement tracking is shown — per-recipient states are visible, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-025 — Escalation stop: escalation stops on acknowledgement
**Type:** Positive
**Covers:** 4.3 → Escalation stop: escalation stops on acknowledgement
**Preconditions:** A Super Admin account is active; an alert is at escalation level 1 and unacknowledged.
**Steps:**
1. As the level-1 recipient, acknowledge the alert.
2. Observe the escalation state.
3. Observe the result and verify the full behavior: no further escalation occurs.
**Expected Result:** The escalation stops — acknowledgement halts further escalation, delivered exactly as documented.
**Priority:** Critical

### TC-SA-AR-04-026 — Rule: informational alerts do not escalate by default
**Type:** Positive
**Covers:** 4.3 → Rule: escalation applies only to alert types with escalation enabled; informational alerts do not escalate by default
**Preconditions:** A Super Admin account is active; an informational alert type exists.
**Steps:**
1. As a Super Admin, trigger an informational alert that goes unacknowledged.
2. Observe over the escalation delay period.
3. Observe the result and verify the full behavior: no escalation occurs.
**Expected Result:** The informational alert does not escalate — no escalation occurs, delivered exactly as documented.
**Priority:** Medium

### TC-SA-AR-04-027 — Rule: reaching the maximum level stops escalation; the alert remains open
**Type:** Positive
**Covers:** 4.3 → Rule: reaching the maximum escalation level stops escalation; the alert remains open until acknowledged
**Preconditions:** A Super Admin account is active; an alert has reached the maximum escalation level unacknowledged.
**Steps:**
1. As a Super Admin, observe the alert past the maximum level's delay.
2. Check the alert state.
3. Observe the result and verify the full behavior: no further escalation; the alert remains open.
**Expected Result:** The alert remains open at the maximum level — no further escalation, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-028 — Rule: an unavailable recipient is skipped to the next level
**Type:** Positive
**Covers:** 4.3 → Rule: a recipient who is unavailable (inactive account) is skipped to the next level
**Preconditions:** A Super Admin account is active; the level-1 recipient has an inactive account.
**Steps:**
1. As a Super Admin, trigger an unacknowledged alert.
2. Observe the escalation.
3. Observe the result and verify the full behavior: the inactive level-1 recipient is skipped; the alert goes to level 2.
**Expected Result:** The unavailable recipient is skipped — the alert escalates to the next level, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-029 — Rule: escalation configuration changes are audit-logged
**Type:** Positive
**Covers:** 4.3 → Audit logging of escalation rule configuration
**Preconditions:** A Super Admin account is active; the audit log is accessible.
**Steps:**
1. As a Super Admin, change the escalation path and save.
2. Open the audit log.
3. Observe the result and verify the full behavior: the change is recorded with the actor and timestamp.
**Expected Result:** The escalation change is audit-logged — the actor and timestamp are recorded, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-030 — Channel routing: the channel(s) per alert type and severity
**Type:** Positive
**Covers:** 4.4 → Channel routing: the channel(s) per alert type and severity
**Preconditions:** A Super Admin account is active; channel routing is configured (warning = push + in-app).
**Steps:**
1. As a Super Admin, trigger a warning alert.
2. Check the delivery channels.
3. Observe the result and verify the full behavior: the alert is delivered on push and in-app only.
**Expected Result:** The channel routing is applied — the alert is delivered on the configured channels, delivered exactly as documented.
**Priority:** Critical

### TC-SA-AR-04-031 — Severity-based routing: critical alerts routed to higher-priority channels
**Type:** Positive
**Covers:** 4.4 → Severity-based routing: critical alerts routed to higher-priority channels
**Preconditions:** A Super Admin account is active; critical routing is set to push + SMS + email.
**Steps:**
1. As a Super Admin, trigger a critical alert.
2. Check the delivery channels.
3. Observe the result and verify the full behavior: the alert is delivered on push, SMS, and email.
**Expected Result:** The severity-based routing works — the critical alert uses the higher-priority channels, delivered exactly as documented.
**Priority:** Critical

### TC-SA-AR-04-032 — Quiet hours windows: the quiet hours start and end times
**Type:** Positive
**Covers:** 4.4 → Quiet hours windows: the quiet hours start and end times
**Preconditions:** A Super Admin account is active; quiet hours are set to 22:00–07:00.
**Steps:**
1. As a Super Admin, trigger a non-critical alert at 23:00.
2. Observe the delivery.
3. Observe the result and verify the full behavior: the alert is deferred (within the quiet hours window).
**Expected Result:** The quiet hours window is applied — the alert is deferred during 22:00–07:00, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-033 — Quiet hours scope: per recipient timezone or platform-wide
**Type:** Positive
**Covers:** 4.4 → Quiet hours scope: per recipient timezone or platform-wide
**Preconditions:** A Super Admin account is active; quiet hours scope is set to per recipient timezone.
**Steps:**
1. As a Super Admin, trigger a non-critical alert at a time that is within quiet hours for recipient A (their timezone) but outside for recipient B.
2. Observe both deliveries.
3. Observe the result and verify the full behavior: recipient A's alert is deferred; recipient B's is delivered.
**Expected Result:** The per-timezone scope works — deferral follows each recipient's timezone, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-034 — Deferral behavior: non-critical alerts deferred until quiet hours end
**Type:** Positive
**Covers:** 4.4 → Deferral behavior: non-critical alerts deferred until quiet hours end
**Preconditions:** A Super Admin account is active; quiet hours end at 07:00; a non-critical alert was raised at 23:00.
**Steps:**
1. As a Super Admin, observe the deferred alert after 07:00.
2. Observe the result and verify the full behavior: the alert is delivered once quiet hours end.
**Expected Result:** The deferral works — the alert is delivered when quiet hours end, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-035 — Critical bypass: critical alerts delivered immediately
**Type:** Positive
**Covers:** 4.4 → Critical bypass: critical alerts delivered immediately regardless of quiet hours
**Preconditions:** A Super Admin account is active; quiet hours are active.
**Steps:**
1. As a Super Admin, trigger a critical alert during quiet hours.
2. Observe the delivery.
3. Observe the result and verify the full behavior: the critical alert is delivered immediately.
**Expected Result:** The critical bypass works — the critical alert is delivered immediately, delivered exactly as documented.
**Priority:** Critical

### TC-SA-AR-04-036 — Rule: a deferred alert is delivered once at the end of quiet hours
**Type:** Positive
**Covers:** 4.4 → Rule: a deferred alert is delivered once, at the end of quiet hours, not repeatedly
**Preconditions:** A Super Admin account is active; a non-critical alert was deferred during quiet hours.
**Steps:**
1. As a Super Admin, observe the recipient's notifications after quiet hours end.
2. Observe the result and verify the full behavior: the alert is delivered exactly once.
**Expected Result:** The deferred alert is delivered once — no repeated delivery, delivered exactly as documented.
**Priority:** High

### TC-SA-AR-04-037 — Rule: an unrouted combination defaults to in-app only
**Type:** Positive
**Covers:** 4.4 → Rule: channel routing is per alert type and severity; an unrouted combination defaults to in-app only
**Preconditions:** A Super Admin account is active; an alert type/severity combination has no routing configured.
**Steps:**
1. As a Super Admin, trigger an alert of the unrouted combination.
2. Check the delivery channels.
3. Observe the result and verify the full behavior: the alert is delivered in-app only.
**Expected Result:** The default routing applies — the unrouted alert is delivered in-app only, delivered exactly as documented.
**Priority:** Medium

### TC-SA-AR-04-038 — Rule: routing and quiet hours changes are audit-logged
**Type:** Positive
**Covers:** 4.4 → Audit logging of channel routing and quiet hours configuration
**Preconditions:** A Super Admin account is active; the audit log is accessible.
**Steps:**
1. As a Super Admin, change the channel routing and quiet hours and save.
2. Open the audit log.
3. Observe the result and verify the full behavior: the changes are recorded with the actor and timestamp.
**Expected Result:** The routing/quiet hours changes are audit-logged — the actor and timestamp are recorded, delivered exactly as documented.
**Priority:** High