TelemetryGuard AI

Overview

TelemetryGuard AI is a local monitoring demo. A Python simulator sends synthetic readings to FastAPI. SQLite stores the data and alert state, while a Next.js dashboard receives updates over WebSockets. What I built: the simulator, backend, persistence, alert handling, report-provider interface and dashboard. This is a personal full-stack project, not an industrial deployment. Detection uses rules, and the default reports are deterministic mock templates.

Architecture and decisions

Synthetic input. Controlled scenarios avoid real machine or customer data.
Threshold rules. Alerts are explainable; no trained ML model is used.
Alert lifecycle. Persist state and acknowledge or resolve alerts.
Report boundary. Default templates need no provider credentials or paid inference.

SQLAlchemy models connect machines, readings, alerts and reports. WebSocket broadcasts carry backend updates to the dashboard.

Engineering details, tests and current limitations

Connecting data to an actionable interface

A monitoring interface needs more than a changing chart: readings, machine status and alert state must remain connected. The code includes ingestion routes, alert deduplication, acknowledge/resolve handling and WebSocket broadcasts. Those are concrete integration responsibilities; no throughput or reliability benchmark is claimed.

Testing and reliability

The repository includes pytest cases for the health endpoint, threshold/anomaly rules, alert updates and structured mock report generation. The report test checks the provider label and the structure of causes, actions and evidence. These tests were inspected, not run as part of this portfolio update.

What “AI” means in this version

The default reporting implementation is a deterministic mock. Optional Gemini/OpenAI classes are integration stubs; their presence does not establish live LLM reporting. My PDF resume uses broader wording about AI-generated reports. This case study states the current implementation more precisely without altering that PDF.

Current state and limitations

A simulated demo with private source. There are no real sensors connected, no production factory installation and no validated predictive-maintenance model. Authentication, production observability, PostgreSQL/TimescaleDB and real-data ML evaluation are future requirements, not current capabilities.

Future improvements

Add authentication and a stronger deployment boundary, test end-to-end alert-state consistency and measure a clearly defined streaming workload. Any real model integration would need its own evidence, evaluation and failure handling.

Evidence scope

Based on read-only inspection of the private README, FastAPI routes, SQLAlchemy models, simulator, report providers and test files. No company infrastructure or private telemetry is shown. There is no public repository or deployed demo link for this version.