# Safety Classification

> Software Safety Classification and Architectural Impact

- Skill: `aminalam/safety-classification` (Agent Skill)
- Install (CLI): `npx skillmds@latest add aminalam/safety-classification`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aminalam/safety-classification/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: AminAlam (https://skillmd.com/u/aminalam)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/aminalam/safety-classification

---


# Software Safety Classification and Architectural Impact

## Purpose
Define how IEC 62304:2006+A1:2015 safety classification (Class A/B/C per 4.3) influences architecture, segregation, documentation, and testing—ensuring activity rigor scales with harm severity and software items are decomposed with defensible class assignments.

## When to Apply
- Early architecture and system hazard analysis.
- Decomposing a software system into items or units.
- Changes that alter hazard exposure, control placement, interfaces, or SOUP on safety paths.
- Problem investigations that suggest misclassification (see `DOC-PROBLEM-RES`).

## Requirements (testable)
1. Classification Flow [Class A, B, C]: Assign class from whether software can contribute to a hazardous situation and resulting harm severity after considering risk controls **outside** the software item only (hardware, independent software, procedures, etc.). Rationale: 4.3 a (interpretation).
2. Failure Assumption [Class A, B, C]: Treat software failure as possible when analysing contribution to hazardous situations; do not rely on probability of software failure to reduce class at assignment time. Rationale: 4.3 note (interpretation).
3. Class A [Class A]: Class A when software cannot contribute to a hazardous situation, or contribution does not yield unacceptable risk after external controls. Rationale: 4.3 a.
4. Class B [Class B]: Class B when contribution can yield unacceptable risk with serious injury not expected (non–serious injury harm). Rationale: 4.3 a.
5. Class C [Class C]: Class C when contribution can yield death or serious injury. Rationale: 4.3 a.
6. Re-classification [Class A, B, C]: Additional external controls may be added and class reassigned with documented rationale. Rationale: 4.3 a (second paragraph).
7. Risk File Record [Class A, B, C]: Document assigned class for each software system in the risk management file. Rationale: 4.3 c.
8. Decomposition [Class A, B, C]: Decomposed items inherit parent class unless documented rationale and segregation justify a different class. Rationale: 4.3 d–e.
9. Group Rule [Class A, B, C]: When applying processes to a group of items, use requirements of the highest class in the group unless lower class is justified in the risk file. Rationale: 4.3 f.
10. Default Class C [Class A, B, C]: Until class is assigned, apply Class C requirements. Rationale: 4.3 g.
11. Segregation [Class B, C]: Separate higher-class items from lower-class via process/memory/interface boundaries; Class C document segregation needed for risk control (5.3.5). Rationale: 4.3 d, 5.3.5.
12. Interface Contracts [Class B, C]: Validate interfaces between classes (bounds, timeouts, errors, integrity checks). Rationale: architectural risk control.
13. Evidence by Class [Class A, B, C]: Tailor architecture detail, design depth, and verification per Annex A class mapping (informative Table A.1); Class B/C architecture and integration; Class C detailed design and enhanced unit criteria. Rationale: 5.3–5.5.
14. Software Risk Controls [Class B, C]: Items implementing risk controls are classified based on the risk the control mitigates; develop per Clause 5. Rationale: 7.2.2. Skill: `REG-IEC62304-SWRM`.
15. Change Impact [Class A, B, C]: Reassess classification and segregation when functionality, interfaces, or hazards change. Rationale: 4.3, 6.2.2 (interpretation).

## Recommended Practices
- Maintain a per-item class table with justification, segregation method, and hazard links.
- Use MPU/MMU regions or process isolation for Class C vs non-safety code.
- Apply defensive serialization and checksum on inter-partition messages.
- Keep class-aware test depth (informative: MC/DC for Class C control logic where justified).
- Draw a decision diagram in the risk file (interpretation of 4.3 flow) without copying standard figures.

## Patterns
Class table (YAML):
```yaml
software_system: pump_firmware
system_class: Class C
rationale: HZ-07 serious injury if over-infusion; external clamp not sole mitigation
items:
  - name: pump_control
    class: Class C
    inherits: pump_firmware
    segregation: dedicated MPU region; no shared stack with ui_task
  - name: ui_task
    class: Class B
    rationale: segregated; failure cannot corrupt pump_control memory (DES-SEG-02)
```

Interface validation snippet:
```c
// CLASS C boundary; REQ-IF-01; TEST-IC-12
int handle_cmd(const cmd_t *cmd, size_t len) {
    if (len != sizeof(cmd_t)) return -1;
    if (!crc_ok(cmd, len)) return -2;
    return dispatch(cmd);
}
```

## Anti-Patterns (risks)
- Whole product labeled Class A without hazardous-situation analysis -> risk: under-verification.
- Using software reliability estimates to lower class at assignment -> risk: contradicts 4.3 failure assumption.
- Shared memory between Class C and utility code without protection -> risk: corruption.
- Decomposition to lower class without segregation evidence -> risk: audit challenge on 4.3 d.
- Risk-control software left at Class A -> risk: weak verification of mitigations (7.2.2).

## Verification Checklist
- [ ] System class documented in risk file with hazard linkage.
- [ ] Classification assumptions documented (external controls, failure treatment).
- [ ] Item-level classes documented; decomposition rationale where class differs.
- [ ] Group/process tailoring uses highest class unless risk-file exception.
- [ ] Until complete analysis, Class C controls applied.
- [ ] Segregation mechanisms implemented and reviewed for B/C (C: risk-control segregation).
- [ ] Interfaces across classes validated.
- [ ] Verification depth matches class; software risk controls classified per mitigated risk.
- [ ] Re-assessment performed after significant changes or problems.

## Traceability
- Link item class entries to hazards (`HZ-###`), controls (`RISK-CTRL-###`), and tests (`TEST-###`).
- Maintain class table under configuration control (`DOC-SCM`); reference in `DOC-DESIGN-DOCS`.

## References
- IEC 62304:2006+A1:2015, 4.3 (software safety classification).
- IEC 62304:2006+A1:2015, Annex A Table A.1 (informative class summary—clause IDs only).
- ISO 14971:2019 (`REG-ISO14971`).
- IEC TR 80002-1:2019 (informative).
- `REG-IEC62304-SWRM` (7.2.2 risk controls in software).

## Changelog
- 1.1.0 (2026-05-21): Aligned with 4.3 assignment rules, decomposition, default Class C, 7.2.2 control classification.
- 1.0.1 (2026-01-04): Audit correction - updated IEC TR 80002-1 to 2019 edition.
- 1.0.0 (2026-01-04): Initial skill covering class derivation, segregation, interfaces, and verification expectations.

## Audit History
- **2026-05-21**: IEC 62304 4.3 alignment pass.
- **2026-01-04**: Audit performed. IEC TR 80002-1:2009 updated to 2019 edition.