The Graph Goes Digital.

The request was one sentence: "Assess the workload impact of the digital graph on the network controller role." The sponsor's own summary, in the covering note, was that the change made the work simpler and safer, because it was the same graph on a screen without the pencil.

The digital graph already existed in a training environment, so it could be seen and used. What the analysis could do was say what the change did to the work: what it removed, what it left behind, what it introduced, and what the controller would need to keep for the days the screen was not there.

A practitioner who reads "workload impact" and reaches for a workload rating scale has answered the question with the wrong instrument. That was the first decision, and it is recorded at stage 3.

A network controller on a long single-line territory runs the shift from a paper train graph, time along one axis and distance along the other, one line per train. The graph is drawn in three colours and each colour is a different job. Pencil is the plan: where every train is expected to be, where the crosses at loops will fall, redrawn every time a five-minute delay throws the plan out, with blocking lines placed to show what is protected. Red is what has been authorised: when a train authority is issued, the controller draws the authorised movement in red and checks it visually against every other line for line clearance, for track gangs and for restrictions. Blue is what actually happened: as each train reports clear of a location by radio, the controller records the reported time in blue and updates the blocking lines, which is the confirmation of line clearance that every following movement depends on.

The train authority itself is a telephone transaction. The crew call, the controller confirms the train's configuration, gives working advice on opposing, following and press movements, confirms line clearance on the graph, fills in the authority form, reads it to the driver, and cross-checks what the driver reads back. Thirteen operations, one call, one read-back. The read-back is the barrier the whole rail industry has relied on for a century.

The digital graph replaces the paper. Pencil becomes editing on screen. Red becomes a proposed authority drawn on screen and verified there. And blue disappears: the system updates each train's actual pathway automatically, from its reports, so the controller no longer records anything. The controller's job at that step changes from recording to monitoring. The telephone transaction is untouched. The form is still paper. The read-back still happens. The graph is digital; the authority is not.

That last sentence is the framing. The sponsor described the change as the same graph on a screen. It is not. It removes a whole category of manual work, it removes the act that forced the controller to attend to every report, and it introduces a display whose currency and filter state cannot be seen the way a pencil line can. Written as a question:

What does the digital graph remove from the controller's work, what does it introduce, and what must the controller keep, in skill and in procedure, for the days it is not there?

The telephone transaction is out of scope by design. This example stops where the telephone starts.

The boundary: the controller's desk, the graph in both forms, the telephone transaction as it stands, and handover are in. The signalling and the track access process, a separate telephone transaction the change does not touch, are out and treated as context. The roles, as positions: Network Controller and Rail Traffic Crew as primary users; Trainers and Competency Assessors as secondary; Track Workers, whose protection depends on the graph, as tertiary. The modes: normal; degraded, with the digital graph unavailable and the controller back on paper; handover, where the graph is the shared artefact; and transition, because during rollout a controller holds both methods in currency.

In ErgoSphere the framing is the Early Human Factors Analysis, run as a wizard with the standards lens on AS 7470. The change goes in as two states, the paper graph and the digital graph. The three user groups are entered. The elements of note are the ones a document review and an early walk of the training build put at the top: the digital graph display, whose currency, provenance and filter state are not observable the way a hand-drawn graph's are; degraded operation; the workstation layout, which had a prior assessment of unknown status; and the long-tenure controllers whose procedural habits would carry over. The eight domain probes are rated with task novelty, HMI and human error potential high and workload medium, manual handling considered and dismissed with a rationale. The significance level is set high, with the reason: a safety-critical task in a safety-critical role, a new platform with a direct interface, and existing controls removed rather than only added.

Nobody hands a practitioner the list. It is assembled in order of authority, and the order matters because when two documents disagree the higher one wins.

