ksaikiran2004/tric

1. Overall shape

This is a locally hosted, Flask-style real-time monitoring system. The repo is split into a Python backend that ingests/derives events and a browser frontend that renders the operator dashboard. The main runtime entrypoints appear to be app.py, run_tric.py, and backend/main.py.

2. User-facing layer

The frontend/ folder is a server-rendered UI with HTML templates plus vanilla JS/CSS. The JavaScript modules are split by concern: map loading, sensor rendering, alert panels, incident tables, video streaming, and path animation. The frontend is mostly a consumer of live state delivered from the backend via HTTP and WebSockets.

3. API and realtime transport

backend/api/routes.py and backend/api/demo_routes.py provide HTTP endpoints, while backend/api/websocket_manager.py handles push updates. This is the boundary where backend events are exposed to the dashboard, so it is the key integration point between state changes and UI updates.

4. Core orchestration

backend/orchestrator/alert_orchestrator.py and backend/orchestrator/event_manager.py are the coordination layer. They take incoming telemetry, detections, and confirmations, then decide when something becomes an alert or incident. Architecturally, this is the central “decision bus” between ingestion, tracking, and persistence.

5. Sensor and telemetry ingestion

The repo supports both real and synthetic sensor inputs. backend/simulation/ generates test nodes and trigger events, which is useful for offline validation; backend/api and backend/surveillance are the likely live ingress paths for actual telemetry and video-related events. The presence of data/sensors.json suggests sensor state/config is also persisted locally.

6. Video and vision pipeline

backend/surveillance/ handles camera/image capture, and backend/vision_processor.py plus backend/detection/yolo_inference.py run local object detection with the bundled yolov8s.pt model. backend/detection/detection_parser.py appears to normalize model output into domain events that the orchestrator can understand.

7. Tracking and movement reasoning

backend/tracking/ contains the path/direction/intrusion logic. path_builder.py, intrusion_tracker.py, and direction_classifier.py together turn raw detections into trajectories and movement classifications. This is the stage that converts “a detection happened” into “a target is moving along a path.”

8. Alert confirmation

backend/confirmation/ provides a multi-sensor confirmation step before escalation. multi_sensor_confirmation.py and alert_engine.py imply the system tries to reduce false positives by requiring corroboration across inputs before the orchestrator logs or broadcasts a higher-confidence alert.

9. Persistence and audit trail

Runtime records are stored under data/ as JSON snapshots: active_alerts.json, incidents.json, and sensors.json. backend/database_manager.py, backend/logging_system/incident_logger.py, and backend/logging_system/log_formatter.py suggest a lightweight local persistence/auditing layer rather than a separate database service. backend/utils/file_lock.py is important here because it indicates concurrent file writes are expected and guarded.

10. Domain model boundary

backend/models/ defines the shared data shapes for alerts, incidents, paths, and sensors. These model classes sit between the event-processing subsystems and the UI/persistence layers, giving the system a consistent schema for alerts, trajectories, and sensor state.

11. Geospatial and visualization assets

frontend/geo/border_line.geojson and the static assets under frontend/static/assets/ support map-based visualization and sensor icons. The README references offline map rendering and a 3D “holotable” view; in the repository, that visual layer is represented by the map and animation JS modules rather than a separate backend service.

12. Configuration and utilities

config/settings.py and backend/config.py centralize runtime settings, while backend/utils/ provides shared helpers for IDs, timestamps, geospatial math, and locking. These are supporting modules that reduce coupling across the ingestion, orchestration, and persistence code.

13. End-to-end data flow

The dominant flow is: sensor/video input or simulation event → parsing/detection → tracking/confirmation → alert orchestration → logging/persistence → WebSocket/HTTP update to the dashboard. The system is therefore event-driven, with the backend acting as the processing core and the frontend acting as a live operator display.

14. Operational boundary

The repository is designed as a self-contained local system with no obvious dependency on external cloud services in the code tree. That makes the main architectural constraint not network integration, but keeping realtime ingestion, file-based persistence, and frontend updates synchronized inside one air-gapped process boundary.