SM Simulator
Screen Book

Six decisions sit under every screen that follows. Settling them first is what keeps eleven screens from becoming eleven unrelated products.

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

Builtlogin.htmlThree accounts hardcoded in the page. There is no directory behind it and nothing is protected.

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.

Builttrainee.htmlEvery word on it is written from trainee-sm-2291.yaml.

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.

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.

Builtdashboard.htmlThe trainer opens the same page and gains the switcher, the cohort overlay and the remarks.

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.

Builttrainer.htmlSign on as the instructor first — the console reads the session for who is at the desk.

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.

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. The exam page is not. References and version history have no store behind them, and the exercise page says so rather than inventing clause numbers.

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 builtAnd it cannot be finished until the panel scores injected faults: faultState is written by injectFault and read only by renderFaults, so nothing injected reaches the interlocking.

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; the filters, badges and qualification marks described below do not.

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 blockFour stations run, the last of them in automatic block with four-aspect signalling. The exercise chrome, the block instrument pane and the forms drawer do not.

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.

Part built panel-editor.html The panel editor, minus the drawing canvas: every board opens, edits, validates and downloads, and the preview beside it is the runtime rather than a picture of it. The track graph is still written by hand, there is no version history, and user management does not exist yet.

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

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

The eleven 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.