2  From Sensing to Action

Keywords

sensor applications, sensor to action, IoT sensing decisions, measurement purpose, sensor evidence, data quality checks

2.1 Start With the Decision Story

Start with one ordinary decision, such as whether to water a plant bed, warn about a cold room, or turn on a fan. The sensor reading matters only because it helps that decision stay tied to context, quality checks, and a clear action boundary.

What a Sensor Application Promises

A sensor application is the full path from a physical condition to a useful decision or action. It includes the purpose, measured condition, sensor placement, data record, quality check, decision rule, action, validation evidence, and retest trigger. The useful claim is not "the sensor sends data." The useful claim is that accepted readings can support a named application decision within a bounded context.

This distinction matters because the same sensor reading can support different applications. A temperature reading can be a comfort display, a cold-chain alert, a machine-protection signal, or a model feature. Each purpose changes the acceptable range, freshness, uncertainty, action rule, owner, and evidence record.

For example, suppose a learning greenhouse application uses soil-moisture readings to decide whether to show a watering reminder. The application record should not stop at "moisture value received." It should name the plant bed, probe placement, sample time, accepted range, stale-data rule, and the reminder rule. If the probe is moved, the sample interval changes, or the reminder becomes an automatic pump command, the claim has changed and the review must reopen. That small example shows why the application is the whole sensor-to-action path, not the device alone. A reviewer can then ask whether the reminder was justified by accepted evidence, not merely whether a number appeared.

A sensor application should be reviewed as a chain from purpose to measured condition, context, quality check, decision rule, action, evidence record, and retest trigger. A displayed reading is only one link in that chain.

If you only need the intuition, this layer is enough: start with the decision the application must support, then work backward to the measurement, context, quality checks, action, and retest trigger.

The Sensor-to-Action Chain

Purpose

Name the observation, alert, report, control decision, review task, or model input that the application needs.

Measurement

Define the condition, units, location, sensor, placement, timing, and context that make the reading meaningful.

Quality and decision

State which readings are accepted, rejected, stale, missing, noisy, out of range, or contradictory before any rule uses them.

Action and evidence

Record the display, alert, report, automation, owner response, validation evidence, and retest trigger for the claim.

Beginner Examples

• A greenhouse dryness alert starts with the irrigation decision, then defines soil condition, placement, quality checks, alert rule, and retest conditions.
• A room occupancy display may accept coarse motion evidence, while a safety interlock needs stronger evidence and clearer failure behavior.
• A mobile-phone sensing task needs permission state, user prompt, device context, and data quality evidence before readings are aggregated.
• A dashboard is an action surface, not the full application; it still depends on measurement context, freshness, and quality rules.

Overview Knowledge Check

Build the Application Evidence Record

A practical sensor application review should produce an evidence record that another person can inspect. The record should be narrow and operational: what the application claims, what data supports the claim, how bad readings are handled, what the application does with accepted readings, and who retests the claim after changes.

The safest workflow is to define the action before choosing the sensor details. Monitoring, alerting, automation, and review decisions have different evidence needs. A trend chart can tolerate more uncertainty than a local shutdown rule. A public aggregate statement needs stronger context controls than a private lab exercise.

Application Review Sequence

1. State the claim. Write the purpose in one sentence: what decision, action, or review does this application support?
2. Bind the measurement. Name the physical condition, sensor placement, unit, sample interval, context, and expected range.
3. Define quality states. Separate accepted, stale, missing, saturated, impossible, noisy, contradictory, and unreviewed readings.
4. Choose the action rule. State whether the application displays, alerts, reports, automates, queues review, or refuses action.
5. Record retest triggers. Retest when sensor, placement, threshold, data path, environment, owner, action, or firmware changes.

Evidence Item

What to Record

Common Failure

Retest Trigger

Purpose

Decision, user, action, acceptable delay, harm from false alarm, and harm from missed event.

The team collects data without knowing what decision the application will support.

Decision owner, action type, threshold, response workflow, or accepted risk changes.

Context

