A fork has a name, a date and tracks. Each track has a name, a color, conditions, and plans its own dates after the date of the fork, played with those of the trunk; it may fork again. Once every step up to the date of the fork is played, r-iosemit reads the knowledge space and goes on with the first track whose condition holds, tried in order; the last track, Otherwise, is taken when none does. A track still to be completed is never taken.

• State of a resource: its current state (Off or On for a barbecue, Open or Closed for a pool, Wet, Bradycardia or Dead for a person).
• Position of a resource: inside or outside a good drawn by a polygon (a swimming pool, a building).

Rows are joined by and or or. Forks saved earlier may also read the status of an actuality or a risk, the end of a task or the value of a sensor; these rows are kept and still read, but no longer offered. The reading is the one any observer of the field could make: nothing in the knowledge space knows the simulator, or that a fork was met.

Which track each fork took is a choice of the playback, kept apart from the scenario. The scenario as played is the trunk with the chosen tracks: it is what is compiled into the DATA pairs, what STORY narrates and what Restart prepares. In TIMELINE, the Tracks view shows the story divided at each fork, every track visible, and the Flat view the way the playback takes. Played step by step (Discrete), the fork is read when its date is reached.

A task done on the field can change what a fork read: a child taken out of the pool, a barbecue put out. When a simulated task sends its effect, the forks already met that read what the task acted on are read again, the first one met first; if another track holds now, the playback leaves its track for that one from the date of the effect, and what the track left still planned is not played. Under the tracks, the row Expected effects from the tasks draws each effect (a move, a curve, a point), linked to the track it made the story take, and the row Detected problems draws the risks and actualities r-io suite detected. Both are kept with the run.

A fork is added from the planning box (Add a fork…, in the track being edited) or edited from its chip: name, date, tracks reordered, rows of conditions, a track added or removed; a fork left with a single track disappears. Forks can also be proposed: on a value curve that crosses CEP thresholds, or with Suggest forks on a run, a fork per actuality or risk that appeared, with a track named after it and an empty track for what could happen instead. Details: Scenario timelines › authoring tools.

The Henri Barbecue Story forks three times, each fork inside a track of the previous one: at 09:02:55 on the state of the barbecue, at 09:03:13 on the state of the pool, at 09:03:54 on whether Henri is inside the pool. Without supervision the barbecue is on, the pool open and Henri stays in the water. In auto mode, Julie gets Henri out: the heart fork switches to Otherwise. With extrapolation, Paul puts the barbecue out before the first fork, which takes Otherwise: Henri never gets burned.

Walkthrough: Henri at the barbecue, rules and forks. The Orléans scenario has no fork.

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).