System Requirements Document for panic-alert

1. Introduction

panic-alert is an early-detection and panic-alert system for a fire fighting system. Its purpose is to detect fire conditions early — before they become fire incidents — and to raise panic alerts so that the people responsible for the site can acknowledge, confirm, escalate, and resolve them in time to prevent the fire from spreading.

The product is a life-safety instrument, not an administrative dashboard. It monitors the fire fighting system for early fire-detection signals, surfaces the current fire-condition status of every monitored zone, and turns any threshold breach into an unmissable panic alert that must be acknowledged and closed out.

The audience is the fire-safety crew of a monitored industrial site:

• Fire Safety Operator — watches live sensor and detection telemetry across long shifts, is the first to see an early-detection alert, and acts on it.
• Fire Safety Supervisor — owns the fire-prevention outcome across the site, reviews how alerts were handled, and tunes detection thresholds and monitored zones so early detection stays reliable.

Anonymous visitors may read what the system is and what it does on the public entry surface, but all monitoring, alert handling, review, and configuration work happens behind verified identity.

2. System Overview

panic-alert continuously monitors the fire fighting system for early fire-detection signals. When a monitored condition crosses its configured threshold, the system raises a panic alert, records the detection event, and presents the alert to the Fire Safety Operator as an unacknowledged alarm that must be triaged. The operator confirms the affected zone or asset, escalates or dispatches a response, and marks the alert resolved once it is handled. The Fire Safety Supervisor reviews the resulting alert history and detection events, verifies that alerts were acknowledged and resolved, and adjusts detection thresholds and monitored zones so coverage stays effective.

Current delivery is a first-party web application with a public entry surface, verified identity for protected work, and a set of operational and administrative destinations. Detection monitoring runs as background automation against the fire fighting system; the human-facing work of seeing, triaging, responding to, closing, reviewing, and configuring detection is delivered as custom application pages.

Actors

• Fire Safety Operator (human, active)
• Fire Safety Supervisor (human, active)
• The fire fighting system and its sensors (external monitored system — source of detection signals, not a persona)
• The application's background detection process (system actor — evaluates signals and raises alerts, not a persona)

Narrow exclusions

• No blue, indigo, cyan, or violet anywhere in the system; no white or near-white page grounds; no light mode as the default.
• No glassmorphism, frosted panels, gradient blobs, or soft pastel gradients.
• No rounded pill buttons or 20px+ corner radii on panels.
• No strobing or full-screen flashing alarm animations.
• No stock photography of fires, firefighters, or smiling office people; no clip art; no flat illustration.
• Amber is reserved exclusively for alarm meaning and is never used decoratively.
• No adjacent account-management capabilities beyond first-use identity establishment and returning verification.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. The product is delivered as a first-party web application. The public entry surface is anonymously reachable and introduces the system's fire early-detection and panic-alert purpose. All protected work — live monitoring, active alert handling, alert detail, response, closure, history review, and detection configuration — is owned by the application and requires verified identity. The fire fighting system and its sensors remain external: they supply detection signals, and the application owns the evaluation, alerting, and human-facing handling of those signals.

Identity boundary. Identity is application-owned. Fire Safety Operators and Fire Safety Supervisors are invited or provisioned before they can use protected functions, and returning users verify themselves through Login. The Login surface is itself anonymously reachable — it is the interaction that establishes access to the protected destinations, so it cannot sit behind them. Identity continuity exists so that alert acknowledgement, response, resolution, and configuration remain bound to the correct participant and can be resumed across shifts.

Current vs. future. Everything described in this document is current. No future-horizon capabilities are accepted at this time.

2b. Source Content Inventory

Not applicable — no reference directive in this project declares content_source authority.

2c. Page Content and Component Coverage

Landing

