Safety-Critical Rust

Summary

Make Rust viable for certified safety-critical systems by delivering coverage, specification, linting, and unsafe documentation foundations.

Motivation

The status quo

Engineers building software under functional safety standards need auditable evidence and predictable tooling. The major standards families include:

This includes OEMs, suppliers, integrators, and toolchain vendors. Safety cases must reference a specification for the language being used, and the toolchain must produce evidence that assessors accept.

What these teams need most:

• Coverage tooling. MC/DC reports that assessors accept.
• A specification that tracks stable releases. So safety cases can reference current language features via the FLS.
• Continued progress on unsafe documentation. The Reference, Rustonomicon, and standard library docs have improved substantially over the years, but gaps remain for common patterns.
• Stable foundations. Product lifetimes of 10-20 years require confidence in toolchain support and MSRV conventions.

Teams at SIL 2 and ASIL B are shipping Rust today. These deliverables reduce the workarounds they need and create a path to higher integrity levels.

What we are shooting for

We are building a capability ladder that unlocks Rust at increasing safety-integrity levels. The 2026 focus is the foundation, while keeping a clear path to higher tiers.

• Foundation (ASIL A/B, SIL 1/2, DO-178C Level C). Stable branch/DC coverage baselines and predictable FLS releases, plus initial safety-critical linting to enforce Safety-Critical Rust Consortium coding standards.
• Intermediate (ASIL C, SIL 3, DO-178C Level B). Normative unsafe pattern documentation and expanded lint coverage, with coordination for mixed-language interop and async runtime patterns.
• Highest integrity (ASIL D, SIL 4, DO-178C Level A). MC/DC coverage in rustc and formal-methods coordination toward contracts, semantics documentation, and verified tooling.

Key use cases

• Certification evidence: Generate coverage and spec references that auditors accept.
• Qualified toolchains: Tool vendors can qualify rustc/Clippy with predictable releases and lint sets.
• Mixed-language systems: Integrate Rust into C and C++ stacks with well-defined unsafe contracts.
• Long-lived products: Maintain 10-20 year systems with stable MSRV and documentation baselines.

Design axioms

• Evidence first. Prioritize deliverables that produce audit-ready evidence.
• Use standard tooling. Improve rustc, Clippy, and core docs rather than forks.
• Ship a ladder. Foundations first, with an explicit path to higher integrity levels.
• Document safety contracts. unsafe patterns must have normative, citable guidance.

2026 goals

Frequently asked questions

How do these goals relate to each other?

They form a coherent evidence chain: FLS releases provide a citable specification, unsafe documentation defines safety contracts, Clippy lints enforce coding guidelines, and MC/DC coverage produces the evidence required at the highest integrity levels.

Does this certify Rust for safety-critical use?

No. Certification is per product and toolchain. These goals deliver the foundations that make qualification and certification feasible without bespoke tooling.

Why focus on foundations in 2026?

Teams at lower integrity levels are already shipping Rust and need practical improvements now. The foundation work also makes the higher-integrity goals achievable later.