System Requirements Document for safevision-ai

1. Introduction

SafeVision AI is a mobile camera application that uses Artificial Intelligence (AI) to analyze the user's surroundings in real time through the smartphone camera, helping identify potential hazards and provide safety recommendations. The application uses the smartphone camera as a visual sensor; the AI analyzes objects, environmental conditions, obstacles, roads, vehicles, humans, fire, smoke, puddles, damaged areas, and other risky conditions. Analysis results are displayed directly as an overlay on top of the camera view.

The product is a working application, not a mockup. It is built for pedestrians, cyclists, low-vision users, night-shift workers, and field crews who use it outdoors, in glare, one-handed, while moving. The emotional register is instrument-grade vigilance: a tool you trust in bad light, that reads like a wrist instrument rather than a phone app. High outdoor contrast is a hard requirement, so the interface lives on a dark instrument ground with luminous amber/teal signals, never on white.

The application is explicitly a safety aid, not a replacement for human vision, safety officers, signage, or professional navigation. It must never claim that an environment is truly safe; when the AI finds no risk it uses the term "tidak terdeteksi bahaya" (no hazard detected). All path recommendations are labeled as estimates based on what the camera sees.

2. System Overview

SafeVision AI is delivered as a mobile application with a full-bleed camera workspace as its primary surface. The camera feed is the only imagery; all other visual elements are engineered instrument chrome. The app runs AI computer vision analysis on sampled camera frames at adaptive intervals, overlays hazard markers, risk levels, safety advice, and safe-path estimates on the live camera view, and speaks warnings through text-to-speech so the user does not have to keep looking at the screen.

Current delivery includes: real-time AI camera scanning with periodic frame analysis; hazard detection across a broad visual taxonomy; danger bounding boxes with labels that track object motion; four-level risk assessment with short explanations; prioritized safety advice; safe-path analysis with directional indicators; multiple-hazard display with priority; voice assistant with ON/OFF control; emergency warning with large display and sound but no automatic emergency call; tappable hazard markers with AI explanation; locally stored scan history with delete option; privacy controls including consent-gated upload, local processing when supported, no permanent recording by default, and no face/identity recognition; and additional features including flash, zoom, front/back camera, screenshot, night mode, detection sensitivity settings, Indonesian and English languages, text-to-speech, haptic warning, detection history, and first-time tutorial.

Actors: the Safety Camera User (primary operator), the History and Settings Reviewer (manages analysis results and app preferences), and the First-Time Tutorial User (learns AI limits and scan flow). These are the accepted active human personas. The AI computer vision backend/API is a non-persona system actor.

Narrow exclusions: no automatic emergency calls; no continuous camera video upload without user consent; no permanent camera recording by default; no face/identity recognition to identify people; no fabricated hazards; no overconfident safety instructions; no claim of "AMAN" or "jalur aman"; no AI inference on every frame when it causes device heat or battery drain.

2a. Product Interpretation and Delivery Boundary

SafeVision AI is a first-party mobile application owned and delivered by the application itself. All accepted human-facing behavior — scanning, hazard review, advice, safe-path viewing, voice control, emergency warning, history, settings, screenshots, tutorial, and uncertainty handling — is owned by the application's own pages. There is no provider-owned or external-only surface for the accepted human work; the AI computer vision backend/API is a supporting system actor that the application calls, not a destination the user visits.

Access ownership: the accepted journeys do not require application-owned identity, private durable actor-specific state, or commitments bound to a specific participant. Scan history and settings are stored locally on the device and are not tied to an account. The Landing entry is anonymous and explains SafeVision AI, its target users, and its safety-analysis function before the camera is used. Camera Permission handles the camera grant before the scan flow begins. No account creation, login, or profile management is part of the current delivery.

Current versus future boundary: everything described in this document is current. No future-horizon requirements were accepted in the authoritative thread. The emergency assistance feature is conditional — "jika tersedia fitur bantuan darurat" (if an emergency assistance feature is available) — and when present it requires user confirmation before any action; it never places an automatic call.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares content_source; the authoritative sources are the user-authored requirement thread and the Planning Scope contract, which supply product requirements rather than a verified factual content collection.

2c. Page Content and Component Coverage

The following pages are the closed ordered page contract. Each page is represented exactly once.

Landing

• Information/state: Anonymous entry that explains SafeVision AI, its target users, and its safety-analysis function before the camera is used. States that the app is a safety aid, not a replacement for human vision, safety officers, signage, or professional navigation. States that the app never claims an environment is truly safe and uses "tidak terdeteksi bahaya" when no risk is found.
• Primary actions: Enter the app to begin the camera permission flow; open the Tutorial.
• Supporting actions: Read the AI-limits and privacy summary.
• Domain entities: Product identity, AI-limits statement, privacy summary, target-user description.
• Component responsibilities: Instrument-ground hero with condensed uppercase product wordmark; ruled summary rows for AI limits and privacy; entry control to proceed to Camera Permission; link to Tutorial.
• States: Loading (initial asset/state resolution), empty (no prior session), success (entry ready), error (asset load failure with retry), recovery (retry entry).

Camera Permission

• Information/state: Explains that camera access must be granted before the camera can activate. Shows current permission status (not yet requested, granted, denied).
• Primary actions: Request camera permission; proceed to Scanner when granted.
• Supporting actions: Open device settings guidance when permission is denied; return to Landing.
• Domain entities: Camera permission status, permission rationale.
• Component responsibilities: Permission rationale panel; request control; denied-state guidance with settings path; retry control.
• States: Loading (permission check), empty (not yet requested), success (granted, proceed), error (denied with guidance), recovery (re-request or open settings).

Tutorial

• Information/state: First-time tutorial covering how to use the scan flow, AI limitations, the meaning of "tidak terdeteksi bahaya", the estimate label on path recommendations, and when images/video are sent to the AI server plus local processing mode. Uses macro-style technical line-art diagrams: a phone held at chest height with a ruled sightline, a bounding-box corner-tick diagram, and a bezel gauge legend. No photography of people's faces, no stock humans, no decorative illustration.
• Primary actions: Step through tutorial pages; complete tutorial and proceed to Scanner.
• Supporting actions: Revisit tutorial from Settings; skip to Scanner.
• Domain entities: Tutorial steps, AI-limits content, privacy/processing-mode content, diagram assets.
• Component responsibilities: Step container with ruled progress; diagram panel; explanatory text blocks; next/back controls; completion control.
• States: Loading (tutorial content), empty (not applicable), success (completed), error (content load failure with retry), recovery (retry or skip).

Scanner

• Information/state: Camera workspace for starting, pausing, and selecting the scanning camera. Shows the live camera feed full-bleed with instrument chrome: top status rail (AI state, FPS/sampling indicator, battery-aware note), left-edge vertical risk gauge (Rendah→Kritis as a 4-segment bezel scale), bottom control deck (scan bezel, voice toggle, flash, zoom, camera flip, settings), and a right-edge pull-tab that opens the Analysis Dashboard.
• Primary actions: Press "Mulai Scan" to start scanning; press pause to stop scanning; flip front/back camera; toggle flash; adjust zoom; toggle voice; open settings; pull the right-edge tab to open the Analysis Dashboard.
• Supporting actions: Take a screenshot of the analysis result; open History.
• Domain entities: Camera stream, scan state (idle/scanning/paused), sampling interval, camera selection, flash mode, zoom level, voice state, battery-aware sampling note.
• Component responsibilities: Full-bleed camera viewport; 96px circular scan bezel with amber index sweep that rotates while scanning and freezes when paused, doubling as pause button and sampling-rate indicator (inner arc shortens when the app drops to battery-saver sampling); top status rail; left-edge risk bezel with needle and tabular hazard counter; bottom control deck with 44px targets; right-edge pull-tab.
• States: Loading (camera initialization), empty (camera not yet started), success (scanning active), error (camera unavailable or permission lost), recovery (re-request permission or restart camera).

