Applications built on what your sensors actually record.
Sensor applications live or die on a question asked too late: at what resolution is this recorded, and for how long is it kept. Answer it first and the application is straightforward engineering. Answer it after the interface is designed and you discover the data cannot support the question the interface was built to ask.
Pipelines sized for your actual message rate including bursts, with backpressure so a spike delays rather than drops data.
Storage and retention chosen against the questions you need to answer, including how far back and at what granularity.
Surfacing readings that matter, tuned against your own history rather than generic thresholds.
Filtering and aggregation on the device where bandwidth cost or latency demands it, within the hardware's real power budget.
Dashboards and alerts built for the person acting on them, at the refresh rate the decision actually needs.
Sensors drift. Handling recalibration and flagging suspect readings is designed in rather than discovered in year two.
A sample of the raw data and an honest description of how it is currently recorded and stored. That tells us what can be answered today and what needs a change at the device, which is far cheaper to establish before design than after.
Usually yes. The constraint is rarely the sensor brand — it is the sampling interval and retention, which determine the questions the data can support regardless of what is built on top.
Then that is the project, at least initially. Building analysis on inconsistent readings produces confident outputs nobody should trust, so we would rather fix the recording first and say so plainly.