SM Simulator
Screen Book

As at 31 August 2026. The percentages below are a judgement of how much of the finished capability works, not how much code exists. The capability-by-capability tracker behind them is Design/01_progress.md, which the running app reads in its own documentation reader.

Against forty-two tracked capabilities: trainee ~64%, trainer ~42%, platform administrator ~70%, organization administrator ~88% — about 61% overall.

Seven decisions sit under every screen that follows. Settling them first is what keeps twelve screens from becoming twelve unrelated products. Six of them were written before anything was built; the seventh was learned while building the two administration consoles.

You asked for a recommendation rather than a menu, so here is the reasoning and then the answer. The 91 exercises in the library already carry three different orderings inside them, and each one is a plausible course structure.

The resulting catalogue

Mapping the existing library onto that spine gives five certification courses. Nothing is invented and nothing is orphaned.

The skill framework

Six domains, derived by reading the ten “Steps for the Station Master” that every failure exercise ends with. Each maps to observable system events, which is what makes automatic scoring possible.

Two cross-cutting measures ride alongside the six and are reported separately because they are not knowledge but execution: sequence discipline (did the right steps happen in the right order — authority issued after the points were clamped, never before) and timeliness (time to first correct action, and total detention caused).

Built/loginRebuilt as a server-rendered route. The account is checked on the server against a directory it never ships to the browser, and the answer is a signed, HTTP-only session cookie carrying SM ID, role, organization, cubicle and language. Role decides where sign-on lands, every guarded route reads that cookie rather than trusting the page, and there is a sign-out. The service strip is here, one of its lamps a real probe. Passwords are still stored in the clear and the signer falls back to a secret that is in the source if none is configured — neither is safe outside the lab.

This is a fixed lab with ten numbered cubicles and one instructor desk, not a public web app. The login screen should behave like equipment being signed on to: no self-registration, no marketing, and a visible statement of what the machine is connected to before anyone starts an exercise.

• Left panel · 55%Institute identity and a full-bleed schematic of a station layout, dimmed almost to the ground colour. Beneath it, the standing notice: Training simulation — not a real interlocking. Nothing here authorises any train movement. That line belongs on the first screen, not buried in a footer.
• Right panel · 45%The credential plate. Fields: SM ID (the unique trainee identifier used across every session record), password, and a language selector. Role is derived from the account, never chosen.
• Cubicle selectorTen numbered plates below the password field, laid out in the physical arrangement of the lab. The trainee taps the desk they are sitting at. This is what lets the trainer’s console address a person by seat, and what lets a session survive a machine swap.
• Status stripFour small lamps along the bottom edge: simulation service, logging server, audio link to instructor, panel library. Amber or red here should stop an exam from starting, and the strip explains why in one line rather than failing later.
• Resume bannerAppears above the fields only when the account has an unfinished session: Exercise 14 in progress on Panel 3, interrupted 09:42 — resume or abandon. Consecutive sessions with no downtime is a stated requirement; the recovery path belongs on the way in, not hidden in a menu.

Built/traineeConverted to typed TSX rendered on the server. It takes the reader from the signed session rather than from the query string, and serves organization accounts and the original trainee records alike. Every word is still written from the trainee’s yaml: the live strip, the assignments and the completed attempts are prepared data, not anything the lab produced. The call-instructor button came off the top bar — there is no audio subsystem for it to open.

The organising question is “what should I do right now?”, and the answer is almost never “browse the catalogue”. So the page is ordered by obligation, then recommendation, then choice — and the top of it changes depending on whether an instructor is currently driving the lab.

