Real-Time Data Quality Control, QA/QC, and Flagging
Domain focus
Real-time QC protects users from bad observations while preserving the record. The exam tests automated checks, manual QA/QC, flag semantics, and provisional-versus-verified status.
Core rules
- Real-time automated QC runs at acquisition or ingest: range checks, rate-of-change checks, spike and flat-line tests, persistence, and comparison with predictions or neighboring stations.
- QA/QC is the later human review: calibrations, maintenance logs, comparison with independent sensors, and final disposition.
- Flag, do not delete. CO-OPS-style QC flags distinguish good, questionable, bad, and missing values; preserve the original observation and the reason.
- Provisional data can change after review; verified data carry a higher confidence. Products should label status.
- Metadata and audit trails matter: who changed a flag, when, and why.
Worked example
A water-level sensor shows a 0.8 m jump in one 6-minute interval during a storm. The rate-of-change check flags it questionable. The analyst compares the value with the predicted tide, a nearby station, and the barometer; if the jump is physically implausible and not replicated, it is flagged bad, but the raw value remains in the archive with a note.
Traps
Deleting outliers instead of flagging them; treating a real storm surge as a spike; using QC flags as calibration corrections; assuming real-time data are final; flagging a whole day for one bad interval.