# IEC 62304 Software Lifecycle Documentation Mapping

## Scope

**MADDENING is not subject to IEC 62304.** It is an open-source research tool, not a medical device, and it is not developed under a medical device QMS. This mapping is provided voluntarily to support downstream SOUP assessment.

## Mapping

| IEC 62304 Phase | Clause | What the Standard Requires | What MADDENING Provides | Gaps |
|---|---|---|---|---|
| **Software development planning** | 5.1 | Development plan, standards, tools, configuration management plan | `DESIGN.md`, `ROADMAP.md`, `CONTRIBUTING.md`, Git + GitHub CI | No formal development plan in IEC 62304 format. Not required — MADDENING is not subject to IEC 62304. |
| **Software requirements analysis** | 5.2 | Documented software requirements | `DESIGN.md` Sections 1-5, module READMEs, test suite | Requirements documented but not in formal specification with IDs and traceability. |
| **Software architectural design** | 5.3 | Software architecture document, SOUP identification, segregation analysis | `DESIGN.md`, graph-based architecture, functional purity. See Clause 5.3.5 below. | Architecture well-documented. |
| **↳ Segregation analysis** (Class C) | 5.3.5 | Demonstrate failure isolation or detection | **Data-flow layer**: functional purity (pure functions, no shared mutable state, explicit data flow). **Execution layer (XLA Shadow)**: XLA compiler bugs, GPU hardware faults cannot be detected by MADDENING's architecture. Manufacturer must implement execution-layer defences via HealthCheck infrastructure. **Algorithmic Diversity**: mandatory for Class C — HealthCheck monitors must use different numerical primitives than monitored physics nodes. | MADDENING provides data-flow segregation evidence; manufacturer provides execution-layer segregation evidence. |
| **Software detailed design** | 5.4 | Detailed design for each software unit | Per-node algorithm documentation in `docs/algorithm_guide/`, `NodeMeta` metadata, Implementation Mapping tables | Coverage grows as algorithm guides are populated. |
| **Software unit implementation** | 5.5 | Implement per detailed design, coding standards | Source code in `src/maddening/`, NumPy-style docstrings | Formal coding standard planned. |
| **Software unit verification** | 5.6 | Verify each unit against design and requirements | `tests/` with 500+ tests, registered verification benchmarks in `tests/verification/` | Good coverage. Registered benchmarks formalize verification. |
| **Software integration and integration testing** | 5.7 | Integration testing | Integration tests in `tests/core/test_integration.py`, graph-level tests | Present. Graph architecture naturally exercises integration. |
| **Software system testing** | 5.8 | System-level testing against requirements | End-to-end example scripts, surrogate training + validation pipeline tests. **Manufacturer recommendation**: include cross-backend numerical agreement tests (CPU vs GPU). | No formal system test plan. Cross-backend testing is manufacturer obligation. |
| **Software release** | 5.9 | Release documentation, known anomalies, verification summary | `CHANGELOG.md`, tagged releases, `known_anomalies.yaml`, SOUP package document | Well-covered once SOUP package is complete. |