• Top barName, SM ID, cubicle number, language, and a call instructor button that opens the audio channel. Persistent across every trainee screen.
• Left railHome · My courses · Tests · My performance · Panels · Forms & registers · Help. Seven items, no nesting.
• Live stripFull width, only present when the instructor has assigned something to this cubicle: Instructor has set Ex 14 — Down Starter failure, point failure — on Panel 1. Mode: Assessed. Join. Cyan, unmissable, and it supersedes everything below it.
• Due & mandatoryMandatory courses with a deadline. Each row: course name, board, progress ring, next exercise, days remaining. Overdue rows carry the red band. This section is empty for a fully compliant trainee — and being empty is the point.
• My coursesEnrolled courses as cards, each carrying the station schematic of the board it runs on — the same drawings the panel listing already uses, so a trainee recognises a course by its layout before reading its name. Card shows module progress, exercises passed of total, best-scoring module, and Continue pointing at the exact next exercise.
• Assigned practiceSkill Packs raised by the analytics engine, each labelled with the skill that triggered it: Authorities & forms — 4 exercises — assigned after Ex 12, 14 and 57. Naming the cause is what makes remedial work feel diagnostic rather than punitive.
• Tests & examsThree groups: scheduled (with window and board), available now, and completed with result. An exam that has not opened shows its window rather than a disabled button with no explanation.
• Performance snapshotFour figures — competency index, exercises passed, mandatory completion, sessions this month — over six thin skill bars. Links through to the dashboard. Deliberately shallow: this is a pointer, not a report.
• Free practiceA single row at the bottom: open any panel unassessed, with faults available to the trainee themselves. Separated from everything above because nothing here is recorded against competency.

Builtcourse-details.html?id=C1One page serves this screen and the course half of 07 — the trainer reads the same layout. Sequential module unlocks, exercise freedom inside a module, the mode ratchet and the exam gate are all in. Still a browser page reading yaml, and progress is read but never written back, so nothing a trainee does moves the ring.

A course is a board plus an ordered set of modules. The page has to make both legible at once — where am I in the sequence, and what layout am I working on — and it has to show the skills the course develops, because that is the link back to the dashboard.

• HeaderCourse name, section type, mode policy for this course, overall progress as a ring, estimated remaining time, and any prerequisite that is not yet met (stated as a link, not a block).
• Board plateThe station schematic at full width with its facts beneath: signals, points, track circuits, roads, platforms, interlocking standard, block instrument type, line configuration. Two buttons: open the panel to explore (unassessed, no fault) and read the control table. A trainee should be able to learn the layout before being tested on it.
• Module listThe spine. Each module is a collapsible block: title, exercise count, progress, status lamp. Expanded, it lists its exercises as rows.
• Exercise rowNumber and title · the fault in one phrase · the authority it teaches (T/369(3b), T/509) · skill tags · status · best score · attempts · the modes it may be run in. The authority column matters more than it looks — it is how a trainee revising for an exam finds the exercise they half-remember.
• Skills coveredA side card: the six domains with this course’s current level on each, and a note of which modules feed which skill. This is the same data as the dashboard, scoped to one course.
• Course examA distinct block at the foot, visually separated. Shows the unlock condition, the board, duration, attempts allowed and pass mark. Locked until the condition is met, with the remaining requirement spelled out.

Built/dashboardConverted to typed TSX on the server: identity, index, skill profile, trends, history, evidence, remarks and the printed report. The trainer opens the same page and gains the switcher, the cohort overlay and the remarks; a trainee who asks for someone else’s dashboard is quietly given their own. It still reads prepared performance yaml, because no finished session is recorded anywhere. The pre-conversion dashboard.html is still sitting in public/ and will answer its old address until it is deleted.

One screen, two readers. The trainee opens it for themselves; the trainer opens the identical screen for any trainee, gaining only a cohort comparison overlay, a remarks field and an export. Building it twice would guarantee the two views disagree.

The brief was that a trainer should understand it at a glance, so the page is arranged as a descent: one number, then six, then the detail behind them. A trainer reviewing ten trainees before a class reads only the first two levels.