• Information / state: Anonymous introduction to the fire early-detection and panic-alert system and its fire-prevention purpose. Full-bleed graphite cockpit hero. Left seven columns carry a stacked Saira Condensed uppercase headline — DETECT THE FIRE / BEFORE THE FLAME — at 96px with the second line indented 96px and the word BEFORE in amber #FF7A1A. Beneath it, a live-looking instrument strip of three circular gauges (SMOKE, HEAT RISE, CO) with champagne needles and a ruled row of live values in tabular numerals. Right five columns carry a macro photograph of a sprinkler head or smoke detector on black, cropped edge-to-edge, crossed by a thin amber rule with the uppercase caption ZONE 04 — SUBLEVEL 2. Bottom edge carries a full-width 1px champagne hairline with a scrolling event ticker of simulated detection pings.
• Primary action: Enter the system (capsule button in amber with black text, sized to sit inside the gauge strip) → Login.
• Supporting actions: None beyond entry.
• Domain entities: Monitored zone (illustrative), detection reading (illustrative), event ping (illustrative).
• Component responsibilities: Hero headline block; three-gauge instrument strip with needle sweep and digit-by-digit count-up on first paint; ruled live-value row; macro imagery panel with amber rule and zone caption; champagne hairline with scrolling event ticker; topographic contour motif in #C8A96A at 12% opacity behind the hero.
• States: Loading — gauges rest at zero with bezels drawn, tick marks visible, values blank. Empty — not applicable; the hero always renders its illustrative instrument strip. Success — needles sweep to their resting values over 400ms cubic-bezier(0.22, 1, 0.36, 1) and numerals count up digit-by-digit. Error — if the illustrative strip cannot animate, it renders at final values with no motion. Recovery — reduced-motion preference renders the composed final frame with no sweep, no count-up, and no ticker scroll.

Login

• Information / state: Returning verification for Fire Safety Operators and Fire Safety Supervisors. Anonymous entry state; protected state remains unavailable until identity is established.
• Primary action: Verify identity and enter the protected system.
• Supporting actions: Recover from a failed verification attempt by retrying.
• Domain entities: User identity (Fire Safety Operator or Fire Safety Supervisor).
• Component responsibilities: Credential entry fields; submit control; inline failure message; link back to Landing.
• States: Loading — submit control shows a pending state while verification is in flight. Empty — fields render empty with labels and no error. Success — verification succeeds and the user lands on the destination appropriate to their work. Error — invalid credentials produce an inline message and the fields remain editable; no protected state is revealed. Recovery — the user corrects the entry and resubmits; repeated failure keeps the user on Login.

Monitoring

• Information / state: Live detection inputs and current fire-condition status for the monitored site. Dense instrument board: a 2×3 grid of circular gauges — smoke density, temperature rise rate, CO ppm, sprinkler line pressure, suppression tank, evacuation route status — above a full-width ruled event ticker. Every value is tabular, right-aligned, and carries a unit and a timestamp in the same row. A topographic site plan in #C8A96A at 12% opacity sits behind the zones map, with each monitored zone rendered as a small circular bezel that fills amber as its risk score rises.
• Primary action: Read current zone and sensor status; open an active alert when one is present.
• Supporting actions: Navigate to Active Alerts; navigate to Alert History (Supervisor); navigate to Detection Settings (Supervisor).
• Domain entities: Monitored zone, sensor reading (smoke density, temperature rise rate, CO ppm, sprinkler line pressure, suppression tank, evacuation route status), detection event, panic alert, risk score.
• Component responsibilities: Six circular gauges with champagne needles and tick marks; ruled data rows with champagne leader dots and right-aligned tabular numerals; zone bezel map over the topographic motif; full-width event ticker; left navigation rail with engraved instrument icons and a champagne active indicator bar, where the Alerts icon carries a live amber count badge that never animates on hover.
• States: Loading — gauges render at rest with bezels and ticks drawn and values blank. Empty — when no detection events have arrived, the ticker shows a ruled empty row and gauges hold their last known or resting values. Success — gauges sweep their needles on data update over 400ms cubic-bezier(0.22, 1, 0.36, 1) and numerals count up digit-by-digit to the new value. Error — a sensor feed that stops reporting is shown as a stale row with its last timestamp rather than a blank. Recovery — when the feed resumes, the gauge sweeps to the current value and the row timestamp updates.

