Split View: Ferrocene의 인증된 core — 컴파일러는 ASIL D인데 라이브러리는 왜 ASIL B에서 멈추나

Ferrocene's Certified core — The Compiler Is ASIL D, So Why Does the Library Stop at ASIL B?

• Introduction — The Trap in "ASIL D-Certified Rust Compiler"
• Tool Qualification and Software Certification Are Different Things
• What Actually Happened, December 2025 to May 2026
• Why a Subset, Not All of core
• How the Subset Is Enforced — From cfg Hacks to a Callgraph Lint
• What the ASIL B Ceiling Actually Is — What the Vendor Wrote Down Itself
• Your Chip Is Probably Not on the List
• So What's Still Left to You
• When Not to Use This
• Closing
• References

Introduction — The Trap in "ASIL D-Certified Rust Compiler"

There's a sentence that keeps coming up whenever embedded Rust gets discussed: "Ferrocene has received ISO 26262 ASIL D certification." The sentence itself isn't wrong — Ferrous Systems's public documentation says exactly that.

The problem is the conclusion people draw from it. "So now you can write ASIL D software in Rust." No. Two distinct claims have been mashed into one, and what actually moved in the first half of 2026 wasn't the mashed-together claim — it was the thing underneath it: the core library.

This post is that story. What Ferrocene actually certified between December 2025 and May 2026, why the compiler is ASIL D while the library stops at ASIL B, where that ceiling comes from, and what is still left to you. The short version: the most valuable part of this story isn't something the vendor hid — it's something the vendor wrote down itself.

Tool Qualification and Software Certification Are Different Things

Terminology first. This is the skeleton for the whole post.

The Ferrocene compiler (rustc) was qualified as a tool. The first sentence of the Ferrocene Qualification Report reads: this document is the report of the qualification material developed for certification against the automotive ISO 26262:2018 (ASIL D / TCL 3), industrial IEC 61508:2010 (class T3), and medical IEC 62304:2006 + AMD 1:2015 standards.

The key abbreviation here is TCL — Tool Confidence Level. What ISO 26262 part 8 clause 11 addresses is "confidence in the use of the software tool," not the integrity level of the code the tool produces. Being qualified at TCL 3 for ASIL D means "you may use this compiler for ASIL D development." It does not mean "the compiled output is ASIL D."

The core library subset is a completely different thing. It isn't a tool — it's a software component — and it received certification as software. The same qualification report continues: parts of this document may be referenced from the Core Library Certification developed for certification against the automotive ISO 26262:2018 (ASIL B) and industrial IEC 61508:2010 (SIL 2) software standards.

These two numbers aren't marketing copy — they're baked in machine-readable form into a documentation build config. Open ferrocene/doc/sphinx-substitutions.toml in the Ferrocene repo and you get this:

iso_26262_ferrocene_asil = "ASIL D"
iso_26262_core_asil = "ASIL B"
iso_26262_ferrocene_tcl = "TCL 3"
iso_26262_ferrocene_tql = "class T3"

iec_61508_core_sil = "SIL 2"

Compiler: ASIL D / TCL 3. Core: ASIL B. This file is byte-identical between the 26.02.0 and 26.05.0 branches — the ASIL B ceiling holds in the latest release too.

And the "Qualification scope" chapter of the Safety Manual pins down user responsibility in plain terms: per ISO 26262:2018 part 8 clause 11.4.2, the user must verify the validity of the predetermined TCL before using this software tool for safety-related development. And per clause 11.4.3, the user must ensure that the tool's usage, environment, and functional constraints match the evaluation criteria or qualification.

Read closely, this isn't "we've done it all, just use it" — it's "you verify the valid scope of our qualification."

What Actually Happened, December 2025 to May 2026

In chronological order:

December 3, 2025 — the first core subset, IEC 61508 SIL 2. Ferrous Systems announced it in a press release. TÜV SÜD certified the first subset of the Rust core library to IEC 61508 (SIL 2), and that subset ships in Ferrocene 25.11.0. The certification applies to use on the Ferrocene toolchain and qualified targets (including Armv7E-M and Armv8-A). The work started in 2023, with Cryspen and Thoughtworks contributing tools and time. In the words of Florian Gilcher, Ferrous's managing director — "It's not practical to run Rust without core in embedded or safety-critical contexts, and core can't be certified unless it's rigorously verified with a toolchain like Ferrocene."

