The SafeForge Data Model — How We Represent Risk

The why

The problem

Hazard logs are supposed to be the single source of truth for the risk story of a safety-critical system. In practice they are the opposite. Most are spreadsheets that started as someone’s good intention three years ago and have since drifted into the kind of artefact that nobody trusts but everyone has to use.

There are two shapes the dysfunction tends to take.

The Excel hazard log

Most safety teams begin with a flat spreadsheet — one row per hazard, columns for description, severity, likelihood, status, and a comma-separated list of “linked controls” that nobody updates. It works at first. Then the project grows. Our founder has run, inherited and audited hazard logs across rail signalling programmes, a transport authority’s own register and defence aviation, and every bad one started the same way: as a spreadsheet that was never meant to carry the load.

The pattern is consistent. As the spreadsheet grows past a hundred or so hazards:

• The same control gets typed in five different ways across five different rows
• The “linked threats” column becomes a wall of comma-separated IDs nobody can interpret
• Two engineers add the same hazard with different IDs because no one searched first
• A hazard is closed but the threat that fed into it is still open, and nobody notices
• A regulator asks for the control-requirement traceability matrix and it’s a one-week archaeology project

The UK MoD’s official hazard log toolkit names the failure mode directly:

“If it is not sufficiently robust or well-structured, this may obscure the identification and clearance of hazards… if hazards are not well defined when they are entered into the hazard log, then the rigour enforced by the need for a clear audit trail of changes made may make it very difficult to maintain the hazard and accident records.” — ASEMS Online, the UK MoD’s Acquisition Safety and Environmental Management System toolkit

The same system’s hazard-log procedure spells out what the tool has to do, and it is not a flat list:

“Hazard Log Reports will be capable of showing the linkages between hazards, accidents and controls (i.e. which hazards could lead to which potential accidents, possibly with many-to-many relationships, and which controls relate to which hazards and accidents).” … “Whatever Hazard Log tool is adopted should be under strict configuration control to ensure robust audit trail.” — ASEMS SMP11, Hazard Log (v4.3, 2022), §11.5.0.1 and §11.5.2.2

The US FAA’s System Safety Handbook says the same thing in one line: “The presence of a centralized hazard tracking system is a good indicator of a quality system safety program and should be a contractual requirement.” (Chapter 8, 2000; the FAA’s own copy has moved, so this links a mirror.)

A spreadsheet is not the wrong starting point. It’s the wrong endpoint. Once the data outgrows the format, the format actively works against the engineer trying to maintain it.

The enterprise requirements-tool route

The conventional answer to spreadsheet sprawl in safety-critical industries — particularly defence and rail — has been an enterprise requirements management tool such as IBM Rational DOORS, IBM ELM / DOORS Next, Polarion, or Jama Connect. These tools are powerful, mature, and have served large prime contractors for decades. For programmes operating with thousands of seats and a dedicated tools team, that investment can be entirely justified.

For everyone else, it is often a different experience. Public user reviews on PeerSpot from senior practitioners name the recurring trade-offs:

“DOORS is very difficult for novice users to use.” — Greg Mazalo, Associate Director Systems Engineering, PeerSpot user review

“They have to wait too long for the page to return… performance is a very essential thing.” — Hubert Zenner, Technical Sales Specialist, PeerSpot user review

These quotes reflect their authors’ experience with the products as configured at their organisations and may not generalise. Some teams report DOORS performing well for them, particularly where a dedicated tools group maintains the templates, scripts, and integrations that make the platform sing. The reviews are genuinely mixed; the trade-off pattern is consistent enough to be worth taking seriously.

The cost profile is also worth understanding before committing. Third-party pricing estimators such as ITQlick put a Rational DOORS licence in the five figures, with adoption concentrated in very large enterprises. The product’s commercial centre of gravity is the 10,000-employee prime, not the consultancies and SMEs doing a large portion of safety engineering work in the field.

Jama Software, a competitor, frames the recurring failure mode for teams who do invest:

