System Requirements Document for animal-rescue

1. Introduction

OrbiResQ is an AI/ML-powered animal rescue and emergency response platform. It is designed to detect animal emergencies, monitor environmental hazards, and coordinate rapid rescue operations. Using computer vision over authorized live camera feeds, geospatial intelligence, and real-time incident detection, the platform identifies animals in distress, potential threats, and hazardous situations.

The platform provides live geospatial monitoring, automated alerts, incident tracking, and rescue coordination so that authorities, animal welfare organizations, and rescue teams can respond efficiently. Initial deployment targets Odisha, West Bengal, and Andhra Pradesh, India. The stated purpose is to reduce animal suffering, improve rescue response times, and support data-driven decision-making.

The intended audience is three operational roles: Authority / Emergency Response Coordinator, Animal Welfare Organization Staff, and Rescue Team Member. Over a 12-month project horizon the platform is to be functional, scalable, secure, and reliable, integrating AI-based detection, interactive mapping, emergency notifications, and centralized incident management to strengthen animal welfare and environmental protection.

2. System Overview

OrbiResQ is delivered as a first-party web application with a shared backend. The current delivery includes:

• AI/ML detection running over authorized live camera feeds using computer vision to identify animals in distress, potential threats, and hazardous situations.
• Real-time incident detection that converts detections into incident records with location and hazard context.
• Live geospatial monitoring on an interactive map of incidents and environmental hazards across the target regions.
• Automated alerts and emergency notifications generated from detected incidents.
• Centralized incident management and incident tracking with a durable, revisitable incident record and lifecycle status.
• Rescue coordination among authorities, animal welfare organizations, and rescue teams.

Actors:

• Authority / Emergency Response Coordinator — monitors live camera feeds and geospatial hazard data, reviews AI-detected incidents, and dispatches or coordinates rescue teams.
• Animal Welfare Organization Staff — tracks incidents involving animals in distress, follows incident status and history, and supports rescue coordination.
• Rescue Team Member — receives automated emergency alerts and incident details, locates incidents on the live map, and carries out and updates rescue operations.
• Backend processing (system actor) — performs AI detection, durable incident management, alert generation, geospatial monitoring, and rescue coordination support. It is not a human persona.

Narrow exclusions: no stock photography of animals in distress; no satellite imagery on the map; no dark mode as the default surface; no decorative illustration of animals. Camera feeds must be authorized before ingestion. Initial deployment is limited to Odisha, West Bengal, and Andhra Pradesh, India.

2a. Product Interpretation and Delivery Boundary

OrbiResQ is public-safety infrastructure for animal emergency response, not a lifestyle application. Its users are dispatchers, field responders, and welfare coordinators who must read incident data quickly under pressure. The product's identity is a wayfinding system for emergencies: incidents are located, prioritized, and dispatched through a single consistent severity language.

Delivery ownership. The platform is a first-party application with custom UI for all operational surfaces. The backend owns AI detection, durable incident records, alert generation, geospatial data, and rescue coordination state. Camera feeds are external inputs that must be authorized before the platform ingests them for detection; the platform does not own the cameras. Automated alerts and emergency notifications are generated by the platform and delivered to responders through the platform's own notification surface.

Identity and access. The platform owns identity. Independently participating authorities, welfare organization staff, and rescue team members enroll themselves; there is no invitation or provisioning boundary in the source. Returning users verify their identity to regain access to durable incidents, alerts, camera operations, and rescue coordination. The Landing page is anonymously reachable and explains the platform before protected access. Sign Up and Login are anonymously reachable entry surfaces. Operational surfaces require login, and camera feed operations, incident detail editing, and rescue coordination are restricted to the roles that own that work.

Current vs. future. Everything described in this document is current. The 12-month horizon is the delivery window for the functional, scalable, secure, and reliable platform; it is not a deferral of the listed capabilities. No future-horizon capabilities are asserted beyond the current scope.

2b. Source Content Inventory

