Measurement, state, event, action: the four quantities

"Give me four honest words, what I measured, what is true, what changed, and what I did about it, and I can run a factory."

A Well-Organized AI Agent

A pulse oximeter never measures the oxygen in your blood, a thermometer never touches your core, and a crash sensor never feels the crash. Yet each fires a decision that can save a life. Any of it works because every sensing problem, however exotic, collapses into just four quantities. This section names those four and binds them with a single equation. You need no more than comfort with functions and basic probability. Chapter 4 builds the probability machinery carefully, so treat any density here as a promissory note redeemed there.

Measurement: what the sensor hands you

What it is. A measurement is the number, or vector of numbers, that a transducer (the physical sensing element that converts a physical quantity such as heat or light into an electrical signal) produces. The continuous-time signal off the front end we write \(x(t)\); once sampled we index it as \(x[n]\) within a window, or \(x_k\) at discrete time step \(k\). When we want to distinguish the raw transduced signal from the cleaned, conditioned quantity that an inference model actually consumes, we reserve \(x\) for the raw signal and \(y\) for the observation. Most of the time the difference does not matter and people say "measurement" for both; we make the split explicit only where filtering or feature extraction sits between them.

Why it needs its own name. The whole reason sensory AI is hard is that the measurement is not the thing you care about. A pulse oximeter does not measure oxygen saturation; it measures how much red and infrared light reached a photodiode after passing through a finger. The quantity of interest is hidden, and the measurement is a distorted, noisy shadow of it. That relationship deserves an equation. In short: a sensor never hands you the truth, only a noisy shadow of it, and all of sensory AI is the craft of reading that shadow backwards.

How they connect. Get this relationship wrong and the damage is not abstract: a pulse oximeter that misjudges how light maps to oxygen can report a comfortable number while a patient quietly desaturates, and every alarm and action downstream inherits that lie. The central object of this book is the measurement model

where \(s\) is the hidden state, \(h(\cdot)\) is the sensor response (the physics and geometry that turn state into a signal), and \(\eta\) (sometimes \(\varepsilon\)) is measurement noise. Read it as a sentence: the world is in some true state \(s\); the sensor applies its response \(h\); noise corrupts the result; you observe \(x\). The map \(h\) is rarely the identity and rarely linear. It can saturate, it can be direction dependent, it can drift with temperature. We assume the noise is additive and Gaussian only where we say so explicitly; in general \(\eta\) is whatever the physics dictates, and pretending otherwise is a classic way to ship a miscalibrated system. Where \(h\) comes from, and how to characterize it per sensor, is the entire subject of Chapter 2.

State: what is actually true

The measurement model puts the hidden \(s\) on its right-hand side, so having named the signal the sensor hands you is only half the job; now we name the thing that signal is a shadow of.

What it is. The state \(s\) (or \(s_t\) as it evolves in time) is the quantity you actually care about, the thing you would measure directly if the universe were kind enough to let you. State comes in three flavors. It can be continuous (core body temperature, the three-axis orientation of a drone, blood glucose), discrete (a valve is open or shut, a machine is in one of five operating modes, a sleeper is awake or in rapid eye movement (REM) sleep), or hybrid, mixing both (a robot's continuous pose together with a discrete "which room am I in" label).

Why the distinction earns its keep. State type largely dictates the downstream toolkit. Continuous state points you at estimators and filters; discrete state, at classifiers and detectors; hybrid state needs both stitched together. Naming the type early is the fastest way to pick the right method, and to avoid forcing a categorical problem into a regression that reports "3.7 rooms."

When state changes over time. Physical state has memory. Temperature now is close to temperature a second ago; a machine that was healthy last minute is probably still healthy. That temporal structure, captured by writing \(s_t\) and modeling how \(s_t\) begets \(s_{t+1}\), is exactly what recursive estimators exploit, and it is the backbone of Chapter 9.

Event: what changed

Tracking a state moment by moment answers "what is true now," but many decisions hinge instead on the instant that truth changes, and that instant is a quantity in its own right.

What it is. An event \(e\) is a discrete, labeled occurrence in time, most often a transition in the state. A footstep, a heartbeat, a valve opening, a bearing beginning to fail, a driver's hand leaving the wheel: each is a point (or a short interval) on the timeline that you want to mark and count. Where state is something you track continuously, an event is something you either declare or you do not.

Why it is not just "state, again." Two reasons. First, downstream consumers often want the event, not the trajectory: a maintenance team wants "bearing wear crossed the alarm line at 14:07," not ten thousand vibration samples. Second, events are where the value and the liability concentrate. A missed event (you failed to declare a real one) and a false event (you declared one that did not happen) have very different costs, and tuning that trade is a design act in itself. Detecting events as changes in a signal's statistics is the province of Chapter 12.

How to think about it. Formally, an event is a function of the state history: \(e\) fires when \(s_t\) crosses a boundary, enters a region, or changes regime (shifts from one qualitative mode of behavior to another). That framing keeps events anchored to the physical world rather than to accidents of the raw signal, which matters because you want to detect the bearing failing, not the one noisy sample that happened to spike.

import ruptures as rpt          # x_k is your 1-D measurement array
algo = rpt.Pelt(model="rbf").fit(x)
events = algo.predict(pen=10)   # indices k where the regime changes -> your e

Action, the perceive-act loop, and one notation to rule them all

Declaring that something changed is inert until the system does something about it, and that final quantity is what turns a stream of events into behavior.

What it is. An action \(a\) is what the system does with its inference: raise an alarm, brake the car, adjust a setpoint, log a row, or do nothing (a legitimate action). Action is what makes sensing purposeful. A perception stack that never influences a decision is a data logger; the loop from measurement to action is what turns it into a system.

Precisely. An action is the output of a decision rule, a policy that maps your belief \(p(s \mid x)\) (or its point estimate \(\hat{s}\)) to a choice from a fixed set of options. It matters because the objective you truly care about, safety, cost, or comfort, is defined at the action and not at the estimate, so a perception module with tiny error can still drive a costly decision. The mechanism is to score each candidate option by its expected cost under the belief and pick the cheapest, which is why you reach for a full decision-theoretic policy whenever the penalties for different mistakes are lopsided (a missed cardiac alarm versus a nuisance beep) and settle for a bare threshold on \(\hat{s}\) only when those penalties are roughly symmetric.

Why it closes the loop. Actions change the world, which changes the state, which changes future measurements. The four quantities therefore form a cycle, not a pipeline. Figure 1 shows the full turn: state produces a measurement through \(h\); inference recovers a belief and an estimate \(\hat{s}\); the estimate declares events; a policy chooses an action; the action perturbs the state; the cycle repeats. Keeping this loop in mind stops you from optimizing perception in isolation when the real objective lives at the action.

One notation, fixed here. The symbols above are the book's contract, summarized in Table 1. Learn them once. Two extras round out the set: a learned representation or embedding is \(z\) (it appears the moment neural encoders enter, in Chapter 13), and a probability density is \(p(\cdot)\), with a hat marking any estimate.

Table 1. The fixed notation for the book. Every later chapter inherits these symbols.

What's Next

In Section 1.4, we use this four-part vocabulary to organize the zoo of real sensors, laying out a taxonomy of modalities (inertial, optical, acoustic, biopotential, radar, and more) and the task families (regression, detection, tracking, forecasting) that map onto state, event, and action. With the four quantities and their notation fixed, you will be able to place any new sensing problem on that map at a glance.