Intelligent Products & AI
Connected products that interpret what is happening and respond
Intelligence becomes part of how the product works: what it senses, what it concludes, what it may do and how it improves, engineered with the device that carries it.
This page starts with what intelligence enables in the product. Need responsibility for method, placement, runtime integration and lifecycle? See AI for IoT & Edge AI.
See what changes in the product- SignalVibration from the machine
- ContextNormal for this unit and load
- DecisionA developing change, not noise
- ResponseA person is told what to inspect
What becomes possible
Intelligence changes what a product can notice, decide and do
An intelligent connected product interprets signals from its physical environment and uses that context to support or make a decision, within limits its makers define.
Notice a condition while it is still developing
Is this normal for this machine, today?
Respond where the cloud is too far, too slow or not permitted
What is in view, and who needs to know now?
Adapt to the installation it finds itself in
Which threshold fits this unit?
Diagnose itself from signals it already has
Which part is at fault? Sometimes no extra sensor is needed.
Not every product needs this. If a rule or threshold is enough, it should stay a rule. A model earns its place when the decision depends on patterns a rule cannot express.
How intelligence enters the product
Design the product so intelligence can take part where it creates value
Intelligence added later inherits whatever signals, compute and update path the product already has. Designed in, it can take part where it creates value and change after launch.
That is what AI-native means for a connected product: data, context, decision boundaries and feedback designed into the architecture. It does not mean AI in every layer, cloud AI or autonomy in every decision.
One decision, placed three ways
Everything runs on the device; evidence returns to the cloud. Fits decisions that must be fast, work offline or keep data local, within the device’s compute and power budget.
The device senses; an edge gateway builds context across devices and decides. Fits when several devices share context, or a gateway can carry more compute than each device.
The device senses; the cloud decides; a person receives a recommendation in an application. Fits decisions that need fleet-wide data or heavy compute and can tolerate delay.
- Sense
- Which signals, trusted how far?
- Context
- What situation do they describe?
- Decide
- On what evidence, within what limits?
- Act
- What happens, and what stays human?
- Feedback
- How does the outcome reach engineers?
A lens, not a pipeline: most steps may stay ordinary rules. The dashed path is reviewed and ships as signed updates; the product does not retrain itself.
Edge AI runs machine-learning inference on or near the device instead of sending everything to the cloud. It is one of three places a decision can run, and none is better in general. What edge computing means for IoT

Beyond the model
A model that works in a notebook is not yet product behavior
Sensor, firmware, connectivity, data path, model and update path are one design problem. What is chosen at design time decides whether intelligence can be added later without rebuilding the product.
Signals
Can the decision trust what the product senses?
Placement, noise, representative dataConstraints
Can it run where it must, within the power, compute and latency allowed?
Runtime, memory, connectivityTrust
What happens when it is wrong, uncertain or offline?
Failure behavior, override, privacy, securityLifecycle
Can it be updated, observed and rolled back after launch?
Signed updates, monitoring, drift
Engineered, not only demonstrated
An AI capability has to be tested as part of the product, not only evaluated as a model
On the real sensors, in the real light, on the real hardware. Three anonymized projects, three lessons.

Recognize and alert at the edge
Recognition has to survive motion, light and a small budget
A drone concept had to recognize objects in motion, through shake, blur and changing light, and alert a person. Lightweight detection was optimized for edge processing.
See the projectWhat this showsProof of concept. Recognition was simulated with shapes projected onto a floor. No detection performance is claimed.
Flag a developing fault
A warning is only as good as the signal behind it
Vibration from rotating machinery was analyzed against reference levels, with alarms and a diagnostic dashboard for operators.
See the projectWhat this showsThe record supports signal analysis, alarms and a diagnostic dashboard, not quantified outcomes or predictive fault detection.
Adapt to the installation
Not every smart behavior is a model
Lifts differ in starting current, so detecting trips accurately meant adapting thresholds to each lift’s operating characteristics.
See the projectWhat this showsAdaptive thresholds are algorithmic. They are not machine learning.
Project examples focus on engineering scope, evidence and system boundaries.
Your starting point
Which of these sounds like you?
From prototype to product
- We have an AI prototype, but not a product architecture.
- We’re exploring computer vision.
First, we would look atWhat the prototype proved and what it did not; then what must change for real hardware, power, latency and updates.
Decide before you commit to engineeringFrom product data to product behavior
- We already collect useful product data.
- We want the product to understand context.
- We’re not sure where intelligence belongs.
First, we would look atThe decision first, then what the product can already sense, its compute and update headroom, and where the result must appear. Often the first change is the data path, not the model.
How IoT product engineering worksWhen placement is forced
- We need faster, local decisions.
- Cloud-only behavior isn’t enough.
- We’re considering greater autonomy.
First, we would look atWhat forces the decision to run where it does (latency, connectivity, privacy, power), and how much authority it should have.
Embedded and firmware engineeringBring the product, the decision it should make and the data you have.
Discuss where intelligence fits your productAfter launch
A product improves through an engineered loop, not on its own
Outcomes return as evidence; engineers review, validate and ship a signed update with a way back. That is why the update path is designed before the first model.
Cognitive IoT is Indeema’s model for where connected products are heading, from connected through observable to intelligent and adaptive. This page is the engineering path into those stages. Why Cognitive IoT
Where relevant, reusable Indeema engineering foundations can support the work. None is required. Explore the Indeema Ecosystem