Active Alerts

• Information / state: The operator's revisitable workspace for unacknowledged and in-progress panic alerts. Each alert reads as a ruled row with zone, condition, threshold breach, and time since raise. When an alert is active, the amber #FF7A1A bezel pulses twice, a 1px amber scan line travels the panel edge once every 3s while unacknowledged, and the page background lifts from #0D0F12 to #14100B.
• Primary action: Acknowledge an active panic alert.
• Supporting actions: Open an alert's details; return to Monitoring.
• Domain entities: Panic alert, monitored zone, detection event, acknowledgement record.
• Component responsibilities: Alert list of ruled rows; dominant alert panel at 8 columns with a 4-column action column; amber bezel pulse; 3s amber scan line; live amber count badge in the navigation rail.
• States: Loading — the list renders its ruled frame with placeholder rows. Empty — no active alerts: the panel shows a calm ruled state with no amber treatment and the background stays #0D0F12. Success — acknowledgement is a hard 120ms state snap with no easing; the alert leaves the unacknowledged set and the count badge decrements. Error — if acknowledgement cannot be recorded, the alert remains unacknowledged with its amber treatment intact and an inline failure message appears. Recovery — the operator retries acknowledgement; the alert stays visible and unacknowledged until it succeeds.

Alert Details

• Information / state: Active-alert detail, including the affected zone or asset, the breached condition, the threshold that was crossed, the reading that crossed it, and the time of the detection event.
• Primary action: Confirm the affected zone or asset and proceed to respond.
• Supporting actions: Return to Active Alerts; proceed to Response.
• Domain entities: Panic alert, detection event, monitored zone, asset, threshold, reading.
• Component responsibilities: Dominant alert panel at 8 columns; 4-column action column; ruled detail rows with champagne leader dots and right-aligned tabular numerals; amber scan line while the alert remains unacknowledged.
• States: Loading — detail rows render their ruled frame with values pending. Empty — not applicable; Alert Details is only reached from an existing alert. Success — the zone or asset is confirmed and the operator can move to Response. Error — if the alert is no longer active (already resolved elsewhere), the page states that plainly and offers a return to Active Alerts. Recovery — the operator returns to Active Alerts and continues from the current list.

Response

• Information / state: Escalation or dispatch of a response to an active alert, with the alert's zone, condition, and elapsed time held in view.
• Primary action: Escalate or dispatch a response for the active alert.
• Supporting actions: Return to Alert Details; proceed to Alert Closure once the response is handled.
• Domain entities: Panic alert, response action, escalation, dispatch, monitored zone.
• Component responsibilities: Dominant alert panel at 8 columns; 4-column action column; response action controls; ruled record of the response action taken with its timestamp.
• States: Loading — the response controls render disabled until the alert context is loaded. Empty — not applicable; Response is only reached from an existing alert. Success — the response action is recorded against the alert and the operator can proceed to closure. Error — if the response action cannot be recorded, the alert stays active and an inline failure message appears. Recovery — the operator retries the response action; the alert remains active until the action is recorded.

Alert Closure

• Information / state: Marking a handled alert as resolved, with the alert's zone, condition, response action taken, and elapsed time held in view.
• Primary action: Mark the handled alert as resolved.
• Supporting actions: Return to Active Alerts; return to Monitoring.
• Domain entities: Panic alert, resolution, response action, monitored zone.
• Component responsibilities: Dominant alert panel at 8 columns; 4-column action column; resolution control; ruled record of the resolution with its timestamp.
• States: Loading — the resolution control renders disabled until the alert context is loaded. Empty — not applicable; Alert Closure is only reached from an existing alert. Success — the alert is marked resolved, leaves the active set, and the count badge decrements. Error — if the resolution cannot be recorded, the alert stays active with its amber treatment intact and an inline failure message appears. Recovery — the operator retries resolution; the alert remains active until it succeeds.