• Identity stripName, SM ID, cohort, programme, enrolment date, mandatory completion. On the trainer’s view: a trainee switcher so ten dashboards can be walked without returning to a list.
• Competency indexA single 0–100 figure with its band, its change since the last assessment, and its position against the cohort. Stated as a sentence beneath, not left as a bare number: 68 — developing. Up 9 since the March assessment. Cohort median 70.
• Skill profileThe centrepiece. Six axes, three traces: current, previous assessment, cohort median. A radar is the right form here only because the six domains are a fixed, non-ordered set read as a shape — a trainee weak on paperwork but strong on the board makes a visibly lopsided figure. It is paired with, never used instead of, the bars below, which carry the readable values.
• Skill barsSix horizontal bars, each with a target line at the pass band and the sub-skills nested beneath on expand. Colour comes only from the band — green at or above 80, amber 60–79, red below 60 — so the row that needs attention is found without reading a single number.
• Progress over timeCompetency index by session, as a line with the assessment points emphasised. Session-over-session comparison is a stated requirement; this is where it lives. Mode is encoded on the line — assessed sessions solid, guided sessions hollow — because comparing a guided score to an examined one would be misleading.
• Topic heatmapModules down the side, attempts across, cells shaded by score band. The fastest way to see that a trainee has failed three separate Home signal exercises while passing everything else. Clicking a cell opens that session’s replay.
• Recurring errorsA ranked list, not a chart: Private number not recorded — 6 times · Failure not entered in the register in time — 4 times · Issued T/509 where T/369(3b) applied — 3 times. This is the single most actionable block on the page and the one a trainer will screenshot. Each row carries its skill tag and links to every session it occurred in.
• TimelinessTwo figures with distributions: time to first correct action against benchmark, and total detention minutes caused. Kept apart from the skill bars because slowness and error are different problems needing different remedies.
• Session historyTable: date, exercise, board, mode, duration, score, errors, faults injected, instructor. Every row opens the replay. This is the audit trail the four-year retention exists to serve.
• RecommendationsThe Skill Packs the system has assigned and why, plus the exercises it suggests next. On the trainer view these become assignable in place, with a note field.
• ReportA print action producing the formal per-trainee report: mistakes with timestamps, weak attributes, comparison against previous sessions, examiner remarks, signature block.

Part builttrainer.htmlSign on as the instructor first — the console reads the session for who is at the desk. Ten tiles, multi-selection, the session commands, the alert column, the fault tray, today’s schedule and the health strip are all present, and all of them drive a state machine local to the page: no tile is bound to a real cubicle, no command reaches a trainee seat, and nothing injected leaves the browser. Cubicles and cohorts now exist as real records on screen 12, so binding the tiles to them is the next move here.

You asked what should appear here. The answer follows from what the trainer is doing while the page is open: standing at one desk, supervising ten, needing to see a mistake the moment it happens and act on it without walking anywhere. So this is an operations screen, not a portal — the live lab takes the top half, and every authoring shortcut is pushed below the fold.

• Lab boardThe hero. Ten cubicle tiles laid out in the physical arrangement of the room, so a trainer looking at the screen and looking at the lab see the same shape. Each tile: cubicle number, trainee name, exercise, mode chip, elapsed time, a thumbnail of their live panel, and a status lamp. Tiles are multi-selectable; the control bar acts on the selection.
• Session controlStart · pause · resume · stop · replay, applied to the selection — one cubicle, a pair, or the whole room. Beside it, the topology control: set the selected cubicles to standalone, paired, or three-way junction, which is what turns two trainees into two ends of one block section.
• AlertsA live column beside the lab board, newest first. Critical errors (a SPAD, an authority issued before the road was secured), trainees stalled beyond a threshold, and help requests. Each alert carries three actions in place: talk (audio), prompt (push a hint to their screen), take over (drive their panel). The trainer should never have to leave this page to intervene.
• Fault trayA short shelf of recent and favourite faults. Drag one onto a cubicle tile to inject it. The full desk is screen 08; this is the two-second path for the fault the trainer uses forty times a day.
• Observer controlWhich cubicle is mirrored to the hall display, with a queue. One click to switch, because the review discussion moves faster than the menu does.
• TodayScheduled classes and examinations with room, cohort and course. Starting a class from here pre-loads all ten cubicles with the right exercise — the single biggest time saving available on this screen.
• Awaiting assessmentSessions needing manual marking or examiner sign-off, oldest first, with an age indicator. Examinations cannot publish until this queue is cleared, so it must be visible daily.
• Cohort snapshotTwo small charts: the weakest skills across the cohort, and the exercises with the lowest pass rate. This is what tells the trainer what to teach next week, and it is the only part of the console that is not about the current hour.
• WorkbenchShortcuts into the authoring tools: new exercise, new course, new test, my drafts, awaiting approval. Bottom of the page — authoring is done in prep time, not while ten people are running.
• System healthCompact strip: simulation service, logging server and its retention headroom, audio, panel library version. Amber and red states name the consequence, not the component.