AI Status

• Information/state: Displays periodic analysis results and AI status without claiming the environment is definitely safe. Status values: AMAN, WASPADA, BAHAYA, DARURAT. When no risk is found, displays "tidak terdeteksi bahaya" instead of a safety claim. Shows the AI state in 40–96px condensed uppercase ("TIDAK TERDETEKSI BAHAYA" in teal, "WASPADA" in amber, "BAHAYA TINGGI" in red).
• Primary actions: Read current AI status; observe status changes as analysis updates.
• Supporting actions: Open Analysis Dashboard for detail.
• Domain entities: AI status value, analysis timestamp, sampling indicator.
• Component responsibilities: Status display with condensed uppercase typography; status color mapping (teal for no hazard detected, amber for WASPADA, red for BAHAYA TINGGI/DARURAT); sampling/FPS indicator.
• States: Loading (awaiting first analysis), empty (no analysis yet), success (status displayed), error (analysis unavailable), recovery (resume analysis).

Camera Overlay

• Information/state: Displays markers, bounding boxes, hazard labels, direction arrows, and estimated paths on the camera view. Each detected hazard gets four L-shaped chamfered corner ticks in its risk color with a hairline inner frame and a ruled label plate pinned to the top-left tick, so the object stays fully visible inside the frame. Markers track object motion when the camera moves.
• Primary actions: Tap a hazard marker to open Hazard Details; observe marker positions as they track objects.
• Supporting actions: Read hazard labels and risk indicators.
• Domain entities: Hazard markers, bounding-box corner ticks, hazard labels, direction arrows, safe-path chevrons, risk-level indicators.
• Component responsibilities: Absolutely positioned hazard markers in the camera viewport; bracket-corner drawing (180ms draw-in, then hold; corners translate with tracked objects, never re-animate); ruled label plates; safe-path chevron with estimate label; risk-color mapping.
• States: Loading (awaiting detections), empty (no hazards detected), success (markers displayed), error (overlay render failure), recovery (re-render on next analysis).

Risk Levels

• Information/state: Explains the risk level and reason for each hazard. Levels: Rendah, Sedang, Tinggi, Kritis. Provides a short reason for the assessment (example: "Risiko tinggi: kendaraan berada sangat dekat dan bergerak menuju area Anda."). Risk escalation is a color ramp within the instrument logic: Rendah #3FD1C7, Sedang #E8A33D, Tinggi #F0603A, Kritis #FF2E3F (reserved exclusively for the DARURAT full-screen warning).
• Primary actions: Read risk level and reason for each hazard.
• Supporting actions: Open Hazard Details for full explanation.
• Domain entities: Risk level, risk reason, risk color mapping.
• Component responsibilities: Risk level display; reason text; color ramp application; tabular numerals for counters.
• States: Loading (awaiting risk assessment), empty (no hazards), success (levels displayed), error (assessment unavailable), recovery (re-assess on next analysis).

Safety Advice

• Information/state: Presents the recommended action after a hazard is detected. When multiple action options exist, priority order is: 1) safest action, 2) alternative, 3) things to avoid. Example: "⚠️ Ada kendaraan mendekat dari kanan." / "Saran: berhenti sejenak dan jangan melintas sampai kendaraan menjauh."
• Primary actions: Read the prioritized advice.
• Supporting actions: Open Hazard Details for the associated hazard.
• Domain entities: Recommended action, alternative action, action to avoid, priority order.
• Component responsibilities: Ruled advice rows with priority labels; safest-action emphasis; alternative and avoid rows.
• States: Loading (awaiting advice), empty (no advice), success (advice displayed), error (advice unavailable), recovery (re-request on next analysis).

Safe Paths

• Information/state: Displays the estimate of a relatively safer direction based on detected hazards. Indicators:\x20\xf0\x9f\x9f\xa2 Jalur relatif lebih aman,\x20\xf0\x9f\x9f\xa1 Perlu waspada,\x20\xf0\x9f\x94\xb4 Hindari. Shows lines/arrows on screen for the suggested direction. Example: "Jalur depan terhalang." / "Alternatif yang terlihat lebih aman: bergerak ke sisi kiri." Always labeled as "jalur yang tampak lebih aman berdasarkan gambar kamera" — never stated as definitely safe.
• Primary actions: Read the suggested direction and indicator.
• Supporting actions: Observe the on-screen arrow/line.
• Domain entities: Path indicator, suggested direction, estimate label.
• Component responsibilities: Directional arrow/line overlay; indicator color mapping; estimate label plate; safe-path chevron sweep (single amber chevron sweeps left across the lower third on first detection).
• States: Loading (awaiting path analysis), empty (no path estimate), success (path displayed), error (path analysis unavailable), recovery (re-analyze on next frame).

Hazards

• Information/state: Displays all detected hazards simultaneously with position and priority. Example:\x20\xe2\x9a\xa0️ Kendaraan — kanan,\x20\xe2\x9a\xa0️ Lubang — depan,\x20\xe2\x9a\xa0️ Genangan — kiri. Then provides priority: "Bahaya utama: kendaraan di kanan." / "Disarankan berhenti dan menunggu kendaraan lewat."
• Primary actions: Read the full hazard list and primary-hazard priority.
• Supporting actions: Tap a hazard to open Hazard Details.
• Domain entities: Hazard list, hazard type, relative position, risk level, primary hazard, priority advice.
• Component responsibilities: Ruled hazard rows (Jenis | Lokasi | Risiko); primary-hazard emphasis; priority advice block.
• States: Loading (awaiting detections), empty (no hazards detected), success (hazards listed), error (detection unavailable), recovery (re-detect on next analysis).

Voice Alerts

• Information/state: Manages text-to-speech warnings and the Voice ON/OFF control. Voice examples: "Perhatian. Ada kendaraan dari kanan." / "Jangan maju." / "Jalur depan memiliki rintangan." / "Area kiri tampak lebih memungkinkan untuk dilewati."
• Primary actions: Toggle Voice ON/OFF; hear spoken warnings.
• Supporting actions: Adjust voice-related settings in Settings.
• Domain entities: Voice state (on/off), spoken warning text, TTS engine.
• Component responsibilities: Voice toggle control (\xf0\x9f\x94\x8a Voice ON/OFF); TTS playback; warning text queue.
• States: Loading (TTS engine init), empty (no warnings), success (voice active), error (TTS unavailable), recovery (fall back to visual-only warnings).

Emergency Warning

• Information/state: Displays a large warning and uses sound when the AI detects a potentially very dangerous condition. Example: "BAHAYA TINGGI" / "BERHENTI DAN PERIKSA LINGKUNGAN." On KRITIS the entire screen frame becomes a 12px red bezel with the warning in condensed uppercase across two ruled bands, the risk needle slams to KRITIS, and a triple haptic pulse fires once. No automatic emergency call. If an emergency assistance feature is available, the user must confirm first.
• Primary actions: Read the large warning; confirm before any emergency assistance action.
• Supporting actions: Dismiss the warning after acknowledging.
• Domain entities: Emergency condition, warning text, confirmation state, haptic pulse.
• Component responsibilities: Full-bezel takeover with 12px red bezel; two ruled warning bands; confirm-gated emergency button beneath; single 2-beat amber→red flash plus triple haptic pulse (no continuous strobing).
• States: Loading (evaluating emergency condition), empty (no emergency), success (warning displayed), error (warning render failure), recovery (re-evaluate on next analysis).

Hazard Details