Alert History

• Information / state: Past panic alerts and detection events for review, with how each alert was acknowledged and resolved. Ruled data rows with champagne leader dots and right-aligned tabular numerals; every value carries a unit and a timestamp in the same row.
• Primary action: Review past panic alerts and detection events.
• Supporting actions: Filter or narrow the reviewed set; return to Monitoring.
• Domain entities: Panic alert, detection event, acknowledgement record, response action, resolution, monitored zone, threshold.
• Component responsibilities: Ruled history rows; filter controls; left navigation rail with champagne active indicator bar.
• States: Loading — the history renders its ruled frame with placeholder rows. Empty — no past alerts: a ruled empty state with no amber treatment. Success — the reviewed set renders with acknowledgement and resolution visible per alert. Error — if history cannot be loaded, an inline failure message appears with a retry. Recovery — the supervisor retries the load; the previous view is preserved until it succeeds.

Detection Settings

• Information / state: Early-detection thresholds and monitored zones. Each threshold reads as a ruled row with its zone, condition, current value, and unit.
• Primary action: Configure early-detection thresholds and monitored zones.
• Supporting actions: Return to Monitoring; return to Alert History.
• Domain entities: Threshold, monitored zone, detection condition, unit.
• Component responsibilities: Ruled threshold rows with champagne leader dots and right-aligned tabular numerals; zone list; threshold edit controls; save control.
• States: Loading — threshold rows render their ruled frame with values pending. Empty — no monitored zones configured: a ruled empty state prompting zone configuration. Success — saved thresholds and zones take effect for subsequent detection evaluation. Error — if a save fails, the previous values remain in force and an inline failure message appears. Recovery — the supervisor corrects the entry and resaves; the previous values stay in force until the save succeeds.

3. Functional Requirements

FR-1 — Early fire detection and panic alerting As a Fire Safety Operator, I should be alerted early when fire conditions emerge in a monitored zone, so that the fire is prevented from spreading.

• Provenance: explicit
• Trigger / input: The fire fighting system reports detection signals for a monitored zone.
• Observable result: A panic alert is raised for the affected zone with its condition, threshold breach, and time of raise.
• Access state: Protected — requires verified identity.
• Failure / recovery: If the alert cannot be raised or recorded, the condition remains visible on Monitoring as a threshold breach and the alert is retried.
• Continuation: The operator proceeds to acknowledge the alert on Active Alerts.
• Acceptance: A threshold breach in a monitored zone produces a visible, unacknowledged panic alert naming the zone and the breached condition.

FR-2 — Monitoring the fire fighting system for early detection signals As a Fire Safety Operator, I should see live detection inputs and current fire-condition status for every monitored zone, so that I can judge the site's state at a glance.

• Provenance: explicit
• Trigger / input: Continuous detection signals from the fire fighting system.
• Observable result: Monitoring shows smoke density, temperature rise rate, CO ppm, sprinkler line pressure, suppression tank, and evacuation route status per zone, each with a unit and a timestamp.
• Access state: Protected — requires verified identity.
• Failure / recovery: A sensor feed that stops reporting is shown as a stale row with its last timestamp rather than a blank.
• Continuation: The operator opens an active alert when one is present, or continues watching.
• Acceptance: Every monitored zone's current readings are visible with units and timestamps, and a stale feed is distinguishable from a live one.

FR-3 — Acknowledging an active panic alert As a Fire Safety Operator, I should acknowledge an incoming panic alert, so that the team knows it has been seen and triage has begun.