“DXL-heavy environments often require a small set of specialists who maintain scripts, troubleshoot imports, and update reports as processes change.” Once those support tasks become routine, Jama adds, the tool starts consuming engineering time instead of protecting it — and that is usually when organisations start looking at alternatives. — Jama Software, What Is IBM DOORS Software?

This is a competitor’s framing, not a neutral one. But it matches a recurring pattern in the field: tools designed for breadth of customisation can quietly relocate engineering effort from the work to the tooling. SafeForge is built for the teams who don’t want to make that trade.

What this costs

The cost isn’t just productivity. It’s the quality of the hazard analysis that feeds your safety case. The IChemE Hazards 28 paper on bow-tie practice identifies the consequence of poor structure directly:

“The Bow Tie method today is often conducted too loosely with poor analysis, no generally accepted methodology and only proprietary company or software guides being available. … No rule set for barriers resulting in too many barriers giving operations and management a false sense of security.” — IChemE Hazards 28 Paper 31

When hazard logs are hard to maintain, controls get added without scrutiny, and operators start to believe they are protected by barriers that exist only on paper. The Australian rail regulator put it in plainer language:

“Risk assessment as an administrative task or hurdle rather than as a process to support or guide their decision-making… risk assessment may overlook certain risks which may result in mitigating controls not being introduced.” — ONRSR Safety Message

The pattern repeats in post-incident reports. Boeing’s 737 MAX certification documentation showed an MCAS command authority of 0.6° in the safety analysis when the actual implementation was 2.5° — and Boeing did not resubmit the revised hazard assessment to the FAA. At Nimrod, BAE Systems left 40% of identified hazards “Open” and a further 30% “Unclassified” when the safety case was signed off. These were not unsophisticated organisations. They were organisations whose data tools made it possible — and in some cases easy — to lose track of what mattered.

The right answer is not to add more rigour to a broken format. The right answer is to use a format that matches the way safety engineering actually thinks about risk.

The model

How SafeForge addresses it

A note on scope. SafeForge is not a safety case tool. The safety case — the documented argument that a system is acceptably safe — is a much broader artefact than a hazard log. It includes the safety argument structure, the evidence catalogue, the lifecycle assurance, the verification reports, and a great deal else. SafeForge manages the part of that ecosystem most teams find hardest: the hazard log, the bow-tie analysis, the control-requirement traceability, and the change history that supports the rest. Done well, a SafeForge project becomes the structured evidence base your safety case argument cites — not the safety case itself.

With that in mind, SafeForge starts from a different position from the typical hazard log tool: a proper data model with five first-class entities, the bow-tie diagram as the unifying view, and an editing experience designed so that doing the right thing is easier than doing the wrong thing.

The five entities

Concept	SafeForge Term	What it represents
What can go wrong	Hazard	A condition or situation with the potential to cause harm
What causes it	Cause (threat)	A mechanism, failure, or condition that can realise the hazard
What happens if it occurs	Outcome — a field on the hazard, drawn as its consequences on the bow-tie; not a separate entity	The adverse result if the hazard is realised without adequate control
What prevents or limits it	Control (Barrier)	A preventative or mitigative measure
What we are taking as given	Assumption	A claim, dependency, or constraint the hazard analysis rests on
What we are committing to	Requirement	A verifiable statement derived from a control or hazard

Every entity has a stable ID (HZD-001, CTRL-P-014, THR-022, ADC-003, REQ-017 — causes keep the bow-tie’s threat prefix; assumptions use ADC, for assumption, dependency or constraint), a defined attribute set, and its own table in the database. Nothing is shoved into a generic “risk” row.

The entity model

Here is how the entities relate. The relationships are explicit, not implied by comma-separated columns:

Five entities, five relationships, each a real many-to-many link in the database. A control can apply to many hazards. A hazard can be supported by many assumptions. A requirement can implement many controls. None of this is comma-separated. None of it lives in someone’s head.

The bow-tie as the unifying view

When you open a hazard in SafeForge, you don’t see a row. You see a bow-tie:

Every box is clickable. Click a control to open it and see every hazard it protects. Click a cause to open its record. The bow-tie isn’t a report rendered after the fact — it’s the live structure of your data, on screen, while you edit.