• Information/state: Explains the selected marker: what was detected, location relative to the camera, risk level, why it is considered dangerous, and recommended action.
• Primary actions: Read the full hazard explanation; close the detail view.
• Supporting actions: Navigate between hazards.
• Domain entities: Detected object, relative location, risk level, danger reason, recommended action.
• Component responsibilities: Detail panel with ruled label/value rows; close control; navigation between hazards.
• States: Loading (detail resolution), empty (no hazard selected), success (detail displayed), error (detail unavailable), recovery (re-select hazard).

Analysis Dashboard

• Information/state: Summary panel showing status (example: "⚠️ WASPADA"), the list of detected hazards with position and risk level (example: 1. Kendaraan — kanan — risiko tinggi; 2. Lubang — depan — risiko sedang; 3. Genangan — kiri — risiko rendah), and a recommendation (example: "Kurangi kecepatan/pergerakan dan tunggu kendaraan menjauh. Setelah itu pilih area yang tampak lebih bebas dari rintangan."). Uses a strict 4-column ruled grid with label/value rows (Jenis | Lokasi | Risiko | Alasan), never cards. Opened by pulling a right-edge tab so the camera never leaves the screen. At 1280px it opens as a persistent 380px right rail beside the camera.
• Primary actions: Read status, hazard list, and recommendation; close the panel.
• Supporting actions: Tap a hazard row to open Hazard Details.
• Domain entities: Status, hazard list, position, risk level, recommendation.
• Component responsibilities: Ruled instrument panel with 4-column grid; hairline rules; tabular numerals; faint topographic contour overlay texture at 4%; right-edge pull-tab; responsive rail at 1280px.
• States: Loading (panel data), empty (no hazards), success (panel displayed), error (data unavailable), recovery (refresh on next analysis).

History

• Information/state: Reviews and deletes locally stored analysis history. Each entry contains: time, number of hazards detected, hazard types, and risk level.
• Primary actions: Review history entries; delete history.
• Supporting actions: Open an entry for detail.
• Domain entities: History entry (time, hazard count, hazard types, risk level), local storage.
• Component responsibilities: Ruled history list; entry rows with tabular numerals; delete control with confirmation; empty-state message.
• States: Loading (history read), empty (no history), success (entries listed), error (storage read failure), recovery (retry read).

Settings

• Information/state: Manages detection sensitivity, camera selection, flash, zoom, night mode, language (Indonesian/English), voice, and haptic. Also provides access to revisit the Tutorial.
• Primary actions: Adjust detection sensitivity; select camera; set flash mode (auto/manual); set zoom; toggle night mode; select language; toggle voice; toggle haptic.
• Supporting actions: Revisit Tutorial; return to Scanner.
• Domain entities: Sensitivity setting, camera selection, flash mode, zoom level, night mode state, language setting, voice state, haptic state.
• Component responsibilities: Ruled settings rows with label/value controls; toggle controls; selection controls; tutorial link.
• States: Loading (settings read), empty (defaults), success (settings applied), error (settings write failure), recovery (revert to last valid value).

Screenshots

• Information/state: Captures the analysis result for the user. Shows captured screenshots and provides access to them.
• Primary actions: Take a screenshot of the analysis result; view captured screenshots.
• Supporting actions: Delete a screenshot.
• Domain entities: Screenshot image, capture timestamp.
• Component responsibilities: Capture control; screenshot gallery/list; delete control.
• States: Loading (capture processing), empty (no screenshots), success (screenshot saved), error (capture failure), recovery (retry capture).

Uncertainty

• Information/state: Displays a warning when the image is blurry, too dark, the object is occluded, or the AI is not confident: "⚠️ Tidak yakin — periksa lingkungan secara langsung." The AI must not fabricate hazards that are not visible and must not give overconfident safety instructions.
• Primary actions: Read the uncertainty warning; check the environment directly.
• Supporting actions: Adjust lighting or position and resume scanning.
• Domain entities: Uncertainty condition, warning text.
• Component responsibilities: Uncertainty warning banner; confidence indicator; guidance text.
• States: Loading (confidence evaluation), empty (no uncertainty), success (warning displayed), error (evaluation unavailable), recovery (re-evaluate on next frame).

3. Functional Requirements

Each requirement is a distinct story point with provenance, lifecycle facts, and observable acceptance.

FR-01 — Real-time AI camera analysis (explicit) As a Safety Camera User, I should point the smartphone camera at my surroundings so that the AI analyzes objects, environmental conditions, obstacles, roads, vehicles, humans, fire, smoke, puddles, damaged areas, and other risky conditions in real time.

• Trigger/input: Camera feed active.
• Observable result: Analysis results displayed directly as an overlay on top of the camera view.
• Access state: Anonymous; camera permission required.
• Failure/recovery: If analysis is unavailable, show an error state and resume on the next frame.
• Continuation: Overlay updates as new frames are analyzed.

FR-02 — AI Camera Scanner with rear camera and periodic analysis (explicit) As a Safety Camera User, I should use the smartphone's rear camera and have camera frames analyzed periodically by the AI so that scanning runs continuously while I move.

• Trigger/input: Press "Mulai Scan".
• Observable result: Camera active; frames analyzed at periodic intervals.
• Access state: Anonymous; camera permission required.
• Failure/recovery: If the camera is unavailable or permission is lost, show an error and allow re-request.
• Continuation: Scanning continues until paused.

FR-03 — AI status display without safety claims (explicit) As a Safety Camera User, I should see the AI status as AMAN, WASPADA, BAHAYA, or DARURAT, and when no risk is found I should see "tidak terdeteksi bahaya" instead of a claim that the environment is truly safe.

• Trigger/input: Periodic analysis result.
• Observable result: Status displayed in condensed uppercase with instrument color mapping.
• Access state: Anonymous.
• Failure/recovery: If status is unavailable, show an error state and resume on next analysis.
• Continuation: Status updates as analysis continues.

FR-04 — Hazard detection taxonomy (explicit) As a Safety Camera User, I should have the AI attempt to detect approaching vehicles, motorcycles and cars, people too close, road obstacles, potholes or damaged road surfaces, stairs and elevation changes, puddles, fire, smoke, cables or objects blocking the path, falling objects, areas that appear slippery, blocked doors or paths, dark areas with low visibility, large objects that may block the user, risky traffic conditions, and other visually recognizable hazards.

• Trigger/input: Camera frames.
• Observable result: Detected hazards listed and marked.
• Access state: Anonymous.
• Failure/recovery: If a hazard cannot be recognized, it is not fabricated; uncertainty is shown instead.
• Continuation: Detection continues on subsequent frames.

FR-05 — Danger bounding boxes with tracking (explicit) As a Safety Camera User, I should see each detected hazard marked with a box/marker on the camera screen, labeled with examples such as "⚠️ KENDARAAN", "⚠️ LUBANG", "⚠️ ASAP", "⚠️ RINTANGAN", and the marker should follow the object's position when the camera moves.

• Trigger/input: Hazard detection.
• Observable result: Bracket-corner markers with ruled labels positioned on the hazard; corners translate with tracked objects.
• Access state: Anonymous.
• Failure/recovery: If tracking is lost, the marker is removed; no fabricated marker is shown.
• Continuation: Markers update as the camera moves.

FR-06 — Risk level with short reason (explicit) As a Safety Camera User, I should see each hazard's risk level as Rendah, Sedang, Tinggi, or Kritis, with a short reason for the assessment (example: "Risiko tinggi: kendaraan berada sangat dekat dan bergerak menuju area Anda.").

• Trigger/input: Hazard detection.
• Observable result: Risk level and reason displayed.
• Access state: Anonymous.
• Failure/recovery: If assessment is unavailable, show an error state and re-assess on next analysis.
• Continuation: Risk levels update as conditions change.

FR-07 — Prioritized AI safety advice (explicit) As a Safety Camera User, I should see recommended actions after a hazard is detected, and when multiple action options exist the priority order should be: 1) safest action, 2) alternative, 3) things to avoid.