Not applicable. No reference directive in this request declares a content_source, so no source content inventory is produced.

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous entry explaining OrbiResQ, its AI-powered emergency detection, and its rescue coordination purpose before protected access. Presents the mission and the operational model.
• Primary actions: Request Access (routes to Sign Up); Sign In (routes to Login).
• Supporting actions: Read the mission section; view the live incident ticker.
• Domain entities: Recent detection events (severity, timestamp, location); mission content.
• Component responsibilities: Oversized headline band; single muted body line; red pill CTA; live incident ticker marquee; documentary-style field photography of responders and equipment in the mission section, cropped to the grid; numbered section navigation.
• States: Loading (ticker fetching recent detections); empty (no recent detections — ticker shows a static "no recent detections" strip); success (ticker scrolling with real detection events); error (ticker unavailable — headline and CTA remain fully usable); recovery (ticker retries and resumes scrolling).

Sign Up

• Information/state: Self-service enrollment form for independently participating platform users. Anonymous access.
• Primary actions: Create account with the selected role.
• Supporting actions: Switch to Login; read role descriptions to choose correctly.
• Domain entities: Account identity; role selection (Authority / Emergency Response Coordinator, Animal Welfare Organization Staff, Rescue Team Member).
• Component responsibilities: Enrollment form; role selector; validation messaging; link to Login.
• States: Loading (submitting); empty (untouched form); success (account created, routed to Login or into the platform); error (validation failure or duplicate identity — inline field errors, form preserved); recovery (correct and resubmit).

Login

• Information/state: Returning verification for access to durable operational records and workflows. Anonymous access.
• Primary actions: Verify identity and enter the platform.
• Supporting actions: Switch to Sign Up; recover access when credentials are not accepted.
• Domain entities: Account identity; session.
• Component responsibilities: Credential form; error messaging; link to Sign Up.
• States: Loading (verifying); empty (untouched form); success (routed to the operational surface the role works in); error (invalid credentials — inline error, form preserved); recovery (retry, or route to Sign Up).

Camera Feeds

• Information/state: Authorized operational workspace for ingesting and processing live camera feeds used by AI detection. Role-restricted to Authority / Emergency Response Coordinator.
• Primary actions: Authorize a camera feed for ingestion; view a live feed panel.
• Supporting actions: Review feed status; inspect detection output on a feed.
• Domain entities: Camera feed (authorization state, location, status); detection output; timestamp overlay.
• Component responsibilities: Feed list; framed feed panels with timestamp overlays; authorization control; feed status indicators.
• States: Loading (feed list and stream connecting); empty (no feeds authorized — prompt to authorize the first feed); success (feed live, detections flowing); error (feed unreachable or authorization rejected — feed marked unavailable, other feeds unaffected); recovery (re-authorize or retry the feed).

Incident Alerts

• Information/state: Operational surface for reviewing real-time AI detections with incident location and hazard context. Requires login.
• Primary actions: Review a new detection; open the incident it belongs to.
• Supporting actions: Filter by severity; acknowledge an alert.
• Domain entities: Detection event (severity, type, timestamp, location); incident reference; hazard context.
• Component responsibilities: Alert feed with severity coding; filter chips; alert count badge; link into Incident Details.
• States: Loading (fetching detections); empty (no active detections); success (alerts listed, new rows sliding in); error (feed unavailable — retry control); recovery (reconnect and resume the live feed).

Live Map

• Information/state: Interactive geospatial monitoring surface for live incidents and environmental hazards across the target regions. Requires login.
• Primary actions: Inspect an incident or hazard marker; open the incident from the map.
• Supporting actions: Pan and zoom; toggle incident and hazard layers; filter by severity.
• Domain entities: Incident location; hazard location; severity; region (Odisha, West Bengal, Andhra Pradesh).
• Component responsibilities: Topographic map layer with muted terrain; circular markers with coloured ring and white centre; layer toggles; severity filter chips; marker pulse on new critical detections.
• States: Loading (map tiles and incident layer fetching); empty (no incidents or hazards in view); success (markers placed, new critical markers pulsing once); error (map layer unavailable — list fallback of incidents remains readable); recovery (reload the layer).

Notifications

• Information/state: Responder-facing surface for automated alerts and emergency notifications generated from detected incidents. Requires login.
• Primary actions: Read a notification; open the incident it references.
• Supporting actions: Mark as read; filter by severity or recency.
• Domain entities: Notification (severity, timestamp, incident reference, read state).
• Component responsibilities: Notification list; unread badge with flip increment; severity coding; link into Incident Details.
• States: Loading (fetching notifications); empty (no notifications); success (notifications listed, unread count accurate); error (delivery or fetch failure — retry control); recovery (retry and reconcile unread count).

Incidents