The same release names two real-world adopters. Sonair uses it in ADAR, a 3D ultrasonic sensor for autonomous robots (running on quad-core Armv8-A alongside an Armv7E-M subsystem), and Kiteshield uses it in collision-avoidance systems for manned and autonomous underground-mining equipment, where some components ultimately require IEC 61508 SIL 3.

February 15, 2026 — ASIL B added, subset expanded. This is the 26.02.0 release. ISO 26262 (ASIL B) was added to the certified core subset, and the SIL 2 subset itself grew substantially. By the vendor's own published figures, the number of certified functions went from 2,903 to 5,169, modules like core::slice, core::iter, core::ffi, and core::result expanded, and a minimal certified panic hook was added. The repo's ferrocene/version file confirms this release's rustc is 1.92. eeNews Europe covered it independently too — announced at embedded world 2026, and the point was that certification had moved down past the compiler toolchain into the library layer.

May 2026 — core::fmt certified, and the enforcement mechanism replaced. This is where it gets interesting. There's no announcement blog post for 26.05.0. ferrous-systems.com/blog/ferrocene-26-05-0/ is a 404, and the blog index's latest Ferrocene release notice is still 26.02.0. But the release shipped — the repo's release/1.95 branch has ferrocene/version holding 26.05.0, and the :upcoming-release: marker has been removed from the release notes (while 26.08 on release/1.97 still carries that marker). The contents:

• The core::fmt module was certified to ISO 26262 (ASIL B) and IEC 61508 (SIL 2) — the code that formats Rust data structures into human-readable output.
• As a result, the "certified panic runtime" targets (aarch64-ferrocene-none, thumbv7em-ferrocene-none-eabi, and others) were retired. They existed to certify panics without certifying the formatting code — no longer necessary.
• The ferrocene::unvalidated lint was introduced, and the "subset targets" were retired. More on this below.
• A new qualified target, aarch64-rhivos2-linux-gnu, was added (only when compiling on an aarch64-unknown-linux-gnu host), and the proc_macro crate type was permitted.
• thumbv7em-m4-none-eabihf and aarch64-a53-none were removed. These were newly added in 26.02.0, but the same effect is now achieved by passing -C target-cpu=cortex-m4 / -C target-cpu=cortex-a53 on the base target.

Traces of the 26.05.0 core::fmt certification show up in the user manual too. The 26.02.0 core/using.rst had a warning: core library behavior differs when using a certified target — in particular, the panic! macro supports only static strings rather than arbitrary format_args!, so panic messages may be less informative. In the same file in 26.05.0, that entire paragraph is gone.

Independent verification. The repository ships an authoritative list of certified symbols as a CSV (ferrocene/doc/symbol-report.csv; the Safety Report chapter of the core-certification docs includes this file directly). Pulling and counting from the two release branches gives:

release/1.92 (26.02.0):  5,235 unique symbols   core::fmt symbols:   0
release/1.95 (26.05.0):  8,790 unique symbols   core::fmt symbols: 535
                         (added 3,597 / removed 42)

This confirms the core::fmt certification landed, independent of the release notes. To be honest, though, the 5,235 in the 26.02.0 CSV doesn't line up exactly with the vendor's announced "5,169 certified functions." As the file name suggests, this is a symbol report while the announcement counted functions, so the counting basis is likely different. Read 5,169 as the vendor's own tally, then — what's solid is the order of magnitude and direction: the subset grew roughly 1.7x in one release.

The 42 removals are interesting too. Most are old certified-panic-runtime parts like core::panicking::PanicArguments::as_str and derive-internal markers (assert_receiver_is_total_eq). The subset doesn't only grow — it shrinks too.

August 2026 (upcoming). 26.08 on release/1.97 still carries the upcoming marker and previews three new qualified targets — aarch64-unknown-qnx, armv7r-none-eabihf, and x86_64-pc-qnx. flip-link is being promoted to quality managed.

Why a Subset, Not All of core

Callgraph analysis (April 1, 2026), written by Ferrous compiler engineer Jynn, spells out the reason. The certification target was IEC 61508 (SIL 2), and one of that standard's requirements that scales with codebase size is Annex A.9, "Software verification." Ferrous uses methods 3 and 4 (static and dynamic analysis). The documented approach is to run tests on every target platform where certified core exists, and collect code coverage that verifies every function has been tested.

So more code means more tests needed. In the post's own words: to avoid spending years of work before shipping a product, they decided to verify only a subset of core. Mark functions as validated, run tests against each of them to collect coverage, and tell customers to use only those validated functions.

