Who should a monitoring system trust when the data disagrees?
Divya Koppikar, Product and UI/UX Designer, Nirixense Technologies
Om Narayan Singh, Applications Engineer, Nirixense Technologies
(September 2026)
Not every engineering decision requires the same evidence. The more consequential the decision, the more context is needed to make it responsibly.
From observation to context
In the last article, we looked at how Structural Health Monitoring (SHM) is beginning to move beyond simply identifying changes in infrastructure towards supporting the decisions that follow those observations. We asked what actually happens between an observation and a decision, and why the value of monitoring increasingly lies in making that reasoning more informed and consistent.
This time, the question is slightly different.
What happens when the evidence itself does not tell one clear story?
A sensor may indicate an unusual response while an inspection shows no visible deterioration. A current measurement may differ from historical behaviour, but the loading or environmental conditions may also have changed. A structural model may predict one response while the measured behaviour suggests another.

These situations are not unusual in engineering. They are part of working with complex physical systems. The important question is therefore not simply which source should be trusted.
It is what evidence is relevant to the decision being made, and what additional context is required before that decision can be made with confidence?
The decision changes what information matters
A sensor reading does not have a single meaning.
The context required to decide whether to continue monitoring, investigate, inspect, recommend maintenance, restrict operations or intervene immediately can be very different, even when those decisions begin with the same observation.

Consider an unusual increase in vibration. If the immediate decision is whether to continue monitoring, a recent history of similar behaviour and the current operating conditions may be sufficient. If the decision is whether to initiate an inspection, persistence, location and related sensor behaviour become more important. If the decision is whether to impose an operational restriction, the required evidence becomes considerably broader.
The observation has not changed. The decision has.
And with it, the context required to make that decision.
Different decisions require different context
A useful way to think about monitoring is therefore to start with the decision rather than the data.
Should we continue monitoring?
At this stage, the system may need to establish whether the behaviour is temporary or persistent, whether it has occurred before and whether current environmental or operating conditions could explain it.
Context:
Current readings → recent history → environmental conditions → operating conditions
Should we investigate further?
Now the question becomes whether the observation is sufficiently unusual or persistent to justify additional investigation.
Context:
Historical baseline → related sensors → anomaly persistence → previous occurrences
The system does not necessarily need to determine what is wrong. It needs to establish whether there is enough reason to look closer.
Should we inspect the asset?
A physical inspection introduces another layer. The engineer may need to understand where the behaviour is occurring, whether it corresponds with known structural elements or previous defects, and whether other evidence supports the need for inspection.
Context:
Sensor behaviour → spatial location → asset history → previous inspection findings → operating conditions
The monitoring data becomes a way of deciding where and why to look, rather than replacing the inspection itself.
Should we recommend maintenance?
This requires more than evidence that something has changed. The engineer needs to understand whether the condition is deteriorating, what its likely significance is, what interventions have previously been undertaken and what the consequences of delaying action might be.
Context:
Trend → severity → deterioration history → previous interventions → asset condition → consequence of inaction
The decision has moved from “Is something happening?” to “What should we do about it?”
Should operations change?
This is considerably more consequential. A speed restriction, load limitation or temporary shutdown directly affects how an asset is used.
The required context therefore extends beyond structural condition into operational context.
Context:
Structural behaviour → confidence in evidence → current loading → operating conditions → consequence of restriction → engineering assessment
The monitoring system is now informing a decision about the asset’s performance, not simply its condition.
The same asset can require different kinds of evidence
A good example comes from a continuously monitored railway steel truss bridge in India. Researchers compared measured structural responses with analytical expectations and found that strain measurements corresponded closely with simple truss-analysis estimates across many members, while measured accelerations differed substantially from calculated values. Other dynamic parameters were ultimately more useful for identifying deterioration.

The important lesson is not that one measurement was “right” and another was “wrong”. Different measurements were answering different questions about the structure.

The usefulness of the evidence depended on what the engineer was trying to understand.
This is an important distinction because engineering monitoring is often presented as a progression from measurement to diagnosis, as though every additional measurement simply makes the answer clearer. In practice, the relationship is more conditional.
The evidence required depends on the question being asked.
Context is not the same as more data
If every engineering decision simply required more data, the solution would be straightforward: add more sensors, collect longer histories and increase the amount of information available to engineers.
But context is not synonymous with volume.
A study of a railway bridge in Tamil Nadu demonstrated this particularly well. Even with a relatively simple bridge configuration, interpreting the large amount of sensor data was not straightforward. The researchers used multidimensional visualisation to identify relationships and patterns before applying quantitative analysis to validate those observations.
The challenge was therefore not a lack of measurements.
It was understanding the relationships between them.