• Trigger/input: Hazard detection.
• Observable result: Prioritized advice displayed (example: "⚠️ Ada kendaraan mendekat dari kanan." / "Saran: berhenti sejenak dan jangan melintas sampai kendaraan menjauh.").
• Access state: Anonymous.
• Failure/recovery: If advice is unavailable, show an error state and re-request on next analysis.
• Continuation: Advice updates as hazards change.

FR-08 — Safe path analysis with estimate labeling (explicit) As a Safety Camera User, I should have the AI analyze the visible camera area and show a relatively safer direction based on detected hazards, using indicators\x20\xf0\x9f\x9f\xa2 Jalur relatif lebih aman,\x20\xf0\x9f\x9f\xa1 Perlu waspada,\x20\xf0\x9f\x94\xb4 Hindari, with lines/arrows on screen for the suggested direction (example: "Jalur depan terhalang." / "Alternatif yang terlihat lebih aman: bergerak ke sisi kiri."), and the path must never be stated as definitely safe — it must use the term "jalur yang tampak lebih aman berdasarkan gambar kamera".

• Trigger/input: Hazard detection and visible area analysis.
• Observable result: Directional arrow/line with indicator and estimate label.
• Access state: Anonymous.
• Failure/recovery: If path analysis is unavailable, show an error state and re-analyze on next frame.
• Continuation: Path estimate updates as hazards change.

FR-09 — Multiple hazard detection with priority (explicit) As a Safety Camera User, I should see all hazards displayed simultaneously when many exist (example:\x20\xe2\x9a\xa0️ Kendaraan — kanan,\x20\xe2\x9a\xa0️ Lubang — depan,\x20\xe2\x9a\xa0️ Genangan — kiri), and the AI should then provide priority (example: "Bahaya utama: kendaraan di kanan." / "Disarankan berhenti dan menunggu kendaraan lewat.").

• Trigger/input: Multiple hazards detected.
• Observable result: Full hazard list with positions and primary-hazard priority.
• Access state: Anonymous.
• Failure/recovery: If detection is unavailable, show an error state and re-detect on next analysis.
• Continuation: List and priority update as hazards change.

FR-10 — Voice assistant with ON/OFF control (explicit) As a Safety Camera User, I should hear AI voice warnings so I do not have to keep looking at the screen (examples: "Perhatian. Ada kendaraan dari kanan." / "Jangan maju." / "Jalur depan memiliki rintangan." / "Area kiri tampak lebih memungkinkan untuk dilewati."), and I should have a 🔊 Voice ON/OFF button.

• Trigger/input: Hazard detection or user toggle.
• Observable result: Spoken warnings when voice is on; silence when off.
• Access state: Anonymous.
• Failure/recovery: If TTS is unavailable, fall back to visual-only warnings.
• Continuation: Voice state persists for the session.

FR-11 — Emergency warning without automatic call (explicit) As a Safety Camera User, I should see a large warning and hear sound when the AI detects a potentially very dangerous condition (example: "BAHAYA TINGGI" / "BERHENTI DAN PERIKSA LINGKUNGAN."), and the app must not make an automatic emergency call; if an emergency assistance feature is available, I must confirm first.

• Trigger/input: Potentially very dangerous condition detected.
• Observable result: Full-bezel warning with 12px red bezel, two ruled warning bands, single 2-beat amber→red flash, and triple haptic pulse.
• Access state: Anonymous.
• Failure/recovery: If warning render fails, re-evaluate on next analysis.
• Continuation: Warning dismisses after acknowledgment; no automatic call is placed.

FR-12 — Tappable hazard markers with AI explanation (explicit) As a Safety Camera User, I should be able to tap a hazard marker to see what was detected, its location relative to the camera, its risk level, why it is considered dangerous, and the recommended action.

• Trigger/input: Tap on a hazard marker.
• Observable result: Hazard Details panel with the five explanation elements.
• Access state: Anonymous.
• Failure/recovery: If detail is unavailable, show an error state and allow re-selection.
• Continuation: Return to the camera view.

FR-13 — Local scan history with delete (explicit) As a History and Settings Reviewer, I should have analysis history stored locally containing time, number of hazards detected, hazard types, and risk level, and I should have the option to delete the history.

• Trigger/input: Open History; select delete.
• Observable result: History entries listed; delete removes them.
• Access state: Anonymous; local device storage.
• Failure/recovery: If storage read fails, show an error and allow retry.
• Continuation: History updates as new analyses complete.

FR-14 — Privacy controls (explicit) As a Safety Camera User, I should have the app not upload camera video continuously without my consent, explain when images/video are sent to the AI server, provide a local processing mode if the technology/model supports it, not store camera recordings permanently by default, and not perform identity/face recognition to identify people.

• Trigger/input: Camera use; consent decision.
• Observable result: Consent-gated upload; processing-mode explanation; no permanent recording by default; no face/identity recognition.
• Access state: Anonymous.
• Failure/recovery: If consent is not given, upload does not occur; local processing is used when available.
• Continuation: Privacy state persists for the session.

FR-15 — High-contrast outdoor UI with fullscreen camera and controls (explicit) As a Safety Camera User, I should have a modern, futuristic, simple, and easy-to-use design with a fullscreen camera view, start/pause scanning button, AI status, risk indicator, voice button, and settings button on the main page, and camera overlay with bounding boxes on hazardous objects, hazard labels, direction arrows, relatively safer path, and risk-level indicators, using high-contrast design so information is easy to see outdoors.

• Trigger/input: App use.
• Observable result: Instrument-ground UI with luminous amber/teal signals; full-bleed camera; anchored instrument chrome.
• Access state: Anonymous.
• Failure/recovery: If a control fails, show an error state and allow retry.
• Continuation: UI remains usable while moving.

FR-16 — Analysis Dashboard panel (explicit) As a Safety Camera User, I should be able to open an analysis panel that shows status (example: "⚠️ WASPADA"), the list of detected hazards with position and risk level (example: 1. Kendaraan — kanan — risiko tinggi; 2. Lubang — depan — risiko sedang; 3. Genangan — kiri — risiko rendah), and a recommendation (example: "Kurangi kecepatan/pergerakan dan tunggu kendaraan menjauh. Setelah itu pilih area yang tampak lebih bebas dari rintangan.").

• Trigger/input: Pull the right-edge tab.
• Observable result: Ruled instrument panel with 4-column grid (Jenis | Lokasi | Risiko | Alasan) sliding over the camera.
• Access state: Anonymous.
• Failure/recovery: If panel data is unavailable, show an error state and refresh on next analysis.
• Continuation: Close the panel and return to the camera.

FR-17 — Technology stack (explicit) As a Safety Camera User, I should have the app use mobile camera API, AI computer vision, object detection, image segmentation when available, depth estimation when the device supports it, GPS only when needed for location-based features, text-to-speech for voice warnings, a secure AI backend/API, and local processing when possible.

• Trigger/input: App operation.
• Observable result: Features delivered through the specified technologies.
• Access state: Anonymous.
• Failure/recovery: If a technology is unavailable on the device, degrade gracefully to available capabilities.
• Continuation: Available technologies are used on subsequent frames.

FR-18 — Low-spec optimization with adaptive sampling (explicit) As a Safety Camera User, I should have the app optimized to run on low-specification smartphones, and the AI must not perform inference on every frame if it causes the device to heat up or drain the battery; adaptive interval/frame sampling must be used.

• Trigger/input: Device performance and thermal/battery state.
• Observable result: Adaptive sampling interval; battery-aware note in the top status rail; scan bezel inner arc shortens when the app drops to battery-saver sampling.
• Access state: Anonymous.
• Failure/recovery: If the device overheats, reduce sampling further.
• Continuation: Sampling adapts continuously.

