Verifying Code You Did Not Write: An ISO 26262 Quality Gate for LLM-Generated Safety Code, Demonstrated on a Rust CRC Unit
Rune B. Molzen - Langenhan Engineering Services GmbHContext and Application Example
The growing use of Large Language Models (LLMs) in software engineering requires practical approaches to integrate generated code into rigorous, ISO 26262-compliant processes. Concurrently, Rust is gaining relevance in the safety-critical domain due to its inherent memory guarantees.
The methodology was applied to a configurable 8-bit CRC generator, developed as a Safety Element out of Context (SEooC) with an assumed target of ASIL B. It was implemented in Rust under no_std and #![forbid(unsafe_code)]. The unit provides a bitwise variant and a table-based variant (256 bytes of read-only footprint), both following the Rocksoft model; table integrity is checked at power-on against the independently verified bitwise path.
The two functions of the table-based variant were generated by an LLM. Verification comprises 26 requirement-based unit tests, conformance checks against the Greg Cook catalogue, 100% statement and branch coverage, and a Criterion-based throughput measurement showing a factor of 3.0 for the table-based variant. Across five documented generation attempts, three defective intermediate results were rejected, each at a different stage of a designated quality gate: an iterator construct not permitted inside a const fn (rejected during manual inspection), a missing index cast (static analysis), and incorrect checksum results (dynamic verification). No defective fragment entered the code base. These observable outcomes were explicitly documented, deliberately avoiding unprovable statistical statements about LLM reliability.
How Is This Difference from Reviewing Human-Written Code?
The individual verification steps are identical to those applied to human-written code. The main differences lie in the normative framing and the resulting effort profile:
■ Normative framing. A human developer is covered by competence and process management. An LLM must be treated as a software tool and classified under ISO 26262-8. Confidence cannot be placed in the producer; it rests entirely on the detection measures applied to the output.
■ No reducible learning curve. Review effort for developers can decrease as competence is demonstrated over time. An LLM accumulates no such contextual record; each generation is independent. The full gate must be executed for every fragment, reducing the long-term time savings of generation.
■ Automation bias versus human workarounds. The biggest enemy of safety is often experienced developers relying on obscure workarounds that “somehow” work. While human code may sometimes signal its flaws, LLM output is consistently well-formed and plausible, risking automation bias. This makes rigorous, line-by-line manual inspection crucial to catch semantically flawed but structurally sound code.
The Role of Rust
Rust serves as the concrete application example and contributes significantly to safety compared to permissive C-compilers. A strict compiler that refuses to compile ambiguous code actively prevents the “it works somehow” scenarios. Within the case study, #![forbid(unsafe_code)] is used as a project-wide, compiler-enforced language subset mapping to ISO 26262-6, Table 1. The compiler, borrow checker, and linter (clippy) serve as tool-supported evidence for memory, control-, and data-flow integrity. Furthermore, branchless masked arithmetic combined with const generics yields a statically analysable, data-independent control flow supporting WCET analysis. The combination of these strict language-inherent guarantees and procedural safeguards yields an evidence-based argument for ISO 26262 compliance.
Applicable the Next Working Day
■ Declare LLM output an unqualified draft in your process, not a work product, and forbid direct integration.
■ Run the four existing Clause 9 measures as an ordered gate per fragment: line-by-line manual inspection (walk-through/inspection), static analysis, traceability assignment via REQ-IDs, and dynamic requirement-based verification (with 100% statement and branch coverage).
■ Log per generation attempt which stage rejected which fragment and why. This log serves as your Tool Error Detection evidence.
■ Argue TI/TD/TCL per bounded tool use case.
Scope and Limitations
The work is a Bachelor’s thesis with a defined scope: design, implementation and verification of a CRC-8 Safety Element out of Context (SEooC) on software unit level, under an assumed target of ASIL B (Assumption of Use). Build infrastructure, hardware-in-the-loop testing, formal qualification of compiler and linker, dependency management, and CI integration were not investigated and are assigned to the later system integrator as further Assumptions of Use. The demonstrated detection effectiveness holds for error classes that the tool system structurally captures. Transferability to other models, languages, or toolchains was not evaluated. From our perspective, these boundaries are excellent discussion points for an experienced audience.
Context and Application Example
The growing use of Large Language Models (LLMs) in software engineering requires practical approaches to integrate generated code into rigorous, ISO 26262-compliant processes. Concurrently, Rust is gaining relevance in the safety-critical domain due to its inherent memory guarantees.
The methodology was applied to a configurable 8-bit CRC generator, developed as a Safety Element out of Context (SEooC) with an assumed target of ASIL B. It was implemented in Rust under no_std and #![forbid(unsafe_code)]. The unit provides a bitwise variant and a table-based variant (256 bytes of read-only footprint), both following the Rocksoft model; table integrity is checked at power-on against the independently verified bitwise path.
The two functions of the table-based variant were generated by an LLM. Verification comprises 26 requirement-based unit tests, conformance checks against the Greg Cook catalogue, 100% statement and branch coverage, and a Criterion-based throughput measurement showing a factor of 3.0 for the table-based variant. Across five documented generation attempts, three defective intermediate results were rejected, each at a different stage of a designated quality gate: an iterator construct not permitted inside a const fn (rejected during manual inspection), a missing index cast (static analysis), and incorrect checksum results (dynamic verification). No defective fragment entered the code base. These observable outcomes were explicitly documented, deliberately avoiding unprovable statistical statements about LLM reliability.
■ Co-Author/Presenter: Thorsten Langenhan
■ Co-Author/Presenter: Laura Hain
Short Bio:
Rune B. Molzen B.Sc. Angewandte Informatik (Hochschule Flensburg, 2026), currently enrolled in the consecutive Master’s programme. Worked extensively on functional safety verification of Rust-based algorithms for safety-critical embedded systems.
Thorsten Langenhan Dipl.-Ing.-univ. Aerospace Engineering (UniBwM), Dipl.-Wirtsch.- Ing. (FH) (Akademie für Berufstätige). 15 years of experience in functional safety across process, system, hardware, and software levels in multiple industry sectors.
Laura Hain Electronics Technician for Information and Systems Technologies. 4.5 years of experience as Functional Safety Manager and Engineer on Systems, Hardware and Software, according to ISO 26262 and IEC 61508.