The formal certification path is documented too. Per the Certification scope chapter of the core-certification docs, the IEC 61508 side follows Route 3S in section 7.4.2.12 — "Assessment of non-compliant development" — and the ISO 26262 side is SEooC (Safety Element out of Context) software development, tailored across parts 2/6/8.

If Route 3S doesn't mean much on its own, think of it this way: Rust's core was never developed with IEC 61508 in mind. Route 3S is the path for taking something that wasn't developed to a standard from the outset and assessing after the fact whether it's usable. And there's one interesting item in the ISO 26262 list of applicable clauses: "8-12, Qualification of software components" is marked not applicable, with the justification "qualification not applied, treated as new development instead." In other words, they built the evidence as if it were newly developed, rather than going through the existing software-qualification path.

How the Subset Is Enforced — From cfg Hacks to a Callgraph Lint

This is the most engineering-flavored part of the story.

Here's the problem. It's easy to say "only use certified functions," but there's no way for a user to know which parts of core they're actually calling. The Callgraph post nails it: core isn't an ordinary library — it carries deep integration with the compiler and the language itself. Something as innocuous-looking as do_io()? actually emits a call to core::ops::try_trait::Try::branch. Knowing which function calls which requires real compiler integration.

First attempt (25.11, 26.02): cfg forking plus fake subset targets. The approach was to fork the standard library and slap cfg all over the panic machinery. But that affects every user, not just the ones who care about certification, so to avoid breaking changes they created entirely new targets like aarch64-unknown-ferrocene.subset. Ferrous's own assessment is blunt: build scripts couldn't parse the target name, libtest used parts of core that had been cfg'd away so it couldn't compile for that target, and in practice people had to be told "run cargo check --target aarch64-unknown-none.subset, but don't use it for a full build" — a very bad user experience.

The Safety Manual flags the same thing in a warning box: subset targets may only be used to verify subset compliance, and must not be used as a certified target at runtime.

Second attempt (26.05): a lint on top of a custom rustc driver. This is the ferrocene::unvalidated lint introduced in 26.05.0. Per the Safety Manual, the procedure for proving compliance is now this short:

// 1. Turn on the lint at each crate root
#![warn(ferrocene::unvalidated)]

// 2. Compile with -D warnings. If it succeeds, the subset held.
//
// If it fails, pick one of four options:
//   a) if the function is yours, attach #[ferrocene::prevalidated]
//   b) if it's a core function, contact Ferrous to discuss adding it to the subset
//   c) remove the call and rewrite with the same meaning
//   d) keep it, but prove safety yourself and add #[allow(ferrocene::unvalidated)]

The invariant the lint enforces fits in one sentence: the set of validated functions in core must be closed under the function-call operation. If a call appears inside a validated function, the callee must also be validated. The reverse direction doesn't matter — there's nothing wrong with an unvalidated core::async_iter::from_iter calling a validated usize::checked_add.

The implementation splits into two passes.

• A pre-mono pass (THIR-based). It gives fast feedback in cargo check, running late enough to desugar built-in syntax like ?. It catches unsizing casts from function types to function pointers — blocking the workaround of "pass an unvalidated function pointer into a validated function" — and also catches casts to dyn Trait objects (accounting for supertraits and dyn-to-dyn coercions).
• A post-mono pass (MIR-based). This is the pass certification actually depends on. Before generics are instantiated, you can't know which clone a call to x.clone() resolves to, so this pass starts from monomorphized roots and walks the call graph, substituting types as it goes. It doesn't run in cargo check, only in cargo build (and it can surface even later for libraries with public generic functions).

The design principle is spelled out explicitly: prefer false positives over false negatives. Rejecting valid code by mistake is better than certifying invalid code. That's the right direction for a safety tool, and in practice it also means "code that's actually fine gets flagged by the lint, and you end up writing a safety argument to attach #[allow]."

The transition itself is a signal. Enforcement moved from "fork the standard library plus a weirdly named fake target" to "a compiler pass." The former is a hack; the latter is engineering.

What the ASIL B Ceiling Actually Is — What the Vendor Wrote Down Itself

Now the central question of this post. The compiler was qualified as an ASIL D tool — so why does the library stop at ASIL B?

You don't have to guess at the answer. Ferrous put a document called ISO 26262 6-Method Tables directly into its MIT/Apache-2.0-licensed public repository. For every method table in ISO 26262 part 6, it records, line by line, "how strongly recommended at ASIL B / how strongly recommended at ASIL D / did we apply it."

