Resilient and IEC 62304 (Medical Device Software)

IEC 62304 governs the software lifecycle for medical devices. This page lists where Resilient features contribute evidence across software safety classes A, B, and C, and the gaps that remain the manufacturer’s responsibility.

Table of contents

Honest framing

Resilient is not IEC 62304 compliant and not a validated software tool under IEC 62304:2006/AMD 1:2015. No medical device has shipped on Resilient.

The mapping below is the realistic path for a team evaluating Resilient: the language contributes to specific clauses, but software validation under §5.1.4 / §8.1.1 must be performed before Resilient artifacts can be used as primary evidence on a regulated device.

Clauses Resilient contributes to

  • §5.5 (Software unit implementation and verification). Contract-driven verification at the unit level — requires / ensures discharged by Z3 — provides primary evidence of unit-level property satisfaction.

  • §5.6 (Software integration and integration testing). Contracts that cannot be discharged at compile time become typed runtime asserts that act as oracles during integration testing.

  • §5.7 (Software system testing). Re-verifiable SMT-LIB2 certificates from --emit-certificate provide artifacts the manufacturer can re-execute under their own Z3 to confirm property satisfaction.

  • §7 (Software risk management). The language’s no-unsafe discipline, static-only heap, and bounds-checked indexing eliminate whole hazard classes by construction — reducing the risk-management burden for memory-corruption hazards.

  • §8 (Software configuration management). Per-cert sha256 hashes in manifest.json and the Ed25519 cert.sig give tamper-evidence on verification artifacts.

Class-specific notes

  • Class A (no injury or damage to health possible). Resilient’s compile-time checks already exceed what Class A requires.

  • Class B (non-serious injury possible). Contract-driven verification provides strong evidence for hazard mitigation in the unit-level subset that the verifier discharges.

  • Class C (death or serious injury possible). Software validation under §5.1.4 is mandatory. Resilient artifacts are supplementary evidence until validation is performed by the manufacturer.

Gaps the manufacturer still owns

  • Software validation per §5.1.4. Not started — the manufacturer must validate the toolchain in their environment.
  • Risk analysis (ISO 14971). Unaffected by language choice.
  • Software-of-Unknown-Provenance (SOUP) classification of the Resilient compiler. As an open-source tool without a validation history, the compiler itself is SOUP and must be evaluated per §5.3.3 / §8.1.2.
  • Post-market surveillance. Standard, unchanged.

See also