diff --git a/bazel/rules/rules_score/docs/user_guide/dependability_analysis.md b/bazel/rules/rules_score/docs/user_guide/dependability_analysis.md
index e7a364c5..6241f22a 100644
--- a/bazel/rules/rules_score/docs/user_guide/dependability_analysis.md
+++ b/bazel/rules/rules_score/docs/user_guide/dependability_analysis.md
@@ -13,7 +13,31 @@
 
 # Dependability Analysis
 
-The `dependability_analysis` rule is the top-level safety artifact in `rules_score`. It summarizes the dependability analyses (Safety / Security) which were performed for the dependable element.
+The `dependability_analysis` rule  summarizes the all the dependability analyses (Safety / Security) for a dependable element. A single element may have multiple dependability analyses.
+
+## Overview
+
+### Why safety analysis?
+
+Safety analysis is required to systematically identify failures that could violate safety goals and to demonstrate that appropriate countermeasures are in place. In ISO 26262 terms it provides the evidence that residual risk is acceptable.
+
+### How FMEA works
+
+A Failure Mode and Effects Analysis (FMEA) follows three steps for each public interface of the software module:
+
+1. **Identify failure modes** — apply structured fault models (see below) to each public interface to derive what can cause a violation of a overarching safety goal.
+2. **Analyse effects and causes** — document the effect on the system and decompose to root causes using a Fault Tree Analysis (FTA).
+3. **Define countermeasures** — for every root cause specify a `ControlMeasure` (or `PreventiveMeasure` / `Mitigation`) and trace it back through the FTA to the failure mode.
+
+### Fault models
+
+The failure modes to consider are defined by the SCORE process:
+
+> [FMEA Fault Models — Process Description](https://eclipse-score.github.io/process_description/main/process_areas/safety_analysis/guidance/fault_models_guideline.html#id1)
+
+The fault models cover three categories: **messages** (send/receive behaviour), **time constraints** (too early / too late), and **execution** (wrong result, loss, delay, corruption, non-determinism). The `GuideWord` enum in the `ScoreReq` model maps each category to a structured label used in the `FailureMode` records.
+
+The description below covers the FMEA-based **safety** analysis for a software module.
 
 ## Bazel Rule `dependability_analysis`
 
diff --git a/bazel/rules/rules_score/trlc/config/score_requirements_model.rsl b/bazel/rules/rules_score/trlc/config/score_requirements_model.rsl
index d1186214..2c554777 100644
--- a/bazel/rules/rules_score/trlc/config/score_requirements_model.rsl
+++ b/bazel/rules/rules_score/trlc/config/score_requirements_model.rsl
@@ -93,15 +93,56 @@ tuple CompReqId {
 // Safety Analyses
 ///////////////////////////////
 
-enum GuideWord "HAZOP-style guide words used to categorise the nature of a failure mode." {
-    TooEarly           "The function or signal occurs earlier than expected."
-    TooLate            "The function or signal occurs later than expected."
-    Wrong              "The function produces an incorrect value or signal."
+enum GuideWord "HAZOP-style guide words used to categorize failure mode." {
+
+    // -------------------------------------------------------------------------
+    // Message fault models  (MF_01_xx)
+    // -------------------------------------------------------------------------
+
+    // MF_01_01: message is not received
+    // MF_01_06: message is not sent
+    // EX_01_04: loss of execution [shared with Execution]
     LossOfFunction     "The function is completely absent when it should be active."
+
+    // MF_01_04: message not received correctly by all recipients
+    // EX_01_06: processing not complete (infinite loop)   [shared with Execution]
     PartialFunction    "The function is active but only partially fulfils its purpose."
+
+    // MF_01_05: message is corrupted
+    Corrupted          "Data or message content is incorrect due to corruption during transmission or storage, distinct from a functional logic error."
+
+    // MF_01_07: message is unintended sent
     UnintendedFunction "The function is active when it should not be."
-    ExceedingFunction  "The function operates beyond its specified bounds."
+
+    // -------------------------------------------------------------------------
+    // Time constraint fault models  (CO_01_xx)
+    // Note: TooEarly / TooLate also apply to message timing (MF_01_02, MF_01_03)
+    // -------------------------------------------------------------------------
+
+    // CO_01_01: minimum constraint boundary is violated
+    // MF_01_03: message received too early
+    TooEarly           "The function or signal occurs earlier than expected."
+
+    // CO_01_02: maximum constraint boundary is violated
+    // MF_01_02: message received too late
+    TooLate            "The function or signal occurs later than expected."
+
+    // -------------------------------------------------------------------------
+    // Execution fault models  (EX_01_xx)
+    // -------------------------------------------------------------------------
+
+    // EX_01_01: process calculates wrong result(s)
+    Wrong              "The function produces an incorrect value or signal due to a logic error."
+
+    // EX_01_02: processing too slow
     DelayedFunction    "The function is active but with an unacceptable delay."
+
+    // EX_01_03: processing too fast
+    ExceedingFunction  "The function operates beyond its specified bounds."
+
+    // EX_01_05: processing changes to arbitrary process
+    ArbitraryExecution "Processing deviates from its specified behaviour and executes in an unpredictable or non-deterministic manner."
+
 }
 
 type FailureMode "A potential failure of a system function, described using a HAZOP guide word." extends ScoreReq.RequirementSafety {