Builtexercises.htmlThe library, searched and filtered. The way into everything below it.

Builtexercise-editor.htmlCreate an exercise, or edit one by ?id=. The fault list is read from the board being configured.

Builtcourse-builder.htmlModules, and exercises drawn into them, with the skill coverage under it.

Builttest-generator.htmlA fixed paper, or a blueprint drawn per candidate, with what the paper tests.

Part builtAll four run offline from configuration, as the brief required, and the library is up to 35 authored exercises of the 91. What none of them can do is save: there is no store behind the editors, so an exercise, a course or a paper closes with the window. Persist, validate, version, publish and assign is one piece of work that finishes all four at once.

Three authoring tools and the listing that leads to them. They were one page with a switch across the top; they are four addresses now, because a tool a reader cannot link to or bookmark is a tool they have to be walked to. The exercise generator is the substantial one and the other two consume its output, so it is described in full and the others by difference. All of them must work with the simulation service unavailable — scenario authoring is specified as an offline activity, so nothing in these flows may depend on a live runtime except the optional dry run.

Exercise listing

The library is ninety-odd exercises, and until there was a listing an exercise once published could not be found again — the generator opened on a blank form every time. The listing filters along the axes the library is actually written along: course, module, board, skill, difficulty and lifecycle state, all built from the configuration rather than hard-coded. Search is over the number and the title, which is how an instructor names an exercise out loud. Every filter lives in the query string, so a filtered listing is a link that can be sent. Each row offers two different errands — View, which shows what the library records and changes nothing, and Edit, which opens the same eight steps that wrote it. A row that is not published is dimmed rather than hidden: a draft in the library is a fact about the library.

Exercise generator

An eight-step wizard down the left, a live board preview occupying the right two-thirds throughout. The preview is not decoration: from step 2 onward it is the actual panel being configured, and in steps 4 and 5 it is the input device — the trainer clicks the signal or the track circuit rather than finding it in a dropdown. Steps are navigable in any order once step 2 is settled; the wizard tracks completeness rather than forcing a march.

1. Identity & intent

   Title, exercise number, section type, category (normal or abnormal working), the training objective in one sentence, difficulty, estimated duration, and the language variants to be authored. Skill tags are not entered here — they are derived in step 6 from the steps themselves, which keeps them honest.

2. Board & yard configuration

   Choose the signalling panel, then its variable configuration: interlocking standard (knob, RRI, SSI, VDU), line type (single, double, twin single, multiple), working system (absolute or automatic block), block instrument type (SGE, UFSBI, Daido, push-button, block interface VDU), traction, LC gates and their positions, BPAC presence. The preview redraws on every change, so an incompatible pairing is seen rather than reported.

3. Trains & traffic

   For each train: number, class (passenger, goods, relief engine, ARME, motor trolley, lorry), direction, entry point, and time offset from exercise start. Single-train and multi-train exercises are the same form with more rows. Where the topology is paired or three-way, this step also assigns which station the trainee holds and who works the others — another trainee, or the system.

4. Initial state

   The board as the trainee finds it: signal aspects, point positions, block section state, gate positions, any train already standing, and pre-filled register entries. The fast path is capture from the live board — the trainer sets the state up by hand on the preview and freezes it, which is far quicker than describing it in fields.

5. Fault plan

   The heart of the tool. Faults are added by clicking the element on the preview, which filters the ~90-type library down to what is valid at that location. Each fault carries: type, location, trigger (at start, at a time, when a train enters a section, when the trainee attempts a route, or on instructor command during the run), clearing condition (instructor clears, after a duration, or when the correct action is taken), whether it is annunciated or silent, and an operator note.

   Validation runs continuously and is the reason to build this step around the board: it flags a fault at a location no route in the exercise touches, warns when a fault combination makes the exercise unwinnable, and refuses a clearing condition that can never be met.

