The Data Log and the Symptom Don't Line Up: Decision Tree
Why this matters
The connected system's history says everything was normal. The customer swears it failed, or you can see it failing right now. When the log and the symptom disagree, techs pick a side too fast: trust the log and call the customer confused, or ignore the log and miss the one data point that would have solved it. Both are mistakes. A log is a witness with known blind spots, and the skill is knowing when it saw the event, when it looked the wrong way, and when it simply was not recording the thing that broke.
Start here: never trust a clean log over a live hazard
If you can see or smell a hazard, act on it regardless of what the log says.
- A gas smell, a burning smell, or water on a live circuit outranks any "all normal" reading. De-energize, evacuate, or shut off as the hazard demands, then reconcile the data later.
- A log that shows normal while a protective device is tripping in front of you means the log is missing the event, not that the trip is false. Believe the trip.
The log informs the diagnosis; it never overrides your senses on a safety call.
Branch 1: did the log actually capture the moment
Most log-versus-symptom conflicts are timing, not lying. Find out whether the event was even in frame.
- Sampling interval: a log that records every several minutes can miss a fault that lasts seconds. A short trip, a brief sag, a momentary spike falls between samples and leaves a clean record. Ask what the interval is before you trust a gap.
- Clock skew: the log's clock and the customer's phone are often minutes or hours off, especially after a power loss or a time change. Line up a known event (a manual start you just did) to calibrate the offset before you compare timestamps.
- Retention: short-retention logs overwrite. The event may have scrolled off. Absence of a record is not proof of absence.
If the event could not have been captured, the log is silent, not contradicting.
Branch 2: is the log measuring what actually failed
A sensor reports one point, and the fault may be somewhere the sensor cannot see.
- Placement: a temperature or pressure sensor reads its own location. A comfort complaint in a far room, a restriction downstream of the sensor, a leak past the metering point all fail without moving the logged value. Ask where the sensor sits relative to the symptom.
- What it does not measure: logs record the handful of points the system was built to watch. The failed item - a mechanical bind, a noise, an intermittent connection, a smell - may not be on any channel. A normal log of the wrong variables proves nothing about the fault.
- Derived versus measured: some logged values are calculated, not read. A computed number inherits the error of whatever feeds it.
Branch 3: reconcile, then decide who to believe
Now weigh the two witnesses with what you have learned.
- Trust the log when it clearly captured the window at a fine interval, the clock is calibrated, and the sensor sits where the fault would show. A good log beats a fuzzy memory.
- Trust the symptom when the interval is coarse, the clock is skewed, the sensor is placed away from the fault, or the failed item is not a logged channel. Your live reading or the customer's timestamped video wins.
- Trust neither yet when both are ambiguous. Add your own instrument at the fault, set a finer log if you can, and capture the next event directly.
When to pick which witness
| Situation | Believe | Why |
|---|---|---|
| Live hazard, log says normal | Your senses | Safety never yields to a clean log |
| Fine interval, calibrated clock, sensor on the fault | The log | It saw the event accurately |
| Coarse interval or skewed clock | The symptom | The event fell outside the record |
| Sensor placed away from the fault | The symptom | The log measured the wrong point |
| Both ambiguous | Neither | Instrument the fault and recapture |
The recap
- A live hazard beats any clean log; act on the hazard first.
- Check interval, clock skew, and retention before you trust a gap in the record.
- Confirm the sensor measures where and what actually failed.
- Believe the witness with the better claim, and when both are weak, instrument the fault yourself.
References
- Trade-standard practice for interpreting connected-system and controller logs
- Manufacturer documentation on sensor placement, sampling rate, and logged versus derived values
- See related: Reading a Connected System's Own Data Log; The Numbers Only Make Sense if Two Things Are Wrong