• Provenance: required_inference
• Trigger / input: An unacknowledged panic alert on Active Alerts.
• Observable result: The alert leaves the unacknowledged set and the live amber count badge decrements; acknowledgement is a hard 120ms state snap with no easing.
• Access state: Protected — requires verified identity.
• Failure / recovery: If acknowledgement cannot be recorded, the alert remains unacknowledged with its amber treatment intact and an inline failure message appears; the operator retries.
• Continuation: The operator opens the alert's details.
• Acceptance: An acknowledged alert is no longer counted as unacknowledged, and a failed acknowledgement leaves the alert visibly unacknowledged.

FR-4 — Confirming the affected zone or asset As a Fire Safety Operator, I should confirm the affected zone or asset for an active alert, so that the response goes to the right place.

• Provenance: required_inference
• Trigger / input: An acknowledged alert opened on Alert Details.
• Observable result: The affected zone or asset, the breached condition, the crossed threshold, the reading that crossed it, and the detection event time are all visible.
• Access state: Protected — requires verified identity.
• Failure / recovery: If the alert is no longer active, the page states that plainly and offers a return to Active Alerts.
• Continuation: The operator proceeds to Response.
• Acceptance: The zone or asset is confirmed against the alert before any response is dispatched.

FR-5 — Escalating or dispatching a response As a Fire Safety Operator, I should escalate or dispatch a response to an active alert, so that the fire is prevented from spreading.

• Provenance: required_inference
• Trigger / input: A confirmed alert on Response.
• Observable result: The response action is recorded against the alert with its timestamp.
• Access state: Protected — requires verified identity.
• Failure / recovery: If the response action cannot be recorded, the alert stays active and an inline failure message appears; the operator retries.
• Continuation: The operator proceeds to Alert Closure once the response is handled.
• Acceptance: A dispatched or escalated response is recorded against the correct alert and remains visible on that alert.

FR-6 — Marking a handled alert as resolved As a Fire Safety Operator, I should mark a handled alert as resolved, so that the active set reflects only what still needs attention.

• Provenance: required_inference
• Trigger / input: A handled alert on Alert Closure.
• Observable result: The alert is marked resolved, leaves the active set, and the live amber count badge decrements.
• Access state: Protected — requires verified identity.
• Failure / recovery: If the resolution cannot be recorded, the alert stays active with its amber treatment intact and an inline failure message appears; the operator retries.
• Continuation: The operator returns to Active Alerts or Monitoring.
• Acceptance: A resolved alert no longer appears in the active set and its resolution is recorded with a timestamp.

FR-7 — Reviewing past panic alerts and detection events As a Fire Safety Supervisor, I should review past panic alerts and detection events, so that I can verify alerts were acknowledged and resolved.

• Provenance: required_inference
• Trigger / input: A review request on Alert History.
• Observable result: Past alerts and detection events render as ruled rows showing acknowledgement and resolution per alert.
• Access state: Protected — requires verified identity.
• Failure / recovery: If history cannot be loaded, an inline failure message appears with a retry; the previous view is preserved.
• Continuation: The supervisor adjusts thresholds or zones on Detection Settings when coverage proves inadequate.
• Acceptance: Each reviewed alert shows whether it was acknowledged and whether it was resolved.

FR-8 — Configuring early-detection thresholds and monitored zones As a Fire Safety Supervisor, I should configure early-detection thresholds and monitored zones, so that early detection stays reliable.

• Provenance: required_inference
• Trigger / input: Threshold or zone edits on Detection Settings.
• Observable result: Saved thresholds and zones take effect for subsequent detection evaluation.
• Access state: Protected — requires verified identity.
• Failure / recovery: If a save fails, the previous values remain in force and an inline failure message appears; the supervisor corrects and resaves.
• Continuation: The supervisor returns to Monitoring to confirm the new coverage.
• Acceptance: A saved threshold change alters which readings raise a panic alert, and a failed save leaves the previous values in force.

FR-9 — First-use identity establishment As a Fire Safety Operator or Fire Safety Supervisor, I should be invited or provisioned before using protected functions, so that alert handling and configuration stay bound to the correct participant.