Table 9, structural coverage metrics at the software-unit level, reads:

No.  Method            ASIL B  ASIL D  Justification
1a   Statement coverage   ++      +     Applied, 100% line coverage with
                                        explanations for any coverage gaps
1b   Branch coverage      ++      ++    Not applied, 1a applied instead
1c   MC/DC                 +      ++    Not applied, 1a applied instead

It's all right there. The only thing applied is statement coverage; branch coverage and MC/DC are "not applied, 1a applied instead." But as the table shows, branch coverage is strongly recommended (++) at both ASIL B and D, and MC/DC is strongly recommended at ASIL D. Statement coverage, conversely, drops to merely recommended (+) at ASIL D.

In other words, ASIL B isn't a hard ceiling — it's that the evidence gathered so far only supports ASIL B. Claiming ASIL D would require filling in 1b and 1c in Table 9, which means re-establishing branch coverage and MC/DC across the entire core subset. No public document lays out a plan to do that.

The same document has a few more cells that embedded engineers in particular should note.

• Table 7, 1m, Resource usage evaluation. Strongly recommended at ASIL D. The verdict: "not applied — it's just a library, so it's the integrator's responsibility." Translated into embedded terms, this is stack-depth analysis and WCET. Using certified core doesn't come with answers about how much stack it eats or what the worst-case execution time is. That's your job.
• Table 6, 1j, No recursion. Strongly recommended at ASIL D. The verdict: "not applied." The exact wording: unconditional recursion is prohibited (except for #[lang_item]s where the compiler substitutes the body), but conditional recursion is allowed. On an MCU with a tight stack budget, that's not a line to skim past.
• Table 7, 1g, Data flow analysis. Strongly recommended at ASIL D. "Not applied — no internal data flow to analyze, no global state, everything via well-defined interfaces only."
• Table 1, Modeling and coding guidelines. The verdict here is blunt: the certified core library has no coding standard. The reasoning is that using upstream Rust's own lints and tests as-is keeps drift from upstream low, and more drift means more maintenance burden and more bug surface. That's an unfamiliar answer if you're used to MISRA, but the logic itself is defensible.
• Tables 2/3/4, software architecture design. All "not applicable, there is no architecture." The core-certification requirements document says the same thing: the core library is small enough that it doesn't need a software architecture.
• Table 8, 1b/1c, equivalence class generation/analysis and boundary value analysis. Strongly recommended at both ASIL B and D. Verdict: "partially applied." The text is candid — coretests' test cases were built with great care, but Ferrous Systems did not exhaustively review whether boundary and extreme values are always tested. The argument that follows is that achieving 100% line coverage guarantees every code path executed and that no code was left untested for lack of a test on a particular input.

And the requirements-management approach itself is contentious. The Requirements Management chapter of core-certification opens with: requirements are implemented as doc-comments. A function's doc-comment is that function's requirement, a module's doc-comment is the module design, and requirement identifiers are "Ferrocene version + the function's module path." How requirements trace to tests: since a function's requirement is the doc-comment above that function, requirements trace to functions; certification relies on code coverage to guarantee each function is sufficiently tested; therefore, if every function is covered by tests, every requirement is covered too; therefore there's no need to manually trace tests to requirements.

Whether you find this argument convincing is your own call. But it's clear why it's a clever choice — Rust core's doc-comments are unusually well-written by comparison and are enforced as doctests, so they're hard to let drift from the code. It's better to promote documentation that already exists and is already verified into requirements, rather than inventing a requirements spec that doesn't exist yet.

One thing worth stressing. The "not applied" cells above aren't a vendor weakness I dug up. Ferrous wrote them themselves and put them in an open-source repo. A safety-critical tool vendor's norm mapping is usually behind an NDA, and you typically sign a contract to see an assessment report. The fact that these tables are one git clone away might be the best part of this whole project. And these tables don't hide the ceiling — they explain it. If you want to know where ASIL B comes from, Table 9 is all you need.

Your Chip Is Probably Not on the List

Before getting into certification at all, there's something to check: is your target even on the list?

The 26.05.0 Safety Manual's qualification scope is limited to these combinations:

Host                       Target                        Certified  Uncertified          Qualified
aarch64-unknown-linux-gnu  aarch64-rhivos2-linux-gnu     core       alloc
x86_64-unknown-linux-gnu   aarch64-unknown-none          core       alloc
x86_64-unknown-linux-gnu   aarch64-unknown-nto-qnx710    core       alloc, std, test     proc_macro
x86_64-unknown-linux-gnu   thumbv7em-none-eabi           core       alloc
x86_64-unknown-linux-gnu   thumbv7em-none-eabihf         core       alloc
x86_64-unknown-linux-gnu   x86_64-unknown-linux-gnu      core       alloc, std, test     proc_macro
x86_64-unknown-linux-gnu   x86_64-pc-nto-qnx710          core       alloc, std, test     proc_macro

Here's what to read off this.

Only core is certified. alloc, std, and test are all uncertified. In the document's own words: the uncertified libraries provided are evaluated and tested within Ferrocene's qualification scope solely for the purpose of compiler use. End-user code using these libraries is currently outside the scope of Ferrocene's qualification; if you use them, certification is the end user's responsibility. If your design needs heap allocation, alloc is your homework starting today.

On the MCU side, there are only two qualified targets: the thumbv7em pair. That's Cortex-M4/M7. So what's missing? Ferrocene's target support tier document lists these under the Supported tier — riscv64gc-unknown-linux-gnu, thumbv6m-none-eabi (Cortex-M0/M0+), thumbv8m.base-none-eabi, thumbv8m.main-none-eabi, thumbv8m.main-none-eabihf (Cortex-M23/M33), armv7r-none-eabihf, armv8r-none-eabihf, wasm32-unknown-unknown, x86_64-pc-windows-msvc (host), and more. 26.05.0 added s390x and powerpc64le to that list.

Which means neither Cortex-M33 — used in half of today's newer secure MCUs — nor RISC-V is on the qualified list. 26.08 is set to promote armv7r-none-eabihf to qualified, so the direction is right, but as of today, "Rust is certified" does not mean "certified Rust runs on my chip."

The document also tabulates the difference between Supported and Qualified. Qualified runs the full test suite before every merge, tracks and provides known issues, and comes with a two-year support window and LTS. Supported means testing is "best effort," known issues are "documented only," and support patches are "critical only." It notes that a target can be promoted to qualified or quality managed on request — which is really a way of saying it's a contract conversation. Ferrous calls its own development model "contract-driven," and states outright that you can pay to focus the company's attention on the features that matter most to you.

The host is x86-64 Linux, and only that. macOS (aarch64-apple-darwin) is quality managed, and Windows (x86_64-pc-windows-msvc) is supported — neither is qualified. The machine producing a certification-target build has to be x86-64 Linux. Only the RHIVOS row is the exception, using an aarch64-unknown-linux-gnu host.

So What's Still Left to You

The Safety Manual's Constraints list gives each item an identifier. Filtering to the core-related ones:

• CORE_CSTR_0020_PANIC_ABORT — the user must always pass -C panic=abort to rustc.
• CORE_CSTR_0030_SUBSET_ONLY_STABLE — experimental functions in the certified subset must not be used. nightly features are out of scope entirely.
• CORE_CSTR_0060_VERIFY_MACROS — the user must verify that all macro-generated code is correct. That's a demanding line for a Rust codebase that leans on macros.
• CORE_CSTR_0060_VERIFY_ARCH — architecture-specific code must be reasoned about and tested in the application context. The wording is blunt: we guarantee the compiler emits the instructions you asked for correctly, not that those instructions make sense in context. This applies to the entire core::arch module and core::hint::spin_loop.
• CORE_CSTR_0070_VERIFY_FLOATS — floating-point code depends on external conditions like which FPU is in use and which operations are implemented in hardware. The user must thoroughly test floating-point computations in their own application and hardware context, and must not rely on compiler and library qualification alone as the argument for correctness.
• CORE_CSTR_0040_MATCHING_VERSION — the user must verify that the core and rustc versions match.

To that, add the "Handling Unsafety" chapter of the rustc-side Safety Manual. Minimum obligations when using unsafe: localize the use of unsafety as much as possible and never let it cross module boundaries; the module must do exactly one job; use assertions, preconditions, postconditions, and invariants on both the unsafe code and its clients; and comment on safety on both sides. The minimum obligations for verification are heavier still: at least two senior engineers must code-review it, or a third-party review must be used; the entire module containing unsafe code must be reviewed; unit and integration tests must be run on both the unsafe code and its clients. And a mitigation strategy must be developed.

There are operational obligations too. The Known Problems database is accessible only to customers with an active subscription (problems.ferrocene.dev sits behind a login wall). And the Safety Manual is direct about it: it is the customer's responsibility to become aware of newly discovered problems and apply the procedures described in new DB entries — whether by subscribing to notifications or monitoring periodically. Buying a qualified compiler isn't the end of it; you have to build a process inside your organization for watching that compiler's defect notices.

Finally, environment. The Degraded Environment chapter flags RUST_TARGET_PATH and RUSTC_BOOTSTRAP as potential sources of error, and states the user must verify these variables are not set. RUSTC_BOOTSTRAP is, unsurprisingly, the escape hatch that force-opens nightly features on a stable compiler.

When Not to Use This

Laid out honestly:

Don't, if

• Your application is ASIL D or SIL 3 and you're relying on core to get you there. The library is ASIL B / SIL 2. The compiler being an ASIL D tool doesn't close that gap. Closing it is on you, and Table 9 tells you exactly what's missing.
• Your target isn't on the list. On RISC-V, Cortex-M0/M23/M33, you get a compiler that runs fine — not a certification argument. It can be promoted by contract, but that's a budget-and-schedule conversation.
• Your design requires the heap. alloc is outside the certification scope, and the docs say explicitly that it's the end user's responsibility.
• You need to build certification-target artifacts somewhere other than Linux. Host qualification is x86-64 Linux only.
• This isn't a safety-critical project to begin with. This is probably the most common case. You gain nothing from certification and still pay the subscription (per the vendor's own notice, €25 per user per month or €240 per year, as of February 2026) and the subset discipline. Use upstream Rust. If you're new to embedded Rust altogether, the no_std hands-on guide will help you a lot more.