FR-19 — AI safety system limits and uncertainty (explicit) As a Safety Camera User, I should have the AI act as a safety aid, not a replacement for human vision, safety officers, signage, or professional navigation; when the image is blurry, too dark, the object is occluded, or the AI is not confident, I should see "⚠️ Tidak yakin — periksa lingkungan secara langsung."; the AI must not fabricate hazards that are not visible; and it must not give overconfident safety instructions — all path recommendations must be labeled as estimates based on what the camera sees.

• Trigger/input: Low-confidence or inadequate image conditions.
• Observable result: Uncertainty warning displayed; no fabricated hazards; estimate labels on path recommendations.
• Access state: Anonymous.
• Failure/recovery: If confidence evaluation is unavailable, show an error state and re-evaluate on next frame.
• Continuation: Uncertainty clears when image conditions improve.

FR-20 — Additional features (explicit) As a Safety Camera User, I should have automatic/manual flash, zoom, front/back camera, screenshot of analysis results, night mode, detection sensitivity settings, Indonesian and English languages, text-to-speech, haptic warning, detection history, and first-time tutorial.

• Trigger/input: User interaction with controls.
• Observable result: Each feature available and functional.
• Access state: Anonymous.
• Failure/recovery: If a feature is unavailable on the device, show an error state and allow retry.
• Continuation: Settings persist for the session.

FR-21 — Working application, not a mockup (explicit) As a Safety Camera User, I should have a genuinely working application, not just a mockup.

• Trigger/input: App use.
• Observable result: All accepted capabilities function end-to-end.
• Access state: Anonymous.
• Failure/recovery: Failures show error states with recovery paths.
• Continuation: The app remains usable across sessions.

FR-22 — Main flow (explicit) As a Safety Camera User, I should be able to follow the main flow: open the app → allow camera access → press "Mulai Scan" → camera active → AI analyzes the environment → hazards marked on screen → AI determines risk level → AI gives warning → AI gives action advice → AI shows the direction/path that appears safer → I can open details for each hazard.

• Trigger/input: App launch.
• Observable result: Each step in the flow is reachable and functional.
• Access state: Anonymous; camera permission required.
• Failure/recovery: If a step fails, show an error state and allow retry from that step.
• Continuation: The flow completes and the user can open hazard details.

FR-23 — Priority on accuracy, latency, battery, privacy, and safety (explicit) As a Safety Camera User, I should have the app prioritize accuracy, low latency, efficient battery usage, privacy, and user safety.

• Trigger/input: App operation.
• Observable result: Adaptive sampling, consent-gated upload, estimate labeling, and uncertainty handling all serve these priorities.
• Access state: Anonymous.
• Failure/recovery: If a priority conflicts with another, safety and privacy take precedence.
• Continuation: Priorities guide ongoing operation.

FR-24 — Camera permission prerequisite (required_inference) As a Safety Camera User, I should grant camera permission before the camera activates so that the scan flow can begin.

• Trigger/input: Entering the scan flow.
• Observable result: Camera activates only after permission is granted.
• Access state: Anonymous; permission grant required.
• Failure/recovery: If permission is denied, show guidance and allow re-request or open settings.
• Continuation: Proceed to Scanner when granted.

FR-25 — AI limits and privacy comprehension (required_inference) As a First-Time Tutorial User, I should understand the AI's limits, the term "tidak terdeteksi bahaya", the estimate label on path recommendations, and the obligation to check the environment directly, so that I use the app correctly.

• Trigger/input: First-time tutorial.
• Observable result: Tutorial completed with comprehension of AI limits and privacy.
• Access state: Anonymous.
• Failure/recovery: If tutorial content fails to load, allow retry or skip.
• Continuation: Proceed to Scanner.

FR-26 — Consent-gated image/video upload with local processing (required_inference) As a Safety Camera User, I should have image/video transmission to the AI server explained and require my consent, with local processing used when available.

• Trigger/input: Camera use; consent decision.
• Observable result: Upload occurs only with consent; local processing used when available.
• Access state: Anonymous.
• Failure/recovery: If consent is not given, upload does not occur.
• Continuation: Privacy state persists for the session.

FR-27 — Emergency assistance confirmation (required_inference) As a Safety Camera User, I should have emergency warnings never place an automatic call, and if an emergency assistance feature is available, I must confirm before any action.

• Trigger/input: Emergency condition detected.
• Observable result: Warning displayed; no automatic call; confirm-gated emergency button.
• Access state: Anonymous.
• Failure/recovery: If confirmation is not given, no action is taken.
• Continuation: Warning dismisses after acknowledgment.

FR-28 — Adaptive frame sampling for latency, heat, and battery (required_inference) As a Safety Camera User, I should have frame processing use adaptive intervals to maintain latency, device temperature, and battery.

• Trigger/input: Device performance and thermal/battery state.
• Observable result: Adaptive sampling interval; battery-aware note; scan bezel inner arc shortens in battery-saver mode.
• Access state: Anonymous.
• Failure/recovery: If the device overheats, reduce sampling further.
• Continuation: Sampling adapts continuously.

4. User Personas

Pengguna Kamera Keselamatan (Safety Camera User)

Product context: This persona uses the smartphone's rear camera as a visual sensor while walking or moving, with the goal of recognizing potential hazards in their surroundings in real time. They operate the app outdoors, in glare, one-handed, while moving — often in situations where they cannot afford to look down at a screen for long.

Primary goal: To make safer movement decisions based on the warnings and recommendations displayed, without assuming the environment is truly safe.

Distinct accepted responsibilities: Granting camera access; pressing "Mulai Scan"; monitoring the hazard overlay, AI status, and risk indicator; listening to or toggling the voice assistant; tapping markers to view AI explanations; following action advice and the direction of the path that appears safer; opening the Analysis Dashboard; taking screenshots of analysis results; and responding to emergency warnings without expecting an automatic call.

Relevant inputs or decisions: Whether to start or pause scanning; whether to trust and act on a warning; whether to toggle voice on or off; whether to confirm an emergency assistance action; whether to adjust flash, zoom, camera, or night mode in the moment.

Interactions with other accepted participants: This persona is the primary operator of the Scanner, Camera Overlay, AI Status, Risk Levels, Safety Advice, Safe Paths, Hazards, Voice Alerts, Emergency Warning, Hazard Details, Analysis Dashboard, and Screenshots pages. They interact with the AI computer vision backend/API indirectly through the app. They may also be the same person as the History and Settings Reviewer and the First-Time Tutorial User.

Observable success: They can make a safer movement decision based on the warnings and recommendations displayed, while understanding that the app never claims the environment is truly safe and that all path recommendations are estimates based on what the camera sees.

Pengguna Peninjau Riwayat & Pengaturan (History and Settings Reviewer)

Product context: This persona is the same user or a device user who manages analysis results and app preferences. They use the app's History and Settings pages to review what was detected and to configure how the app behaves on subsequent camera sessions.

Primary goal: To have history and settings stored locally according to their wishes so that the next camera session matches their preferences and privacy.

Distinct accepted responsibilities: Opening detection history to view time, number of hazards, hazard types, and risk level; deleting history; and configuring detection sensitivity, night mode, flash, zoom, front/back camera, Indonesian/English language, and voice/haptic.

Relevant inputs or decisions: Whether to delete history; how sensitive detection should be; whether night mode is on; which camera to use; which language to use; whether voice and haptic are on.

Interactions with other accepted participants: This persona interacts with the History and Settings pages and with the Voice Alerts page for voice/haptic configuration. They may be the same person as the Safety Camera User.

Observable success: History and settings are stored locally as desired, and the next camera session follows their preferences and privacy choices.

Pengguna Baru (First-Time Tutorial User)

Product context: This persona opens SafeVision AI for the first time and needs to understand the AI's capability limits and how to use the scan flow. They arrive without prior knowledge of the app's terminology or safety posture.