1. The law and the regulator. The rail safety national law and its schedule on the contents of a safety management system, which is what makes Human Factors integration mandatory. It says the work must be done. It does not say how.
2. The governing standard. AS 7470:2024, Human Factors Integration and Technical Requirements for Rail Engineering Projects. Everything on this page answers to it: the process, the documents, the technical requirements. It is a different kind of standard from the ones most practitioners are used to, and the box below says how.
3. The operator's own system. The safety management system, the safety-critical communications standard the industry body publishes, and the operating rules that govern how a graph is kept and handed over. These sit under AS 7470 and give it local teeth.
4. The industry guidelines on integrating Human Factors across the project lifecycle and in engineering design, read for method rather than for clauses.
5. Sources of criteria AS 7470 does not supply. Section 9.6 requires controls and displays to suit the user. It does not give a viewing angle or a distance. To score a screen's position the practitioner has to reach outside the governing standard for a number, and that reach is a leap that has to be explained. ISO 11064-4, the control-centre workstation standard, is the place to reach, because a network control desk is a control centre and that part of the standard gives the viewing angles, the upward gaze limit and the distances a desk is laid out to. It enters the example only as the criterion used to satisfy an AS 7470 clause, and never as a standard the design must comply with in its own right. Other display standards exist, and Example 02 is governed by one of them; none is needed here, and reaching for one when the control-centre standard already has the number would be a leap without a reason.

AS 7470 is in the Standards Register's library. Add Standard, From Library, and the 2024 edition arrives as a tree: the standard, its sections, and every requirement clause under them with its clause reference, its requirement level and its acceptance criteria. The clause text is a verbatim transcription held as fragments, so what is screened is what the standard says and not a paraphrase. The register's own header draws the line: a clause here is the standard's requirement, not yet the project's.

Screening makes it the project's, section by section: Applicable, Partial or N/A, with who decided and when, and Confirm to lock it. The process sections, on planning, on the concept-phase documents, on issues and on user requirements, are Applicable in full. Section 9 is Partial, decided clause by clause: error tolerance, negative transfer, workload, and controls and displays Applicable; the clauses on manual handling, on physical environment and on staffing levels N/A, each with its one-sentence rationale in the box the app marks required. Any clause in a Partial section left undecided is counted and shown rather than dropped.

The KPIs then show screening status, applicable, not applicable and client acceptance, and the exclusions are listed in the Applicability Statement. That statement is what the gate review asks for first.

The criteria source goes into the register in a different role from AS 7470, and the register is made to show it. ISO 11064-4 is not in the library, so its workstation clauses, the handful on viewing angles, gaze limits and viewing distance, are entered on the Custom tab as a small requirement set, with the standard type set to Guidance, which is what it is in this context. The professional judgement on each clause says the same thing in one sentence: "Criterion adopted under AS 7470 9.6; this clause supplies the limit AS 7470 does not." A reviewer who opens it sees at once that it is there to serve an AS 7470 clause, not to govern.

The leap deserves a plain statement, because a rail reviewer will query it. An international control-centre standard's numbers are being used, under an Australian rail process standard, to test a control desk. That is legitimate when three things are true: the AS 7470 clause it serves is named; the client has agreed the source; and the number is read as a criterion, not as a compliance target. None of this makes the desk "compliant with ISO 11064", and the report never says so. It makes the desk assessed against AS 7470 9.6 using a stated criterion.

The industry guidelines, the communications standard and the operating rules are read but not entered clause by clause; they are held in the Document Register and cited in the judgement of the clauses they informed. The rule: nothing that shaped a decision goes unrecorded, but not everything read needs a register entry.

• Structure. What does the controller do in each state, decomposed to the operations actually performed, described the same way so the two can be compared?
• Error. At each step materially affected by the change, what can credibly go wrong, what recovery exists, and what is removed, introduced or retained between states?
• Demand. Where does the work actually fall, and how much of it does the change take away? Counted, not reported.
• The desk. Do the new screens fit the controller population, given that the last workstation assessment predates them?

And one constraint: no operational data existed for the digital state, because it was not in service. Anything that needed measured times or observed frequencies on the digital graph was either deferred to commissioning or not attempted, and the plan says which.

Three more methods were planned and then not applied, and each is recorded with its reason. Time-on-task analysis, because no operational data existed for the digital state and estimating it would have carried a precision the evidence did not support. Targeted SPAR-H quantification, because nobody had asked for a probability and there was no target to read one against. And a heuristic review of the interface, because the SHERPA already produced interface requirements with a traceable source, and a second list of findings without one would have competed with them rather than added to them.

ErgoCompass starts with two plain questions, which industry, Rail, and what kind of problem this mainly is, human error or reliability, plus the problem statement in the practitioner's words. It rates the problem's complexity on twelve short tenets, shows a ranked palette with the methods native to rail flagged, HTA and SHERPA among them, and asks whether the foundations are covered: data gathering, an HTA, decomposition, triangulation. Then the justification record: the selected methods and the stack, HTA feeding SHERPA; why this fits; considered and set aside, which is the four forks above; the foundations note; and the field that closes the loop later.

