VERIFY. TRACE. TRUST THE EVIDENCE.
Monitoring Data Quality & Assurance
RAUZ applies structured QA/QC across geotechnical, environmental, survey and InSAR monitoring data, preserving provenance, baselines, validation status and traceability before technical interpretation.
Quality & Data Assurance
Trust the evidence before you interpret the trend.
RAUZ Quality & Data Assurance is the control layer around environmental and engineering monitoring evidence. It covers measurement identity, baseline control, metadata, completeness, validation status, processing history, traceability and review discipline so that a technically neat chart is not mistaken for trustworthy evidence.
Quality assurance defines the planned system used to produce monitoring information fit for its intended decision. Quality control applies the checks that test whether individual measurements, files, transformations and outputs meet those requirements. RAUZ connects both to engineering and environmental interpretation.
Measurement integrity
Confirm that the instrument, location, orientation, reference, range and operating condition are suitable for the monitoring question.
Data integrity
Preserve timestamps, units, identifiers, raw values, baselines, metadata and processing history so the record can be reconstructed.
Technical validity
Check whether a result is physically credible in relation to related sensors, survey, groundwater, weather, construction and the expected mechanism.
Decision traceability
Keep the reason a value was accepted, questioned, corrected, remeasured, excluded or escalated visible to the next reviewer.
Different from Data Diagnostics: Quality & Data Assurance is preventive and systematic. Data Diagnostics is the focused investigation used when an existing trend, trigger or dataset already appears abnormal, inconsistent or unexplained.
RAUZ Assurance Framework
A seven-stage evidence chain from monitoring question to reviewed data.
The exact acceptance limits depend on the project. The control sequence should not. RAUZ uses a repeatable framework so data quality is considered before acquisition, during data flow and again before interpretation.
Decision, monitoring question, parameter, expected behaviour and required response.
Instrument, sensor, location, serial/channel identity, units and reference system.
Installation record, calibration/check status, zero, baseline and initial condition.
Timestamped raw observations, communication status, manual records and source metadata.
Completeness, range, reasonableness, continuity, duplicates, drift and cross-source checks.
Trend, rate, trigger state, project context, independent evidence and uncertainty.
Flags, corrections, approvals, revisions, comments and the issued technical record.
Official context: EPA distinguishes the wider QA plan from the QC measures used to determine the validity of specific procedures and data, and links data quality objectives to the decision the information is intended to support.
U.S. EPA — Quality Assurance and Quality Control ↗ U.S. EPA — Data Quality Objectives Process ↗Data Quality Objectives
“Good data” only has meaning when the intended use is defined.
A monitoring programme does not automatically need the highest possible precision, fastest frequency or largest sensor count. It needs evidence of sufficient type, quality, quantity and timeliness for the decision being made.
Decision relevance
State what the data must answer: construction control, asset behaviour, environmental compliance, slope response, groundwater change, anomaly investigation or another defined purpose.
Acceptance criteria
Define accuracy or bias requirements where applicable, precision, completeness, representativeness, comparability, detection or sensitivity needs and valid-data rules appropriate to the method.
Timeliness & availability
Decide when evidence must reach the reviewer, what happens during communication failure, how delayed data are treated and whether the decision requires manual, periodic or near-real-time review.
| Quality question | What should be defined | Why it matters |
|---|---|---|
| Accurate enough? | Expected change, instrument/system performance, calibration or verification requirement and reference uncertainty. | A numerically precise value can still be too uncertain for the intended decision. |
| Complete enough? | Required frequency, valid-record rule, allowable gaps and treatment of outages. | Missing data can look like physical stability if acquisition status is hidden. |
| Representative? | Location, depth, orientation, spatial footprint and sampling interval. | A reliable sensor may still observe the wrong zone for the question being asked. |
| Comparable? | Units, time zone, datum, reference epoch, coordinate system and processing method. | Cross-source comparison is unsafe when underlying references are misaligned. |
| Reproducible? | Raw record, metadata, transformations, corrections, flags and revision history. | Traceability lets another reviewer reconstruct the issued value. |
Measurement Control
Data quality starts before the first reading enters a database.
Software cannot repair an unsuitable measurement location, unstable reference, undocumented installation or incorrect channel mapping. Assurance begins with the physical measurement system and the records needed to understand it later.
| Monitoring system | Typical assurance checks | Useful review question |
|---|---|---|
| Total station / prisms | Instrument status, control stability, target identity, network/resection quality, reference points and relevant corrections. | Is the apparent movement at the target, or could it originate in control or geometry? |
| GNSS | Receiver/antenna identity, mounting stability, reference solution, processing method, gaps and quality indicators. | Is the displacement significant relative to solution quality? |
| Inclinometer | Casing identity, orientation, depth reference, probe/system identity, baseline, repeatability and depth continuity. | Is the profile change coherent with depth and the expected mechanism? |
| Piezometer / groundwater | Sensor identity, elevation/datum, zero/baseline, logger mapping, calibration/check record and installation depth. | Does the change plausibly reflect the groundwater system? |
| Tilt / crack / strain / load | Orientation, mounting, zero reference, range, channel mapping and relevant environmental influence. | Does the local response agree with wider asset behaviour? |
| Environmental sensors | Parameter, siting, method, calibration/field check, maintenance, interval, data capture and metadata. | Is the observation representative of the environmental decision? |
| InSAR-derived motion | Product identity, acquisition period, line-of-sight geometry, reference convention, spatial coverage and processing metadata. | Does the trend represent the same movement component and area as the ground evidence? |
Calibration is one control, not the whole assurance system. Identity, installation, configuration, reference stability, maintenance, replacement history and the treatment of questionable periods also affect confidence.
Baseline & Configuration Control
A baseline is a documented reference condition—not simply “zero”.
Baseline control is one of the strongest safeguards against false movement, false stability and unexplained steps. The baseline needs enough context that a later reviewer can understand what physical and system condition it represented.
Establish normal behaviour
Where programme and method allow, collect pre-works observations long enough to assess repeatability, existing trend and relevant environmental or seasonal variation.
Control re-zeroing and replacement
Record logger changes, sensor replacement, re-zeroing, survey-control changes and transformations that can introduce an artificial step.
Verify continuity
Power loss, flooding, impact, repair, excavation near an instrument or communication loss should trigger an explicit continuity check.
- Baseline date and period recorded
- Raw observation retained where available
- Reference datum / epoch defined
- Units and sign convention recorded
- Instrument identity and location linked
- Reason for re-baselining documented
- Reviewer / approver identified
- Effect on alerts or triggers assessed
Official project lesson: Crossrail’s Hyde Park tunnelling research reported more than 12 months of baseline monitoring, supporting assessment of measurement-system accuracy and thermal or seasonal effects before tunnelling-induced response was interpreted.
Crossrail Learning Legacy — Hyde Park instrumentation ↗Monitoring Data QA/QC
Automated checks should expose uncertainty—not quietly remove it.
RAUZ separates raw observation, validation status and technical interpretation. A flag is evidence about the record; it should not become an invisible edit that prevents another reviewer from reconstructing what happened.
Missing & delayed data
Expected-versus-received counts, communication gaps, stale channels, logger backlog, missing metadata and periods without valid observations.
Range & reasonableness
Impossible values, unexpected steps, duplicate timestamps, unit/sign errors, rate checks, source warnings and values outside defined technical rules.
Cross-source comparison
Compare technically related instruments, survey, groundwater, weather, remote sensing and project activity without assuming correlation proves causation.
Processing history
Keep filters, offsets, transformations, corrections, remeasurements, manual edits, exclusions and review comments visible.
Outlier detected
Sudden step change
Gradual drift
Data gap followed by a jump
Official industry context: FHWA’s Long-Term Pavement Performance programme uses controls before, during and after data collection, plus database checks, QA audits, higher-order checks, peer review and feedback.
FHWA — LTPP Data Quality Efforts ↗Data Provenance & Traceability
Every important monitoring value should have a recoverable history.
Projects increasingly combine manual readings, automated loggers, survey systems, environmental stations, IoT gateways, GIS and remote sensing. A stable metadata model keeps engineering meaning attached to a value as it moves between systems.
What is this observation?
- Project / asset / zone
- Instrument, station and channel identifier
- Observed parameter and units
- Location, depth, orientation and reference
- Timestamp and time-zone convention
- Raw, processed or derived status
- Source system / file / interface
What happened to the record?
- Calibration / verification status
- Baseline or zero change
- Filter, correction or offset
- Sensor/logger/control replacement
- Manual edit or invalid-data flag
- Reason for exclusion or remeasurement
- Reviewer and review date
- Revision and issued-output linkage
Vendor-neutral metadata matters. The OGC SensorThings API is an example of an open standard that manages observations and metadata from heterogeneous IoT sensing systems. RAUZ does not require one standard for every project; the broader principle is that the observation must remain connected to the metadata needed to understand it.
Open Geospatial Consortium — SensorThings API ↗Trigger & Alert Assurance
A threshold is useful only when the measurement and action path are both controlled.
Quality assurance for a trigger system extends beyond comparing a value with a number. The project should define which value is tested, how it is processed, how it is verified, who is notified and who has authority to act.
Define the trigger basis
Parameter, units, baseline, raw/processed/derived status, rate rule, persistence rule, valid-data requirement, frequency, contacts and action ownership.
Preserve the evidence
Record the value, timestamp, instrument/system state, verification result, related data, site condition, notifications and required response.
Close the technical loop
Retain the review, inspection, instruction, increased monitoring, revised interpretation and any approved change to the trigger or monitoring plan.
No universal movement threshold fits every project. Trigger values and actions must come from the applicable design, asset sensitivity, expected behaviour, uncertainty and formally approved action framework.
Official project lesson: Crossrail’s Stepney Green cavern paper describes project-specific Green, Amber and Red trigger zones linked to predicted lining displacement and used as benchmarks for checking observed behaviour. The lesson is the connection between prediction, measurement and action—not reuse of those numerical limits elsewhere.
Crossrail Learning Legacy — Stepney Green Cavern ↗Project-Specific Context
Data assurance cannot be separated from geology, environment and project stage.
This is a global capability page, so RAUZ does not invent a single “local geology”, groundwater profile, climate or trigger regime. Real project QA/QC must be configured against official site information and the physical mechanism the monitoring system is intended to observe.
Ground model & stratigraphy
Fill, soft soil, rock structure, weak layers, stiffness contrast, compressibility and known mechanisms affect what a credible movement profile may look like.
Groundwater & pore pressure
Dewatering, recharge, rainfall, pumping, seepage, tidal or seasonal effects can alter both physical response and interpretation.
Weather & exposure
Temperature, rainfall, flooding, humidity, freeze-thaw or other relevant exposure can affect the system, equipment, power, communications or baseline behaviour.
Sequence & timing
Excavation, support installation, tunnelling, dewatering, loading, grouting, piling or temporary works provide the event timeline needed for validation.
Project type & consequence
Tunnels, slopes, buildings, dams, railways, bridges, mines and environmental systems have different mechanisms, frequencies and escalation paths.
Access, power & telemetry
Remote sites, live assets and dense urban works require different arrangements for communications failure, buffering, fallback readings and out-of-hours review.
Project & Contract Interfaces
Many monitoring-data failures begin at the interface between organisations.
An accurate sensor cannot compensate for unclear data ownership, undefined acceptance criteria or an alarm with no named response owner. Assurance requirements should appear in the monitoring plan, technical scope and project interfaces—not only inside software.
| Interface | What should be defined | Why it matters |
|---|---|---|
| Data ownership | Raw data, processed values, metadata, configurations, QA flags, reports and close-out archives. | Prevents loss of the engineering record at handover or supplier change. |
| Acceptance criteria | Completeness, frequency, valid-data rules, calibration/check status, review deadlines and reporting. | Makes “acceptable data” measurable rather than subjective. |
| Alarm responsibility | Who receives, verifies, escalates and closes alerts, including out-of-hours arrangements. | A correct alarm can still fail if nobody owns the response path. |
| Change control | Approval for baseline, trigger, sensor, transformation, filter and manual-edit changes. | Protects continuity and prevents unexplained changes. |
| System availability | Communication outage, buffering, recovery, maintenance, failure notification and fallback. | Distinguishes “no movement” from “no valid data”. |
| Independent review | Access to raw evidence, metadata, calculations, QA status and trigger basis. | Allows a second party to challenge and reproduce conclusions. |
| Retention & handover | Archive formats, revision history, close-out status and retention requirements. | Keeps the record usable after active monitoring ends. |
RAUZ can support the technical definition of these interfaces during monitoring planning, mobilisation, independent review, data recovery or recurring monitoring-intelligence work. Contractual wording and statutory duties remain jurisdiction- and appointment-specific.
Official International Lessons
Established programmes treat data quality as a system, not a single check.
The examples below come from official government, project, standards or original-provider sources. They are not RAUZ projects and do not imply endorsement, partnership or commercial association.
Plan quality around intended use.
EPA guidance distinguishes programme-level QA from specific QC measures and uses Data Quality Objectives to define the type, quantity and quality of environmental information needed for defensible decisions.
Official EPA guidance ↗Quality control continues through the data lifecycle.
FHWA’s LTPP programme documents controls before, during and after collection, database checks, audits, higher-order checks, peer review and feedback.
Official FHWA source ↗Baseline evidence improves interpretation.
Crossrail’s Hyde Park research reported more than 12 months of baseline monitoring to assess measurement-system accuracy and thermal or seasonal effects before tunnelling response.
Official Crossrail source ↗Automation can validate and flag.
Leica officially describes automated monitoring functions including outlier detection, data validation, filtering and automatic remeasurement across geodetic, geotechnical and environmental sensor data.
Official Leica source ↗Multi-source systems still depend on data integrity.
Sixense’s Beyond Monitoring material describes multi-source integration, validated manual measurements, smart alarms and controls intended to support reliable monitoring information and decisions.
Official Sixense source ↗Interoperability depends on context.
The OGC SensorThings API models observations and metadata across heterogeneous sensing systems, illustrating why data exchange must preserve the information needed to understand a measurement.
Official OGC source ↗RAUZ Role
Quality assurance should make monitoring conclusions easier to defend.
RAUZ sits between measurement and decision. The role is to make the evidence chain visible: what was measured, how it was checked, what changed, what was corrected, what remains uncertain and how the issued interpretation was reached.
Monitoring QA/QC review
Review monitoring plans, instrument schedules, baseline rules, source data, QA flags, trigger logic, reports and exceptions from an independent technical perspective.
Assurance workflow design
Define metadata requirements, validation rules, review status, escalation logic, reporting, change control and handover around existing systems.
Recurring data assurance
Apply scheduled completeness, validation, exception and trend reviews as part of a wider Monitoring Intelligence or automated-reporting workflow.
Typical deliverables
- Monitoring QA/QC review memo
- Data-quality and completeness register
- Baseline / configuration review
- Metadata and traceability requirements
- Validation-rule schedule
- Trigger / alert assurance review
- Interface and responsibility matrix
- Recurring quality review summary
Potential collaboration routes
- Owner / authority — assurance requirements and oversight
- Designer / consultant — monitoring-plan QA and evidence review
- Contractor — workflow, reporting and QA/QC support
- Monitoring provider — second-layer review and governance
- Sensor / IoT provider — metadata, validation and context
- InSAR provider — provenance and ground-data comparison
Scope boundary: RAUZ can provide an agreed technical assurance and review scope. Formal certification, statutory approval, Engineer-of-Record duties, laboratory accreditation, manufacturer certification or project safety authority should not be assumed unless expressly included and legally applicable.
Frequently Asked Questions
Monitoring data quality and QA/QC questions.
Is Quality & Data Assurance the same as instrument calibration?
What is the difference between QA and QC in monitoring?
Can RAUZ review monitoring data from systems it did not install?
Should an outlier simply be deleted?
How should a trigger exceedance be quality-checked?
Can one QA/QC procedure be used for every project?
Can QA/QC be automated?
Does RAUZ certify that monitoring data is correct?
Official Reference Library
Public sources used for this technical discussion.
External material is used for technical context only. Product and project references remain the property of their respective organisations and do not imply endorsement, partnership or commercial association with RAUZ.
U.S. EPA — QA/QC
Official explanation of quality assurance, quality control, data quality objectives and Quality Assurance Project Plans for environmental information.
Open EPA source ↗U.S. EPA — Data Verification & Validation
Official EPA guidance resources for environmental data verification and validation.
Open EPA source ↗FHWA — LTPP Data Quality
Official documentation of layered data-quality controls, database checks, audits, peer review and feedback.
Open FHWA source ↗Crossrail Learning Legacy
Official project learning on high-quality field instrumentation, baseline monitoring and project-specific trigger zones.
Open Crossrail source ↗OGC — SensorThings API
Open standard for observations and metadata across heterogeneous IoT sensor systems.
Open OGC source ↗Leica Geosystems — GeoMoS
Official monitoring-platform description covering multi-sensor acquisition, outlier detection, validation, filtering and automatic remeasurement.
Open Leica source ↗Sixense — Beyond Monitoring
Official monitoring-platform material covering multi-source data, manual measurement validation, alarms and secure data handling.
Open Sixense source ↗RAUZ — Data Integration
RAUZ’s first-party approach to preserving source, time, units, references and metadata across multi-domain monitoring data.
Open RAUZ Data Integration →Start a Technical Review
Have monitoring data you do not fully trust?
Send a representative monitoring report, sample dataset, instrument schedule or QA/QC procedure. A useful first discussion defines the monitoring objective, data sources, project stage, known quality concerns, trigger framework and the decision the evidence is expected to support.
What to send
Instrument register, installation or calibration records, baseline information, representative raw and processed data, QA flags, trigger table, monitoring report, project chronology and relevant drawings.
What RAUZ can define
Whether the priority is a QA/QC gap review, baseline/configuration check, metadata improvement, focused Data Diagnostics, independent review or recurring Monitoring Intelligence assurance.