Explore the factors
Pick a context, pick a factor, and see where it lands in 4 external frameworks, including the rows that assert there is no counterpart. Then push the same factor through the rule engine. Step through a full derivation →
PIF explorer
Four context dimensions, twenty IDHEAS-G factors, one crosswalk.
Run the rule engine
Start from a scenario, change one factor, read the band and the derivation. Every result was computed by the repository's own engine when this page was built, one factor changed at a time.
Ordinal screening label. Not a human error probability, not a rate, not calibrated against outcome data. Band thresholds are conventions chosen by the author.
Computed at build time: ehs_hfo.assessment.assess on examples/reactor_startup_nonroutine.json and an all-nominal variantWhy this exists
A derivation trace is the reasoning, not a description of it written afterwards.
A language model asked to explain a risk score will produce a fluent explanation. That explanation is generated after the answer and is not causally connected to how the answer was produced, so it can be confident, readable and wrong about its own reasoning. In a regulated setting that is worse than no explanation, because it invites reliance it cannot support.
Read on
This repository takes the other route. Contextual factors shaping human error are encoded as an OWL ontology, and a forward-chaining rule engine evaluates a scenario against it. Every derived fact records the rule that fired and the facts that satisfied that rule's body, down to the scenario inputs. The trace is not a narration of the reasoning. It is the reasoning, printed.
Two properties make it auditable rather than merely verbose. Every rule declares whether its basis is literature, in which case a citation is enforced at construction, or convention, in which case it says so and names no source. And output is deterministic: two runs of the same scenario produce byte-identical reports, because an audit record that changes between runs is not an audit record.
Conceded up front
Read on
- Factor levels are analyst-assigned ordinals. A person decides that training is degraded. Nothing in this repository measures it.
- The observable proxies suggested for deriving levels from operational data are proposed, not validated.
- A compatibility argument is owed. Adopting one project's factor set while restructuring the error taxonomy it was built against needs to be justified explicitly, and that argument is not yet made.
What this does and does not show
What this shows
- An encoding of the 20 IDHEAS-G factors with the source's own wording attached, so the transcription can be checked rather than trusted.
- A crosswalk to 4 external frameworks: 90 cited alignments, 6 asserted absences, only 34 close matches.
- A forward-chaining engine whose every conclusion carries the rule that fired and the facts behind it, deterministic run to run.
What this does not show
- Factor levels are analyst-assigned ordinals. The observable proxies suggested for deriving them from operational data are proposed, not validated.
- A compatibility argument is owed. Adopting a PIF set while restructuring the error taxonomy it was constructed against requires an explicit argument. That argument is not yet made.
- The engine has not been evaluated against expert judgement.
- The screening bands are conventions. The thresholds are the author's.
- The scenario corpus is synthetic. The worked example is a hand-written illustration and is not a record of a real event at any site.
The taxonomy is adopted, not invented
The most useful thing this page can do is tell you what is borrowed before you find out yourself.
Method, limits and notes
The four context dimensions here are not new, and the twenty factors are not new either. They are the performance-influencing-factor context categories and the twenty PIFs published by the U.S. Nuclear Regulatory Commission in IDHEAS-G (NUREG-2198, 2021), adopted unchanged. Two of the four labels are identical to the source's; two are synonyms.
This is said first because it is what a reviewer from the human reliability community would otherwise find and hold against the work. Claiming novelty for a relabelling of performance shaping factors would not survive that reviewer, and should not.
Adding another loosely defined factor grouping would also make a documented problem worse rather than better: existing PSF sets already range from one factor to more than fifty, and the literature reports that they are not defined precisely enough to be applied consistently.
Notes
So what is contributed
- An encoding. Fixed identifiers with the source's own wording attached, so a reader can check the transcription rather than trust it. Hand-written Turtle, 1,028 lines, parsed by a standard-library parser because the repository takes no dependencies.
- A crosswalk as a first-class artifact. Every factor mapped to its counterpart in 4 external frameworks, with a match strength and a citation on every row, and an explicit assertion of absence where a framework has none. Generated from the ontology, and the test suite fails if the two disagree.
- Traceable inference. The rule engine, and the guarantees below.
Crosswalk to prior work
20 factors across 4 context dimensions, mapped onto 4 external frameworks with a citation on every row.
Crosswalk match strength by framework
Why
exact is declared in the ontology and deliberately never used, and a test enforces that, because asserting exact identity between factors written decades apart for different industries would claim more than the sources support.| dimension | local factor | framework | external counterpart | strength | citation |
|---|---|---|---|---|---|
| Human context | Procedures, guidance and instructions | CREAM | Availability of procedures and plans | close | hollnagel1998 |
| Human context | Procedures, guidance and instructions | HFACS | Operational process | broader | shappell2006 |
| Human context | Procedures, guidance and instructions | HSE Performance Influencing Factors | Preparation for task | partial | hse_pifs |
| Human context | Procedures, guidance and instructions | HSE Performance Influencing Factors | Procedures inadequate or inappropriate | close | hse_pifs |
| Human context | Procedures, guidance and instructions | SPAR-H | Procedures | close | gertman2005 |
| Human context | Staffing | CREAM | Adequacy of organisation | broader | hollnagel1998 |
| Human context | Staffing | HFACS | Resource management | close | shappell2006 |
| Human context | Staffing | HSE Performance Influencing Factors | Manning levels | close | hse_pifs |
| Human context | Staffing | SPAR-H | Work processes | partial | gertman2005 |
| Human context | Team and organisation factors | CREAM | Adequacy of organisation | close | hollnagel1998 |
| Human context | Team and organisation factors | CREAM | Crew collaboration quality | close | hollnagel1998 |
| Human context | Team and organisation factors | HFACS | Crew resource management | close | shappell2000 |
| Human context | Team and organisation factors | HFACS | Organizational climate | partial | shappell2006 |
| Human context | Team and organisation factors | HSE Performance Influencing Factors | Clarity of roles and responsibilities | partial | hse_pifs |
Why
none are assertions that a framework has no counterpart at all, which is a claim someone can argue with rather than a silence. Showing 14 of 96 rows.A derivation trace
This is the whole argument for the approach, so it is shown rather than described.
screeningBand(stop-and-review) <- R33-band-stop-and-review [convention; no source]
rule: screeningBand(stop-and-review) :- severelyDegradedFactor(?F), not mitigatedFactor(?F), aggravatedErrorMode(?M).
because: A severely degraded factor occurring alongside an aggravated error mode puts the scenario in the stop-and-review band. Threshold chosen by the author; no source supports it.
severelyDegradedFactor(ehs:ScenarioFamiliarity) <- R02-severely-degraded [literature; nureg2198]
rule: severelyDegradedFactor(?F) :- factorLevel(?F, ?L), levelSeverelyDegraded(?L).
because: A factor at the lowest assessed level is severely degraded.
factorLevel(ehs:ScenarioFamiliarity, ehs:LevelSeverelyDegraded) [given]
levelSeverelyDegraded(ehs:LevelSeverelyDegraded) [given]
aggravatedErrorMode(ehs:KnowledgeBasedMistake) <- R22-aggravated-by-second-factor [literature; groth2012]
rule: aggravatedErrorMode(?M) :- degradedFactor(?F), factorPredisposesTo(?F, ?M), degradedFactor(?G), factorPredisposesTo(?G, ?M), lt(?F, ?G).
because: An error mode flagged by one degraded factor and flagged again by a second, distinct degraded factor is recorded as aggravated. This says two independent routes to the same failure class are open. It does not say the risk has doubled; nothing here supports a multiplicative claim.
degradedFactor(ehs:ScenarioFamiliarity) <- R01-degraded [literature; nureg2198]
rule: degradedFactor(?F) :- factorLevel(?F, ?L), levelDegraded(?L).
because: A factor assessed below the nominal condition is a degraded factor. Levels and their ordinal ranks come from the ontology, not from here.
factorLevel(ehs:ScenarioFamiliarity, ehs:LevelSeverelyDegraded) [given]
levelDegraded(ehs:LevelSeverelyDegraded) [given]
factorPredisposesTo(ehs:ScenarioFamiliarity, ehs:KnowledgeBasedMistake) [given]
degradedFactor(ehs:TimePressureAndStress) <- R01-degraded [literature; nureg2198]
rule: degradedFactor(?F) :- factorLevel(?F, ?L), levelDegraded(?L).
because: A factor assessed below the nominal condition is a degraded factor. Levels and their ordinal ranks come from the ontology, not from here.
factorLevel(ehs:TimePressureAndStress, ehs:LevelDegraded) [given]
levelDegraded(ehs:LevelDegraded) [given]
factorPredisposesTo(ehs:TimePressureAndStress, ehs:KnowledgeBasedMistake) [given]
(3 further derivations recorded and not expanded here)
(2 further derivations recorded and not expanded here)The top of the derivation for the screening band, produced by running the repository's own command-line tool against its committed worked example at the moment this page was generated. Two things to notice. The band rule announces itself as [convention; no source], because the threshold is the author's and no literature supports it. And the chain bottoms out in [given], which are facts the scenario or the ontology supplied, so there is nothing between the input and the conclusion that a reader cannot inspect.Generated at build time from examples/reactor_startup_nonroutine.json
What the engine guarantees
Guarantees worth having, and the narrow shape of the thing they apply to.
- Termination
- No function symbols, so the Herbrand base is finite and evaluation reaches a fixpoint.
- Negation
- Stratified negation as failure, checked at construction. A negative dependency inside a cycle raises rather than picking an answer.
- Determinism
- The fact index is seeded in sorted order and alternative derivations are canonically sorted, so two runs produce byte-identical reports.
- Rule basis
- Every rule declares
literature, which requires a citation and is enforced in the constructor, orconvention, which states that the author chose a threshold and no source supports it. Every screening-band rule is convention, and a test fails if one ever claims otherwise. - Missing data
- A factor omitted from a scenario is carried as unknown, never as nominal, and the report prints assessment coverage. Treating missing data as satisfactory is the standard way a screening tool understates a hazard.
- Output
- An ordinal screening band. Not a probability, not a rate, and the report says so in the line that prints it.
What the factor set does not reach
A crosswalk is only credible if it publishes its own gaps.
| Framework | Local factor with no counterpart | What is asserted |
|---|---|---|
| SPAR-H | Noise and communication pathways | Asserted absence: no counterpart in this framework. |
| SPAR-H | Resistance to physical movement | Asserted absence: no counterpart in this framework. |
| SPAR-H | Thermal conditions | Asserted absence: no counterpart in this framework. |
| SPAR-H | Workplace accessibility and habitability | Asserted absence: no counterpart in this framework. |
| SPAR-H | Workplace visibility | Asserted absence: no counterpart in this framework. |
| HFACS | Scenario familiarity | Asserted absence: no counterpart in this framework. |
Why
Honest limits
What is not established
- Factor levels are analyst-assigned ordinals. The observable proxies suggested for deriving them from operational data are proposed, not validated. No study here establishes that any proxy measures the factor it is attached to, and a screening band computed from unvalidated inputs inherits their uncertainty entirely.
- A compatibility argument is owed. An internal review flagged that adopting a PIF set while restructuring the error taxonomy it was constructed against requires an explicit argument that the two remain compatible. That argument is not yet made.
- The engine has not been evaluated against expert judgement. Nobody has checked whether its screening bands agree with what experienced analysts would say about the same scenarios.
- The screening bands are conventions. The thresholds are the author's. The engine declares this in every trace, which makes it honest, not validated.
- The scenario corpus is synthetic. It is fabricated, labelled as such in the repository, and used only to exercise the engine. The worked example is a hand-written illustration and is not a record of a real event at any site.
Run it yourself
git clone https://github.com/priyatham9/ehs-human-factors-ontology
cd ehs-human-factors-ontology
python3 -m unittest discover -s tests -t .
PYTHONPATH=src python3 -m ehs_hfo assess examples/reactor_startup_nonroutine.jsonStandard library only. Two runs of the same scenario produce byte-identical reports.