Send to HFIP writes each justification into the Integration Plan. The plan is its own wizard, and this one has two things to notice. Its screening step asks the novelty of the change, and the honest answer is Modified, not Like-for-like, the sponsor's word from 1.1 written down at last. And it has a Planned and not applied section, which is where the three methods above go with their reasons, so the plan shows the methods that were considered and dropped as decisions rather than as gaps.

The data came from two shifts at a desk, one quiet and one with a possession in force, and from structured interviews with senior controllers afterwards, which is where the plans come from. Observation says what the operations are. The controller says when each is done, in what order, and what triggers it. The three graphing colours, with their triggers, came out of the interviews in the first ten minutes; a description written from the procedures alone would have listed the graph as one task.

Two habits keep an HTA honest. Write the plan for every node with children. A node with children and no plan is a list. Apply a stopping rule: decompose to operations where the change touches the work, and stop at sub-tasks where it does not. Here the safeworking audit and the network planning branches stop early, because the digital graph changes how they are read and not what they are. The train authority and the graphing branches go all the way down, because that is where the change lives.

Counted at the leaves: thirty-six discrete controller operations, thirteen of them in the train authority cycle, eleven of them performed by hand on the graph. Those three numbers are the baseline everything else is read against.

In ErgoSphere the tree is built with Add Child and Add Sibling, the numbering is automatic and never edited by hand, and each node carries its goal, its plan as free text or a formal expression the tool can play back, its performer and its preconditions. The stop rule is a toggle on the node, and because the tool does not do the probability-times-cost arithmetic, the reasoning goes in the node's notes where the next reader finds it. The standing validator flags a parent with a single child and a node with children and no plan as you go. The tree is the one decomposition the rest of the project reads. SHERPA does not re-enter a single operation; it pulls this tree.

SHERPA walks every operation the change touches and asks, against a taxonomy of action, checking, retrieval, communication and selection errors, which are credible. For each, the practitioner writes what the error looks like, its consequence, where and whether it would be recovered, a probability and a criticality, and the performance shaping factors that make it more likely, drawn from the SPAR-H set: available time, stress, complexity, experience and training, procedures, ergonomics and interface, fitness for duty, work processes. The discipline is in the word credible. The analysis records the modes a controller reading it would recognise.

The rows that mattered on the paper graph were the ones that belong to pencil and paper themselves:

In ErgoSphere the session starts by choosing Classic mode, which locks once the first step exists, and Import from HTA creates one worksheet row for every bottom-level operation in the tree. Each row picks its error mode from the taxonomy, grouped by category, and carries the description, the psychological mechanism, the consequence, the shaping factors, the existing controls, the recovery step, and probability and criticality as Low, Medium or High. The remedial strategy is written under four headings the worksheet holds apart, Equipment, Training, Procedures, Organisational, and that split is what makes 5.1 possible. The HTA diagram opens beside the worksheet with each row's number badged on its node.

The second tree came from the system's concept of operations, from the training build, and from a two-hour walkthrough of that build with two controllers who had been observed on paper the month before. The walkthrough is where the analysis learned that blue graphing did not become "digital blue graphing". It became nothing. The system updates the train's actual pathway from its reports, and what the controller does at that point is watch it happen.

The rule that makes the comparison work: do not build the second tree, duplicate the first. The paper-graph HTA is given the state role Current, and Duplicate as next state makes the Target copy with every node remembering the node it came from. Then the copy is edited. The safeworking audit's graph review becomes a review on screen. Confirm line clearance is a visual check on screen. Draw on graph becomes draw the proposed authority on screen. Pencil graphing becomes digital editing: amend or clear previous planning, develop the plan, input planning lines, apply blocking lines. Red becomes the digital proposed authority. Blue's two operations, record reported times and update blocking lines, are removed. And one new operation appears under 3.2.1: monitor the auto-updated train pathway. Correspondence is recorded at duplication and never guessed, and ErgoDelta will refuse two trees built separately. That refusal is a feature.

The train authority branch, 3.1, is edited only where the graph touches it. Thirteen operations before, thirteen after. The telephone call, the form, the read-back are untouched, because the digital graph digitises the graph and not the authority.

