VERIFY. TRACE. TRUST THE EVIDENCE.
Monitoring Data Quality for Engineering & Environment
RAUZ explains how monitoring data quality is established across sensors, surveys, environmental observations and InSAR, covering QA/QC, metadata, baselines, validation, traceability and engineering interpretation.
Knowledge · Data Quality
Monitoring data is useful only when its quality is understood.
Monitoring data quality is the degree to which a dataset is fit for the decision it is expected to support. A clean chart is not enough: the measurement source, metadata, baseline, timing, units, processing history, completeness and physical plausibility all affect how confidently a result can be interpreted.
In practical engineering and environmental monitoring, data quality means knowing what was measured, how it was measured, whether the record is complete and traceable, what limitations apply, and whether the evidence is reliable enough for its intended technical or operational use.
Quality is decision-specific.
A dataset that is adequate for long-term screening may not be adequate for a trigger decision, short-duration event review or precise deformation assessment.
Quality starts before analytics.
Instrument identity, installation, calibration or checks, baseline, datum, timestamps, units and raw-data retention can matter before any trend calculation is attempted.
Credibility is not the same as significance.
A reading may be technically credible yet still require context from neighbouring sensors, survey, groundwater, weather, construction activity or other independent evidence.
U.S. EPA — Quality Management Tools for Projects ↗ · USGS — Quality Assurance Recommended Practices ↗
Quality Model
Seven questions reveal whether a monitoring dataset is decision-ready.
The list below is a RAUZ working model for technical review. It is not presented as a universal standard. It converts broad QA/QC principles into questions that can be applied to geotechnical, structural, environmental, agricultural, survey and remote-sensing records.
| Quality dimension | Review question | Typical evidence |
|---|---|---|
| Fitness for purpose | Is the dataset suitable for the decision, scale, frequency and level of uncertainty involved? | Monitoring objective, acceptance criteria, trigger framework, required accuracy, reporting need. |
| Provenance | Can each observation be traced to a known instrument, location, method and source? | Instrument register, sensor ID, serial number, location, depth, axis, source file or API record. |
| Completeness | Are the expected readings present, and are gaps or communication outages visible? | Expected schedule, timestamps, missing intervals, logger status, field notes. |
| Validity | Are values physically plausible and consistent with the measurement method and known instrument condition? | Range checks, repeatability, calibration/check records, resets, maintenance, known sensor limits. |
| Consistency | Are units, sign conventions, reference systems, timestamps and processing rules consistent through time? | Metadata, coordinate system, time zone, units, baseline history, version-controlled calculations. |
| Traceability | Can a reviewer reconstruct how a raw observation became the plotted or reported value? | Raw data, transformations, exclusions, corrections, reviewer notes, audit history. |
| Contextual coherence | Does the observed behaviour agree—or meaningfully disagree—with independent evidence and the physical context? | Neighbouring instruments, survey, groundwater, weather, construction sequence, inspection, InSAR. |
A dataset can pass automated format and range checks yet remain unsuitable for a particular engineering conclusion. Conversely, an unusual value is not automatically “bad data”; it may be the first valid indication of real change and should be investigated before exclusion.
Failure Modes
Most bad decisions begin with an invisible break in the evidence chain.
Data-quality problems can enter before measurement, during acquisition, during transfer, during processing or during interpretation. The review should identify where the chain changed rather than treating every anomaly as the same type of error.
Instrument and field-condition problems
Baseline, datum and reference changes
Timestamp and synchronization problems
Units, sign convention and coordinate-system errors
Missing, duplicate, reset and flat-line records
Processing and filtering without traceability
Context errors rather than measurement errors
Crossrail Learning Legacy — Review of Monitoring Methods ↗
QA/QC Workflow
Quality control should follow the data from planning to decision.
EPA quality planning starts before data collection, while FHWA guidance for geotechnical instrumentation calls for standardized data collection, record keeping, timely monitoring and communication with geotechnical interpretation. A practical monitoring workflow should preserve that same continuity.
Parameter, purpose, required frequency, accuracy, trigger or reporting use.
Instrument, location, depth, axis, units, reference system, ownership and metadata.
Timestamped raw values, status information, manual records and source provenance.
Gaps, duplicates, range, flat-lines, jumps, resets, timing and metadata consistency.
Baseline history, maintenance, reference movement, neighbouring sensors and external events.
Accepted, qualified, questioned or not decision-ready, with reasons and limitations recorded.
Prevent predictable problems.
Define methods, responsibilities, metadata, baseline rules, maintenance records, quality criteria, data ownership and review routes before the monitoring programme relies on them.
Detect and control problems in the record.
Apply checks to readings and processing, investigate exceptions, document corrections and retain enough information to reproduce what was reported.
U.S. EPA — QAPP Guidance ↗ · FHWA — PDDM Chapter 6, Geotechnical ↗
Cross-Source Validation
Independent evidence is most useful when unlike measurements are not treated as interchangeable.
Cross-source review asks whether separate observations tell a coherent physical story while respecting each method’s geometry, reference, sampling interval, uncertainty and spatial scale. Agreement can increase confidence; disagreement can be equally valuable because it identifies the next question.
| Evidence source | Typical data-quality questions | Useful independent comparison |
|---|---|---|
| Inclinometer / in-place inclinometer | Depth reference, orientation, baseline, repeatability, local step changes, missing depths or channels. | Survey movement, settlement, adjacent profiles, excavation stage, groundwater. |
| Piezometer / water level | Sensor elevation, installation zone, units, datum, drift, atmospheric or temperature correction where applicable. | Rainfall, pumping, excavation/dewatering events, neighbouring water-level records. |
| Total station / GNSS | Control stability, prism/point identity, coordinate frame, atmospheric conditions, missing observations and reference geometry. | Levelling, structural sensors, ground instruments, independent control observations. |
| Environmental sensors | Siting, calibration/check status, averaging period, time alignment, maintenance, completeness and sensor response. | Nearby stations, field observations, process records or another measurement method appropriate to the parameter. |
| InSAR ground motion | Line-of-sight geometry, reference frame, point density, temporal coverage, local deviations and product quality information. | GNSS, levelling, prisms, settlement points, asset inspection and ground context. |
| Manual records / inspections | Time, location, operator, method, transcription, photo/document linkage and completeness. | Automated sensors, event logs, survey or repeat inspection. |
Open Geospatial Consortium — SensorThings API ↗
Monitoring Domains
The quality question changes with the physical system being observed.
RAUZ applies one evidence discipline across ground, infrastructure, environment, agriculture and remote sensing, but the actual QA/QC checks must follow the measurement method and the decision being supported.
Movement, pressure and structural response
Check baselines, reference systems, instrument geometry, repeatability, construction sequence, neighbouring measurements and whether the observed pattern is physically coherent.
Water, weather, air, noise and soil observations
Define the intended use, sampling method, siting, frequency, calibration or checks, data completeness, metadata and acceptance criteria before drawing environmental conclusions.
Soil, moisture and field conditions
Interpret point measurements with depth, location, sensor condition, weather, irrigation or field-operation context rather than treating one sensor as representative of an entire site.
InSAR and spatial ground-motion evidence
Review product type, line-of-sight geometry, reference, temporal coverage, precision/accuracy information and local validation before comparing satellite-derived movement with ground instruments.
Copernicus Land Monitoring Service — EGMS technical documents ↗ · Copernicus — Assessing EGMS product quality ↗
RAUZ Working Framework
Separate the raw observation, the quality finding and the engineering interpretation.
RAUZ uses a traceable review sequence so a client can see what the original evidence showed, what quality issue was identified, what processing or qualification was applied, and what conclusion remains supportable. This is a RAUZ working method, not an external standard.
Define the technical question before judging whether a record is “good enough”.
Trace instrument, location, configuration, source, baseline and processing route.
Check time, units, gaps, duplicates, resets, metadata and raw-data retention.
Review range, repeatability, instrument condition, reference behaviour and known events.
Compare nearby sensors, survey, environment, construction and remote sensing where relevant.
State confidence, limitations and the next check before technical interpretation is used.
No material quality issue has been identified for the defined use, subject to stated limitations.
The data can support part of the review, but a known limitation must remain visible.
An anomaly, inconsistency or missing record needs verification before the result is relied upon.
The available evidence is insufficient or materially compromised for the decision being considered.
RAUZ does not treat a confidence label as a substitute for project responsibility. Final technical and statutory decisions remain with the parties appointed for the project, asset or jurisdiction.
Official Public Lessons
Large monitoring programmes show why data quality is an engineering system, not a spreadsheet clean-up task.
The examples below are public technical lessons from official organizations and project archives. They are not RAUZ projects and do not imply partnership or endorsement.
Standardized records and timely interpretation
FHWA guidance for geotechnical instrumentation calls for monitoring plans that address timely data collection, standardized record keeping and timely communication of findings with geotechnical interpretation.
Validity review and troubleshooting questionable data
The Bureau of Reclamation’s Instrumentation Group describes routine dam-performance monitoring that includes reviewing data for validity, identifying performance anomalies and troubleshooting questionable data.
Common formats and multi-supplier coordination
Crossrail’s Western Tunnels paper describes the need to collect monitoring data from multiple sources, map records to the correct measurement points and maintain a system that could accept changing data formats and growing data volumes.
Product QA/QC plus local validation
EGMS publishes formal quality documents and validation reports, while its own user guidance notes that local deviations can still occur. Regional-scale data quality therefore does not remove the need for project-specific interpretation.
Practical Checklist
Before trusting a monitoring trend, check the evidence behind the graph.
This checklist is intended for first-pass technical review. Project specifications, manufacturer requirements, statutory rules and appointed professional responsibilities take precedence where they apply.
- Confirm the instrument or data-source identity.
- Confirm location, depth, axis and reference system.
- Check units, sign convention and coordinate/datum definitions.
- Confirm the baseline and every later re-baseline or reset.
- Check timestamps, time zone and expected sampling interval.
- Identify missing, duplicate, flat-line and abruptly shifted records.
- Review calibration, verification, maintenance and replacement history.
- Preserve raw values before correction, filtering or transformation.
- Record exclusions, corrections and processing logic.
- Compare neighbouring or independent evidence where technically meaningful.
- Check construction, groundwater, weather or operating events relevant to the trend.
- State uncertainty and whether the dataset is fit for the intended decision.
Official Sources
Primary public references used for this guide.
External technical statements on this page are based on official government, standards-body or project-owner sources. These links are provided so readers can check the source material directly.
U.S. Environmental Protection Agency — EPA Quality Management Tools for Projects
Official EPA material on data quality assessment, Quality Assurance Project Plans and systematic planning for environmental information.
Open official EPA source ↗U.S. Environmental Protection Agency — QAPP Guidance
Current EPA guidance for developing Quality Assurance Project Plans that address planning, implementation and assessment of environmental data activities.
Open official EPA guidance ↗U.S. Geological Survey — Quality Assurance Recommended Practices
USGS data-management guidance emphasizing documented methods, trained data collection and project-level quality criteria.
Open official USGS source ↗Federal Highway Administration — PDDM Chapter 6: Geotechnical
Official FHWA guidance covering instrumentation purpose, timely monitoring, standardized record keeping and geotechnical interpretation.
Open official FHWA source ↗U.S. Bureau of Reclamation — Instrumentation Group
Official description of instrumentation services including validity review, anomaly review, troubleshooting and monitoring database management.
Open official Reclamation source ↗Open Geospatial Consortium — SensorThings API
Open standard for managing observations and metadata from heterogeneous IoT sensor systems using structured entities and relationships.
Open official OGC standard page ↗Copernicus Land Monitoring Service — European Ground Motion Service
Official EGMS product specifications, validation reports and quality assurance/control documents for satellite-derived ground-motion products.
Open official Copernicus source ↗Crossrail Learning Legacy — Monitoring Data Management
Official Crossrail technical paper on instrumentation-data management, common data formats, visualization and coordination across monitoring suppliers.
Open official Crossrail paper ↗FAQs
Monitoring data quality questions engineers and asset teams ask most often.
What is monitoring data quality?
What is the difference between QA and QC?
Can automated QA/QC prove that movement is real?
Should suspicious monitoring data be deleted?
How should missing monitoring data be treated?
Can InSAR and ground instruments be compared directly?
Does RAUZ require its own sensors or monitoring hardware?
Discuss a Data-Quality Question
Have monitoring data that looks clean but still does not feel trustworthy?
A first technical discussion can start with a representative dataset, monitoring report, instrument register, baseline information and the specific decision your team is trying to support. RAUZ can help define whether the issue needs QA/QC review, data diagnostics, cross-source validation or a wider independent monitoring review.
What to send first
Representative raw and processed data, instrument list, metadata, baseline, trigger table, maintenance notes, relevant project chronology and any existing interpretation that needs to be checked.
What the first scope can define
Data-quality checks, missing evidence, anomaly-investigation priorities, technically meaningful cross-comparisons, confidence limitations, deliverable type and responsibility boundaries.