Five sensors, five rates.
One warning, hours early.
Chalk fuses vibration, motor current, shaft speed, pressure and bearing temperature, each sampled at its own rate, into features on one clock, and scores every pump's failure risk with a model that runs inside the query. On this fictional fleet the bearing fault was flagged 15 hours before the pump tripped.
Eight pumps, 48 hours, one bearing fault
Drag the timeline or press replay. P-104 develops a bearing fault and trips at hour 44. P-106 runs near full load all day, so its raw vibration is among the highest in the fleet while it stays healthy; judged per unit of load, it looks like every other pump. Pick any pump and instant, then recompute it live on Chalk.
P-104 · synchronized sensor traces
10-minute summaries · 48 hFused features
as of the cursor- Vibration RMS, 1 h √ mean of squared vibration samples
- 5.39 mm/s
- Load, 1 h mean motor current ÷ rated current
- 92%
- Vibration per unit load vibration RMS ÷ load: two sensors fused
- 5.86
- Vibration trend 1 h RMS ÷ 6 h RMS
- 1.26×
- Bearing temperature slope 1 h mean vs 6 h mean
- +2.37 °C/h
Recompute P-104 at hour 36.0 with a real Chalk online query, its clock pinned to that instant. Chalk reads the raw historian, fuses the five tags and runs the model, usually in a few seconds.
Northfield Water and its pumps are fictional, and so is the sensor data, generated from a seeded simulator. The fleet view is a recorded Chalk offline query (768 rows, one per pump every 30minutes) over that historian; “Recompute live” runs a real Chalk online query against the same feature definitions each time you press it.
How it works
Sensor fusion is mostly a timing problem: getting tags that report at different rates onto the same instant, without letting any of them peek ahead.
Read the historian as it is
Five tags per pump arrive at their own rates, from every 10 seconds to every minute. Chalk reads them as one table of tagged samples; nothing is resampled upstream.
Put every tag on one clock
Windowed aggregations ending at chalk_now turn each tag into a value per instant: vibration RMS, mean current, speed, pressure and bearing temperature.
Fuse across sensors
A loud pump is not a failing pump. Vibration is judged per unit of load measured by motor current, next to its 6-hour trend and the bearing's temperature slope.
Score the risk in Chalk
A logistic regression trained offline runs as a native expression over the fused features, and a second head estimates the hours left once a fault is developing.
Fuse your own sensors
Clone the example, deploy it to a branch, and replay the fleet with one offline query. The historian here is a seeded simulator so the example runs anywhere; point the SensorReading resolver at your own historian table and the features and model do not change.
The model was trained on a separate simulated fleet of 160 pumps (holdout AUC 0.994) and never saw the eight pumps on this page.
chalk-ai/predictive-maintenancegit clone https://github.com/chalk-ai/predictive-maintenance
cd predictive-maintenance
chalk login
# The historian, the fused features and the model, on a branch
chalk apply --branch predictive-maintenance
# Fleet risk every 30 minutes for 48 hours: one offline query
./record_run.py
# Or ask for one pump at one instant of the recorded window
chalk query --branch predictive-maintenance --in pump.id=P-104 \
--out pump.failure_risk_12h --out pump.vib_per_load_1h \
--now 2026-10-11T12:00:00ZWhat Chalk handles
Alignment, fusion and scoring in one feature graph, served live and replayed exactly.
Any rate, one timeline
Tags sampled every 10 s and every 60 s land on the same instant without a resampling job, because the window is part of the feature.
Features that span sensors
Ratios, trends and slopes across tags are one-line expressions over other features, computed in the same query.
Same definitions, live and replayed
The online query on this page and the offline replay behind the fleet view run the same feature code. Here they agree to within 1e-11.
Models as expressions
A trained linear or logistic model becomes a Chalk expression: vectorized, versioned with the features, and nothing extra to serve.
Point-in-time training data
Every row of the replay sees only samples from before its timestamp, so the same query that powers the demo builds leak-free training sets.
Runs next to your data
Resolvers read your historian or warehouse where it lives, and the API on this page is a Chalk ScalingGroup in the same environment.
Catch the failure before the trip
Pumps, turbines, compressors or vehicles: talk to an engineer about fusing your sensor data into features your models can act on.