Rust certification in S-CORE: gap analysis and plan (September 2026)

[dcalavrezo-qorix]

Rust certification in S-CORE: gap analysis and plan (September 2026)

This is a proposal for review by the Rust community, the tooling community and the safety manager. It takes stock of what we still need before a Rust ASIL B module can pass a confirmation review, against ISO 26262:2018 and our own process. Sources: the S-CORE process and platform documents, project board #34 "Rust certification", the Ferrocene public qualification documents and the published work of the Safety-Critical Rust Consortium. Board and issue state as of 2026-09-14.

State legend: 🔴 gap (nothing usable exists) · 🟡 partial (started, not certifiable yet) · 🟢 done (in place, keep) · 🔵 external (depends on Ferrous, QNX or the consortium)

TL;DR

Rust was approved for ASIL B components in DR-001-Arch (March 2026) on the evidence that formatting, linting and a qualified compiler were in hand and that coverage, core library and coding guidelines were on their way. Six months on, the tooling has moved, but very little has been turned into the work products ISO 26262 and our process ask for.

Gaps in the register below	67 across 10 areas
Rust tools with a Tool Verification Report	2 of 10 (clippy, rustfmt; both TCL HIGH)
Rust coding guideline	a lint table, no rule set with IDs
Consortium coding guidelines	~23 draft rules, alpha, 5 of 19 spec chapters
Rust certification chapter in our docs	6 empty pages

The five blockers, in order:

1. A real Rust coding guideline with rule IDs, an ISO 26262-6 Table 1 and Table 6 mapping, an enforcement column and a deviation process. Today this is one open action item (#1208) from 2025. The consortium will not close this for us in 2026.
2. Tool Verification Reports for the Rust toolchain: Ferrocene rustc, the coverage tool, the Rust test harness, CodeQL for Rust, Miri. The tool list marks rules_rust and score_toolchains_rust as "not relevant", which is wrong.
3. A qualified target compiler that exists. Ferrocene for QNX 8 is in the unreleased 26.08.0. Our current pin is a rolling-channel commit, which is explicitly not qualified.
4. A decision on the standard library. The certified core subset is ASIL B, but alloc and std are uncertified and most of our Rust code uses std. The Ferrous offer decision DR-001 set for July 2026 has no open tracking item.
5. A branch-coverage story that survives a qualified toolchain. Stable rustc emits no branch data at all; -Zcoverage-options=branch is nightly-only. It works today only because the pin is rolling. The coverage tool documents this itself and is otherwise our best-documented Rust tool, but nothing in the platform documents references it yet.

Two findings that were not on anyone's list:

• The clippy TVR argues TCL HIGH because lints are "only a measure of quality", while the coding guideline and the implementation process name Clippy as the enforcement mechanism for Table 6 design principles. Both cannot stand.
• Upstream rustc removed all MC/DC support in August 2025 (rust-lang/rust#144999). Not required at ASIL B, but it should be written into the verification plan so it stops being raised as a blocker.

1. Baseline

What our process demands of Rust code

• ASIL B for everything safety-related, developed as SEooC. Proven-in-use is tailored out project-wide.
• TCL is binary: LOW when tool impact is YES and detection is NO. LOW means qualification, and the only permitted method is validation of the software tool.
• Unit verification: 100 % statement and 100 % branch coverage for safety code, zero Critical or High static-analysis findings, zero compiler warnings. No MC/DC at ASIL B.
• ASIL Rust units use the safe subset via #![forbid(unsafe_code)], edition 2021; host compiler "pick your own".
• A coding guideline is a required section of the Software Development Plan (ISO 26262-6 5.4.3, Table 1).

What Ferrocene gives us

• rustc plus rust-lld qualified TCL3, ISO 26262 ASIL D, IEC 61508, IEC 62304 Class C. Signed documents and the TÜV report are Enterprise-tier deliverables.
• A certified core subset at ASIL B, enforced by the ferrocene::unvalidated lint. alloc, std, test are uncertified.
• cargo, clippy, rustfmt, rustdoc, LLVM tools, criticalup and the self-test are explicitly not qualified.
• Qualified only for --edition 2021, -C opt-level=2, -C panic=abort, listed targets. QNX 8 targets land in 26.08.0, not yet released.
• About twenty RUSTC_CSTR_* / CORE_CSTR_* constraints the user must fulfil. These become assumptions of use for S-CORE.

What the consortium gives us

• Coding guidelines at release 0.1.25: ~23 real guidelines, all draft, covering 5 of 19 spec chapters. Nothing on unsafe, FFI, concurrency, errors or patterns.
• MISRA C:2025 Addendum 6 and CERT C applicability matrices; MISRA C++:2023 in progress. No ISO 26262 matrix inside the guidelines.
• An ISO 26262 Part 6 gap analysis on arewesafetycriticalyet.org (March 2026) rating Rust against Tables 1, 3, 6, 7, 9, 10, 12.
• A reviewed tools list, a desired-compiler-features list, and the 2026 Rust project goal to host safety-critical lints in Clippy. No tool-qualification guidance.

2. Gap register

Each row is something that has to exist, or exist in a different form, before an assessor accepts Rust ASIL B code from a module. Where the board already has an issue, the gap is the missing content, not the missing ticket.

A. Compiler and toolchain qualification

ID	Gap	State	Evidence today	Proposed action
A1	No TVR for Ferrocene rustc	🔴	Tool list 5b-1 "Relevant YES, TVR N/A"; certification page compiler empty; #2030 Backlog	Write doc_tool__ferrocene_rustc on the QCC pattern: use cases compile / link / instrument, TCL LOW, qualification section referencing vendor kit + Safety Manual constraints
A2	Qualified QNX 8 target does not exist yet	🔵	#2434 closed on "available Q3 2026"; toolchains_rust ships self-built QNX toolchains	Reopen tracking: obtain 26.08.0 stable, confirm qualified target list and required flags, re-pin to the qualified release
A3	Toolchain pinned to a rolling commit, not a qualified release	🟡	toolchains_rust 0.10.0 pins ferrocene_toolchain_builder 1.3.1 = Ferrocene commit 779fbed0 (rolling, Dec 2025); tool list says "1.90.0"	Split a verification toolchain (rolling, instrumented, branch coverage, Miri) from a production toolchain (qualified stable). Document the self-build as unqualified. Fix the tool list
A4	No host compiler decision	🔴	SW Development Plan: "Pick your own favourite"	Same Ferrocene version on x86-64 Linux host for all verification runs; record in the plan
A5	Edition 2021 lock vs edition 2024 wish	🟡	Ferrocene qualified for 2021 only; toolchains_rust#42 asks for 2024	Edition 2021 for ASIL crates until Ferrocene qualifies 2024; QM crates may differ
A6	Ferrocene Safety Manual constraints not mapped to S-CORE	🔴	No page lists the ~20 CSTR items (clean env, clean build, -D warnings, no -A, build-log monitoring, KP handling, unsafe module rules)	"Ferrocene usage in S-CORE" guideline: one row per constraint, how we satisfy it (Bazel flag, CI check, review), linked from module safety plans as AoU
A7	Known Problems monitoring process	🔴	Nothing in process or plans; KP database is login-only	Recurring safety-plan task: subscribe to notifications, review KPs per release, record impact per module
A8	Qualified compiler options not enforced	🔴	Not checked centrally	Put the qualified flag set into score_rust_policies as toolchain default; CI check that ASIL targets do not deviate
A9	Linker and C linker driver for mixed C++/Rust binaries	🔴	Not documented	Document the link step on QNX and Linux; cover it in A1's link use case

B. Standard library, async runtime and third-party crates

ID	Gap	State	Evidence today	Proposed action
B1	No decision on std for ASIL code	🔵	#2023 open; #2026 sent scope to Ferrous, silent since 2026-03-25; DR-001 deadline July 2026 passed	Decide: (a) buy an extension of the certified subset, (b) restrict ASIL crates to certified core + qualified baselibs, or (c) qualify a std subset per ISO 26262-8 Clause 12. Record as design decision with cost
B2	Certified-core subset not enforced in CI	🔴	#2587 has no concept; ferrocene::unvalidated lint not in score_rust_policies	Add the lint to the strict profile for ASIL crates; review rule + report for every ferrocene::prevalidated
B3	core gaps vs S-CORE usage	🟡	#2248: core::{task,pin,future,ffi} missing; fmt and panic! added in 26.05.0	Re-run the import scan against the 26.05.0 subset; re-price the delta
B4	Certified async runtime	🟡	#2029 points at kyron; kyron v0.1.4 is configured ASIL_B, pins stable 1.90.0, has no safety plan, requirements or analysis	Decide whether async is allowed in ASIL code; if yes, give kyron a module safety plan like any ASIL module
B5	Third-party crate qualification procedure	🟡	score-crates has a merged manual (component classification, ISO/PAS 8926 pattern) and a draft SEooC safety plan; exactly one crate (pastey) classified, ~50 in the index unqualified; #2027/#2028 empty	Promote the manual into process_description; produce the allowed-crate list per ASIL module; checklist into the module safety plan template
B6	Proc-macro crates in ASIL builds	🟡	pastey matrix is the only example; CORE_CSTR_0060 requires verifying generated code	List every proc-macro crate used by ASIL code; "review expanded code" step in the guideline

C. Coding guidelines

ISO 26262-6 5.4.3 requires coding guidelines addressing Table 1 topics and Table 6 principles. The current page is a philosophy statement plus a lint table: no rule IDs, no classification, no deviation process, primary reference an unnamed "safety- and cybersecurity-oriented Rust baseline". This is the largest content gap and the one no vendor closes for us.

ID	Gap	State	Evidence today	Proposed action
C1	No rule-level coding guideline	🔴	#1208 open since 2025; #592 closed "solved with other issues"; #1621 says none exists	Rewrite doc__rust_coding_guidelines as a rule set (~60–90 rules): ID, category (mandatory/required/advisory, MISRA Compliance:2020), source (SCRC gui_ id, MISRA Add. 6, CERT, own), enforcement (compiler / clippy / CodeQL / Miri / review), ASIL scope
C2	No ISO 26262-6 Table 1 / Table 6 mapping	🔴	Consortium website has one (March 2026); we have none	Appendix table citing the consortium analysis, stating S-CORE's position per row with the enforcing rule or tool
C3	Unsafe code guideline	🔴	#2033 Backlog, nothing produced; Ferrocene RUSTC_CSTR_0100 requires module containment, safety comments, two senior reviewers, dedicated tests	Unsafe chapter: where allowed (QM crates, FFI shims, baselibs), mandatory // SAFETY: (lint already deny), Miri required, review by two, how a safe wrapper is qualified
C4	FFI and mixed-language rules	🔴	Not addressed anywhere; S-CORE is C++17 + Rust in one process	FFI chapter: extern "C" only, no panics across the boundary, #[repr(C)], bindgen/cbindgen policy, ownership contract per function, matching rule on the C++ side
C5	Panic and error-handling policy	🟡	Guideline denies unwrap/expect/panic, requires overflow-checks; no rule for top-level Err in an ASIL unit; panic=abort mandatory with certified core	Panics are faults, not errors; how a unit reports to the supervisor; which operations still panic implicitly (indexing, division, overflow) and what to do
C6	Concurrency and async rules	🔴	None	Allowed sync primitives, lock ordering, no blocking in async, executor choice, interrupt constraint (RUSTC_CSTR_0110)
C7	Complexity, recursion, metrics	🔴	No Clippy lint for recursion; metrics tools "still unavailable"	Limits (cyclomatic, nesting, length) + tool; call-graph check for recursion on ASIL crates
C8	Deviation process	🔴	None for Rust (nor C++)	Deviation record (ID, rule, justification, scope, approver, expiry); #[allow(..., reason = "DEV-…")] enforced on ASIL crates; reported in the module safety case
C9	API design guideline draft, QM	🟡	doc__rust_api_design draft; #2031 Backlog	Finish, raise to valid, link C1 rules for error types and object safety
C10	Security coding rules for Rust	🟡	process_description#544 open	Fold into C1 with a security tag
C11	Consortium alignment strategy	🟡	#2034 in progress since January; SCRC stays pre-1.0 into 2027	S-CORE writes v1 now citing SCRC ids where they exist; re-baseline at SCRC 1.0; nominate a producer in the consortium

D. Static analysis and lint tooling

Contradiction to resolve. The clippy TVR argues TCL HIGH ("lints are only a measure of quality"). The coding guideline and the implementation process name Clippy as the enforcement mechanism for Table 6 principles. If Clippy enforces guideline rules, a false negative violates a safety requirement with no other detection → TCL LOW. Either the guideline must not rely on Clippy alone, or the TVR must be redone as LOW with a qualification section.

ID	Gap	State	Evidence today	Proposed action
D1	Clippy TVR inconsistent with its use	🟡	doc_tool__clippy evaluated, TCL HIGH, names 1.90.0 while the toolchain is a Ferrocene commit	Re-evaluate per use case: "quality lint" (HIGH) vs "guideline enforcement" (LOW); qualify the LOW use cases by validation: one positive + one negative test per enforced lint, kept in score_rust_policies, run per toolchain bump
D2	Clippy strict/relaxed profiles are placeholders	🟡	#2966 open	Derive the strict profile from C1 rule by rule; every deny lint traces to a rule ID; validate on baselibs and one module
D3	CodeQL for Rust has no TVR	🔴	Tool list 2a-4 "TBD, YES, no TVR"	Write the TVR; decide whether CodeQL results are safety evidence (LOW) or supplementary (HIGH)
D4	Miri not integrated	🟡	#2010 Backlog; Miri built in ferrocene_toolchain_builder, no Bazel/CI integration, not in the tool list	rust_miri_test rule or aspect in score_tooling; run on crates with unsafe; TVR (likely HIGH)
D5	No whole-program checks	🔴	None	Evaluate cargo-call-stack or an LLVM-IR script for recursion/stack; CI gate on ASIL crates
D6	Custom lints for S-CORE rules	🔴	#1621 open; consortium plans a Clippy home for safety lints, no Dylint plan	Dylint for project-specific rules now; upstream generic ones via the consortium
D7	SCA finding classification for Rust	🔴	Process defines Critical/High/Medium/Low; no Rust mapping	Map deny lints → Critical/High, warn → Medium in the strict-profile docs

E. Structural coverage

ID	Gap	State	Evidence today	Proposed action
E1	Coverage tool evidence exists, platform documents do not reference it	🟡	coverage_tool v0.1.0 (2026-09-11): 6 use cases, HazOp errors ERR-01..10 reaching TCL LOW, ~30 tool_req with generated test links, 10 constraints of use, known problems, verification report (223 unit cases, 11 Starlark tests, 15 e2e checks vs. golden LCOV), self-coverage 95.6 % / 87.2 %; all documents draft. In the score repo: no doc_tool__score_coverage, no tool-list row, verification plan still says gcovr / "tooling provided by Ferrocene". #2591 still targets symbol-report/blanket	Short platform TVR doc_tool__score_coverage: malfunction table from ERR-01..10, "requires qualification", qualification section linking the tool's requirements, verification report and constraints. Tool-list row. Update verification plan and DR-001. Close #2591 as superseded. Before "qualified": close the tool's own deviations and raise its docs to valid
E2	Branch coverage on the shipped toolchain	🟡	Stable rustc: function/line/region only; -Zcoverage-options=branch nightly-only (#79649), no match-arm branches (#124118); coverage_tool known problems: "on a stable-channel Ferrocene drop the flag; Rust branch coverage is then not available"; CSTR-01 excludes QNX on-target	Write the measurement strategy into the verification plan: (a) verification toolchain (rolling, same Rust version, instrumented) separate from production toolchain (qualified stable), the former covered by the coverage TVR; or (b) ask Ferrous to ship branch coverage as a supported option on stable. Document the match-arm limitation as a constraint requiring manual justification
E3	Coverage of macro-expanded code	🔴	Consortium lists "coverage of macro expansions" as a missing compiler feature	Usage constraint in E1's TVR; review of macro-generated code for ASIL crates (ties to CORE_CSTR_0060)
E4	Coverage justification format	🟢	Implemented in coverage_tool: YAML with id/category/platforms/reason, COV_JUSTIFIED markers, stale detection, raw vs effective, CSTR-07 review like code	Keep. Add to the coding guideline which justification categories are acceptable for ASIL code and who approves
E5	MC/DC	🟢	Not required at ASIL B; upstream removed MC/DC in Aug 2025; #2015 stale	Close as "not required at ASIL B"; state it in the verification plan

F. Testing

ID	Gap	State	Evidence today	Proposed action
F1	Unit-test framework decision and TVR	🔴	#2016/#2017/#2018 Backlog; verification plan: "built-in test framework"; not in the tool list; gtest and ITF are already TCL LOW	Decide libtest via rust_test + documented assertion crate; doc_tool__rust_libtest as LOW; validate with a known-failing test set
F2	Requirement traceability from Rust tests	🟡	#2037/#2038; docs-as-code source_code_linker exists; not in process pages	Finish the process PR; linker in the Rust module template; CI check that ASIL test targets carry requirement IDs
F3	Mocking approach	🔴	#2017 wants mocking + gtest-like asserts	Pick mockall or hand-written mocks; document in the API guideline
F4	Test derivation methods for Rust	🔴	Boundary values, equivalence classes, fuzzing required at ASIL B; no Rust tooling named	Name proptest / cargo-fuzz / arbitrary in the verification plan; Bazel rules; TVR for proptest
F5	Rust component/integration tests in ITF	🔴	#2019 lists it as uncovered	One example module with ITF tests against a Rust binary; document the pattern
F6	Sanitizers and fault injection	🟢	Optional at ASIL B	Record as optional; document toolchain support

G. Build system and supply chain

ID	Gap	State	Evidence today	Proposed action
G1	rules_rust and score_toolchains_rust marked "not relevant"	🔴	Tool list 4-9 and 4-13: Relevant NO; we maintain a rules_rust fork; RUSTC_CSTR_0030 puts build-action correctness on the user	Flip to Relevant YES with TVRs (own or as Bazel use cases); change-control note for the fork
G2	Bazel TCL LOW, unqualified	🟡	doc_tool__bazel draft, LOW	Not Rust-specific but on the critical path; add Rust action types to Bazel's tool requirements
G3	Build-log monitoring constraint	🔴	None	Build manifest from Bazel's execution log for release builds (tool hashes, flags per action), archived with the release
G4	Crate vendoring, pinning and vetting	🔴	score-crates pins Cargo.lock + Cargo.Bazel.lock; coverage_tool requires --lockfile_mode=error; nothing vets sources	crates_vendor local mode for ASIL deps; cargo-deny + cargo-audit in CI; audit recorded as Clause 12 evidence
G5	Reproducible release builds	🔴	Consortium: deterministic codegen "partial"	Two-build hash check in the release checklist; document known non-determinism
G6	SBOM for Rust binaries	🔴	None	cargo-cyclonedx from the vendored lockfile now; track cargo's native SBOM (2026 project goal, cargo#16565); feed Eclipse Dash

H. Process, plans and traceability

ID	Gap	State	Evidence today	Proposed action
H1	Rust certification pages are empty	🔴	compiler, libcore, libstd, coverage, formatting, static analysis: title only	Fill each with summary + links to TVR, decision record, usage guideline; owner per page
H2	Tool evaluation list out of date for Rust	🔴	Ferrocene "1.90.0"; missing cargo, coverage tool, Miri, libtest, CodeQL-Rust, proptest	One PR: add rows, fix versions to what toolchains_rust pins, set Relevant correctly
H3	Software Development Plan statements stale	🟡	"edition still to be decided", "pick your own host compiler", Ferrocene "planned"	Update after A2–A5
H4	Verification plan Rust statements stale	🟡	"coverage created using tooling provided by Ferrocene"; test framework unnamed	Update after E1 and F1
H5	Rust AoU in module safety plans	🔴	Template has no language section	"Language and toolchain AoU" section in gd_temp__module_safety_plan linking A6, B2, B5, C5
H6	Code → requirement / design linkage	🟡	#2037/#2038; linker in baselibs_rust#49	Finish, document, CI gate for ASIL crates
H7	rustdoc in docs-as-code	🔴	#2036 Backlog, infrastructure#7 open	Decide rustdoc HTML embedded vs sphinx extension
H8	Rust-aware inspection checklist	🔴	Implementation checklist is language-neutral	Add: unsafe review, SAFETY comments, Result handling, allow-attributes with deviation IDs, prevalidated uses
H9	Epics closed while children open	🟡	#2434 closed on an announcement; #2432 closed with #2966 open; #2111 closed "for now"	See section 6

I. Runtime and architecture constraints

ID	Gap	State	Evidence today	Proposed action
I1	Panic strategy at system level	🔴	panic=abort mandatory with certified core = process exit on QNX; no supervisor mechanism described	Panic-to-supervisor mechanism in the platform safety concept; consider no-panic proofs (needs an unwind build) for the smallest ASIL crates
I2	Stack usage and resource evaluation	🔴	Required at level 2; -Z emit-stack-sizes unstable, cargo-call-stack stale	Measure on reference HW (QNX stack watermarks) per module; record as known limitation
I3	Freedom from interference C++ ↔ Rust in one process	🔴	Not addressed	Rule: ASIL Rust and QM C++ do not share a process unless the C++ is also ASIL; document in the safety concept
I4	Global allocator and heap policy	🔴	alloc uncertified; containers_rust has fixed-capacity types but no classification; baselibs safety manual lists only C++ features	ASIL crates allocate at init only or use bounded containers from classified baselibs; OOM handling defined; classify the Rust baselibs crates

J. Organisation, budget and external dependencies

ID	Gap	State	Evidence today	Proposed action
J1	Ferrous commercial decision lapsed	🔵	DR-001 required ordering by July 2026; TLC #2662 escalated funding; no open board item; #2026 silent since March	Decision item with three options and cost (subset extension, std subset, qualified QNX binaries + signatures), owner Project Lead, deadline before 26.08.0
J2	No S-CORE producer in the consortium	🔴	S-CORE mentioned in consortium RFC 0002; no named representative	One person each for coding-guidelines and tooling; monthly report in the Rust meeting
J3	Safety-qualified people for Rust modules	🔴	No Rust-specific training material	Rust safety module in the process training (unsafe review, Ferrocene constraints, coverage justification)
J4	Pilot module for a confirmation review	🔴	No pilot named	One small ASIL B Rust module (a baselibs crate) driven through the roadmap

3. What the consortium gives us, and what it does not

Use now

• Guideline IDs and metadata model: cite gui_ IDs, adopt their category semantics, decidability and scope fields.
• MISRA C:2025 Addendum 6 matrix (61 rules applicable to safe Rust, 68 with unsafe): the fastest route to a defensible Table 6 argument.
• The ISO 26262 Part 6 gap analysis on the website, cited row by row in C2.
• The reviewed tools list for justifying tool choices; the desired-compiler-features list for documenting limitations.

Do not wait for

• A 1.0 guideline (roadmap: 0.2 then 0.3 RFC review, no date for approved status; unsafe/FFI/concurrency chapters empty).
• An ISO 26262 matrix inside the guidelines (issue open since Feb 2025).
• A qualified checker (Clippy home for safety lints is a 2026 goal; first candidate lints discussed June 2026).
• Tool qualification guidance (none published).
• MC/DC or branch coverage on stable.
• A MISRA Rust or ISO document.

4. The document set we should end up with

Mapped onto the Ferrocene structure we want to copy:

S-CORE document	Ferrocene analogue	ISO 26262	Closes
Rust Coding Guidelines v1 (doc__rust_coding_guidelines rewritten)	none (SCRC is the source)	Part 6 5.4.3, Tables 1 and 6, 7.4.13	C1–C11
Rust Toolchain Usage Guideline (new)	Safety Manual	Part 8 11.4.4.2, AoU	A4–A9, B2, H5
TVR Ferrocene rustc (doc_tool__ferrocene_rustc)	Evaluation + Qualification Report	Part 8 11.4.5–11.4.9	A1
TVR coverage tool (doc_tool__score_coverage)	core-cert tool assessment	Part 8 11	E1–E3
TVR Rust test harness (doc_tool__rust_libtest)	core-cert tool assessment	Part 8 11	F1
TVRs clippy (redone), CodeQL-Rust, Miri, rules_rust + toolchain module, proptest	core-cert tool assessments	Part 8 11	D1, D3, D4, G1, F4
Crate Qualification Guideline (promote score-crates manual)	none	Part 8 Clause 12, ISO/PAS 8926	B5, B6
Design decisions: std strategy, host compiler, edition, async in ASIL, panic strategy, Ferrous purchase	none	Part 2 safety plan	B1, A4, A5, B4, I1, J1
Rust certification chapter (six pages filled)	Document List	Part 2 6.4.5	H1

5. Roadmap

Dates assume Ferrocene 26.08.0 with QNX 8 targets ships in Q4 2026. If it slips, phase 2 slips with it; phases 0, 1 and most of 3 do not depend on it.

Phase 0 — Sep to Oct 2026: decide and clean up

• Design records: std strategy (B1), host compiler (A4), edition 2021 for ASIL (A5), async in ASIL (B4), pilot module (J4), Ferrous options (J1)
• Tool list PR (H2, G1); board clean-up (section 6); consortium producers (J2)
• Resolve the clippy TCL contradiction on paper (D1)
• Exit: six decision records merged, tool list correct, board reflects reality

Phase 1 — Oct to Dec 2026: guidelines and usage rules

• Rust Coding Guidelines v1 (C1–C8, C10) incl. Table 1/6 appendix and deviation process
• Clippy strict profile re-derived from the rules, one lint per rule ID, validation cases (D2); Dylint scaffold (D6)
• Rust Toolchain Usage Guideline (A6–A9, B2, H5) with the certified-core lint in the strict profile
• API guideline to valid (C9); Rust inspection checklist items (H8)
• Exit: guideline v1 valid at ASIL B; strict profile enforces it on baselibs with zero unjustified allows

Phase 2 — Nov 2026 to Feb 2027: tool verification reports

• TVRs: Ferrocene rustc (A1), coverage tool (E1, short report over existing evidence), libtest (F1), clippy redone (D1), CodeQL-Rust (D3), Miri (D4), rules_rust + toolchain module (G1), proptest (F4)
• Validation for the LOW ones: known-failing suite for libtest, lint validation set for clippy; coverage tool raises its docs to valid and closes its deviations
• Verification/production toolchain split (A3, E2); build manifest (G3); vendoring, vetting, SBOM (G4, G6)
• When 26.08.0 ships: re-pin, obtain signed documents, update A1 and the SW Development Plan (A2, A3, H3)
• Exit: every Rust tool in the list has a TVR in status evaluated or qualified; LOW tools have validation evidence

Phase 3 — Jan to Apr 2027: pilot module and confirmation review

• Pilot ASIL B Rust module (J4): requirements, design in code with rustdoc rendered (H7), traceability gated in CI (F2, H6), inspection with Rust checklist, 100 % statement and branch with justifications, Miri on unsafe, ITF integration tests (F5)
• Crate qualification on the pilot's dependencies (B5, B6); panic-to-supervisor mechanism (I1); stack usage measured (I2)
• Module safety case, FDR-led confirmation review; findings into guideline v1.1 and the TVRs
• Re-baseline against SCRC 0.2/0.3 and the then-current certified-core list (C11, B3)
• Exit: one Rust module with a positive confirmation review; the chain is repeatable

Continuous: per Ferrocene release: KP review (A7), certified-core delta (B3), lint validation re-run (D1), TVR version bump. Per quarter: consortium report, guideline delta vs SCRC, tool list review.

6. Proposed changes to project board #34

The board has 50 items (20 Backlog, 8 In progress, 22 Done). Board status and issue state agree on all 50. Priority and Size are empty everywhere. The eight "In progress" items have been idle for 1 to 9 months; six of them wait on the same thing, an answer from or decision about Ferrous (J1).

In progress item	Last activity	Register
#2022 Document Ferrocene libcore certification scope	2025-12-08	B1, B3
#2037 Linkage from code to requirements	2026-01-19	F2, H6
#2248 Track gap with Ferrocene to get estimates	2026-02-11	B3
#2591 Qualification for symbol-report/blanket	2026-02-11 (tools since replaced)	E1
#2020 Certified libcore (epic)	2026-03-24	B1–B3
#2026 Ask commercial company for certification	2026-03-25	B1, J1
infrastructure#24 Branch coverage tooling for Rust (epic)	2026-06-09	E1, E2
#2034 SCRC guidelines, decide on move forward	2026-08-06	C11

Reopen or re-scope: #2434 (until a qualified QNX 8 release is pinned), #2432 (child #2966 open; add D1, D3, D6, D7), #2591 (close as superseded; new issue for the platform-side coverage TVR, tool-list row and plan update), #1208 (make it the epic for C1–C11, pull #2034, #2031, #2033, process_description#544 under it), #2111 (reopen as parent of this register).

Create: the six design decisions (Phase 0); TVR issues for Ferrocene rustc, coverage tool, libtest, CodeQL-Rust, Miri, rules_rust + toolchain module, proptest; Rust Toolchain Usage Guideline; crate qualification guideline promotion; FFI and mixed-language rules; build manifest; reproducibility; SBOM; Rust inspection checklist; Rust safety training; pilot module; consortium representation.

Close: #2035 (empty, labelled trash), #2585 (placeholder), #2006 once children are re-parented, #2015 MC/DC as "not required at ASIL B".

Fields: set Priority per phase; use the register IDs in titles so board and register stay linked.

Sources

• S-CORE process: tool management, qualification guideline and tailoring, TVR attributes, implementation guideline
• S-CORE platform: Tool Management Plan, tool evaluation list, Software Development Plan, Verification Plan, Safety Plan, Rust coding guidelines, DR-001-Arch, TVRs for QCC, clippy, Bazel
• Repos: toolchains_rust, score_rust_policies, score-crates, coverage_tool, tooling#394, weekly Rust meeting notes
• Ferrocene: Safety Manual, Evaluation Report, Qualification Plan, core certification tool assessments, release notes
• Consortium: repo, coding guidelines 0.1.25, ISO 26262 gap analysis and tools list, Rust 2026 safety-critical goals

Ferrocene public docs are the unsigned development preview; signed release documents are customer-only. Gap count and phase dates are proposals for review.