In r-iosemit, define a start and an end, then add dated actualities, messages, potentiality changes, referenced actualities or sensor values. Dates are local wall-clock values such as 2026-09-24T09:00:00: do not append Z or a timezone offset. The server rejects duplicate dates, instants outside the bounds and an end that does not follow the start.

Several events may share one instant. Every instant expands into exactly two dataset events per participating sensor: preparation, then principal. The preparation establishes the state before a CEP transition; the principal event performs the planned change. This is not a fixed-interval clock.

Zoom. The − / + buttons, or Ctrl + wheel over the timeline, zoom in around the pointer (up to 8 pixels per second); the timeline then scrolls sideways, and while it plays the view follows the playhead. Fit to window shows the whole timeline again. The zoom of each scenario is kept while the page stays open.

09:00  preparation → principal  [smoke activated + message]
09:07  preparation → principal  [smoke deactivated]
09:25  preparation → principal  [risk becomes certain]

The TIMELINE and DATA views share the timeline. Adding or removing a global pair changes every dataset; editing one sensor must retain that common number of points. The editor checks quantitative thresholds and dedicated boolean transitions so a preparation value cannot accidentally trigger or remove another planned alert.

Mute instead of deleting. Each planned item (actuality, message, potentiality, referenced actuality, sensor value) can be muted from the speaker icon of its future card, or with the Mute button of the actuality, potentiality, referenced-actuality and sensor-value dialogs. A muted item stays on the timeline with its settings, greyed out and struck through, and the header counts it (· N muted); it is neither compiled into DATA nor played, its reflex photo is not taken and the story leaves it out. Every date keeps its DATA pair, even when all its items are muted (hollow dot). Actualities of the same CEP rule at a date are muted together; muting an activation also mutes the deactivation that follows it, and unmuting a deactivation unmutes the activation it undoes. A muted FREEZE activation does not count against the once-per-actuality limit. Editing a sensor value in DATA unmutes it.

Use r-iored to inspect the CEP rules and r-ioda to check the sensor, impacted assets and generated objectives. A scenario cannot compensate for a missing model relation.

The player starts the participating controllers, waits for every preparation emission, then waits for every principal emission. A failure prevents progression to the next phase or instant. Acknowledgement confirms emission, not completion of downstream CEP processing, ML inference or workflow execution.

save the graph checkpoint for this instant
start all participating controllers; wait for all
emit preparation[2 × instant]; wait for all
emit principal[2 × instant + 1]; wait for all
apply planned potentiality changes and referenced actualities
advance the shared cursor

On reload, a known server playback position takes precedence over dataset progress; otherwise progress is reconstructed from the least-advanced controller. A partially emitted pair is retried without replaying already acknowledged steps.

Edit during playback. While a scenario is being played, items after the playhead can still be added, removed or muted: the playback position and the sensor dataset positions are kept, and the next step plays the edited plan. A change that touches a date already played (including a DATA edit of a played step or a story that rebuilds the timeline) is refused before anything is saved; go back before that date with Previous step, the playhead or Restart first.

Previous step, playhead and Restart

Before each instant, PlaybackCheckpoints saves the nodes and edges of the knowledge space, across statuses, in server memory. Previous step or dragging the playhead backwards restores that checkpoint; dragging forwards plays successive steps. Restart requests checkpoint 0 and resets the timeline actors, planned probabilities and referenced actualities.

checkpoint before instant → emit preparation → emit principal → apply direct changes
rewind: pause 2L waves → compare checkpoint with current graph
        → remove later nodes/edges → restore changed/missing nodes/edges
        → notify views and reverse trajectories → resume 2L

Use a dedicated demonstration knowledge space. Rewinding can also undo graph edits made by other users after the checkpoint. Checkpoints are lost when the server stops: a previous step then cannot be restored, and Restart falls back to the changes handled by the timeline itself. This is a graph restoration, not a durable backup or compensation of external actions, workflow execution, sensor histories or time-series databases. The service reports remainingDifferences; restoration is not a guarantee of an atomic or byte-identical rollback.

See the reviewed Henri barbecue walkthrough for the reverse path, and Parc des Princes incidents for referenced actualities and human tasks.