• Information/state: Revisitable browse and management surface for centralized incident records and lifecycle tracking. Requires login.
• Primary actions: Open an incident record.
• Supporting actions: Filter and sort by severity, type, region, and status; scan the ledger.
• Domain entities: Incident (time, severity, type, location, status); region; hazard type.
• Component responsibilities: Ruled tabular ledger with tabular numerals and aligned columns; pinned severity column with 2px left border in the severity colour; horizontal scroll on narrow viewports; filter chips.
• States: Loading (fetching incident records); empty (no incidents match the current filter — clear-filter action); success (ledger populated); error (fetch failure — retry control); recovery (retry and restore the previous filter).

Incident Details

• Information/state: Focused workspace for reviewing and updating an incident's status, context, and rescue progress. Role-restricted.
• Primary actions: Update incident status; record rescue progress.
• Supporting actions: Review detection context, location, and history; open the incident on the Live Map; hand off to Rescue Coordination.
• Domain entities: Incident record; status; rescue progress entries; detection context; location; history.
• Component responsibilities: Incident header with severity coding; status control; progress log; location panel with map link; history timeline.
• States: Loading (fetching the incident record); empty (incident not found or removed — return to Incidents); success (record shown, status and progress updated and persisted); error (update rejected or fetch failed — inline error, prior state preserved); recovery (retry the update or reload the record).

Rescue Coordination

• Information/state: Shared operational workspace for coordinating rescue actions among authorities, welfare organizations, and field rescue teams. Role-restricted.
• Primary actions: Assign or claim a rescue action; post a coordination update.
• Supporting actions: Review participants and their updates; link back to the incident record.
• Domain entities: Rescue action (owner, state); coordination update (author, timestamp, content); incident reference; participating role.
• Component responsibilities: Coordination thread; action assignment control; participant list; incident reference panel.
• States: Loading (fetching the coordination thread); empty (no coordination started — prompt to post the first update); success (updates and assignments visible to all participants); error (post or assignment failed — content preserved for retry); recovery (retry the post or reassign).

3. Functional Requirements

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

FR-1 — AI/ML detection of animal emergencies and environmental hazards (explicit) As an Authority / Emergency Response Coordinator, I should have computer vision run over authorized live camera feeds so that animals in distress, potential threats, and hazardous situations are detected automatically.

• Trigger/input: an authorized live camera feed is ingested.
• Observable result: a detection event is produced with incident type, severity, timestamp, and location.
• Access state: role-restricted to the Authority / Emergency Response Coordinator on the Camera Feeds surface.
• Failure/recovery: an unauthorized or unreachable feed produces no detection and is marked unavailable; the operator re-authorizes or retries.
• Continuation: the detection event flows into Incident Alerts and the incident record.

FR-2 — Real-time incident detection (explicit) As an Authority / Emergency Response Coordinator, I should see detections converted into incidents in real time so that animals in distress, potential threats, and hazardous situations are surfaced without delay.

• Trigger/input: a detection event from FR-1.
• Observable result: a new incident appears in Incident Alerts and on the Live Map with location and hazard context.
• Access state: requires login.
• Failure/recovery: if the live feed is interrupted, the surface shows an error with a retry control and resumes on reconnect.
• Continuation: the incident is openable in Incident Details.

FR-3 — Live geospatial monitoring and interactive mapping (explicit) As an Animal Welfare Organization Staff member, I should monitor incidents and environmental hazards on an interactive map across the target regions so that I can prioritize cases geographically.

• Trigger/input: opening the Live Map.
• Observable result: incident and hazard markers are placed with severity coding; new critical detections pulse once.
• Access state: requires login.
• Failure/recovery: if the map layer fails, a readable incident list fallback remains; the layer can be reloaded.
• Continuation: a marker opens the incident in Incident Details.

FR-4 — Automated alerts and emergency notifications (explicit) As a Rescue Team Member, I should receive automated alerts and emergency notifications generated from detected incidents so that I can respond rapidly.

• Trigger/input: a detected incident meeting alert conditions.
• Observable result: a notification appears on the Notifications surface with severity, timestamp, and incident reference; the unread badge increments.
• Access state: requires login.
• Failure/recovery: a delivery or fetch failure shows a retry control; the unread count reconciles on retry.
• Continuation: the notification opens the incident in Incident Details.