When it earns its keep

• Your product falls within ASIL B / SIL 2 / IEC 62304 Class C, your target is Cortex-M4/M7 or Armv8-A (or QNX 7.1), and you can design around no_std. Sonair and Kiteshield sit exactly here.
• What you need is the certification material more than the certification itself. Ferrocene's Safety Manual, Qualification Report, and norm mapping being open source means you have something to hand an assessor — and that's worth more than it sounds.
• Your organization can absorb the subset discipline. Every time the lint fires, a decision has to be made — rewrite it, ask Ferrous, or write your own safety argument and #[allow] it. You need a review process that can absorb that.

Closing

The one-line version: the compiler is an ASIL D tool, and the library is ASIL B software. These are two different statements, both true, and the moment you mash them into one you get a plan that's wrong.

The real 2026 news isn't "Rust got certified" — that's already years old and only half right. The real news is three things. First, the certified subset is genuinely growing — symbols went from 5.2 thousand to 8.8 thousand in one release, and with core::fmt landing, the constraint that "panic messages on certified targets are static strings only" has gone away. Second, the enforcement mechanism was promoted from a standard-library fork to a compiler pass. Third, the vendor is documenting the holes in its own evidence in a public repository.

There's a clear thing to watch for going forward: whether the day comes when Table 9 marks branch coverage or MC/DC as "Applied." That's the gate to an ASIL D core, and no public document today says it's coming. Until then, if you're evaluating Rust for an embedded safety-critical project, read the five lines of sphinx-substitutions.toml and the three lines of the method table before you read the one-line marketing pitch. The answer is all there.

