Data Quality for AI Analysis in Structural Monitoring

In brief

• A complete series can still be physically wrong if the sensor is mounted incorrectly, out of calibration, or blocked.
• Missing data are not random by definition. If transmission disappears during an extreme event, the remaining sample may understate the risk.
• Freshness is assessed against the real cadence of a given channel, not one global time for the entire project.
• A small sample limits the conclusion regardless of how convincing the language commentary is.
• The safest architecture first computes an explicit quality report and only then allows analysis and narrative.

A data owner fears two scenarios. In the first, they invest in AI that answers "too little data" after launch. In the second, they receive an elegant report with recommendations, yet nobody notices that half of the samples vanished during heavy rain or that one recorder's clock drifted by an hour. The second case is more dangerous because the result looks complete.

It is worth separating the layers described in the article on what AI actually does in structural monitoring: input control cannot be hidden inside the model narrative.

Data readiness is not a single 0-100 result. It is a set of conditions tied to a specific question. A series sufficient to detect a sudden jump may be too short to assess seasonality. Data that are good for a live dashboard may not be suitable for year-on-year comparison after a calibration change. Pre-flight control is meant to reveal this difference before analysis.

Data readiness is the ability to answer the question

Data readiness for analysis is the documented ability of a dataset and measurement path to support a specific purpose within a defined scope and with explicit limitations. It does not mean the absence of all flaws. It means the flaws have been measured and their impact on the conclusion has been assessed.

NIST reminds us that facts about a sample are not automatically facts about a population. Adequacy depends, among other things, on representativeness, sample size, variability, and required precision. In structural monitoring, the sample is usually passive rather than random. That makes it even more important to know which periods, operating modes, and weather conditions it covers.

The last row is separate by design. The first five can largely be computed automatically. Measurement-path capability requires documentation, testing, inspection, and metrological knowledge.

Five stream checks before the model

1. Completeness

Completeness is the ratio of received samples to expected samples within a given scope. The denominator must come from the real cadence or an explicit schedule. If a recorder typically sends data at the default 15-minute interval, one day contains, for illustration, 96 expected moments. However, you must not impose 96 on a channel that works event-driven or at a different cadence.

The percentage alone hides the distribution of gaps. Ten single gaps mean something different from one gap that covers a load peak. The report should show the number, length, and location of interruptions.

The operational meaning of these numbers and the way to account for them is developed in the guide on measurement data SLA.

2. Freshness

Freshness is the time from the last expected observation to the moment of assessment. It requires a correct clock and time zone. A channel updated every hour should not look the same as one updated every minute. The NO_DATA threshold must be matched to the real cadence, transmission latency, and the consequence of losing visibility.

3. Continuity and time

Continuity covers time monotonicity, duplicates, intervals, and regularity. Analysis may miscalculate rate or correlation if two devices have shifted clocks. A history upsert can backfill missing moments, but a report run before that should not pretend it saw them.

4. Technical payload correctness

Check required fields, types, units, ranges, device status, identification, and time. A rejected or only partly interpreted frame is an input problem, not a "structural anomaly." Keeping the communication log helps determine whether the error arose in the device, transmission, or mapping.

5. Sample size and representativeness

The number of samples affects the stability of statistics, but it does not guarantee coverage by itself. One thousand readings from one calm day will not replace a temperature cycle, a construction stage, or an event you want to infer. NIST points out that the required sample size depends on variability and desired precision; there is no single number for every problem.

A gap is not always random

Analysis often treats missing samples as a technical loss. In reality, the cause may be linked to the phenomenon: flooding cuts power, vibration loosens a connection, frost reduces battery performance, and an overloaded link drops packets exactly during many events. In that case, the available data systematically omit difficult conditions.

Pre-flight should mark whether the gap occurred during rain, works, an exceedance at a nearby point, or a device status change. Do not fill it with simple interpolation just to obtain an even series. An interpolated value may be useful for visualization, but it is not an observed maximum and must carry a separate flag.

In practice, prepare a "time x channel" map and overlay external events. If many devices lose data at the same time, look for a common power, transmission, or timing cause. If one point disappears, assess its path. This kind of analysis helps decide whether the report can proceed with caveats or whether the gap invalidates the question.

Stream quality is not physical correctness

The most dangerous dataset can have 100% completeness. A sensor detached from the element still sends regular casing temperature. A blocked transducer repeats a constant value with no gap. Swapped axes create smooth series with the wrong meaning. An incorrect reference produces a consistent offset.

Illustrative example. Assume an inclination channel with 2 016 readings over three weeks at an expected 15 min cadence. Completeness is 100%, time is monotonic, and the payload is correct. The series from the service day onward has exactly the same value. A stream pre-flight may deem transmission excellent, but the lack of variance should trigger diagnostics. Inspection reveals a mechanically jammed bracket. No model would repair the physical observation.

Measurement-path capability is confirmed by other evidence:

• current calibration and device identification;
• consistency of unit, axis, sign, and reference;
• documentation of location and installation method;
• a response test to controlled excitation, if possible;
• comparison with an independent point or method;
• consistency of behavior with the expected mechanism;
• service history and configuration changes.