This structure is endorsed across every safety-critical industry SafeForge serves. CCPS / Energy Institute Bow Ties in Risk Management (2018) is the process industry reference text. DEF STAN 00-56 Issue 7 (2017) is the UK MoD’s safety standard for defence systems. EN 50126-1:2017 governs rail RAMS. SAE ARP 4761A is the aviation system safety assessment process. IEC 61508-1:2010 covers functional safety of electrical, electronic, and programmable systems. ISO 31000:2018 sets the generic risk management framework. The bow-tie is the connective tissue between these standards — and SafeForge keeps it visible at every step.

Dual risk assessment, by default

For every hazard, SafeForge captures initial risk (severity × likelihood before controls — the inherent risk) and residual risk (severity × likelihood after controls — the controlled risk). The delta is the engineered value of your control set.

If your initial risk and residual risk are the same, your controls are doing nothing. If your residual risk is lower but still above your tolerance threshold, you need more controls. This pair of numbers, on every hazard, is the single most important conversation between you and your safety reviewer — and SafeForge makes it the default rather than an afterthought.

Severity, likelihood and risk levels are configurable per project, and a control can carry the integrity level your framework uses — SIL by default, DAL or your own scale by configuration. What SafeForge never does is make the tolerability judgement for you: whether residual risk has been reduced far enough is the duty-holder’s call, and the AI is built so it cannot assert it.

Control characterisation that actually means something

A control in SafeForge is not just a name. It carries:

• Category — preventative or mitigative (which side of the bow-tie)
• Type — elimination, engineering, isolation, administrative, PPE, detection, monitoring (the hierarchy of controls)
• Assurance type — requirement, procedure, direct evidence
• Status — draft, adopted, implemented, verified, rejected, transferred, cancelled
• Criticality and integrity — critical, important or supporting, and an integrity level (SIL by default; configure DAL or your own scale)
• Verification — carried on the requirement that implements the control: method, status, evidence (how we know it works)
• Traceability — linked hazards, linked causes, linked requirements

Every one of those lists is a project setting. Administrators can rename fields, hide the ones a project does not use, and set their own allowed values, so the defaults above are a starting point, not a constraint.

This depth matters because a control’s role in your hazard analysis — and the safety argument that builds on it — depends on all of it. An “administrative control, status Draft, with no requirement behind it” is a very different animal from an “engineering control at SIL 2, status Verified, its requirement verified by FAT 2024-11” — even if both are spelled “Interlock on door” in the summary column.

The Hazards 28 paper warned that bow-ties with no rule set for barriers give operations and management “a false sense of security.” SafeForge’s structured control attributes make that mistake harder.

Many-to-many by design

The relationships in the SafeForge model are real many-to-many links, not comma-separated columns:

• A control can apply to many hazards; a hazard can have many controls
• A control can address many causes; a cause can be addressed by many controls
• A cause can realise multiple hazards; a hazard can have multiple causes
• A control can be implemented by multiple requirements; a requirement can implement multiple controls
• An assumption can apply to multiple hazards; a hazard can depend on multiple assumptions

This sounds pedantic until you hit the first case where it matters. A single “fire detection system” control might address “uncontrolled fire spread” across five different hazards in five different project phases. A requirement like “the train shall have a deadman’s handle” might implement four different controls against three different hazards. Flat hazard logs force you to duplicate the entity (with drift) or flatten the reality (with loss). SafeForge’s junction tables let you describe the relationships accurately.

Hazard hierarchy: structuring analysis at the right level

A real safety analysis produces hazards at multiple levels of abstraction. “Loss of train separation” is a useful description of what can go wrong, but it’s not the level at which an engineer designs controls. Underneath it sit the specific scenarios — “Loss of separation on shared track”, “Loss of separation at level crossings”, “Loss of separation during shunting movements” — each with different causes, different controls, and different residual risk profiles.

