Product methodology
Fatigue Management is designed around a deliberate separation:
Fatigue science + scoped rules + documented management decision
The software does not collapse those layers into a single “safe” or “compliant” label.
1. Modelled fatigue exposure
Section titled “1. Modelled fatigue exposure”The current calculation layer uses an RR446-compatible implementation to produce modelled Fatigue Index (FI) and Risk Index (RI) outputs for planned duties.
Relevant inputs can include:
- duty start and end times;
- shift timing and circadian position;
- duty duration;
- ordered recent duties and cumulative exposure;
- break, workload, and attention values;
- planned one-way travel.
The current beta roster does not capture break, workload, or attention inputs. Those fields therefore use the documented RR446 defaults; the effective values are retained with the evaluation result.
The implementation converts duty instants to UK civil time before extracting model inputs. Its runtime boundary is kept separate from authentication, databases, HTTP, roster persistence, and policy evaluation.
Read the educational explanations of HSE RR446 and the Fatigue Risk Index, FI versus RI, and fatigue model inputs and outputs.
2. Adaptation and data quality
Section titled “2. Adaptation and data quality”The roster application has to map operational planning facts into the model’s expected inputs. The current adapter keeps those mappings explicit:
- one known planned journey is used as the available one-way travel value;
- two equal known travel legs use that common value;
- missing travel preserves the model’s documented 40-minute fallback;
- two unequal known travel legs are left unresolved rather than averaged into an invented FI or RI.
Adaptation warnings and effective inputs are retained with the evaluation result.
3. Compatibility verification
Section titled “3. Compatibility verification”The extracted calculation package is checked against a frozen compatibility fixture set containing 47 complete evaluation scenarios and 12 lower-level reference vectors.
These tests demonstrate behavioural compatibility with the extracted implementation for the covered inputs. They are not independent scientific validation of every result, proof of individual risk, or regulator approval.
4. Policy and rule evaluation
Section titled “4. Policy and rule evaluation”Model output is not organisational policy. A separate versioned layer evaluates selected model and roster metrics against an active named profile.
The current optional profile is Rail Recommended 1.0.0. It can produce:
- OK;
- Advisory;
- Managed Level 1;
- Prohibited.
When it triggers, the application can show the reason, measured value, threshold, travel source, and relevant duty context. Managed Level 1 requires an authorised management reason. Prohibited outcomes cannot be overridden.
Rail Recommended is a product reference profile. It is not an HSE, ORR, RSSB, Network Rail, or regulator-approved standard and must not be used as a universal compliance claim.
Organisations without an active profile continue to receive modelled FI and RI with a clear “No active policy” state.
5. Decision and record
Section titled “5. Decision and record”The authorised person remains responsible for deciding what action is appropriate. Depending on the outcome, that may include changing the roster, removing an assignment, cancelling future work, or providing a permitted management approval reason.
Fatigue-relevant changes create immutable server-side evaluation snapshots. Current product records include calculation inputs, outputs, model and adapter versions, travel provenance, policy identity, triggered reasons, and links to preceding snapshots.
The beta does not yet provide a user-facing audit-history browser, report export, or management-review dashboard.
Limitations
Section titled “Limitations”Modelled outputs:
- estimate relative exposure using population-based research;
- do not measure an individual’s sleep, health, alertness, or fitness for duty;
- do not prove that an incident will or will not occur;
- cannot account for every operational, environmental, or personal factor;
- do not make FI or RI thresholds universal legal limits;
- do not replace competent judgement, worker reporting, supervision, or workplace controls.
Read limitations of fatigue models before using scores in an operational process.
Compliance positioning
Section titled “Compliance positioning”The product can support consistent checks and records only after the applicable rule, policy, contract, or framework is identified. “Compliant” without answering “with what?” is not a meaningful product claim.
The software does not guarantee legal compliance, safe rosters, worker fitness, or approval by any regulator or infrastructure owner.
International scope
Section titled “International scope”The underlying fatigue concepts and general roster workflow are not described as UK-only. Regulatory, contractual, and policy conclusions remain jurisdiction- and organisation-specific. No US, Australian, Indian, or generic global compliance claim is made.