The conclusion "high-quality data" should always state whether it refers to data transport, sample statistics, or the credibility of the physical measurement. Without this, one green tile creates false confidence.

Three decisions: run, run with caveats, do not run

Pre-flight should end with a decision, not only a chart. The matrix below does not establish universal percentage values. It shows the qualification logic.

The "run with caveats" case is needed because real data are rarely perfect. It must, however, constrain the language of the conclusion. If the sample does not cover winter, the report cannot speak about a full annual cycle. If the gap covers an alarm, trend analysis cannot suggest that the maximum did not occur.

"Do not run" is not an AI failure. It is a correct control action. Google, in its machine learning engineering rules, recommends testing infrastructure independently of the model, checking input completeness, and detecting silent pipeline failures. A model that refuses to work on unreliable input is more useful than a model that always produces text.

Pre-flight step by step

First, write down the question and the scope. "Assess the last 7 days against the previous month" is testable. "Tell me whether the structure is safe" does not define variables, responsibility, or boundaries.

Then run the automatic checks: sample size, expected samples, gaps, freshness, duplicates, time order, missing required fields, non-finite values, and configuration changes. Then run the physical checks: calibration, installation, range, reference, and expected response.

Finally, freeze the input package. It should contain the scope, channel list, quality statistics, exclusions, configuration version, and the go/no-go decision. This makes it possible to reproduce and assess the later commentary independently of the model vendor.

Pre-flight checklist to copy

• [ ] The analytical question, window, and baseline are unambiguous.
• [ ] Cadence is determined per channel from real data.
• [ ] Expected and received counts are shown for both windows.
• [ ] Gaps have a start, end, length, and relevance to the purpose.
• [ ] Freshness is assessed against cadence and transmission latency.
• [ ] Time is in UTC, monotonic, and without unexplained duplicates.
• [ ] The payload has the required fields, types, units, and identifiers.
• [ ] Device statuses and input errors are included.
• [ ] The sample covers the conditions the analysis is meant to discuss.
• [ ] Calibration, reference, orientation, and installation are current.
• [ ] Steady channels and post-service jumps have passed diagnostics.
• [ ] The decision reads: run, with caveats, or do not run.
• [ ] Caveats are passed into the report, not hidden in the log.
• [ ] The deterministic analysis works without a language narrator.

How this looks in Inclify

The data quality report in Inclify determines the real cadence from the median interval between samples. On that basis, it calculates the expected number of readings, completeness, gaps, freshness, and continuity. As a result, a 15-minute channel is not assessed the same way as a channel working at a different cadence.

The statistical analysis shows the number of samples in the current window and in the baseline. When the material is thin, the report limits the maximum score and marks the assessment as preliminary or the data quality as low. Z-score, jumps, and diagnostics are produced deterministically in the database. Without the language model key, the numeric report and fallback text still work. The article z-score and alarm threshold explains how to interpret this statistic against operating limits.

The optional narrator receives the calculated results and diagnostics, not raw time series. This limits the volume of data sent to the model, but it does not replace pre-flight or path assessment. The platform will not automatically confirm correct installation, calibration, or whether the sample represents the structural mechanism. These elements are approved by a human according to the principles of human oversight over AI.

The quality report can be compared with the NO_DATA alarm and the communication log, which retains raw frames for the configured period. This helps separate the absence of measurement from a mapping or transmission problem.

Limitations: a quality report can also be green and wrong

Quality heuristics rely on what the platform can see. If a device reports time incorrectly in a consistent way, or if the wrong unit was configured from the start, the stream may pass technical checks. You need independent documentation and a physical test.

Completeness against the detected cadence may entrench the wrong pattern. If the recorder was supposed to send every minute but has sent every 15 minutes by default, or more often from the beginning, the median will describe the actual state, not contract compliance. The contractual requirement and SLA must be compared separately.

The analysis will not reconstruct an event from the period of data loss. Backfilling the history later improves future reports, but it does not change the information available at the time of the earlier decision. If the result has evidential significance, keep the input package, generation time, and limitations used at that moment.

Sources and further reading

• NIST AI Risk Management Framework 1.0 - validation, trustworthiness, use context, and documentation of data and system limitations.
• NIST/SEMATECH - Populations and Sampling - representativeness, sample size, variability, and sample precision.
• NIST/SEMATECH - First Steps in Data Analysis - checking for missing values, outliers, and data errors before analysis.
• Google - Rules of Machine Learning - infrastructure testing, lost-data checks, and silent pipeline failure detection.
• NIST Federal Profile of NISTIR 8259A - Device Security - integrity, secure operation, time, and resilience of IoT devices.
• NIST IR 8200 - International Cybersecurity Standardization for IoT - the importance of integrity and availability of data in IoT systems.

What next

Choose one channel and run pre-flight on two windows: the current one and the reference one. Do not start with the model. Start with the gap map, time, payload, and installation evidence. Talk to the Inclify team if you want to run this test on a pilot dataset and determine whether the result qualifies for analysis without caveats.