Primary goal: To start scanning with a correct understanding of the "tidak terdeteksi bahaya" status, the estimate label on path recommendations, and the confirmation requirement before emergency assistance.

Distinct accepted responsibilities: Following the first-time tutorial; understanding that AI is a safety aid, not a replacement for human vision; and understanding when images/video are sent to the AI server and what local processing mode means.

Relevant inputs or decisions: Whether to complete or skip the tutorial; whether to accept the privacy and processing-mode explanation.

Interactions with other accepted participants: This persona interacts with the Landing, Tutorial, and Camera Permission pages. They may be the same person as the Safety Camera User.

Observable success: They can start scanning with a correct understanding of the AI's limits, the "tidak terdeteksi bahaya" status, the estimate label on path recommendations, and the confirmation requirement before emergency assistance.

5. Core User Flows

Flow 1: First-time user opens the app and starts scanning

1. The First-Time Tutorial User opens SafeVision AI and lands on the Landing page, which explains SafeVision AI, its target users, and its safety-analysis function, and states that the app is a safety aid, not a replacement for human vision, safety officers, signage, or professional navigation.
2. The user opens the Tutorial page and steps through the first-time tutorial, which covers how to use the scan flow, AI limitations, the meaning of "tidak terdeteksi bahaya", the estimate label on path recommendations, and when images/video are sent to the AI server plus local processing mode. The tutorial uses macro-style technical line-art diagrams with no photography of people's faces.
3. The user proceeds to the Camera Permission page, which explains that camera access must be granted before the camera can activate and shows the current permission status.
4. The user grants camera permission. If permission is denied, the page shows guidance and allows re-request or opening device settings.
5. The user proceeds to the Scanner page, where the live camera feed is full-bleed with instrument chrome: top status rail, left-edge vertical risk gauge, bottom control deck, and right-edge pull-tab.
6. The user presses "Mulai Scan". The camera activates and the AI begins analyzing the environment at adaptive intervals. The 96px circular scan bezel's amber index sweep rotates while scanning.
7. The user observes the AI Status display. When no risk is found, it shows "tidak terdeteksi bahaya" in teal — never a claim that the environment is truly safe.
8. The user can open the Analysis Dashboard by pulling the right-edge tab to see status, hazard list, and recommendation.
9. The user can open Settings to adjust detection sensitivity, camera, flash, zoom, night mode, language, voice, and haptic, or to revisit the Tutorial.
10. The user can open History to review locally stored analysis history and delete it if desired.

Flow 2: Safety Camera User scans and responds to a detected hazard

1. The Safety Camera User is on the Scanner page with scanning active. The camera feed is full-bleed and the instrument chrome is anchored in four zones.
2. The AI analyzes sampled frames periodically. On detection, the Camera Overlay draws bracket-corner hazard markers with ruled labels (example: "⚠️ KENDARAAN — KANAN — TINGGI") that track object motion. Corners draw in over 180ms and then hold; when a tracked object moves, corners translate with it and never re-animate.
3. The AI Status display updates to the current state (example: "WASPADA" in amber). The Risk Levels display shows each hazard's level (Rendah, Sedang, Tinggi, Kritis) with a short reason (example: "Risiko tinggi: kendaraan berada sangat dekat dan bergerak menuju area Anda.").
4. The Safety Advice display presents the recommended action with priority order: 1) safest action, 2) alternative, 3) things to avoid (example: "⚠️ Ada kendaraan mendekat dari kanan." / "Saran: berhenti sejenak dan jangan melintas sampai kendaraan menjauh.").
5. The Safe Paths display shows the estimate of a relatively safer direction with indicators\x20\xf0\x9f\x9f\xa2 Jalur relatif lebih aman,\x20\xf0\x9f\x9f\xa1 Perlu waspada,\x20\xf0\x9f\x94\xb4 Hindari, and a line/arrow on screen (example: "Jalur depan terhalang." / "Alternatif yang terlihat lebih aman: bergerak ke sisi kiri."). The path is always labeled "jalur yang tampak lebih aman berdasarkan gambar kamera" — never stated as definitely safe.
6. If multiple hazards exist, the Hazards display shows all of them (example:\x20\xe2\x9a\xa0️ Kendaraan — kanan,\x20\xe2\x9a\xa0️ Lubang — depan,\x20\xe2\x9a\xa0️ Genangan — kiri) and provides priority (example: "Bahaya utama: kendaraan di kanan." / "Disarankan berhenti dan menunggu kendaraan lewat.").
7. The Voice Alerts page speaks the warning if voice is on (example: "Perhatian. Ada kendaraan dari kanan." / "Jangan maju."). The user can toggle 🔊 Voice ON/OFF at any time.
8. The user taps a hazard marker to open Hazard Details, which shows what was detected, its location relative to the camera, its risk level, why it is considered dangerous, and the recommended action.
9. The user acts on the advice and continues scanning. The overlay, status, risk levels, advice, and path estimate update as conditions change.
10. If the image is blurry, too dark, the object is occluded, or the AI is not confident, the Uncertainty display shows "⚠️ Tidak yakin — periksa lingkungan secara langsung." The AI does not fabricate hazards that are not visible and does not give overconfident safety instructions.
11. The user can take a Screenshot of the analysis result at any time.

Flow 3: Safety Camera User encounters an emergency condition

1. The Safety Camera User is scanning on the Scanner page when the AI detects a potentially very dangerous condition.
2. The Emergency Warning page takes over the full screen: the entire screen frame becomes a 12px red bezel with "BAHAYA TINGGI — BERHENTI DAN PERIKSA LINGKUNGAN" in condensed uppercase across two ruled bands, the risk needle slams to KRITIS, and a triple haptic pulse fires once. There is a single 2-beat amber→red flash — no continuous strobing.
3. The Voice Alerts page speaks the warning if voice is on.
4. The app does not make an automatic emergency call. If an emergency assistance feature is available, the user must confirm first via the confirm-gated emergency button beneath the warning.
5. The user acknowledges and dismisses the warning, then continues scanning or stops to check the environment directly.

Flow 4: History and Settings Reviewer manages history and preferences

1. The History and Settings Reviewer opens the History page and reviews locally stored analysis history. Each entry contains time, number of hazards detected, hazard types, and risk level.
2. The user can delete history. If storage read fails, the page shows an error and allows retry.
3. The user opens the Settings page and adjusts detection sensitivity, camera selection, flash mode (auto/manual), zoom, night mode, language (Indonesian/English), voice, and haptic.
4. The user can revisit the Tutorial from Settings.
5. The user returns to the Scanner page. The next camera session follows the configured preferences and privacy choices.

Flow 5: Safety Camera User manages privacy and processing mode

1. The Safety Camera User is on the Scanner page. The app explains when images/video are sent to the AI server and requires consent before any upload.
2. If the technology/model supports it, the user can use local processing mode. If consent is not given, upload does not occur.
3. The app does not store camera recordings permanently by default and does not perform identity/face recognition to identify people.
4. The user continues scanning with the privacy state persisting for the session.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is MARQ by Garmin — luxury instrument aesthetic. The headline is "Precision instrument for the visible world": MARQ's titanium-dark instrumentation turned into a live hazard HUD.

Color tokens (dark mode):

Risk escalation ramp (instrument logic, not a rainbow):

Palette discipline: Roughly 70% graphite ground, 20% titanium surfaces/hairlines, 8% amber, 2% teal/red signals. Accent discipline is the point.

Typography:

• Headings: Barlow Condensed — condensed technical display, uppercase, 600–700 weight, tight tracking (-0.01em) for status words like "WASPADA" and "BAHAYA TINGGI" so they read as instrument engraving.
• Numeric readouts: Saira with tabular figures so counting numbers do not jitter.
• Body: Saira 400/500, 15–17px, 1.5 line-height, never condensed.
• Type scale (1.250 modular): 96 / 64 / 40 / 28 / 20 / 17 / 15 / 13 / 11.
• Status display: clamp(40px, 11vw, 96px).
• Section titles: clamp(24px, 5vw, 40px).
• Hazard label: 13px uppercase with 0.08em letterspacing.
• Body: 17px.
• Micro-label: 11px uppercase with 0.12em tracking.