6. Expected procedure — the model answer

   An ordered step list, written the way the exercise material already writes it: read the panel before touching it · satisfy yourself it is a failure not an occupancy · advise and obtain your private number · record it · keep the train at the Home · secure the road by individual operation · issue the written authority and so on.

   Each step carries five properties: the detection rule that proves it happened (a route request, a point box operation, a form submission, a register entry, a call action); whether it is mandatory, optional or prohibited; its skill tag; its ordering constraint relative to other steps; and a time limit. Two text fields sit beside each step: the prompt shown in Guided mode, and the correction shown in Corrected mode.

   This is the step that makes the whole design work. Filling it once produces the Learning-mode walkthrough, the Prompting-mode interventions, the Testing-mode scoring, and the per-skill analytics — with no second pass and no possibility of the four drifting apart.

7. Evaluation & scoring

   Weights per step and per skill, penalties (wrong authority, unsafe act, sequence violation), instant-fail conditions, pass mark, time allowance and overrun penalty, and the digital forms that must be completed — T/369(3b), T/509, the T/912 series — with which fields are marked. Scoring configurations are saved as reusable templates, since an institute will want one consistent scheme across a course rather than a fresh judgement per exercise.

8. Review, dry run & publish

   A validation checklist covering all seven previous steps, a run as trainee dry run that plays the exercise through in each of the three modes, version and changelog, visibility (draft, in review, published, deprecated), and assignment to courses and modules. Publishing a new version of an exercise already used in a course warns which courses and how many in-progress sessions are affected.

Part builtcourse-details.html?id=C1exercise-details.html?id=EX-001The course page and the exercise page are built, both role-conditional on one layout, and the exercise page is config-driven across the 35 exercises authored so far. The exam page is still not. References and version history have no store behind them, and the exercise page says so rather than inventing clause numbers. The disclosure rule below is drawn on the page but nothing writes a pass record, so nothing yet flips it.

Three reference pages. Each has one canonical layout with role-conditional content rather than separate trainee and trainer versions — when a trainer and a trainee discuss an exercise they should be looking at the same page.

Course details — trainer view

The same spine as the trainee’s course page, with three additions and one substitution. The board plate and module list are unchanged. Added: an enrolment list with per-trainee progress; a progress matrix of trainees down the side against modules across, cells shaded by band, which shows in one glance whether a module is failing individuals or the whole cohort; and exercise-level statistics — attempts, pass rate, mean duration, most common error — on each row, since a module the whole cohort fails is usually a problem with the exercise rather than the trainees. Substituted: the trainee’s Continue button becomes edit, version, assign and publish.

Exercise details

The definitive record of one exercise, and the page a trainer sends someone a link to. Ordered as: overview (objective, section type, difficulty, duration, skill tags, category) → the board (schematic and full configuration as authored) → fault plan (each fault with trigger and clearing condition, in plain language) → expected procedure (the model answer, numbered) → authorities & forms (which forms, and the substitution most often got wrong — T/369(1) where the failed signal is the last stop signal, T/369(3b) where it is not) → evaluation rubric (weights, penalties, instant-fail conditions) → references (the SWR, GR and SR clauses that govern the drill) → version history → usage statistics.

Launch controls sit in a sticky bar: run in Guided, Corrected or Assessed mode, assign to a trainee or cohort, or push to a cubicle now.

Exam page

Three sequential states, each a full screen. The transitions are one-way.

• BriefBefore the clock starts: exam name, board, duration, number of scenarios, pass mark, attempts, and an explicit statement that no guidance will be given and mistakes are reported only at the end. The forms and registers available are listed by name. Identity confirmation and a start button that visibly locks the cubicle into exam mode.
• RuntimeThe panel occupies Display 1 almost entirely, the 3D view Display 2. Exam chrome is a slim bar and four drawers, all collapsed by default: scenario brief, forms (the digital authorities), registers, and communications (call Control, the adjacent Station Master, S&T — and record the private number). The bar carries the timer, scenario n of m, a flag-for-review marker, and submit. Nothing anywhere indicates correctness. Autosave is continuous and a crash resumes at the same board state with the clock adjusted — a candidate must never lose an exam to a machine.
• ResultScore with pass or fail stamped clearly, the six-skill breakdown, the error list with timestamps, a replay timeline with the errors marked on it, examiner remarks, and print. If sign-off is pending the page says so plainly and shows what has been released so far, rather than showing nothing.

