Scenario timelines & observation
Plan dated events in r-iosemit, emit them through the real interpretation pipeline, and compare the plan with the facts observed in r-iose.
Plan a shared local timeline
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.
09:00 preparation → principal [smoke activated + message] 09:07 preparation → principal [smoke deactivated] 09:25 preparation → principal [risk becomes certain]
Keep DATA and the plan consistent
The ACTUALITIES 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.
| Planned content | Contract |
|---|---|
| Actuality | A unique id, sensor id and CEP rule id; activation or deactivation at the chosen date. |
| Message | Text or a picture is required. At most one message per sensor and date; authors and location are optional. |
| Reflex photo | One image per camera and activated actuality. The mock camera selects it by occurrence date without consuming it; it does not fall back to an unrelated image. |
| Potentiality | An eligible emerging/intrinsic Risk or Opportunity, not an unvalidated ML prediction. Activation sets probability to 100%; deactivation restores the stored previous probability. |
| Referenced actuality | Pushed directly on the principal step of its date, without sensor nor CEP rule. FREEZE mode activates an existing FREEZE actuality (at most once per actuality). REFERENCE mode clones a reference actuality into a new ACTIVE one, Near its reference and optionally Impacting a resource, with an optional name, description and picture used as instance icon; these four fields are refused in FREEZE mode. |
| Sensor value | A precise value emitted by a sensor on the principal step of its date and held until its next planned value: exactly one of a number (QUANTITATIVE sensor, finite), a boolean (DEDICATED sensor) or a latitude/longitude pair (GPS, both required and within range), optionally with the name of the model element it was placed on. At most one value per sensor and date. |
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.
Advance, acknowledge, restart
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.
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 advance the shared cursor
On reload, common progress is reconstructed from the least-advanced controller. A partially emitted pair is retried without replaying already acknowledged steps. Restart resets the datasets and the probabilities changed by the timeline; it is not a rollback of the entire knowledge graph or of already executed processes.
Narrate the scenario without changing its facts
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.
Separate planned events from observed facts
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.
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.
Existing use cases and historical captures
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.
Implementation and contracts
game_master.xsd,GameMasterSOAPImplandScenarioTimelineValidator: storage and timeline validation.ScenarioTimelineJson: local date strings and base64 attachment round trips.scenario-timeline.ts,scenario-editor.service.tsandtimeline-playback.ts: paired datasets, consistency and phase barriers.scenario-story.tsandStoryNarrativePayload: narrative contract, validation and translation.ProjectResourceandGameScenarioArchive: scenario folders, datasets and media in project archives.ObservationHistoryService,AbstractSensorandTimelinePhotoSelector: 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.