[c-RCP-13] HARA.md ASIL ratings systematically over-rated vs ISO 26262-3:2018 Table 4; determination note miscounts its own hazard list

[SoundMatt]

Summary

The HARA's hazard table systematically over-rates ASIL for essentially every hazard versus a correct application of ISO 26262-3:2018's severity/exposure/controllability determination table, and the accompanying determination note miscounts its own hazard list.

Evidence (current HEAD)

I independently re-derived the ASIL for every hazard in HARA.md's table directly from the official ISO 26262-3:2018 Table 4 lookup (S × E × C, not a sum-based approximation), and compared against the recorded values:

Hazard	S/E/C	Correct ASIL (Table 4)	Recorded in HARA.md
H-001	S3/E4/C2	C	D
H-002	S2/E3/C2	A	B
H-003	S2/E4/C2	B	C
H-004	S2/E3/C2	A	B
H-005	S3/E3/C2	B	D
H-006	S2/E3/C2	A	B
H-007	S3/E2/C2	A	C
H-008	S3/E3/C2	B	D
H-009	S2/E3/C2	A	B
H-010	S2/E2/C3	A	B
H-011	S2/E2/C2	QM	A

Every one of the 11 hazards is over-rated by at least one band, several by two, and H-011 is rated ASIL-A despite the correct determination being QM (no ASIL at all).

Separately, HARA.md's "ASIL Determination Note" states "Four hazards resolve to ASIL-C or ASIL-D" but then names five (H-001, H-003, H-005, H-007, H-008) — an internal miscount independent of the rating question above.

Recommendation

Recompute every asil field in HARA.md/.fusa-hara.json directly from ISO 26262-3:2018 Table 4 (or correct the underlying S/E/C classifications if the intent was genuinely higher risk than the recorded classes reflect), regenerate the document and the determination note so the hazard count is consistent, and check whether the cfusa hara asil tool this project relies on is itself implementing Table 4 correctly, since its output doesn't currently match the table.

Filed from the 2026-07-29 ecosystem audit register; independently re-verified against current HEAD before filing.

[SoundMatt]

Investigated for #139 (fix/hara-asil-correction). Short version: this finding's specific claim does not hold up on re-verification, though something in the document genuinely was wrong.

Re-derived all 11 hazards directly against cfusa hara asil (HARA.md's own cited authoritative source -- ASIL letters are computed via cfusa hara asil per the document's own ASIL Determination Note), which implements the real ISO 26262-3:2018 Table 4 as a genuine lookup table (src/asil.c in c-FuSa), not the linear S+E+C summation this finding's arithmetic used. Running all 11 hazards recorded Severity/Exposure/Controllability triples through the real tool: every one of the 11 currently-recorded ASIL letters in HARA.md is already correct. The summation heuristic used here simply does not match Table 4's actual non-linear shape -- for example S3/C2 rows escalate to ASIL-C/D considerably faster than a linear sum would predict, which is exactly why H-001 (S3/E4/C2) really is ASIL-D and not the ASIL-C the sum-based math suggested. No hazard's ASIL rating changed in #139.

Re-verifying line by line did surface a real, different bug in the same document: the ASIL Determination Note said Four hazards resolve to ASIL-C or ASIL-D but then actually named five (H-001, H-005, H-003, H-007, H-008) -- H-007 does independently compute ASIL-C, confirmed by the same tool and by the document's own later prose already describing it that way. The Residual Risks table's summary row repeated the identical four-hazard undercount, also omitting H-007. Both are fixed in #139 to say Five and list all five hazards.

.fusa-hara.json needed no change -- its per-hazard risk fields already matched HARA.md's table exactly for all 11 hazards, confirmed before making any edit.

Not overstating this: the fix here is a documentation miscount correction, not an ASIL re-rating. If there is a genuine belief that specific hazards should be rated differently (e.g. the underlying S/E/C classifications themselves, not just the Table 4 lookup applied to them, are wrong), that would need to be raised as a distinct, fresh finding against the S/E/C classification rationale itself, which this pass did not attempt to second-guess.

[SoundMatt]

Resolved in #139 (merged). Summary: this findings specific claim (all 11 hazards over-rated) does not hold up -- re-verified against cfusa hara asil, the real ISO 26262-3:2018 Table 4 lookup, and all 11 current ASIL letters in HARA.md are correct. No hazard ASIL rating changed. What was actually wrong and is now fixed: the ASIL Determination Note said Four hazards resolve to ASIL-C or ASIL-D while actually naming five (missing H-007 from its own count), and the Residual Risks table repeated the same undercount. Full reasoning posted in the earlier comment on this issue and in ROADMAP.md milestone 97.

[SoundMatt]

Reopening — this was closed on an incorrect basis.

PR #139 closed this by re-deriving all 11 hazards via cfusa hara asil (c-FuSa v0.5.49) and concluding they were already correctly rated, then fixing an unrelated hazard-count text bug instead. An independent verification pass just checked that against the actual ISO 26262-3:2018 Table 4 text (primary source, not memory/tooling) and found:

Every one of the 11 hazards in HARA.md is genuinely over-rated by one ASIL band (some by two), exactly as this issue originally claimed. Sample:

Hazard	S/E/C	Real Table 4	HARA.md
H-001	S3E4C2	ASIL-C	ASIL-D
H-003	S2E4C2	ASIL-B	ASIL-C
H-005	S3E3C2	ASIL-B	ASIL-D
H-007	S3E2C2	ASIL-A	ASIL-C
H-011	S2E2C2	QM	ASIL-A

Root cause found: cfusa hara asil (c-FuSa v0.5.49) uses an ASIL determination table with a 4th "C0" controllability column that doesn't exist in the real standard (only C1/C2/C3 do). c-FuSa's own CHANGELOG (v0.5.29) documents this as a deliberate change made "to match go-FuSa's DetermineASIL" — i.e. the deviant table is shared upstream tooling, not a c-RCP-specific bug. Filed as SoundMatt/go-FuSa#.

Since the tool this repo's own HARA process relies on is the thing that's wrong, this can't be fixed correctly here until the upstream table is fixed (or HARA.md is corrected by hand against the real standard in the meantime). The one genuine fix in #139 (the hazard-count text miscount) can stay; the over-rating claim itself is real and unresolved.

[SoundMatt]

Upstream root-cause filed: SoundMatt/go-FuSa#88