Not builtUnchanged, and for the same reason: faultState is written by injectFault and read only by renderFaults, so nothing injected reaches the interlocking. A working subset of authored fault types does now change interlocking behaviour, which is the half of the problem that had to be solved first; the rest of the catalogue is still annotation. The fault tray on the console (05) is the stub this desk grows out of.

The authored fault plan covers what an exercise is designed to do. This is the other half — the instructor reaching into a running session and changing the conditions, without pausing it. It is entered from a cubicle tile on the console and opens as a drawer over the mirrored view of that trainee’s board, so the instructor is always looking at the panel they are about to break.

• TargetWhich cubicles the injection applies to, at the top and always visible. One trainee, a selected group, a paired station, or the whole room. Multi-target injection is what makes a class-wide demonstration possible.
• Pick on the boardThe primary interaction: click the signal, track circuit, point or gate on the mirrored panel, and the fault list filters to what is valid at that element. This replaces hunting through a type dropdown and a location dropdown that do not know about each other, and it removes the most common authoring error — a fault at a location the exercise never reaches.
• Fault libraryThe ~90 types grouped as track circuit · signal · point · block instrument · interlocking and route · LC gate · communication and interface · train working. Search, recents and favourites at the top, because a trainer uses perhaps twelve of the ninety in a normal week.
• OptionsAnnunciated or silent · severity · auto-clear condition · operator note. The note matters: it is what appears in the trainee’s session report as the reason a fault was introduced.
• Arm and fireA fault can be injected immediately or staged. Staged faults sit in a queue with their trigger — at a time, when the trainee sets a particular route, when a train reaches a section — and fire without further attention. This is how one instructor runs ten cubicles: arm the room, then supervise instead of clicking.
• Active faultsEverything currently standing, per cubicle, with elapsed time and who injected it. Clear individually or clear all. Elapsed time is prominent because a fault left standing past its teaching point turns an exercise into a stall.
• MacrosNamed bundles applied in one action — Home signal failure due to point failure injects the point failure at 102 and the stuck occupancy at 102AT together. The recurring fault families from the requirements ship as built-in macros; trainers can save their own.

Builtsignaling-panels.htmlThe listing exists and now indexes six boards; the filters, badges and qualification marks described below still do not. With six cards a filter bar is still noise, which is why this has not moved — but the boards are being added faster than the listing is being taught to sort them.

The existing page is sound and its schematic thumbnails are the best asset in the product — a station is recognised by its shape long before its name. Keep the card layout, the facts row and the drawings. Four changes turn a demo index into a library.

• Filters and search new — section type, line configuration, interlocking standard, block instrument type, LC gates present, number of roads. With three boards a filter bar is noise; with thirty yard variants it is the only way in, and the requirement is explicitly that new yards keep arriving.
• Usage badges new — each card states how many exercises and which courses run on it. This is what a trainer wants to know before authoring, and what an administrator must know before changing a board.
• Lifecycle chip new — published, draft or deprecated, with last-modified date and version. A deprecated board stays visible and openable, because sessions four years old must remain replayable against the layout they were run on.
• Role-conditional actions new — trainee sees open for practice; trainer additionally sees create an exercise on this board and assign; administrator additionally sees edit, clone and version history. One card, three sets of verbs.

Builtsignalling-panel.htmlfour roadssingle line crossingautomatic blockmodel yardmodel yard with KavachSix stations run, the last two of them the Model Yard sheets — four roads worked on absolute block one side and automatic block the other. The exercise chrome, the block instrument pane and the forms drawer do not. The paired second display now carries proper stock — a detailed WAM-4 and ICF coaches, correctly placed and spaced — but it still runs from its own model rather than from the panel’s state, which is the open question at the foot of this book and is now the only thing standing between it and being useful inside an exercise.