This hierarchical structure isn’t a SafeForge invention. It’s how every major safety analysis methodology works. SAE ARP 4761A in aviation moves through the Functional Hazard Assessment (FHA) at the aircraft level, the Preliminary System Safety Assessment (PSSA) at the system level, and the System Safety Assessment (SSA) at the item level — each a refinement of the level above. DEF STAN 00-56 structures hazard analysis at system, subsystem, and item levels. IEC 61508 identifies hazards at the function level and refines to the implementation. EN 50126 defines a top-down RAMS process that decomposes high-level hazards into specific failure modes.

The reason every methodology works this way is that flat hazard lists don’t survive contact with reality. A list of 500 atomic hazards with no structure becomes unnavigable: nobody can hold it in their head, similar hazards drift into duplicates, and the relationships between hazards at different abstraction levels disappear. Hierarchy lets the analysis match how engineers actually think — top-down decomposition, with each level analysed at the granularity appropriate to it.

In SafeForge, hazards are first-class entities with parent-child relationships. Each level carries its own causes, controls and assessment, and the bow-tie at each level shows what’s relevant there; a Key Risk’s showcase then draws the picture together from the hazards it traces. You can manage “Loss of train separation” as a top-level concept while still drilling down to the specific scenarios when you need to.

This also makes it possible to manage assumptions sensibly. The Assumption entity is SafeForge’s catch-all for what your hazard analysis rests on but does not prove — operating context assumptions, dependencies on other systems, constraints that bound the analysis. Assumptions link to hazards, have owners, validation evidence, and a status (open, validated, invalidated, superseded, closed). An assumption made at a parent-hazard level can be inherited or refined at the child level. Every assumption lists the hazards it supports, so when one is invalidated you can see at once where to re-check — at whatever level the assumption applied.

Risk Showcase: highlighting what stakeholders need to see

Hierarchy gives you a navigable tree of hazards. The Risk Showcase sits on top of that tree and answers a different question: of all the hazards in our project, which are the most consequential, and how are we managing them?

Not every hazard deserves the same depth of stakeholder-facing analysis. Out of a hazard log of several hundred entries, a small subset — typically the catastrophic-consequence ones — warrants disproportionate effort and visibility. This isn’t a SafeForge opinion; it is the regulatory consensus.

The HSE’s Guidance on ALARP Decisions in COMAH puts the principle in proportionality language:

“The depth of the analysis in the operator’s risk assessment should be proportionate to the scale and nature of the major accident hazards (MAHs) presented by the establishment. The nearer the risk is to the intolerable / uncomfortably high boundary, the greater the depth of analysis which is needed.” — HSE SPC/Permissioning/37 (archived HSE guidance, since withdrawn)

The CCPS / Energy Institute’s Bow Ties in Risk Management (2018) is equally clear about avoiding the opposite failure mode — applying full bow-tie analysis indiscriminately. Charles Cowley’s summary at the Safety 30 conference:

“Including everything connected with the top event does not help the understanding of barriers or risk management — example from a drilling contractor: 20 prevention and 32 mitigation barriers! All these are probably important, but most will be degradation controls supporting a small number of actual barriers.” — Charles Cowley, Safety 30 Conference, 2018

In aviation, SAE ARP 4761A mandates fault-tree analysis for every system function classified Hazardous or Catastrophic. In defence, MIL-STD-882E requires Catastrophic risks be eliminated or controlled to an acceptable level. In rail, EN 50126 structures the RAMS process around major-consequence events. The pattern across industries is consistent: identify the top hazards, treat them with proportionate depth, and present them in a way stakeholders can engage with.

How SafeForge supports this

SafeForge’s Risk Showcase is the stakeholder-facing surface for the project’s Key Risks — its top-level hazards. From the full hazard log you create a small set of Key Risks (typically the catastrophic-consequence ones, often parent hazards from the hierarchy), each tracing the hazards it draws together. Each Key Risk gets its own showcase page, designed not for the engineer’s working session but for the safety review board, the regulator, or the project director who needs to understand and challenge how this risk is being managed.

Each Key Risk page contains:

• A dedicated bow-tie diagram with the relevant causes, consequences, and preventative / mitigative controls drawn from the underlying hazard data
• A Risk Summary documenting the as-is risk position in narrative form, with an International Incidents note comparing to known precedent in your industry
• A Practice tab: the good international practice controls and standards this hazard class is usually managed against — a comparison, never a statement of compliance
• A readiness figure — how much of the work the project asked for has been done (child hazards managed, controls settled, verification links in place, change requests open) — and a Baselines tab, where a Project Baseline freezes every published Key Risk when you cut a report

These pages sit on top of the registers, not in place of them. Every entity referenced is still navigable back to the underlying log. The showcase is the deliverable; the registers are the truth.

What the AI does for a Key Risk

There are no AI buttons on the page. You ask the SafeForge agent — in the app’s agent tab, or from your own assistant over the SafeForge connection — and it can:

• Pre-populate the bow-tie by drawing causes from the project’s cause register, surfacing typical consequence patterns for the hazard category, and ranking the project’s controls by relevance
• Draft the Risk Summary from the hazard’s controls and risk ratings, giving the engineer a starting point to edit and confirm
• Compare the controls with good international practice for the hazard class — always marked as a comparison, never a statement of compliance
• Report readiness for the Key Risk, and tell you what changed since a cursor or a baseline — a control whose linked requirements have been modified, an assumption that has been invalidated, a hazard whose preventative coverage has weakened

The same Confirmation Pattern applies that governs every other piece of AI assistance in SafeForge. Everything the agent writes lands unconfirmed; the read-only stakeholder view shows only what a person has confirmed, and a Project Baseline freezes the published Key Risks so a report can cite a fixed position. You don’t ship AI-drafted analysis as your own. You ship analysis you have read, edited, and approved.

The Risk Showcase is what you take to a project board, a regulator, or a safety review group when you need to communicate how your most consequential hazards are being managed. It’s the artefact that translates the rigour of your full hazard log into a form a non-specialist can read and challenge.

Change requests focused on what matters, without locking out fixes

A common failure mode of “structured” safety tools is that they make routine corrections impossibly slow. Fixing a typo or updating a stale owner kicks off a multi-stage approval. People learn to avoid the system rather than fight it.

SafeForge takes a different position. The Change Request workflow is mandatory for the things that matter — risk levels, control linkages, status transitions, control category, severity / likelihood — and lightweight everywhere else. Editing a description, adding a remark, fixing a typo, updating an owner: these flow through the same CR but they don’t trigger heavyweight review. On Team projects a second person must approve substantive change; a Solo project self-approves through the same change request. Either way, the audit trail records everything.

The point is that the data model lets the right level of scrutiny attach to the right field. Not every cell needs reviewer approval, but the cells that affect your safety claim do.

A best-practice template, by default

When you start a SafeForge project you don’t get a blank slate. You get the SafeForge canonical model: five entities, the bow-tie view, dual risk assessment, structured control characterisation, configurable severity / likelihood / risk frameworks, and dropdown lists pre-populated with the categories that match your industry standard.

Your project still belongs to you. You can customise field names, add custom fields, hide fields you don’t use, set allowed values, write tooltips. But the starting state is the structure your hazard log will eventually need to feed into your wider safety case. You don’t have to assemble it from first principles every time you start a new project.

In the app

User guide: seeing the model in practice

Here is what the data model looks like inside SafeForge.

The point

Why this matters

The SafeForge data model is opinionated. Five entities instead of one generic “risk” table. Junction tables instead of comma-separated ID columns. Bow-tie structure instead of a single-list hazard log. The bow-tie view alongside the registers, not buried in a separate report. Each of those choices increases the short-term complexity of the tool. They pay back in:

• Traceability — you can always answer “why does this control exist?” and “which hazards does this requirement cover?”
• Auditability — the data model follows the structure the major standards describe
• Safety case quality — the structure makes “barriers that exist only on paper” harder to ship
• AI assistance quality — our AI works with structured data, not free text, so suggestions are grounded
• Export quality — the same model renders as an Excel database, a structured hazard log report, or a governed agent connection for the broader safety case, without loss