More measurements increase what we can observe. They do not automatically increase what we understand.
When the environment becomes part of the evidence
The conditions surrounding a measurement can be just as important as the measurement itself.
The monitoring system developed for the Hong Kong-Zhuhai-Macao Bridge immersed tunnel, for example, considers structural responses alongside environmental measurements including temperature and humidity. Researchers found that fixed thresholds could generate excessive warnings because normal environmental and operational variations could themselves produce significant changes in the data. They therefore developed dynamic thresholds based on historical behaviour and introduced hierarchical warning levels.
This illustrates a broader point.

A reading cannot always be interpreted independently of the conditions under which it occurred.
A change that looks unusual in isolation may be expected under a particular environmental condition. Conversely, a relatively small deviation may become significant when it occurs under conditions where it should not.
The relevant question becomes:
What was happening around the structure when this measurement occurred?
The importance of knowing what decision comes next
This suggests a different way of designing monitoring workflows.
A system should not only ask:
“What is happening?”
It should also understand:
“What decision is this information being used to support?”
If the next decision is whether to inspect, spatial context and previous inspection history may matter most.
If the next decision is whether to intervene, deterioration trends, previous interventions and consequences may become more important.

If the next decision is whether to continue operating normally, structural behaviour, current loading, environmental conditions and confidence in the assessment may become critical.
The same underlying measurement can therefore support very different workflows depending on what comes next.
The decision determines which context matters.
And sometimes the decision is to escalate
There will also be situations where the available context is simply not sufficient.
The system may identify a significant deviation but lack enough historical information to interpret it. Different sensors may provide conflicting signals. An unfamiliar pattern may appear. Or the consequence of making the wrong decision may be too high to proceed without engineering review.
In these situations, the appropriate next step may not be another conclusion.
It may be escalation. Continue monitoring. Collect another measurement. Inspect the asset. Review the operating conditions. Ask an engineer to investigate.

This is important because a mature monitoring system should not be expected to produce an answer to every observation.
It should also recognise when the available evidence is insufficient for the decision being considered.
Where decision support begins
This is where automation begins to become meaningful, but not necessarily as an attempt to automate engineering judgement itself.
The more immediate opportunity is to make the decision process more consistent: bringing relevant historical evidence into view, connecting related observations, surfacing previous inspection findings and decisions, identifying recurring conditions, and recognising when a situation requires investigation or escalation.
The objective is not to make every decision automatically.

It is to reduce the amount of context an engineer has to reconstruct manually every time a decision needs to be made.
That distinction matters. Because automation without an understanding of the decision can simply accelerate the wrong workflow.
The more useful question is therefore not:
“What can we automate?”
It is:
“What does this decision require, and can the system reliably assemble the context needed to support it?”
Where decision support begins
Structural Health Monitoring has already made infrastructure increasingly observable. The next challenge is making the information around those observations equally usable.
That means connecting measurements with the conditions in which they occurred, the history of the asset, previous inspections, previous decisions and the consequence of the action being considered. It also means recognising that different decisions require different levels of evidence.
A decision to continue monitoring does not require the same confidence as a decision to restrict operations.
A decision to inspect does not require the same evidence as a decision to intervene.
And a decision to escalate can sometimes be more responsible than forcing an uncertain conclusion.

This may be one of the more important shifts in Structural Health Monitoring: moving from systems that simply identify changes toward systems that understand what those changes are being used to decide.
Because the goal of monitoring is not to have an answer to every question.
It is to have the right evidence, in the right context, when a decision needs to be made.
What we’re building at Nirixense
This is the direction we are exploring at Nirixense.
We are building SHM systems that go beyond presenting streams of sensor data and isolated alerts. The goal is to connect observation, context, analysis and action within the same workflow.
That means bringing together live and historical sensor behaviour, spatial asset context, environmental and operational conditions, anomaly trends, sensor relationships and asset history, so that an engineer does not have to reconstruct that context manually every time something changes.
The mature system should be able to show not only that something has changed, but also:
Where did it change? How unusual is it? Has it happened before? What else was happening at the time? Which related measurements support or contradict it? What happened the last time this occurred? What level of attention does it warrant?
And when the evidence is insufficient, the system should make that visible too.

Rather than forcing a definitive answer, it should help identify when to monitor, investigate, inspect, escalate or act.
This is the shift we are working toward at Nirixense: from a monitoring dashboard that tells engineers what the structure is doing, to a decision-support system that helps them understand wshat that behaviour means in context and what may need to happen next.
Because ultimately, infrastructure does not need more data for its own sake.
It needs better-connected evidence when decisions matter.
© 2026 Nirixense Technologies Pvt. Ltd. All rights reserved. email: connect@nirixense.com
About this series: Field Notes in Structural Intelligence is a thought leadership series by Nirixense Technologies, where we engage with experts across structural engineering and monitoring to understand how SHM actually works in practice and where it needs to evolve next.