The working panel already carries the board, the operating hints, the fault desk, the event log and the reference tables. It becomes the runtime for every exercise and exam in the product, which means it needs to behave differently depending on why it was opened. Four contexts, one page.

What has to be added to the panel itself

• Block instrument pane — a replica of the instrument in use, beside the board rather than inside it: SGE, UFSBI, Daido, push-button or block interface VDU. Which one appears is part of the exercise configuration. Half the exercise library turns on block working, and it currently has nowhere to happen.
• LC gate and BPAC controls — where the yard configuration includes them, as a distinct group so gate working reads as a separate duty from panel working.
• Forms drawer — the digital authorities, opened by name. The trainee selects the form, fills it, and issues it; correct selection is itself scored, because choosing between T/369(1) and T/369(3b) is the competence being taught.
• Registers drawer — signal failure register, SM’s diary, caution order register. Entries are time-stamped automatically, and the gap between an event and its record is what the timeliness measure reads.
• Communications — call Control, the adjacent Station Master, S&T; capture the private number. Modelled as actions rather than free text so they can be detected as procedure steps.
• Failure guidance pop-up — in Guided mode only, triggered by the fault, explaining what has happened and what the rule requires.
• Second display — the 3D station view as a paired window, driven by the same session state. It shows the consequence of the trainee’s actions and carries no controls.

Built /admin organizations administrator accounts taxonomies The console is built and guarded on the server rather than by hiding menus. The legacy panel editor has been removed, so boards are edited as YAML by hand. The directory this section originally described has moved to screen 12, where it belongs to the institute rather than to the platform.

The console

The platform administrator does not run training. They run the estate: which institutes exist, what each is licensed for, and who administers it. Four pages behind one server guard, and the one part of this book that is further along than the design that produced it.

• HomeThe estate in counts — organizations, licences, administrator accounts, seats in use against seats sold, the size of each taxonomy. Built. Operational alerts and audit history are not.
• Organizations & licencesCreate an institute, inspect it, suspend it, and delete it only when nothing refers to it. Set the ceilings it works within: seats, retention period, expiry. Every rule is checked on the server and the file is rewritten atomically, so a half-written organization cannot exist. Built. Database-backed storage, an audit log and a renewal workflow are the pending half.
• Administrator accountsCreate, disable, reset and safely remove the organization administrators inside a named institute — the handover point between the platform and the tenant. Built. Hashed passwords, an invitation flow, MFA and an audit trail are not.
• TaxonomiesBrowse the skill, fault, form and register taxonomies the whole library is authored against. Read-only. Editing, validation, versioning and publishing are what turn this from an inspector into a tool, and they are the reason content governance below is still a list rather than a screen.

Signalling panel editor

A board is a structured description — scenery, a track graph, points, signals, exits, routes, track circuits, trains, the fault menu and the page text. The editor is a canvas with an inspector, organised as tabs that follow that structure rather than one enormous form.

• CanvasCentre, with a snap grid in board units. Direct manipulation for anything positional: drag a signal along its edge, move a point box, redraw a crossover leg. The canvas is the same renderer the runtime uses, so what is drawn is what trainees will see.
• PaletteLeft. Running line, crossover leg, siding lead, platform, buffer stop, station limit, track-circuit joint, signal of each kind (stop, distant, calling-on, shunt), point, exit button.
• InspectorRight, properties of the selection. A signal: identifier, name, the edge it stands on and distance along it, direction, kind, which side it is drawn, whether it is a subsidiary arm, the point position it applies to, the stop signal a distant repeats.
• TabsLayout · track graph · points · signals · routes and control table · track circuits · trains · fault menu · text and language · validation · versions. The control table tab is the one that needs the most care — it is the interlocking, and it is where an error becomes a board that teaches the wrong thing.
• ValidationContinuous, listed as findings with a click-to-locate: dangling edges, duplicate identifiers, signals with no route, exits nothing reaches, points with no leg drawn, routes that prove a circuit outside their path. Publication is blocked while any error stands; warnings can be accepted with a reason.
• SimulateRun the interlocking engine over the board in a preview pane before publishing — set every route, watch every release. Catching a broken control table here rather than in a cubicle is the difference between a five-minute fix and a lost class.
• VersionsHistory with a diff, clone-from-existing, and import/export of the configuration file. Publishing a change to a board in use warns which exercises and courses depend on it and offers to pin them to the previous version.

