TRIGGERS. CONTEXT. ESCALATION. DECISIONS.
Geotechnical Monitoring Alert Intelligence
GeoSmar reviews monitoring thresholds, data quality, alert severity and engineering context to help infrastructure teams distinguish credible change from noise and build clear, traceable escalation and response workflows.
Alert intelligence
An alert is a signal. The engineering decision comes after it.
Monitoring systems can generate alarms quickly. The harder task is deciding whether the change is credible, whether it is worsening, who needs to know, and what response is proportionate. GeoSmar approaches alerts as an engineering workflow rather than a notification setting.
What GeoSmar means by Alert Intelligence
Alert Intelligence combines trigger review, data-quality checks, severity logic, event verification, escalation rules and engineering interpretation. The objective is not to increase the number of alerts. It is to make each alert easier to understand, trace and act on.
Alert logic
A useful alert chain has more than one threshold.
A robust workflow separates data availability, data validity, trigger evaluation and engineering response. This helps prevent a communication failure, an isolated bad reading and a credible movement event from being treated as the same problem.
Trigger frameworks
Trigger levels should reflect the engineering problem and the required response.
There is no universal movement threshold for every asset. Trigger values should be tied to project-specific design assumptions, existing asset condition, monitoring purpose, stakeholder requirements and the response expected at each level.
Normal
Measurements remain within the agreed operating or observation range. Routine review continues.
Review / Alert
A value or trend warrants checking. The first question is whether the reading and its context are credible.
Alarm / Warning
Escalation increases. Additional verification, closer monitoring or a formal action plan may be required by the project framework.
Action
The project follows the defined response for the highest trigger state. Decision authority must already be clear before this point is reached.
| Logic type | What it checks | Where it can help | Key caution |
|---|---|---|---|
| Absolute threshold | Magnitude relative to a set limit | Settlement, displacement, pressure, vibration | A single value may need verification before interpretation. |
| Rate of change | How quickly the monitored parameter is changing | Progressive movement or changing deformation behaviour | The appropriate time window must match the mechanism and data frequency. |
| Persistence | Whether an exceedance continues over more than one reading or period | Reducing nuisance events from transient spikes | Persistence rules must not suppress genuinely rapid hazards. |
| Correlation | Relationship between two or more metrics | Groundwater versus movement, adjacent instruments, structural response | Correlation does not by itself prove causation. |
| No-data / system status | Whether expected data have stopped arriving | Automated monitoring networks | This is a monitoring-system issue, not automatically an asset-movement event. |
Data quality before escalation
The fastest alert is not useful if the input cannot be trusted.
Alert review should include a data-quality gate. A sudden change may represent real movement, but it may also be associated with a sensor issue, a baseline change, a missed reading, a survey reference problem, communications loss or another project-specific cause.
Continuity
Was the reading received at the expected time and interval? Are there gaps before the event?
Baseline
Is the comparison being made against the correct baseline and current instrument configuration?
Neighbouring evidence
Do nearby instruments or independent survey observations show a compatible change?
Direction and pattern
Is the movement direction physically plausible and consistent with the expected mechanism?
Rate and persistence
Is the change a one-off spike, a sustained trend or an accelerating pattern?
Project events
What changed at the site: excavation stage, loading, dewatering, rainfall, maintenance or another documented activity?
Response and escalation
Every trigger state should already have an owner, a clock and a next step.
Alert Intelligence is partly a technical problem and partly a communication problem. The response chain needs to be agreed before an event occurs, especially where monitored assets are sensitive or project decisions are time-critical.
- Who receives each severity level
- Who acknowledges the event
- Who verifies the monitoring data
- Who performs engineering review
- What response time applies
- What additional readings are required
- When monitoring frequency changes
- When work or access restrictions are considered
- Who has authority to change trigger levels
- How the event and response are recorded
Why acknowledgement matters
Why escalation should be severity-based
Why changing a trigger needs control
Applications
The alert logic changes with the asset and the failure mechanism.
Alert Intelligence is not a single software template. The monitored parameter, likely mechanism, acceptable response time and consequence of movement vary substantially between project types.
Deep Excavations & Tunnels
Settlement, lateral movement, groundwater, structural response and adjacent-asset behaviour may need staged review against construction progress.
Rail & Metro
Alerts may need to reflect track or structure movement, survey observations, vibration and operational interfaces, with clear notification hierarchy.
Slopes & Landslides
Movement may need to be considered together with groundwater, rainfall and rate of change. Rapid hazards require project-specific contingency planning.
Dams & Water Assets
Deformation, uplift or pore pressure and seepage-related indicators may require long-term trend interpretation as well as threshold checks.
Bridges & Structures
Displacement, tilt, strain, vibration or foundation response can be evaluated against asset condition, environmental effects and project criteria.
Critical Facilities
Where operational tolerance is low, data availability, confirmation rules and escalation responsibilities become as important as the threshold itself.
Official industry context
Established monitoring systems already separate threshold logic, notification and response.
The examples below are drawn from official public sources. They are included to show how mature monitoring programmes structure alarms and responses. They do not imply any partnership, endorsement or commercial relationship with GeoSmar.
Trimble T4D Control
Trimble documents alarm definitions with one or more conditions evaluated against sensor observations, configurable notifications, escalation, acknowledgement and alarm-event history. Current T4D documentation also separates sensor-data-flow status from alarm status.
Bentley iTwin IoT
Bentley lists threshold alerts, sensor-network health alerts, correlation alerts, recipient configuration, email/mobile/in-app notifications and issue tracking among iTwin IoT’s monitoring capabilities.
FHWA road tunnel guidance
FHWA’s road tunnel manual describes Review Level / Threshold Value and Alert Level / Limiting Value responses, including meetings, action plans, additional instrumentation and, at the higher level, stopping work subject to the project control procedure.
Hong Kong civil works control mechanisms
Hong Kong CEDD publications describe three-tier Alert-Alarm-Action mechanisms for monitored works and corresponding notification or response requirements. The exact levels and actions remain project-specific.
Scope and contract interface
Most alert disputes begin with unclear responsibility, not unclear colours.
Before an alert workflow goes live, the commercial and technical scope should state who owns the trigger values, who verifies data, who receives notifications and who has authority to make project decisions.
| Interface | What should be defined | Why it matters |
|---|---|---|
| Trigger ownership | Who sets, approves and changes thresholds and response levels. | Prevents software settings from being mistaken for approved engineering criteria. |
| Data responsibility | Who operates instruments, validates readings, maintains communications and identifies no-data conditions. | Clarifies the boundary between monitoring-system operation and engineering interpretation. |
| Review frequency | Continuous system notifications, scheduled engineering review, event-driven review, or a combination. | Avoids an assumption that every digital alert includes immediate engineering assessment. |
| Response time | Working-hours, on-call or 24/7 obligations, and the clock that starts each response period. | Critical for commercial pricing and operational expectations. |
| Escalation chain | Recipients, acknowledgement rules, deputies and escalation after non-response. | Reduces ambiguity during time-sensitive events. |
| Decision authority | Who can suspend work, restrict access, change monitoring frequency or approve resumption. | GeoSmar review should not be confused with statutory or site-control authority unless expressly contracted. |
| Audit trail | Event history, acknowledgements, comments, threshold revisions and final disposition. | Makes later technical and contractual review possible. |
GeoSmar deliverables
From a threshold table to a reviewable alert strategy.
GeoSmar can support a project at design stage, during active monitoring or after a difficult alert event. The scope can be one-off or recurring depending on the data flow and the level of engineering involvement required.
Alert Strategy Review
Review proposed trigger levels, severity naming, monitoring frequency, confirmation logic and response actions.
Trigger & Escalation Matrix
Document conditions, recipients, acknowledgements, response time and decision interfaces in one traceable matrix.
Data-Quality Gate
Define checks for missing data, obvious anomalies, baseline changes and instrument or communication status before engineering escalation.
Alert Event Review
Review the event sequence, data credibility, related instruments, project activities and whether the alert logic performed as intended.
Monitoring Intelligence
Provide scheduled engineering review of active alerts, trends and recurring issues as part of a wider monitoring-intelligence service.
Engineer-Reviewed Alert Reporting
Summarise important events, acknowledgements, technical interpretation, limitations and follow-up for project or asset reporting.
Frequently asked questions
Alerts should shorten the path to understanding, not create another queue to manage.
Does GeoSmar set the trigger levels for a project?
Can Alert Intelligence work with an existing monitoring platform?
Can GeoSmar reduce false or nuisance alerts?
Is an automated alarm the same as an engineering warning?
Can an alert be based on more than one sensor?
Does GeoSmar provide 24/7 alert response?
Discuss an alert framework
Have thresholds, alarms or escalation rules that need an independent engineering review?
Send the current trigger table, monitoring plan, sample event history or a recent alert report. GeoSmar can help identify whether the main issue is threshold logic, data quality, escalation design, monitoring diagnostics or the wider engineering interpretation.