The same walk, on the second tree, and the same duplication rule: the paper-graph SHERPA is duplicated as its next state, then Import from HTA refreshes the rows whose operations changed and adds a row for the new monitoring operation. Five modes disappear with the paper: mis-recorded times, times not recorded, blocking lines not updated after a report, partial erasure, and the smudged graph. Three are retained with their mechanism changed. And four arrive that have no analogue on paper at all:

One more row was written and deliberately not counted: the hypothesis that losing the physical act of drawing reduces situation awareness. It sits in the worksheet marked as recorded, not counted, with its exclusion reason, because the app keeps counted and recorded-not-counted rows apart and reports the difference. That is the row MON-01 came from.

ErgoDelta links the two chains, the HTA states and the SHERPA states, and reads them live; it stores no copy of either, and Recheck re-reads them if anything moves. Measures are added for what should be counted in every state: task operations, task operations in the 3.1 sub-tree, error modes, and error modes with a recovery path. The Tasks tab classifies every row Unchanged, Modified, New, Removed or Folded. The Error modes tab puts each mode's status side by side, annotated "removed at T1" or "introduced at T1", with whether a recovery path exists in each state, and because the SHERPA is Classic it says "no band" rather than inventing a residual number. The summary is the finding:

The digital graph arrives on two wide screens where the paper roll used to lie, above the existing displays, and the concept-phase issue said only that the prior workstation assessment's status was unknown. The desk is modelled from a survey: surface, seat, the existing screens, the two new ones where the installation drawing put them. Before anything is scored the Basis is set, and the app is blunt about what that panel is, what the design is priced against, assumed before any result is computed: percentile, sex selection, the anthropometric population the operator's specification uses, reference posture seated. From those the assessed eye reference point is computed as a number; the figure at the seat is illustrative, with its own eye marked so the two can be told apart.

Then the criterion, and here the leap from 2.3 is made in the tool. The vision cone standard selector offers ISO 11064 and three others, each drawing different optimal, acceptable and critical half-angles and a different upward gaze limit from the assessed eye. ISO 11064 is selected, because the desk is a control-centre workstation and that is the standard written for it, and the choice is recorded in the session report against the AS 7470 9.6 clause it serves. The Cones overlay draws the selected standard in the TOP view, so a reviewer who wants to see what a different criterion would have said can switch it on the same model in seconds, and the report says which one the finding was read against.

Every display is then reported with its angles and viewing distance, placed in a zone and given a compliance level: Optimal, Acceptable, Marginal or Critical. The upper of the two graph screens, mounted high to clear the existing displays, sat above the ISO 11064 upward gaze limit at the 5th percentile basis and came back Marginal, in the tertiary zone. The graph the controller most needs to notice a change on was the one that needed the head tilted back. Lowering the pair by one mounting position and stacking the existing displays left brought both into the primary zone at Acceptable for both bases, and the re-run is in the session report.

A clause tells a designer what to consider. A finding tells the practitioner what went wrong, or could. A requirement is the sentence that turns either into something a designer can build to and a tester can fail: who, shall, what, under which condition, to what criterion, verified how. It is written now, after the results have been read, because that is where most requirements come from: the findings, wound back into the design, one per error mode that needs a control, with the SHERPA row as the source so that each can be traced to the error it addresses. A few came straight from section 9 of the standard and could have been written the day the clauses were screened at stage 2. They are written here with the rest so the set is one set, in one register, with one numbering.

The digital graph already existed, so some of these could not be design inputs. They were written anyway, and carried either as verification items at commissioning or as residual issues with a named owner. A requirement the design cannot meet is recorded as not met, with the reason. It is not deleted.

Every requirement can be failed. Every one traces back to a clause or a SHERPA row, and forward to a verification method and a stage. None contains "intuitive" or "user-friendly", and none contains "and". The whole set is integrated into the project's requirements documentation rather than held as a Human Factors artefact, which is what AS 7470 section 4.5(d) asks, and the ones with safety implications are cross-referenced to the project hazard log.

The HF User Requirements Register holds them. Each is entered with New Requirement and fixed at creation into a requirement group: System, Procedure, Training, Transition or Monitoring, which is exactly the prefix the identifiers above carry. The group is not decoration; it says who has to answer. Then the end-user groups it protects, the verification method and stage, an owner, and a status that starts at Open and moves to Verified, Residual or Not Met, or sits at Unconfirmed while a design question it depends on stays open.