References

• Ferrocene 26.02.0 now available! (Ferrous Systems, February 15, 2026) — ASIL B added, certified functions 2,903 → 5,169 (vendor's own count)
• Ferrous Systems Achieves IEC 61508 (SIL 2) Certification for Rust Core Library Subset (December 3, 2025) — the first core subset certification, Sonair and Kiteshield case studies
• Callgraph analysis (Jynn, April 1, 2026) — why and how the ferrocene::unvalidated lint replaced subset targets
• ferrocene/ferrocene — open-source repository (MIT OR Apache-2.0)
• 26.05.0 release notes source (release/1.95) — core::fmt certification, lint introduction, target changes
• 26.02.0 release notes source (release/1.92)
• ISO 26262 6-Method Tables — method-by-method applied/not-applied table for core certification
• Core Certification scope — Route 3S / SEooC, defining the certification target
• Core Certification requirements — "requirements are implemented as doc-comments"
• Safety Manual qualification scope — qualified-target/library table, user responsibilities
• Safety Manual core constraints — the list of user constraints
• Target support tier document — Qualified / Quality managed / Supported / Experimental
• Ferrocene public documentation site (development-branch preview — warns the docs themselves may be inaccurate)
• Ferrocene 26.02.0 adds automotive core certification (eeNews Europe, March 19, 2026) — independent coverage
• Embedded Rust no_std hands-on (related post)