FR-5 — Incident tracking and centralized incident management (explicit) As an Animal Welfare Organization Staff member, I should browse and track centralized incident records with their lifecycle status so that I can follow each case to resolution.

• Trigger/input: opening Incidents and selecting a record.
• Observable result: a ruled ledger of incidents with time, severity, type, location, and status; the selected record opens in Incident Details.
• Access state: requires login.
• Failure/recovery: a fetch failure shows a retry control and restores the previous filter on retry.
• Continuation: status and progress updates persist on the incident record.

FR-6 — Rescue coordination among authorities, welfare organizations, and rescue teams (explicit) As a Rescue Team Member, I should coordinate rescue actions with authorities and welfare organizations in a shared workspace so that field response is aligned.

• Trigger/input: opening Rescue Coordination for an incident.
• Observable result: a coordination thread and action assignments visible to all participating roles; each participant sees the others' updates.
• Access state: role-restricted.
• Failure/recovery: a failed post or assignment preserves the content for retry.
• Continuation: the incident record reflects the coordinated progress.

FR-7 — Geospatial intelligence supporting data-driven decision-making (explicit) As an Authority / Emergency Response Coordinator, I should use geospatial incident and hazard data to decide where to dispatch rescue teams so that response times improve across Odisha, West Bengal, and Andhra Pradesh.

• Trigger/input: reviewing the Live Map and the Incidents ledger.
• Observable result: severity-coded, region-scoped incident and hazard data available for dispatch decisions.
• Access state: requires login.
• Failure/recovery: if a data layer is unavailable, the remaining layers and the ledger stay readable.
• Continuation: the decision is enacted through Rescue Coordination.

FR-8 — Initial target regions (explicit) As an Authority / Emergency Response Coordinator, I should see incidents and hazards scoped to Odisha, West Bengal, and Andhra Pradesh so that monitoring matches the initial deployment area.

• Trigger/input: opening the Live Map or Incidents.
• Observable result: incidents and hazards are presented within the target regions.
• Access state: requires login.
• Failure/recovery: out-of-region data is not presented as in-region; the operator can still browse all records.
• Continuation: region filtering continues to apply across map and ledger.

FR-9 — Self-service enrollment (required_inference) As an Animal Welfare Organization Staff member, I should enroll myself on the platform so that I can participate without an invitation or provisioning step.

• Trigger/input: opening Sign Up from the Landing page.
• Observable result: an account is created with the selected role.
• Access state: anonymous.
• Failure/recovery: validation failure or duplicate identity shows inline errors with the form preserved.
• Continuation: the user proceeds to Login or into the platform.

FR-10 — Returning verification (required_inference) As a Rescue Team Member, I should verify my identity on return so that I regain access to durable incidents, alerts, camera operations, and rescue coordination.

• Trigger/input: opening Login.
• Observable result: a session is established and the user reaches the operational surface for their role.
• Access state: anonymous entry, protected state after verification.
• Failure/recovery: invalid credentials show an inline error with the form preserved; the user can retry or route to Sign Up.
• Continuation: the user resumes their operational work.

FR-11 — Role assignment (required_inference) As an Authority / Emergency Response Coordinator, I should have my role distinguished from welfare organization staff and rescue team members so that each participant reaches the work they own.

• Trigger/input: role selection during enrollment.
• Observable result: the user's role determines which operational surfaces and controls are available, including camera feed authorization, incident detail editing, and rescue coordination.
• Access state: established at enrollment, applied after login.
• Failure/recovery: an incorrect role selection can be corrected through the enrollment flow.
• Continuation: the role governs access on every subsequent visit.

FR-12 — Camera feed authorization before ingestion (required_inference) As an Authority / Emergency Response Coordinator, I should authorize a camera feed before it is ingested for detection so that only authorized feeds are processed.

• Trigger/input: adding or authorizing a feed on Camera Feeds.
• Observable result: the feed is marked authorized and begins producing detection output; unauthorized feeds produce none.
• Access state: role-restricted.
• Failure/recovery: a rejected or unreachable feed is marked unavailable and other feeds are unaffected.
• Continuation: the authorized feed continues to feed FR-1.

FR-13 — Backend processing for detection, incident management, alerts, geospatial monitoring, and coordination (required_inference) As an Authority / Emergency Response Coordinator, I should have the platform process detections, persist incidents, generate alerts, serve geospatial data, and hold coordination state so that the operational surfaces stay consistent.