• Provenance: required_inference
• Trigger / input: An invitation or provisioning action for a new fire-safety crew member.
• Observable result: The invited or provisioned person can verify identity and reach the protected destinations their work requires.
• Access state: Anonymous entry — the invitation or provisioning step precedes protected access.
• Failure / recovery: An invitation or provisioning that does not complete leaves the person without protected access; the step is repeated.
• Continuation: The person verifies identity through Login.
• Acceptance: A person who has not been invited or provisioned cannot reach protected monitoring, alert handling, history, or configuration.

FR-10 — Returning identity verification As a Fire Safety Operator or Fire Safety Supervisor, I should verify my identity through Login, so that I can resume protected monitoring, alert handling, history, or configuration.

• Provenance: required_inference
• Trigger / input: Credential entry on Login.
• Observable result: Verification succeeds and the user reaches the destination appropriate to their work.
• Access state: Anonymous entry — Login is reachable without identity; protected state remains unavailable until verification succeeds.
• Failure / recovery: Invalid credentials produce an inline message and the fields remain editable; no protected state is revealed, and the user retries.
• Continuation: The user proceeds to Monitoring, Active Alerts, Alert History, or Detection Settings.
• Acceptance: Protected destinations are unreachable without successful verification, and a failed attempt reveals no protected state.

FR-11 — Persisting detection events, alerts, responses, resolutions, thresholds, and zones As a Fire Safety Operator or Fire Safety Supervisor, I should have detection events, panic alerts, response actions, resolutions, thresholds, and monitored zones persisted, so that I can review and continue work across shifts.

• Provenance: required_inference
• Trigger / input: Any detection event, alert raise, acknowledgement, response action, resolution, threshold change, or zone change.
• Observable result: The record survives the session and is available on Alert History and Detection Settings.
• Access state: Protected — requires verified identity.
• Failure / recovery: A write that fails leaves the prior state in force and surfaces an inline failure message.
• Continuation: The operator or supervisor resumes from the persisted state on their next visit.
• Acceptance: An alert acknowledged in one session shows as acknowledged in a later session, and a saved threshold remains in force.

4. User Personas

Fire Safety Operator

Product context. The Operator works the monitoring position on long shifts, including nights, watching live sensor and detection telemetry from the fire fighting system. Their screen is a control-room instrument: a dense board of gauges and ruled data rows that must be readable at a glance across a room. They are the first person to see an early-detection alert when fire conditions emerge.

Primary goal. Every early-detection signal is seen, triaged, and acted on before it becomes a fire incident.

Distinct accepted responsibilities. The Operator monitors live detection inputs and current fire-condition status across all monitored zones; acknowledges incoming panic alerts; confirms the affected zone or asset; escalates or dispatches a response; and marks a handled alert as resolved. Their work is continuous and reactive — the value they add is speed and correct triage under an alarm, not analysis after the fact.

Relevant inputs and decisions. They read smoke density, temperature rise rate, CO ppm, sprinkler line pressure, suppression tank, and evacuation route status per zone, each with a unit and a timestamp. Their decisions are: is this alert real and which zone is it in; does it need escalation or dispatch; and is it now handled well enough to close.

Interactions with other accepted participants. The Operator is the counterparty to the Supervisor's review: the acknowledgement, response, and resolution the Operator records are exactly what the Supervisor later audits. The Operator does not configure thresholds or zones — that is the Supervisor's responsibility — so the Operator works within the detection coverage the Supervisor has set.

Observable success. Every alert the Operator saw carries an acknowledgement, a recorded response action, and a resolution with timestamps, and no early-detection signal was left unhandled.

Fire Safety Supervisor

Product context. The Supervisor owns the fire-prevention outcome across the monitored site. They do not sit the monitoring position continuously; they come to the system to audit how alerts were handled and to keep detection