Manage users

Written here when there was one directory for the whole product. Most of it now belongs to the institute rather than to the platform and is built on screen 12 — the directory, the account actions, the cohorts and the cubicles all exist there, scoped to one organization and enforced against its licence. What is described below and is still genuinely to build is the bulk import, the permission matrix, and the audit trail; the rest is kept because it is the specification screen 12 was built to.

• DirectoryTable: SM ID, name, role, cohort, default cubicle, status, last sign-in, courses enrolled, competency index. Filter by role, cohort and status; bulk actions on a selection.
• Bulk importA CSV intake for a new batch, with a preview-and-correct step before commit. An institute enrols in batches of thirty, and creating them one at a time is the fastest way to make an administrator hate the product.
• Roles & permissionsFive roles — trainee, trainer, examiner, administrator, observer — against a permission matrix: create and edit exercises, edit boards, inject faults, publish examinations, sign off results, view reports, manage users. Shown as a grid because the interesting question is always what a role cannot do.
• CohortsCreate a batch, assign a trainer, attach mandatory programmes with deadlines, set start and end dates. The cohort is what the console’s class scheduling and the dashboard’s comparisons both hang from.
• Account actionsReset password, change role, reassign cubicle, deactivate. Deactivate, never delete — session records are retained four years and must stay attributable to a named person.
• AuditEvery administrative action with actor, target, time and previous value. Read-only, exportable, and the first thing anyone asks for after a disputed result.

Built /org organization administrators trainers & trainees cubicles cohorts Six pages, all server-rendered, all tenant-guarded, all writing atomically to one yaml file with the validation on the server side of the wire. The newest part of the build and the most finished.

The screen this book did not have. The product is licensed to institutes, and an institute has to be able to run its own lab without asking the platform for anything: enrol a batch, stand up ten desks, form a cohort, put a trainer in front of it. That work is not the platform administrator’s and it is not the trainer’s, so it earns a role and a shell of its own.

• Your organizationThe licence as read-only fact — seats, retention, expiry, status — beside the settings the institute may actually change inside it: the languages it offers, its grading policy, its pass mark. What is a ceiling and what is a choice has to be legible on the same page, or every limit becomes a support call.
• AdministratorsPeer administrators within the same institute: add, disable, reset, remove. An institute with one administrator has a single point of failure the first time that person is on leave, so this page exists before it is asked for.
• Trainers & traineesThe directory. Create accounts, disable them, reset a password, change a role. Active accounts count against the licensed seat ceiling and the server refuses the one that would exceed it — a licence that is not enforced at the point accounts are made is not a licence, it is a note in a contract.
• CubiclesThe standing roll of lab desks: create, edit, place in or out of service, remove only when nothing refers to them. This is the record the instructor console’s ten tiles (05) are waiting to be bound to, and the list the sign-on desk selector (01) should be reading instead of a fixed ten.
• CohortsA batch: a name, a trainer, a roster of trainees, start and end dates, a status. Anything a cohort refers to is protected from deletion. The cohort is what the console’s class scheduling and the dashboard’s comparisons both hang from, which is why it is built before either of them can be finished.
• The boundaryEvery one of these pages reads its organization off the signed session and never off the request. There is no organization identifier anywhere in these urls to tamper with — foundation G, stated as a property of the address bar rather than as a rule someone has to remember.

The twelve screens are not equally load-bearing. Three things unblock everything else, and building them first means every later screen has real data to show rather than a placeholder.

The table below is the original order with the position reached against each line. It has been worked out of sequence — items 4 and 5 are done, item 1 is not — which is why the dashboard and the landing page are complete screens showing prepared numbers. The second table is the order the remaining work now takes.

What remains, in order

Re-cut against what is now built. The first three are one piece of work seen from three sides — a runtime, the events it emits, and somewhere to keep them — and until they are done, six of the twelve screens are showing data that no part of the system produced.