Placement, environment, installation note, sensor state, timestamp, device identity, and setup constraints.

The reading is treated as universal even though placement or environment defines what it means.

Sensor moved, enclosure changed, site changed, user prompt changed, or operating environment changed.

Quality

Freshness rule, missing-data rule, impossible-value rule, calibration check, comparison check, and acceptance state.

Every reading is accepted even when stale, saturated, disconnected, or outside reviewed conditions.

Sample rate, calibration, reference source, data path, validation rule, or fault handling changes.

Action

Display, alert, report, actuator command, manual review, suppression, escalation, audit, and owner response.

A reading drives action without proving the evidence is strong enough for that action.

Action target, recipient, actuator, alert policy, dashboard, report wording, or owner changes.

Practitioner Knowledge Check

Handoffs and Claim Boundaries

Under the hood, a sensor application is a chain of handoffs. A physical condition becomes a measurement. A measurement becomes a data record. A data record becomes an accepted or rejected signal. An accepted signal becomes a decision. A decision becomes an action. An action becomes an operational record. Each handoff can fail independently.

Strong applications do not hide those handoffs. They preserve provenance, timestamps, context, quality state, rule version, action owner, and retest reason. That separation prevents a narrow measurement success from being overstated as an application success.

Failure Boundaries to Separate

• Measurement boundary: sensor fit, placement, calibration, range, noise, drift, response time, and local environment.
• Data boundary: units, timestamp, source identity, freshness, missing-data state, storage path, and schema meaning.
• Decision boundary: threshold, rule version, quality gates, context requirement, confidence limit, and unsupported states.
• Action boundary: display, alert, report, actuator command, manual review, suppression, escalation, and audit evidence.
• Operations boundary: owner, maintenance, calibration interval, update path, rollback, incident review, and retest trigger.

Handoff

What It Proves

What It Does Not Prove

Retest Trigger

Condition to record

The system can create a timestamped reading with source, unit, and setup context under reviewed conditions.

That the reading is valid for every decision, environment, placement, or action.

Sensor, placement, unit, timestamp source, setup note, sample rate, or environment changes.

Record to quality state

The application can classify readings as accepted, stale, missing, impossible, noisy, or unreviewed.

That accepted readings automatically justify alerts, reports, or actuator commands.

Quality rule, calibration check, freshness limit, missing-data behavior, or comparison source changes.

Quality state to decision

The decision rule uses only readings that meet the reviewed quality and context requirements.

That the action owner will respond correctly or that the rule remains valid after field changes.

Threshold, rule logic, context, confidence limit, accepted-risk statement, or owner changes.

Decision to action

The application can display, alert, report, actuate, suppress, or escalate according to the reviewed rule.

That the measurement remains valid, the action is always safe, or the report is valid outside scope.

Action target, dashboard, alert route, actuator, report wording, audit path, or escalation process changes.

Under-the-Hood Knowledge Check

2.2 Summary

• A sensor application is a purpose-to-action evidence path, not just a sensor stream.
• The review starts with the decision or action, then works backward to measurement, context, data quality, validation, and retest triggers.
• Monitoring, alerting, automation, reporting, and review each require different evidence strength.
• Readings need source, unit, timestamp, context, quality state, rule version, owner, and audit behavior before they drive important actions.
• Retest is required when sensor, placement, data path, quality rule, threshold, owner, action, environment, or firmware changes.

Key Takeaway

Approve a sensor application only when purpose, measurement context, data quality, decision rule, action owner, validation evidence, and retest boundary are explicit.

2.3 See Also

Sensor Applications: Domain Overview

Map physical conditions to measurements, data paths, domain decisions, and validation records.

Sensor Hardware Selection

Select hardware by matching measurement needs, interfaces, environment, calibration, and maintenance evidence.

Sensor Application Architecture

Review sensing nodes, gateways, processing, storage, actions, quality states, and retest triggers.

Mobile Phone as a Sensor

Use phones as bounded sensing platforms with permissions, setup evidence, quality checks, and scoped interpretation.