Shape language: Instrument geometry — circular gauge rings, bezel arcs, chamfered rectangles with 2px radius (not soft 16px blobs), ruled data rows separated by hairlines, and bracket-shaped bounding-box corners rather than full rounded rectangles. Bounding boxes are drawn as four L-shaped corner ticks in the risk color with a 1px inner hairline and a 6px chamfer, so the hazard itself stays visible inside the frame. Buttons are capsule-free chamfered plates with a 1px luminous top edge; the scan button is a large circular bezel with a rotating index mark.

Layout: Full-bleed camera as the page. Instrument chrome lives in four anchored zones: a top status rail (AI state, FPS/sampling indicator, battery-aware note), a left-edge vertical risk gauge (Rendah→Kritis as a 4-segment bezel scale), a bottom control deck (scan bezel, voice toggle, flash, zoom, camera flip, settings), and a right-edge pull-tab that opens the Analysis Dashboard as a ruled instrument panel sliding over the camera. Hazard markers position absolutely in the camera viewport and track object motion. Dashboard uses a strict 4-column ruled grid with label/value rows (Jenis | Lokasi | Risiko | Alasan), never cards. At 375px the control deck collapses to a single row of 44px targets with the scan bezel centred; at 768px the risk gauge moves to a horizontal bezel strip; at 1280px the dashboard opens as a persistent 380px right rail beside the camera.

Imagery: The camera feed is the only imagery. Everything else is engineered: topographic contour lines as a faint 4% overlay texture on the dashboard panel, machined hairline textures on buttons, and an expedition-style night-mode treatment (desaturated, amber-tinted, boosted contrast) rather than a filter. The onboarding/tutorial uses macro-style technical diagrams — a phone held at chest height with a ruled sightline, a bounding-box corner-tick diagram, a bezel gauge legend — drawn as line art in #F2F0EA on graphite, no photography of people's faces (privacy requirement), no stock humans, no illustration for decoration.

