Problem
Streaming SCADA/AMI-style telemetry arrives continuously and unevenly. Before it feeds a dashboard or alert, someone must check timestamps and device identity are sane, flag drift or outliers, and decide what "degraded" data does to downstream consumers.
Data limits
Synthetic SCADA/AMI-style telemetry only, generated for this lab. No connection to any real utility, grid, or meter.
Pipeline
Ingest synthetic telemetry event → validate timestamp and device_id → check for drift/outliers → apply SLO-style thresholds → emit ok/degraded status.
Validation rules
| Field | Rule | Sample value | Outcome |
|---|---|---|---|
| device_id | Must match a registered synthetic device | SYN-METER-0042 | ACCEPT |
| timestamp | Must be monotonic per device | out of order | DEGRADED — reordering detected |
| reading_kwh | Must fall within a rolling drift band | 4.7x rolling median | DEGRADED — outlier flagged |
Output
A per-device quality summary: ok/degraded status, flagged readings, and an SLO-style signal a dashboard or alert could consume.
Failure modes
- Out-of-order timestamps → flagged degraded, not silently reordered.
- Statistical outliers → flagged for review, not auto-corrected.
- Unregistered device id → rejected rather than assumed valid.
What this proves
Streaming-style quality validation, drift/outlier detection concepts, and SLO-style alerting applied to an energy-shaped telemetry problem.
What it does not claim
This is an energy-pattern lab using synthetic telemetry. It does not claim production utility or grid-operator experience.
Suggested questions
- Hiring manager: "Show me the energy telemetry quality pattern."
- Buyer: "What would a scoped data workflow look like for my team?"