Problem
Streaming SCADA/AMI-style telemetry arrives continuously and unevenly. Before it feeds a dashboard or alert, someone needs to check timestamps and device identity are sane, flag drift or outliers, and decide what "degraded" data should do to downstream consumers.
Data boundary
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?"