Avoid: Any white or near-white ground; blue/indigo primary or accent (#0057FF, #2563EB, #6366F1 family) and any blue-to-violet gradient; Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins or system-ui for headings or body; rounded 16–24px cards, pill buttons, soft offset shadows, and grids of identical hover-lift cards; glassmorphism, frosted panels and gradient blobs; continuous strobing or particle effects on the emergency state; full rounded rectangles for bounding boxes; any claim of "AMAN" or "jalur aman".

7. Signature Design Concept

The first screen is the live camera, edge-to-edge, with no marketing header at all — the product IS the hero. Over it sits the instrument: a top-left status rail reading the AI state in 40–96px condensed uppercase ("TIDAK TERDETEKSI BAHAYA" in teal, "WASPADA" in amber, "BAHAYA TINGGI" in red), a left-edge vertical risk bezel with a needle parked at the current level, and a bottom instrument deck whose dominant element is a 96px circular scan bezel in brushed-graphite with an amber index ring and a rotating sweep mark.

On first detection, three bracket-corner hazard boxes snap onto the feed with ruled labels ("⚠️ KENDARAAN — KANAN — TINGGI") and a single amber safe-path chevron sweeps left across the lower third, labelled "jalur yang tampak lebih aman berdasarkan gambar kamera". Nothing is centred, nothing is a card, and the palette is 90% graphite with amber as the only light source.

Signature moves:

• Bracket-corner hazard markers: Instead of rounded rectangles, each detected hazard gets four L-shaped chamfered corner ticks in its risk colour with a hairline inner frame and a ruled label plate pinned to the top-left tick — the object stays fully visible inside the frame.
• A vertical risk bezel down the left edge: A 4-segment instrument scale (RENDAH / SEDANG / TINGGI / KRITIS) with a needle that eases between positions over 320ms and a tabular counter beneath it reading how many hazards are currently tracked.
• The circular scan bezel as the app's single hero control: A 96px brushed-graphite ring with an amber index sweep that rotates while scanning and freezes when paused, doubling as the pause button and the sampling-rate indicator (its inner arc shortens when the app drops to battery-saver sampling).
• Ruled instrument dashboard instead of cards: The Analysis Dashboard is a label/value grid (JENIS | LOKASI | RISIKO | ALASAN | SARAN) with hairline rules and monospaced-feeling tabular numerals, opened by pulling a right-edge tab so the camera never leaves the screen.
• Emergency state as a full-bezel takeover: On KRITIS the entire screen frame becomes a 12px red bezel with "BAHAYA TINGGI — BERHENTI DAN PERIKSA LINGKUNGAN" in condensed uppercase across two ruled bands, the risk needle slams to KRITIS, and a triple haptic pulse fires once — no auto-call, only a confirm-gated emergency button beneath it.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: restrained Hero Dimensionality: layered_2d

Landing Hero Motion Brief

• Focal subject: The live camera feed as the hero, with the instrument chrome layered over it — the top-left status rail, the left-edge vertical risk bezel with its needle, and the 96px circular scan bezel with its amber index sweep.
• Input→transformation→outcome thesis: The user presses "Mulai Scan" → the scan bezel's amber index sweep begins rotating one revolution per 2.4s and the AI begins analyzing sampled frames → on first detection, three bracket-corner hazard boxes snap onto the feed with ruled labels and a single amber safe-path chevron sweeps left across the lower third, labelled "jalur yang tampak lebih aman berdasarkan gambar kamera".
• Motion vocabulary: Needle-sweep and counting-number motion only. The risk gauge needle eases to its new value over 320ms with a physical ease-out and no overshoot; detected hazard counters tick up digit by digit. Bounding-box corner ticks draw in over 180ms and then hold; when a tracked object moves, corners translate with it, never re-animate. The amber scan reticle rotates one revolution per 2.4s while scanning is active and stops dead when paused. The emergency DARURAT state uses a single 2-beat amber→red flash on the full-screen warning plus a haptic triple-pulse — no continuous strobing. Nothing bounces, no particles, no gradient drift.
• Composed first frame: The camera feed fills the viewport edge-to-edge. The top-left status rail reads the AI state in condensed uppercase. The left-edge risk bezel shows the needle parked at the current level with a tabular hazard counter beneath it. The bottom instrument deck centres the 96px circular scan bezel in brushed-graphite with an amber index ring. The right-edge pull-tab is visible. Nothing is centred, nothing is a card, and the palette is 90% graphite with amber as the only light source.
• Reduced-motion state: With prefers-reduced-motion, the scan bezel's index sweep is static, the needle jumps directly to its value without easing, hazard counters show their final values without ticking, bounding-box corners appear without draw-in, and the safe-path chevron appears without sweeping. All information remains fully readable and every control remains usable.

9. Non-Functional Requirements

NFR-01 — Accuracy priority (explicit) The app must prioritize accuracy in hazard detection and risk assessment. Rationale: the user relies on the app for safety decisions.

NFR-02 — Low latency (explicit) The app must prioritize low latency in analysis and display so that warnings reach the user in time to act. Rationale: safety-critical timing.

NFR-03 — Efficient battery usage (explicit) The app must prioritize efficient battery usage and must not perform AI inference on every frame if it causes the device to heat up or drain the battery; adaptive interval/frame sampling must be used. Rationale: the app runs on low-spec smartphones and must remain usable over time.

NFR-04 — Privacy (explicit) The app must prioritize privacy: no continuous camera video upload without user consent; explain when images/video are sent to the AI server; provide local processing mode if the technology/model supports it; no permanent camera recording by default; no identity/face recognition to identify people. Rationale: explicit privacy constraints in the authoritative source.

NFR-05 — User safety (explicit) The app must prioritize user safety: the AI is a safety aid, not a replacement for human vision, safety officers, signage, or professional navigation; no claim that the environment is truly safe; no claim that a path is definitely safe; no fabricated hazards; no overconfident safety instructions; all path recommendations labeled as estimates based on what the camera sees. Rationale: explicit safety constraints in the authoritative source.

NFR-06 — Low-spec smartphone support (explicit) The app must be optimized to run on low-specification smartphones. Rationale: explicit requirement in the authoritative source.

NFR-07 — High outdoor contrast (explicit) The UI must use high-contrast design so information is easy to see outdoors. Rationale: explicit requirement in the authoritative source; the app is used in glare while moving.

NFR-08 — Working application (explicit) The app must be a genuinely working application, not just a mockup. Rationale: explicit requirement in the authoritative source.

NFR-09 — Secure AI backend/API (explicit) The app must use a secure AI backend/API. Rationale: explicit technology requirement in the authoritative source.

NFR-10 — Readable text and controls at every viewport (required_inference) Headlines, wordmarks, labels, numbers, cards' text and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element may cover any part of them. Rationale: required for the accepted UI to remain usable outdoors and one-handed.

NFR-11 — Reduced-motion usability (required_inference) With prefers-reduced-motion, the app must provide a usable static arrangement: all information remains fully readable and every control remains usable. Rationale: required for accessibility of the accepted motion design.

10. Tech Stack

The following technology choices are preserved from the authoritative source:

• Mobile camera API — for camera access and frame capture.
• AI Computer Vision — for environmental analysis.
• Object Detection — for hazard identification.
• Image Segmentation — when available.
• Depth estimation — when the device supports it.
• GPS — only when needed for location-based features.
• Text-to-Speech — for voice warnings.
• Secure AI backend/API — for server-side AI processing.
• Local processing — when possible.

Platform and framework [Default — not specified by user]: React Native for the mobile application, chosen because the product is a mobile camera app requiring native camera access, text-to-speech, haptics, and local storage across iOS and Android.

Backend [Default — not specified by user]: Python/FastAPI for the secure AI backend/API, chosen for its fit with computer-vision model serving and its ability to expose a consent-gated inference endpoint.

Storage [Default — not specified by user]: On-device local storage for scan history, settings, and screenshots, consistent with the explicit requirement that history is stored locally and that camera recordings are not stored permanently by default.

Deployment [Default — not specified by user]: Docker/docker-compose for the backend service. Kubernetes is not required for the current delivery.

11. Assumptions and Constraints

Assumptions:

1. The user's smartphone has a rear camera and the operating system supports camera permission requests. (Assumption — required for the accepted scan flow.)
2. The device supports text-to-speech for voice warnings; if not, the app falls back to visual-only warnings. (Assumption — consistent with FR-10 failure/recovery.)
3. The device supports haptic feedback for haptic warnings; if not, the haptic pulse is omitted. (Assumption — consistent with FR-20.)
4. Local processing mode is available only if the technology/model supports it; otherwise the app uses the secure AI backend/API with user consent. (Assumption — consistent with FR-14 and FR-26.)
5. Scan history and settings are stored locally on the device and are not tied to an account. (Assumption — consistent with the absence of application-owned identity in the accepted journeys.)
6. The emergency assistance feature is conditional ("jika tersedia") and, when present, requires user confirmation before any action. (Assumption — consistent with FR-11 and FR-27.)

Constraints:

1. Do not claim that the environment is truly safe; use the term "tidak terdeteksi bahaya" when the AI finds no risk. (explicit)
2. Do not state that a path is definitely safe; use the term "jalur yang tampak lebih aman berdasarkan gambar kamera". (explicit)
3. Do not make automatic emergency calls; if an emergency assistance feature is available, the user must confirm first. (explicit)
4. Do not upload camera video continuously without user consent. (explicit)
5. Do not store camera recordings permanently by default. (explicit)
6. Do not perform identity/face recognition to identify people. (explicit)
7. Do not fabricate hazards that are not visible. (explicit)
8. Do not give overconfident safety instructions; all path recommendations must be labeled as estimates based on what the camera sees. (explicit)
9. Do not perform AI inference on every frame if it causes the device to heat up or drain the battery; use adaptive interval/frame sampling. (explicit)
10. The AI is a safety aid, not a replacement for human vision, safety officers, signage, or professional navigation. (explicit)
11. Use the smartphone's rear camera for the AI Camera Scanner. (explicit)
12. Use GPS only when needed for location-based features. (explicit)
13. Build a genuinely working application, not just a mockup. (explicit)

12. Glossary

• SafeVision AI — The mobile camera application that uses AI to analyze the user's surroundings in real time and provide safety recommendations.
• AI Camera Scanner — The feature that uses the smartphone's rear camera and periodically analyzes camera frames with AI.
• AMAN / WASPADA / BAHAYA / DARURAT — The four AI status values displayed to the user. "AMAN" is not used as a safety claim; when no risk is found the app displays "tidak terdeteksi bahaya".
• Tidak terdeteksi bahaya — The term used when the AI finds no risk; it does not claim the environment is truly safe.
• Danger Bounding Box — The box/marker placed on the camera screen for each detected hazard, with a label such as "⚠️ KENDARAAN", "⚠️ LUBANG", "⚠️ ASAP", or "⚠️ RINTANGAN". Markers follow the object's position when the camera moves.
• Risk Level — The risk rating for each hazard: Rendah, Sedang, Tinggi, or Kritis, with a short reason for the assessment.
• AI Safety Advice — The recommended action shown after a hazard is detected, with priority order: 1) safest action, 2) alternative, 3) things to avoid.
• Safe Path Analysis — The AI's analysis of the visible camera area to show a relatively safer direction based on detected hazards, using indicators\x20\xf0\x9f\x9f\xa2 Jalur relatif lebih aman,\x20\xf0\x9f\x9f\xa1 Perlu waspada,\x20\xf0\x9f\x94\xb4 Hindari, and lines/arrows on screen. Always labeled as "jalur yang tampak lebih aman berdasarkan gambar kamera".
• Multiple Hazard Detection — The display of all hazards simultaneously when many exist, with priority for the main hazard and recommended action.
• Voice Assistant — The AI voice that speaks warnings so the user does not have to keep looking at the screen, with a 🔊 Voice ON/OFF button.
• Emergency Warning — The large warning and sound shown when the AI detects a potentially very dangerous condition (example: "BAHAYA TINGGI" / "BERHENTI DAN PERIKSA LINGKUNGAN."). No automatic emergency call; if an emergency assistance feature is available, the user must confirm first.
• AI Explanation — The detail shown when the user taps a hazard marker: what was detected, location relative to the camera, risk level, why it is considered dangerous, and recommended action.
• Scan History — The locally stored analysis history containing time, number of hazards detected, hazard types, and risk level, with an option to delete.
• Local processing mode — Processing images/video on the device instead of sending them to the AI server, available if the technology/model supports it.
• Adaptive frame sampling — Using interval/frame sampling that adjusts to maintain latency, device temperature, and battery, instead of performing AI inference on every frame.
• Uncertainty warning — The message "⚠️ Tidak yakin — periksa lingkungan secara langsung." shown when the image is blurry, too dark, the object is occluded, or the AI is not confident.
• Analysis Dashboard — The panel showing status, the list of detected hazards with position and risk level, and a recommendation, opened by pulling the right-edge tab.
• Instrument chrome — The anchored UI zones over the camera: top status rail, left-edge vertical risk gauge, bottom control deck, and right-edge pull-tab.
• Scan bezel — The 96px circular brushed-graphite ring with an amber index sweep that rotates while scanning and freezes when paused, doubling as the pause button and the sampling-rate indicator.