Sensor Data Validation Chain

validated scientific chain v1.0.0 cc-by-sa

Block ID: 695cdbf7-384e-4996-8741-b1f41f4ef52d

Community-contributed block. PromptDNA makes no guarantee of output quality or fitness for purpose. User assumes all responsibility for use.

Template

Validate the sensor or telemetry data in {sensor_context} before drawing any conclusion from it, because bad data confidently analyzed is worse than no data. (1) Check physical plausibility first: are values within the range the measured quantity can physically take, and within the sensor's rated range? Readings pinned at a limit often mean saturation or fault, not a real extreme. (2) Examine the time structure: flatlines (a stuck sensor), impossible jumps (dropout or glitch), and gaps — distinguishing genuine signal from artifacts of the acquisition system. (3) Cross-validate against redundant or related channels: a temperature that disagrees with a correlated pressure, or two sensors that should track but don't, localizes the fault. (4) Assess the noise character and whether it matches expectation — a sudden change in noise level signals a hardware or grounding problem, familiar to anyone who's chased signal integrity. (5) Check timing and synchronization if multiple streams are combined, since misaligned timestamps create spurious correlations. (6) Classify each anomaly as fix, flag, or discard with a documented reason, and state which conclusions the surviving data can support versus which require recollection. Never silently interpolate over a fault as though the data were real.

Validate the sensor or telemetry data in {sensor_context} before drawing any conclusion from it, because bad data confidently analyzed is worse than no data. (1) Check physical plausibility first: are values within the range the measured quantity can physically take, and within the sensor's rated range? Readings pinned at a limit often mean saturation or fault, not a real extreme. (2) Examine the time structure: flatlines (a stuck sensor), impossible jumps (dropout or glitch), and gaps — distinguishing genuine signal from artifacts of the acquisition system. (3) Cross-validate against redundant or related channels: a temperature that disagrees with a correlated pressure, or two sensors that should track but don't, localizes the fault. (4) Assess the noise character and whether it matches expectation — a sudden change in noise level signals a hardware or grounding problem, familiar to anyone who's chased signal integrity. (5) Check timing and synchronization if multiple streams are combined, since misaligned timestamps create spurious correlations. (6) Classify each anomaly as fix, flag, or discard with a documented reason, and state which conclusions the surviving data can support versus which require recollection. Never silently interpolate over a fault as though the data were real.

Variables

Name	Type	Required	Trust level
sensor_context		yes

sensor-datadata-validationinstrumentationchain-of-thought

Ratings

0.0

Overall (0)

0.0

Accuracy

0.0

Consistency

0.0

Clarity

0.0

Efficiency

Benchmarks

Not yet self-validated against any benchmark. Automated, evaluative only - not a factor in whether this block was published.

Submitted by James P FounderMod via mcp · 2026-07-18