The register carries no pointer to a clause. It carries a source narrative, a sentence like "SHERPA 3.2 and 3.1.4, S2 wrong view selected, residual high", written for the auditor who wants to trace the requirement to the error mode without opening the workbook. The clause's own side of the trace, its compliance status and evidence, is set at stage 7 in the Requirements workspace. Where the EHFA at stage 1 recommended a requirement against a risk area, it is raised straight into this register from the wizard with its provenance already written.

The concept-phase issues from the EHFA were already in the register, ten of them, raised at stage 1. The analysis added the rest, each raised from the session that found it so the provenance is written by the tool: the four introduced modes, the common-mode dependency, the blocking-lines mode the controllers raised themselves, and the degraded-mode reversion. Each carries a severity, an area, an owner who can actually close it, a target date, and links to the user requirements it generated. The owners are positions and organisations: the system's design owner for the interface requirements, training and competency for currency, network operations for the degraded-mode procedure, the Human Factors specialist for the field validation.

Status is deliberately more than open and closed. The two issues the design owner took into their own change process were set to Transferred, not Closed, and the register never folds Transferred and Residual into a closed count where a person reads the number, because a risk somebody else now owns has not gone away. The Issues and Standards registers can leave the project as ReqIF for the operator's own requirements tools.

The clauses screened in at stage 2 have been waiting in the Requirements workspace, the designated requirements and how the design stands against each. Now each is answered. Link Assessment attaches the HTA sessions to the task analysis clauses, the SHERPA sessions and the ErgoDelta to the error tolerance clause, the ErgoDesign session to the AS 7470 controls and displays clauses, with the ISO 11064-4 criteria clauses closed in the same step as the source the judgement cites. The compliance status moves from Not Assessed to Compliant, Partially Compliant or Non-Compliant, never to Not Applicable, because exclusions belong to screening. The professional judgement statement says why, the compliance claim says what is claimed, the justification says how the evidence shows it, and where an issue is open the residual risk gets a rating and a statement. The workload clause, 9.1(j), is answered with the counted demand shift and the judgement that the digital graph does not impair the safety-critical task. The controls and displays clauses are Partially Compliant, with the stale-view issue raised against them until the currency indication is verified.

The EHFA from stage 1 and the Integration Plan from stage 3 are finalised and signed, which freezes each as a dated, hashed version. The close-out wizard then builds the assurance report, and the first choice it offers matters here: the report stage. This is a Design HFAR, not a completions one. Each requirement is closed with its evidence, and most of them close as Open with the honest note that verification needs a delivered system to verify against. Every issue is traced to its requirement. Then the four sub-claims, each with a position and a reason. That the programme delivered was the one the risk picture required: Supported. That requirements were identified, allocated and met: Partially Supported, identified and allocated, not yet met. That issues were managed and closed or transferred: Supported. That the findings demonstrably influenced the design: Partially Supported, because the findings became requirements carried to the design owner for verification at commissioning, and the wizard's own guidance says that rejected and deferred recommendations belong in this sub-claim, so they went in.

The conclusion was Not yet demonstrated, and that is the correct conclusion for a design-stage report on a system that has not entered service. It is not a failure; it is a statement of what a verification at commissioning must show, and the completeness check lists the gaps by kind so that issuing with them is a recorded act. The compiled deliverable is Part I, this assurance summary; Part II, the frozen EHFA; Part III, the frozen plan with its planned-and-not-applied section; then one appendix per session: the two HTAs, the two SHERPAs, the ErgoDelta and the ErgoDesign study. The document set AS 7470 section 3 asked for at 2.1 is the compiled package, produced from one project rather than assembled from seven files.

Each report is marked ready in Deliverables, and a ready mark lapses if the content underneath it changes, so nothing stale can be sealed. Compose Package puts the chosen reports into one file for the operator, hash-sealed, with a manifest of what went in and what was left out, and issues it as Revision A. The reviewer opens it in the free Viewer and meets the analysis itself: both trees, the delta, the desk model, the argument. The one comment that came back was anchored to the ErgoDelta assessment, and it was the right one: why is a change of one operation and one error mode the subject of a report this long? The answer, the change in character, was already in the report at 5.2, so Revision B moved it to the executive summary, where it should have been. Import a Returned Package had filed the comment where it was written, and it was resolved against the revision that answered it.