turbine-7 · deliverable

Scenario authoring notes — Turbine 7

Kit 9 · Turbine 7 · how to add or change an alarm case · for the kit owner and SMEs · fictional case

How the bank works

All cases live in one file, scenarios.js. The 2D simulator and the 3D scene both read it, so a case written once appears in both, with the same scoring. The bank holds two cases per pattern (eight in total). Each shift draws one case per pattern at random and shuffles the order, so a retry is a different shift, not a memory test.

Pattern	Cases in the bank	Best call
Cleared with a logged inspection	087 generator bearing temperature · 079 converter cooling flow	Restart
Rising trend, no inspection yet	092 gearbox vibration · 098 main-bearing temperature	Hold for inspection
Fault came back after a reset	094 blade C pitch fault · 105 yaw motor 3 overcurrent	Hold for inspection
External cause, turbine nominal	101 grid-dip ride-through · 110 storm cut-out	Restart

Anatomy of a case

Field	What it holds	Rule
`id`, `code`, `title`	Alarm number and SCADA-style title	The title names the alarm, never the pattern
`component`	Where the alarm points (the part that gets the work lamp in 3D)	The lamp shows where to look, never what the answer is
`pattern`	One of the four	Exactly one pattern decides each case
`env`	Time, sun height, wind, waves, cloud, rain	Must match the story: a storm case has storm weather
`hud`, `trend`	Readouts and the 20-minute trend	The trend alone must not give the answer for cleared and external cases
`situation`	The alarm text the learner reads at the desk	Ambiguous on purpose; the deciding evidence is not in it
evidence (`EVIDENCE`)	What the learner finds on the part (or the string)	Specific: a number, a time, a name. This is what the call rests on
`scores`, `critical`	2 / 1 / 0 per response; critical responses fail the shift	Critical only for restarting into a rising trend or a recurring fault
`feedback`	One line per response	Says why, in terms of the pattern; no "correct!"
`pm`	Production-desk pushback and three replies (hold cases only)	One data + risk + next-step reply (1), one rule-only (0), one concede (0)
`model`	A model handover note	Must score 6 / 6 on the note check; it is shown in the debrief

Writing a new case

Start from a real pattern, not a real incident. Remove anything that identifies a site, a turbine or a person.
Write the evidence first. What would an experienced technician look at, and what would they need to see? Put that on the component, with numbers and times.
Make the tempting answer tempting. The wrong call should look economically rational: the money at stake is on screen in every case.
Check the trend does not give it away. For cleared and external cases, the trend should look alarming enough that the learner has to check the evidence.
Write the feedback for each response, naming the deciding input.
Write the model note in the voice of a technician: call first, evidence with numbers, next step with who or when.

Checks before a case goes live

node check: every best path scores 14 / 14 and every model note scores 6 / 6 (the QA hooks __THREE_GAME_TEST_HOOKS__.selfTest() in 3D and __T7_SELFTEST__() in 2D run both).
An SME has reviewed the case with the expert-review checklist.
The case is readable without colour: no reading is coloured good or bad before the learner commits.
In 3D, the evidence is reachable by a button as well as by clicking the part.

What not to do

Do not add a fifth response or a fifth pattern without re-checking the pass rule (12 / 14).
Do not make a case depend on a site-specific rule; that belongs in the huddle, with the site's escalation boundary.
Do not use real alarm codes from a specific OEM.

Prefer the source? Download the raw markdown.