The STORY view can request an English or French narrative from the project's configured AI provider. Author guidance is limited to 1,000 characters. It can influence tone and emphasis, but event identifiers and chronology remain constrained. Existing message text is preserved; the narrator can fill messages whose text was left empty. The description of an actuality is passed to the narrator as author context, and planned sensor values are narrated as measures (value read, state switched, carrier moving to a place). A story already written in the other language can be sent with translationOf: the narrator then translates it segment by segment, keeping groups, dates and event identifiers, and also translates the guidance.

The browser validates coverage, group order, dates and event identifiers before applying the result. The saved story has a fingerprint derived from meaningful timeline content, including photo content: changing the plan can make the narrative stale. Inspect the generated text before using it in a demonstration; structural validation is not a guarantee that every sentence is factually correct. Generation and photo description may call a paid external provider.

The narrative adapter removes technical sensor and CEP metadata and uses temporary event identifiers. This is data minimisation, not anonymisation: scenario text, names and supplied images can still contain sensitive information. See AI assistants.

r-iose provides a read-only observation timeline fed by received sensor events and governance notifications. It restores evidence from SensorManager and KnowledgeHistory, rather than treating the simulator's plan as proof that an event occurred. Occurred at preserves the scenario date through CEP creation and removal notifications.

SensorManager retains up to 300 received payloads per sensor during its current lifetime. The observer correlates event ids with CEP evidence, generated actualities and reflex photos. Unvalidated ML predictions do not count as confirmed observations. Clearing the timeline clears the view, not server records; restarting the manager does not restore an earlier run from browser storage.

An ML provider failure is not a successful prediction with no danger found. The mlPredictErrorTopic event carries rule, sensor, source event and error information to r-iosemit and r-iota; other rules may continue. Check the provider configuration before replaying, and do not publish diagnostic messages containing sensitive data.

Continue in r-iota to qualify alerts, validate predictions, deduce a response and supervise it. Sensor emission, interpretation, expert validation and resolution are separate stages.

The schema now stores timeAxis, instant and optional storyJson, replacing numberOfTimeSteps and timeBetweenSteps. Four committed packages now ship a game scenario in the folder layout described below: IMT Albi Crisis and IMT Albi Healthcare (Default Game Scenario), Crisis Event Show — Parc des Princes (Full scenario) and Barbecue (Henri barbecue story). Legacy packaged game scenarios were removed from Albi, Cathedral Albi, Nantes Macro, Golfech, RealWorld, Skateboard Logistics and Toulouse PrisonBreak; their project models remain separate assets.

A project export stores each scenario in its own folder, game_scenarios/<Name_of_scenario>/, holding the scenario XML, a datasets/ folder and a media/ folder for the pictures of referenced actualities and planned messages, all referenced relatively (./datasets/…, ./media/…). On import the media are uploaded into the knowledge space; scenarios that reference a dataset only by name are still read.

Older screenshots and guided demonstrations are retained as historical examples. Their scenario names, step numbers and screens may differ from the current editor; prepare a dated timeline instead of expecting Default_with10steps to be present. The Fire at Albi Cathedral walkthrough remains a model-building and human-task example, not a new standalone Maven use-case module.

• game_master.xsd, GameMasterSOAPImpl and ScenarioTimelineValidator: storage and timeline validation.
• ScenarioTimelineJson: local date strings and base64 attachment round trips.
• scenario-timeline.ts, scenario-editor.service.ts and timeline-playback.ts: paired datasets, consistency, phase barriers, muted items (activeScenario, setItemMuted) and the played-dates guard (playedStepsChanged).
• scenario-story.ts and StoryNarrativePayload: narrative contract, validation and translation.
• ProjectResource and GameScenarioArchive: scenario folders, datasets and media in project archives.
• ObservationHistoryService, AbstractSensor and TimelinePhotoSelector: observation evidence and dated photos.

The authenticated r-iosemit /gameMaster POST endpoints create, update, save, select, list and delete scenarios. JSON uses local ISO date strings; attachments are base64 values, not Java stream objects. See API reference and simulation architecture.