The Nimrod report quoted Lord Cullen on safety cases being “an aid to thinking about risk, not an end in themselves.” That framing applies equally to hazard logs. SafeForge’s data model is built to make your hazard log an aid to thinking — not an end in itself, and not a thing to fix the night before a regulator review.

Further Reading

• CCPS / Energy Institute — Bow Ties in Risk Management (2018) — The foundational text on bow-tie analysis for process safety.
• IChemE Hazards 28 Paper 31 — Bow Ties in Risk Management using the new CCPS-EI book (2018) — On the deficiencies of loose bow-tie practice and the need for quality criteria for barriers.
• IChemE Hazards 29 Poster 01 — Writing ‘usable’ NPP Safety Cases using Bowtie Methodology (2019) — Why complex safety cases end up “gathering dust on a shelf.”
• DEF STAN 00-56 Issue 7 — UK MoD safety management requirements for defence programmes (MOD Defence Gateway login required) — Defence Standard 00-56 governing safety management.
• EN 50126-1:2017 — Railway applications. The RAMS process — European standard for rail reliability, availability, maintainability, and safety.
• SAE ARP 4761A — Guidelines and methods for civil airborne system safety assessment — Aviation system safety assessment process.
• IEC 61508-1:2010 — Functional safety of electrical, electronic and programmable safety-related systems — Cross-industry functional safety standard.
• ISO 31000:2018 — Risk management guidelines — Generic risk management framework.
• ASEMS Online — UK MoD Acquisition Safety and Environmental Management System, hazard-log toolkit — Official MoD guidance on hazard log structure and maintenance.
• The Nimrod Review — Charles Haddon-Cave QC (HC 1025, 2009) — The full report into the loss of XV230. Required reading on what happens when safety cases become paperwork.
• Risktec — The Folly of ‘Paper Safety’ — Useful summary of Haddon-Cave’s findings and the SHAPED safety case principles.
• ITQlick — Rational DOORS Pricing — Third-party pricing estimates for Rational DOORS; figures vary between their pages, so treat them as indicative.
• PeerSpot — IBM Rational DOORS reviews — Verified user reviews from senior practitioners across rail, defence, and aerospace.
• Jama Software — What Is IBM DOORS Software? — Competitor’s framing of why DXL-heavy environments consume engineering time.
• Lord Cullen — Ladbroke Grove Rail Inquiry Report (2001) — Source of “an aid to thinking about risk, not an end in themselves.”

Key risk (top-level hazard) management

• HSE — Reducing Risks, Protecting People (R2P2) (2001, archived copy) — The canonical UK risk-tolerability framework. Sets the tolerability triangle and gross-disproportion principle.
• HSE Assessment Principles for Offshore Safety Cases (APOSC) (2006; copy hosted by the US Chemical Safety Board) — 39 principles HSE uses to assess offshore safety cases. Principles 4, 5, and 10 are essential reading on top hazard management.
• HSE — Guidance on ALARP Decisions in COMAH (SPC/Permissioning/37, archived; since withdrawn) — On proportionate analytical depth for major accident hazards.
• Charles Cowley — Bow Ties in Risk Management (Safety 30 Conference, 2018) — Practitioner perspective on selecting which hazards warrant the full bow-tie treatment.
• Lord Cullen — Piper Alpha public inquiry report (1990) — The 106 recommendations that drove the modern safety case regime, including the requirement to identify and manage Major Accident Hazards.
• Step Change in Safety — Major Accident Hazard Understanding workgroup — UK upstream oil & gas industry resources on identifying and managing major hazards.

SafeForge’s AI can make mistakes. It is a supplement to the engineer’s decision, never a substitute for it, and the six principles of the SafeForge AI Dogma are what keep it that way: its findings inform judgement, they are never a legal or regulatory verdict, and every determination remains the duty-holder’s.

---

SafeForge is an intelligent risk management platform built on this data model. If you’d like to see it in action, view pricing, download the generic hazard log template and open it in Excel — the structure you see is exactly the structure inside SafeForge — or see how a risk workshop lands in the log.