DetermineASIL's Controllability table has a nonexistent 4th column (C0), systematically over-rating ASIL by one band #88

Location: hara/hara.go, DetermineASIL (around line 242) — the table map keyed on {Severity, Exposure, Controllability}.

Finding: The real ISO 26262-3:2018 Table 4 ASIL determination table has three Controllability columns: C1, C2, C3. DetermineASIL here has four: C0, C1, C2, C3 — with C0 mapped to QM/low ratings and the genuine C1/C2/C3 values shifted up to fill C1/C2/C3, C2/C3/C4-shaped slots. In effect, every hazard whose real Controllability is C1 gets looked up as if it were one column further right than the standard actually places it, systematically over-rating by one ASIL band (confirmed against the primary standard text, not a reconstruction):

This was discovered downstream: an independent audit of SoundMatt/c-RCP flagged its HARA.md as over-rating all 11 hazards by one band. A fix attempt used cfusa hara asil (c-FuSa) to "re-verify" and concluded the ratings were already correct — but c-FuSa's own CHANGELOG (v0.5.29) documents that it deliberately extended its table from 3 columns to 4 "to match go-FuSa's DetermineASIL". A second, independent verification pass fetched the actual ISO 26262-3:2018 Table 4 text and confirmed the original over-rating claim was right, and the tooling both projects rely on is the actual source of the drift. Since every x-Net repo's HARA process ultimately runs through *-FuSa tooling, this likely causes the same one-band-high mis-rating anywhere DetermineASIL (or a port of it) is used — c-FuSa is confirmed affected; other *-FuSa ports weren't checked in this pass but should be, since c-FuSa's CHANGELOG suggests they may share the same table by convention.

Recommendation: Drop the C0 column from the Controllability axis (or, if C0 is being used to represent "not controllable at all" as a distinct real-world case, give it its own explicit pre-table QM shortcut the way S0/E0 already get one, rather than folding it into the indexed table and shifting every other column). Add a regression test asserting DetermineASIL output against a handful of textbook Table 4 values (e.g. the ones above) so this can't silently drift again. Once fixed, re-propagate to c-FuSa and any other *-FuSa port that copied the same table, and flag every repo whose HARA was generated/verified against the old table for re-review — SoundMatt/c-RCP#125 is the confirmed instance so far.