Z-score answers the question, "how unusual is the value relative to the reference data?", while the alarm threshold answers, "has the approved operational limit been exceeded?" These are two independent axes. A value can be unusual and safe, or statistically typical and already beyond the engineering limit. Z-score must not be turned into a universal safety threshold.
In brief
- An anomaly describes a difference from the data pattern. An alarm describes an operational rule approved for the asset.
- A baseline may include an invalid state, seasonality, the construction period, or sensor drift. "Normal in history" does not mean "permissible".
- Z-score depends on the sample and the dispersion measure. A small or nearly constant sample can produce an unstable result.
- The best view places the physical value, WARNING / ALARM thresholds, z-score, reference range and data quality side by side.
- A language model can describe a calculated anomaly, but it should not define the safety state on its own.
AI analysis buyers often hear the promise, "we automatically detect anomalies." It sounds like a ready-made alarm. Yet an unusual reading after a trial load change may be fully expected from an engineering point of view, while a slow limit exceedance may stop looking unusual once the moving window learns the new level. If the panel reduces both cases to one red dot, it does not support decision control.
A broader division of roles between statistics, rules and the narrator is described in the article about what AI actually does in structural monitoring.
The separation is simple in concept, but it requires discipline in the interface and the procedure. The statistical path detects deviation. The engineering path assesses the value against the limit and the asset context. Only then does a human combine the evidence and choose the action.
Two definitions that organize the discussion
Z-score is the distance of an observation from the mean expressed in units of standard deviation for the adopted reference set. The classic form is:
z = (x − mean) / standard deviation
NIST notes that using classic z-scores to flag potential outliers can be misleading, especially for small samples. It also describes a modified z-score based on the median and the median absolute deviation, which is more resistant to the influence of extreme observations. Neither version, however, turns itself into a safety limit.
An alarm threshold is an approved value or rule after which the organization changes operating state and carries out the assigned action. It should result from the design, engineering assessment, observational method, instruction, trials, or a justified asset analysis. The threshold has a physical unit, an owner, hysteresis and a response procedure. The process for defining it is developed in the guide how to set alarm thresholds in structural monitoring.
| Feature | Z-score | WARNING / ALARM threshold |
|---|---|---|
| question | is the result unusual | do we change the operating mode |
| source | data and the selected reference window | design, analysis, procedure and responsibility |
| unit | dimensionless number | measurement unit or explicit relation |
| variability | changes with the baseline | changes after configuration approval |
| main risk | bad or too small baseline | threshold without justification or response |
| role | triage and deviation indication | trigger for operational action |
2x2 matrix: typical or unusual x below or above the threshold
The two paths create four states. None of them should be removed from the interface.
| Below operating threshold | Above operating threshold | |
|---|---|---|
| statistically typical | normal operation within the approved range | exceedance tamed by the baseline; respond according to the threshold |
| statistically unusual | anomaly for review, without an automatic claim of danger | highest priority: the threshold and the deviation point to the same case |
Typical and below threshold does not mean "definitely correct". The sensor may be stuck, and a complete series may repeat the same wrong value. This state only says that the value resembles the baseline and does not exceed the configured limit.
Unusual and below threshold often appears after a change in operation, a sharp temperature shift, maintenance, or a local disturbance. It requires quality control, neighboring channels and context. It usually does not justify a "danger" message if the safety threshold and other evidence do not confirm it.
Typical and above threshold is the most deceptive state. If the asset stays at an elevated level for a long time, the moving baseline may start treating it as ordinary. The threshold still requires action. Statistics do not cancel an approved limit.
Unusual and above threshold combines two signals. First you check quality and timing, then you execute the threshold response. Z-score helps prioritize the analysis, but the procedure should also exist when the AI layer is unavailable.
Two examples that expose the false equivalence
Illustrative example 1 - unusual, but below threshold. Assume that the strain in an element changed within a narrow band around 40 µε for weeks. During a controlled test it reaches 70 µε, and the approved WARNING level is 150 µε. The z-score may be high because the historical spread was small. The value needs to be linked to the test and checked in context, but the statistics alone do not prove a dangerous state.
Illustrative example 2 - typical, but above threshold. Assume that after a slow change in conditions, the series has stayed around 165 µε for a month. If the baseline includes that same month, the latest 166 µε may have a z-score close to zero. The WARNING threshold of 150 µε remains exceeded. The organization carries out the planned action regardless of the fact that the result is not unusual relative to the last few weeks.
The numbers are for illustration only. They are not thresholds for any real asset. They show that a statistical premise and an engineering limit can point in different directions.
The baseline is a hypothesis about normality, not the truth
The z-score result depends on what entered the reference set. The window may cover summer and the analysis winter; a quiet operating period and then construction work; the sensor before and after a reference change; different intervals or missing data during the key event. Each such difference changes the interpretation.
Before using the baseline, answer six questions:
- does the range represent the same asset state and operating mode;
- does it include the full temperature or load cycle relevant to the channel;
- were the configuration, calibration and reference consistent;
- is the sample sufficiently large and continuous;
- did extreme events dominate the mean and deviation;
- are you not teaching "normality" on a period that already exceeds the limit.
A z-score close to zero may also result from a wide baseline spread. A high standard deviation flattens the result. Conversely, an almost zero spread can cause a huge z-score for a small physical difference. For a constant channel, divide-by-zero must be handled, and you should consider whether the lack of variability is itself a separate device anomaly.
Seasonality requires a comparable context or a model, not a simple "last 30 days" window. Sometimes the right comparison is against a similar temperature, reservoir level or work phase. The more complex the correction, the more important clear assumptions and reproducibility become.
When to change the baseline, and when to change the threshold
You update the baseline when the definition of the normal statistical context has changed: a construction phase has ended, a new operating mode has appeared, a fuller cycle has been collected, or the old range no longer represents the current question. You do not do this just to reduce the number of anomalies. The change should have a date, an author, justification and a comparison of results before and after.
You change the threshold for a different reason. A new design document, engineering assessment, test results, a structural change or a change in the response procedure is needed. The statistical frequency of exceedances may be information for review, but it does not by itself justify raising the limit. If there are too many alarms, first assess hysteresis, path quality, seasonality and physical meaning.
With every change, run a cross-check on a retained range:
- calculate old and new z-scores without changing the physical values;
- show which observations changed anomaly classification;
- keep the WARNING / ALARM thresholds unchanged during the baseline test;
- when changing the threshold, show the history that would change state;
- record the impact on the number of messages and the operator procedure;
- obtain approval from the proper configuration owner.
This separation protects against "training the alarm" that every long-lasting problem is normal. It also lets you speak with the vendor precisely: updating the statistical model must not quietly shift the engineering limits.
Assign two owners as well. The person responsible for analytics approves the baseline, the method and the stability tests. The engineer responsible for the asset approves the threshold and the response. If one person performs both roles, the protocol should still separate the two justifications. That way the audit shows whether the statistics changed, or the operational decision changed.
Two-path process on one dashboard
First, calculate and display the physical value. Next to it are the approved thresholds and the current state with hysteresis. The second layer shows z-score, the analysis range, the baseline, sample size and quality diagnostics. It does not replace the first.
The triage order may look like this:
- confirm freshness, unit, configuration and absence of channel error;
- assess WARNING / ALARM and execute the assigned response;
- assess z-score and the direction of deviation relative to the baseline;
- compare temperature, load and neighboring points;
- record the human interpretation and next step;
- after the event, assess whether the baseline still represents the correct state.
Do not tune the safety threshold automatically so that "anomalies disappear". Nor should you move the baseline simply because the z-score is triggered often. Frequent deviations may mean seasonality, a wrong reference group, a process change or a real evolution of the asset. Each cause requires a different correction.
Acceptance checklist for z-score analysis
- [ ] The value, unit and channel sign are documented.
- [ ] The threshold has an engineering source, an owner and an action.
- [ ] The analysis window and a separate baseline are defined.
- [ ] The report shows the size of both ranges.
- [ ] Configuration and reference consistency have been confirmed.
- [ ] It is known whether the mean and deviation or a resistant method was used.
- [ ] Small samples and zero or very small spread are handled.
- [ ] Seasonality and operating mode are part of the interpretation.
- [ ] A high z-score does not automatically set a safety alarm.
- [ ] A low z-score does not mute a threshold exceedance.
- [ ] The dashboard shows data quality and freshness.
- [ ] The result can be reproduced without a language model comment.
- [ ] A human records the decision and justification.
What this looks like in Inclify
Inclify calculates statistics and anomalies deterministically in the database. The analysis compares the current window with a longer baseline and shows, among other things, z-score, jumps, the last value and channels with no change. The risk assessment report also uses resistant measures based on the median and MAD, as well as EWMA and CUSUM. These tools are for prioritization, not for setting safety limits on their own.
WARNING and ALARM thresholds are configured independently for each channel and operate with hysteresis. The alarm state comes from the threshold rule, not from the language model text. This keeps the exceedance visible even when the value is statistically typical or the narrative layer is turned off.
The optional language model receives the calculated statistics, anomaly list and diagnostics, not raw time series. It writes commentary and recommendations. It does not calculate z-score and does not set statuses. Without the model key, the platform returns a deterministic report, so the core analysis does not depend on the narrator's availability. The architecture of this separation is developed in the guide on human-supervised AI.
The anomaly report can be combined with thresholds and channel history, allowing the operator to move from a statistical deviation to the physical value and the operating rule.
Limitations: what z-score does not know about the structure
Z-score does not know load-bearing capacity, failure mechanism, material condition or the consequence of exceedance. It does not know whether 1 mm means normal expansion joint operation or a significant support displacement. Meaning comes from the unit, location, model and the engineer's competence.
A point method will not detect a process outside the sensor. It may also label a service error, a reference change or a time correction as an anomaly. First assess data quality before AI analysis, because consistent statistics from a flawed stream still produce a flawed conclusion.
The threshold is not infallible either. A poorly defined limit, no hysteresis, or no update after a structural change can create false safety. Separating the paths does not remove the need to review both configurations. It only shows which part of the process needs correction.
FAQ
Does z-score 3 mean an alarm state?
Not automatically. It means a certain distance from the statistical center under the adopted method and baseline. The alarm state should come from the approved threshold and procedure. A high z-score below the limit may require review, but it is not proof of danger by itself. A low z-score also does not invalidate a threshold exceedance.
What is the best baseline for structural monitoring?
There is no single universal one. It should represent a comparable asset state, configuration, season and operating mode, and it should have adequate size. For a temperature-dependent channel, a fuller cycle or a conditional comparison may be useful. The range and the reason for its selection should be recorded and reviewed periodically.
Can an AI model set the safety threshold on its own?
It should not without an explicit, approved engineering process. Statistics may suggest a level that limits the number of deviations, but it does not know physical consequences and response time. In Inclify, threshold tuning provides proposals for human application; it does not change safety limits on its own based on the model narrative.
What should I do when z-score is high, but the value is far from the threshold?
First confirm data quality, configuration change, temperature and event context. Compare neighboring channels and the direction of change. If the reading is real, record the anomaly and watch its development according to the procedure. Do not escalate it automatically to damage, but do not ignore it just because the threshold has not been reached.
Why does z-score fall even though values remain high?
If the baseline is moved, a longer period of high values begins to dominate its mean or median. New observations stop looking unusual. This is a statistical adaptation, not a confirmation of safety. The physical threshold remains independent. It is worth keeping a fixed reference range or clearly versioning the baseline change date.
Can an anomaly result from sensor maintenance?
Yes. A change in reference, coefficient, orientation, time or device can create a jump without any change in the structure. That is why the analysis must know the configuration history and service work timing. Such an event is still statistically unusual, but its interpretation is technical. An audit log helps connect the deviation with a specific change.
Sources and further reading
- NIST/SEMATECH - Detection of Outliers - definition of z-score, limitations of small samples and modified z-score based on the median and MAD.
- NIST AI Risk Management Framework 1.0 - context, trustworthiness, validation and the role of human judgment in choosing metrics and thresholds.
- NIST AI RMF Core - documenting limitations, testing in context and system oversight.
- USACE EM 1110-2-1908 - Instrumentation of Embankment Dams and Levees - linking instrumentation, expected response and actions to engineering questions.
- NIST/SEMATECH - Control chart for standard deviations - example of distinguishing process variability from specification limits.
- Review of deep learning applications in SHM - supplementary literature on anomaly detection in structural monitoring.
What next
On one dashboard, add four fields: current value, threshold, z-score and baseline range. Then go through all four cells of the matrix and record the team's response. Talk to the Inclify team if you want to test this setup on data from a single channel before deploying the analysis across the full portfolio.