• Trigger/input: authorized feeds, detection events, and user actions on the operational surfaces.
• Observable result: durable incident records, generated notifications, geospatial data, and coordination state available to all authorized participants.
• Access state: system actor; no human interaction with the backend itself.
• Failure/recovery: a processing failure surfaces as an error state on the affected surface with a retry control; durable records are not silently lost.
• Continuation: the affected surface resumes from the persisted state.

4. User Personas

Authority / Emergency Response Coordinator

• Product context: A government or authority-side operator working across Odisha, West Bengal, and Andhra Pradesh. This role sits at the monitoring and dispatch end of the platform, watching live camera feeds and geospatial hazard data and turning AI detections into dispatched rescue work.
• Primary goal: Reduce animal suffering and improve rescue response times by detecting incidents early and dispatching the right teams quickly.
• Distinct accepted responsibilities: Authorizing camera feeds before ingestion; monitoring live feeds and geospatial hazard data; reviewing AI-detected incidents; dispatching or coordinating rescue teams; using geospatial intelligence for data-driven decisions.
• Relevant inputs or decisions: Which feeds to authorize; whether a detection is a genuine incident; which team to dispatch and to which location; how severity and region affect priority.
• Interactions with other accepted participants: Dispatches and coordinates Rescue Team Members; coordinates with Animal Welfare Organization Staff who track the same incidents; sees and responds to the same incident record and coordination thread.
• Observable success: Authorized feeds producing detections; incidents dispatched with a recorded status and progress; response times improving across the target regions.

Animal Welfare Organization Staff

• Product context: A welfare organization user whose focus is the animal and the case, not the dispatch decision. This role follows incidents involving animals in distress and supports coordination with authorities and rescue teams.
• Primary goal: Prioritize cases and reduce animal suffering by tracking incident status and history to resolution.
• Distinct accepted responsibilities: Tracking incidents involving animals in distress; following incident status and history; supporting rescue coordination with authorities and rescue teams; using incident tracking and alerts to prioritize cases.
• Relevant inputs or decisions: Which cases to prioritize; whether an incident's status and history indicate the animal still needs support; what to contribute to the coordination thread.
• Interactions with other accepted participants: Supports Authority / Emergency Response Coordinators and Rescue Team Members on the shared incident record and coordination thread; sees the same alerts and map data.
• Observable success: Cases followed through their lifecycle with accurate status and history; contributions visible to the other participants.

Rescue Team Member

• Product context: A field responder who receives automated emergency alerts and incident details and then carries out rapid rescue operations. This role works from the alert and the incident record outward to the field.
• Primary goal: Locate detected animals in distress quickly and carry out the rescue, updating status toward a successful outcome.
• Distinct accepted responsibilities: Receiving automated emergency alerts and incident details; using live geospatial monitoring and incident tracking to locate incidents; coordinating and carrying out rapid rescue operations; updating incident status toward successful rescue outcomes.
• Relevant inputs or decisions: Which alert to respond to; the incident location on the map; what rescue action to take and record; what to post in the coordination thread.
• Interactions with other accepted participants: Receives dispatch and coordination from Authority / Emergency Response Coordinators; coordinates with Animal Welfare Organization Staff on the same incident; sees and updates the shared incident record.
• Observable success: Incidents located and reached; status and rescue progress updated on the incident record; successful rescue outcomes recorded.

5. Core User Flows

Flow A — Authority / Emergency Response Coordinator: authorize a feed and dispatch a detected incident

1. The coordinator opens the Landing page anonymously and reads the platform's detection and coordination purpose.
2. The coordinator selects Request Access and completes enrollment on Sign Up, choosing the Authority / Emergency Response Coordinator role.
3. The coordinator verifies identity on Login and reaches the operational surfaces for their role.
4. The coordinator opens Camera Feeds and authorizes a live camera feed for ingestion. The feed is marked authorized and begins producing detection output. If the feed is unreachable or authorization is rejected, it is marked unavailable and the other feeds are unaffected; the coordinator re-authorizes or retries.
5. Computer vision over the authorized feed detects an animal in distress or a hazard. A detection event is produced with type, severity, timestamp, and location.
6. The coordinator opens Incident Alerts and reviews the new detection with its location and hazard context. If the live feed is interrupted, the surface shows an error with a retry control and resumes on reconnect.
7. The coordinator opens the incident in Incident Details to review detection context, location, and history.
8. The coordinator opens Live Map to see the incident and surrounding hazards across the target regions, and decides which team to dispatch. If the map layer fails, the readable incident list fallback remains and the layer can be reloaded.
9. The coordinator opens Rescue Coordination for the incident, assigns the rescue action to a Rescue Team Member, and posts the dispatch context. If the post or assignment fails, the content is preserved for retry.
10. The coordinator continues monitoring Incident Alerts and Live Map for further detections, and follows the incident's status and progress on Incidents and Incident Details until it is resolved.

