Every date of the timeline becomes a pair of steps on every participating sensor: a preparation, which sets the state before the change, then the main step, which makes the planned change (a threshold crossed, a value, a position). The player waits for every sensor to emit the preparation, then the main step, before going on. Add a DATA pair inserts a pair on every sensor without crossing any threshold; Remove a DATA pair removes both steps from every sensor and their planned actualities. Details: Scenario timelines › Keep DATA and the plan consistent.

DATA is not written by hand alone: each change of the timeline is compiled into the pairs of the sensors. What is compiled is the scenario as played, the trunk with the track chosen at each fork (see Forks and tracks). When the playback takes another track at a fork, the pairs after the playhead follow it; Restart aligns them again on the tracks the next run starts with. Muted items are neither compiled nor played.

Sensor controllers by group: start or stop a sensor, or all of them, lock it, and select a dataset to see its curve, its played values shaded, and the thresholds of the CEP rules it feeds. A dataset can be played, paused, stopped or played step by step on its own, and its values edited by dragging the curve. The status of a dataset says whether it is connected.

The mock endpoints stand for the external services a process calls, such as IoT cameras: start or stop them, edit them, add the pictures a camera returns, and run an actuator. The reflex photos planned with an actuality on the timeline are returned by these cameras at their date.

A slider per emerging or intrinsic risk or opportunity sets its probability: at 100 % it generates its actualities, below they are frozen. This tab writes the probability directly; planned on the timeline, the same change becomes a risk level item, which Restart puts back.

In the Default Game Scenario of IMT Albi Crisis, the gas sensor of the Rapsodee building plays its dataset pair by pair: its values climb above the maximum of the explosive-gas CEP rule, and the gas leak actuality is raised. The Orléans scenario counts 20 dates, hence 40 DATA steps on its level sensor.

Walkthrough: IMT Albi Crisis — corrective procedures.

r-iosemit plays the field, not r-io suite. No r-io suite application calls it or knows that it exists: for r-io suite, every event it plays is a real one. It reads the knowledge base of r-io suite (states, positions, alerts, risks, tasks) to choose its tracks and to record its runs, without ever writing what it reads. It acts only through the channels of the field: the sensors (their datasets, planned values, GPS moves and forecasts published as a provider would), the messaging sensors, the human-task service for the simulated tasks, and the clock API of the use case once the operator opened it in r-ioga (Edit project › Use case clock › Allow remote clock control).

A few authoring items act on the knowledge space directly, and the dialogs say so: a planned risk level (like the Potentialities Management slider), a referenced actuality (a FREEZE actuality made ACTIVE, or a clone of a REFERENCE one), Previous step and Restart (they restore a checkpoint of the knowledge space kept by the server) and Replay (it writes the supervision settings of a run back, after a warning).