Flow B — Rescue Team Member: receive an alert and carry out a rescue

1. The Rescue Team Member opens Login and verifies identity, reaching the operational surfaces for their role. If credentials are not accepted, an inline error is shown with the form preserved, and the member retries or routes to Sign Up.
2. A detected incident meeting alert conditions generates an automated alert. The member sees it on Notifications with severity, timestamp, and incident reference, and the unread badge increments. If delivery or fetch fails, a retry control is shown and the unread count reconciles on retry.
3. The member opens the notification and lands on Incident Details, reviewing the incident's status, context, and rescue progress.
4. The member opens Live Map to locate the incident and the surrounding hazards, using the severity-coded markers and the target-region scope. If the map layer fails, the incident list fallback remains readable.
5. The member opens Rescue Coordination for the incident, claims or is assigned the rescue action, and posts a coordination update. The update and assignment are visible to the Authority / Emergency Response Coordinator and the Animal Welfare Organization Staff. If the post fails, the content is preserved for retry.
6. The member carries out the rescue and returns to Incident Details to update the incident status and record rescue progress. If the update is rejected or the record fails to load, an inline error is shown and the prior state is preserved; the member retries or reloads the record.
7. The member continues to Incidents to confirm the updated status appears in the centralized ledger, and follows the case to a successful rescue outcome.

Flow C — Animal Welfare Organization Staff: track and support a case

1. The Animal Welfare Organization Staff member opens Sign Up from the Landing page and enrolls with the Animal Welfare Organization Staff role. If validation fails or the identity already exists, inline errors are shown with the form preserved.
2. The member verifies identity on Login and reaches the operational surfaces for their role.
3. The member opens Incidents and scans the ruled ledger by time, severity, type, location, and status, filtering to the cases they want to prioritize. If no incidents match the filter, a clear-filter action is offered; if the fetch fails, a retry control restores the previous filter on retry.
4. The member opens a case in Incident Details to follow its status and history, and reviews the detection context and location.
5. The member opens Live Map to see the case in geographic context alongside other incidents and environmental hazards in the target regions.
6. The member opens Rescue Coordination for the case and posts a coordination update supporting the Authority / Emergency Response Coordinator and the Rescue Team Member. If the post fails, the content is preserved for retry.
7. The member returns to Incidents and Incident Details to follow the case through its lifecycle, confirming that status and history reflect the coordinated rescue progress.

Flow D — Any participant: return to durable operational records

1. A returning participant opens Login and verifies identity. If credentials are not accepted, an inline error is shown with the form preserved; the participant retries or routes to Sign Up.
2. The participant reaches the operational surfaces for their role and resumes from the persisted state: incidents, alerts, camera operations, and rescue coordination are all as they were left.
3. The participant continues their work — monitoring, tracking, or responding — from the durable record rather than from the beginning.

6. Visuals Colors and Theme

Muse: Erik Spiekermann. Headline direction: Typographic infrastructure for animal emergency response — humanist sans systems, wayfinding clarity, warmth inside order.

OrbiResQ is literally a wayfinding system for emergencies: incidents must be located, prioritized, and dispatched. A signal-colour system used like transit lines maps directly onto incident severity. Fira Sans, Spiekermann's own typeface, carries the humanist warmth that keeps a rescue platform from feeling like a cold surveillance tool, while numbered systems and clear columns deliver the operational rigour responders need.

Palette — light mode (default surface):

Proportion: 70% warm neutral ground, 20% white data surfaces, 10% signal colours used sparingly and meaningfully. No blue-indigo primary or accent anywhere. No dark mode as the default surface.

Typography:

• Headings: Fira Sans, 700–800 weight, tight tracking (-0.02em), sentence case for readability at speed.
• Body: Fira Sans.
• Operational data labels: 600 weight, uppercase, wide tracking (0.08em) for scanability.
• Numbers: tabular figures throughout.
• Scale: 1.25 modular scale — 56 / 44 / 34 / 24 / 18 / 16 / 14. Mobile headline 34px to desktop 56px. Body 16px mobile to 18px desktop. Data labels 12px to 14px.
• Line height: 1.5 for body, 1.15 for headlines.
• No decorative type — every weight choice serves hierarchy. No Inter, Roboto, Arial, Helvetica, Poppins, or system-ui for headings or body.

Shape language: Clear, honest geometry. Rounded rectangles (8px radius) for cards and controls — functional, not decorative. 2px left border in signal colour on incident rows to code severity like a transit line. Thin 1px rules (#E0DBD4) separate data sections. No blobs, no soft shadows beyond a single subtle elevation (0 1px 3px rgba(0,0,0,0.08)) on floating panels. Map markers are circular with a coloured ring and white centre — legible at small sizes.

Layout: Strict 12-column grid with generous 24px gutters and 48px page margins on desktop. Incident lists are tabular: time | severity | type | location | status, aligned in columns with ruled rows. The live map occupies the right 7 columns on desktop, the incident feed the left 5. Numbered navigation (01 Overview, 02 Incidents, 03 Map, 04 Alerts) in the sidebar. Mobile stacks to a single column with the map collapsing to a 40vh panel. Every data table scrolls horizontally on 375px with the first column (severity indicator) pinned.

Imagery: Pictograms and schematic diagrams in the Spiekermann tradition — clear, reduced, legible at 16px. Incident type icons (injured animal, trapped animal, hazard, fire, flood) drawn as simple 2px-stroke symbols. The map uses topographic line work and muted terrain colours, not satellite imagery. No stock photography of animals in distress — instead, documentary-style field photos of responders and equipment appear only in the landing page's mission section, cropped to the grid. Camera feed thumbnails are shown as framed panels with timestamp overlays.

7. Signature Design Concept

The incident ticker hero. The landing hero is a full-width warm paper ground (#F5F2EC) split into two horizontal bands.

The upper band (60vh) carries an oversized Fira Sans headline at clamp(34px, 6vw, 72px) in ink black — "Every second counts. Every animal matters." — set flush-left across 9 columns, with the final word "matters" in signal red (#C0392B). Below it, a single line of 18px muted body text and a red pill CTA "Request Access" pinned to the left edge.

The lower band is a live incident ticker: a horizontal marquee of recent detections scrolling right-to-left in a white surface strip with 1px rules. Each item shows a coloured severity dot, timestamp, and location. This is the product's own data as the hero image — the platform feels operational before login.

No gradient, no blob, no centred stack. The ticker is the signature: it turns real detection events into the visual identity, and it carries the same transit-line severity coding used on every other surface.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: The live incident ticker — recent detection events (severity dot, timestamp, location) rendered as the hero visual beneath the headline.
• Input → transformation → outcome thesis: As recent detections arrive from the platform's own data, the ticker scrolls right-to-left in a white surface strip; the outcome is that the visitor sees the platform operating in real time before login, with each item fully readable as it passes.
• Motion vocabulary: Functional and purposeful. Incident rows slide in from the left with a 200ms ease-out when new detections arrive. The severity indicator pulses once when a critical incident is logged. Map markers drop in with a 300ms scale from 0.8 to 1.0. Alert count badges increment with a 150ms flip. No bouncy easing, no decorative loops.
• Composed first frame: Warm paper ground, oversized flush-left headline with the final word in signal red, a single muted body line, a red pill CTA at the left edge, and the ticker strip already in motion beneath — no gradient, no centred stack.
• Reduced-motion state: All motion respects prefers-reduced-motion by showing state changes instantly without transitions. The ticker wraps its items into rows or becomes horizontally scrollable so each item can be brought fully into view; no item is left unreadable.

9. Non-Functional Requirements

• Security (explicit) — The platform must be secure. Camera feeds must be authorized before they are ingested for detection; unauthorized feeds produce no detection output. Operational surfaces require login, and camera feed operations, incident detail editing, and rescue coordination are role-restricted. Rationale: the source states the platform must be secure and that camera feeds must be authorized.
• Scalability (explicit) — The platform must be scalable to serve authorities, animal welfare organizations, and rescue teams across Odisha, West Bengal, and Andhra Pradesh. Rationale: the source states the platform must be scalable.
• Reliability (explicit) — The platform must be reliable, with durable incident records, alerts, and coordination state that survive interruption and are recoverable. Rationale: the source states the platform must be reliable and requires durable operational records.
• Functional completeness within 12 months (explicit) — The platform must be functional within a 12-month project horizon, integrating AI-based detection, interactive mapping, emergency notifications, and centralized incident management. Rationale: the source states the 12-month horizon and the integration requirement.
• Real-time responsiveness (explicit) — Detection, alerting, and geospatial monitoring must operate in real time so that response times improve. Rationale: the source states real-time incident detection and improved rescue response times.
• Geographic scope (explicit) — Initial deployment targets Odisha, West Bengal, and Andhra Pradesh, India. Rationale: explicit hard constraint in the source.

• Accessibility of readable content (required_inference) — Headlines, wordmarks, labels, numbers, and card text and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering them. Moving and scrollable content may cross the viewport edge by design, provided every item becomes fully readable as it passes and a usable static arrangement is provided under prefers-reduced-motion. Rationale: required to make the operational surfaces usable under pressure across the stated viewports.

10. Tech Stack

• Frontend: React — custom UI for all operational surfaces, including the live map, the tabular incident ledger, and the incident ticker hero.
• Backend: Python / FastAPI — a single shared backend process serving AI detection orchestration, durable incident management, alert generation, geospatial data, and rescue coordination state. New APIs and domain modules extend this backend rather than adding separate services.
• Storage: A durable relational store for incident records, detection events, notifications, camera feed authorization state, accounts, and coordination state.
• Cache / real-time fan-out: Redis — required for real-time detection delivery, alert fan-out, and live geospatial updates.
• AI/ML: Computer vision inference over authorized live camera feeds, producing detection events with type, severity, timestamp, and location.
• Deployment: Docker / docker-compose for the application services. Kubernetes only if deployment scale requires it.

11. Assumptions and Constraints

Assumptions

• Camera feeds are external inputs owned outside the platform; the platform authorizes and ingests them but does not own or operate the cameras. (required_inference)
• Self-service enrollment is the correct identity establishment path because the source establishes independently participating authorities, welfare staff, and rescue team members but no invitation or provisioning boundary. (required_inference)
• Role assignment at enrollment is sufficient to distinguish the three accepted roles; no finer-grained permission model is asserted by the source. (required_inference)
• The 12-month horizon is the delivery window for the current capabilities, not a deferral of them. (explicit)

Constraints

• Camera feeds used for detection must be authorized. (explicit)
• Initial deployment targets Odisha, West Bengal, and Andhra Pradesh, India. (explicit)
• The platform must be functional, scalable, secure, and reliable within a 12-month project horizon. (explicit)
• No stock photography of animals in distress; no satellite imagery on the map; no dark mode as the default surface; no decorative illustration of animals. (explicit — creative direction)
• No blue-indigo primary or accent anywhere; the generic indigo/blue-on-white SaaS template is forbidden. (explicit — creative direction)
• No Inter, Roboto, Arial, Helvetica, Poppins, or system-ui for headings or body. (explicit — creative direction)

12. Glossary

• OrbiResQ — The AI-powered animal rescue and emergency response platform described in this document.
• Authorized live camera feed — A camera feed that has been explicitly authorized on the Camera Feeds surface before the platform ingests it for AI detection.
• Detection event — The output of computer vision over an authorized feed: an identified animal in distress, potential threat, or hazardous situation, with type, severity, timestamp, and location.
• Incident — A durable, centralized record created from a detection event, carrying time, severity, type, location, status, and rescue progress.
• Severity — The classification that codes an incident or hazard as critical (signal red), hazard/warning (amber), or resolved (green), applied consistently across incident rows, map markers, alert badges, and filter chips.
• Hazard — An environmental threat detected or monitored by the platform, distinct from an animal in distress but tracked through the same incident and map surfaces.
• Incident ticker — The landing page's live-scrolling marquee of recent detection events, used as the hero visual.
• Target regions — Odisha, West Bengal, and Andhra Pradesh, India — the initial deployment area.
• Rescue coordination — The shared operational workspace where authorities, welfare organizations, and field rescue teams assign actions and post updates for an incident.
• Role — The participant classification established at enrollment: Authority / Emergency Response Coordinator, Animal Welfare Organization Staff, or Rescue Team Member.