Memory safety
One safe language, zero C
EFI stub, kernel, drivers, and userland are all Sigil. The entire class of C
memory-corruption defects — the root of most safety recalls — is absent by design, not patched.
INDUSTRY PACKET · SAFETY-CRITICAL & HIGH-ASSURANCE
Systems where a bug is not an option
Medical · Avionics & defense · Industrial control · Automotive
In these domains, "it usually works" is a recall, a grounding, or a fatality. They demand memory safety, hard isolation between components, and behavior you can prove — not test-and-hope. sigilOS is architected for exactly that from the first principle. This packet is honest about where that architecture is proven today and where certification is still ahead of us.
The problem
High-assurance software is dominated by a decades-old stack: C or C++ on a real-time OS (QNX, VxWorks, INTEGRITY), wrapped in an enormous, expensive certification effort (IEC 62304 for medical, DO-178C for avionics, IEC 61508 for industrial, ISO 26262 for automotive). That effort exists largely to compensate for the language underneath: C gives you no memory safety, no enforced isolation, and no way to state — let alone prove — what a function is allowed to do. Teams spend years and fortunes proving, by review and test, properties the toolchain never guaranteed.
The isolation story is just as fragile. Most embedded stacks run with ambient authority: a component that should only read one sensor can, in practice, reach memory and peripherals it was never meant to touch. Partitioning helps, but it's bolted on, not the substrate.
Why sigilOS is built for this
We didn't harden a general-purpose OS for safety-critical use. We built the properties that certification exists to establish into the substrate — the language and the kernel — so they hold by construction instead of by audit.
Isolation
Capability-secure by construction
No ambient authority. Every resource access is an unforgeable capability enforced
at the hardware seam by the MMU. A component reaches exactly what it was handed — nothing more.
Provable behavior
Contracts checked before runtime
requires/ensures/invariant with blame;
effects are in the type (an undeclared side effect is a compile error). Proven statically, then
erased from the binary — assurance with no runtime tax.Trusted toolchain
Verified, reproducible TCB
The compiler self-hosts and is fixpoint-verified (it rebuilds a bit-identical
copy of itself); the bootstrap seed is byte-reproducible. Verify the artifact — don't trust the
source.
Determinism & uptime
Fault-isolated, auto-restart
Processes fail in isolation and restart without taking the system down — the
STABLE pillar, aimed at the availability these systems require.
One platform, many devices
Pi 3 to workstation, one image
One HAL, two backends, a 1 GB floor. The same verified base spans a small
sensor node and a control workstation — one assurance argument, not five stacks.
The trade we don't make
A certified RTOS gives you real-time rigor but not a memory-safe language, a capability model, or proven contracts. A memory-safe language gives you safety but not an OS, isolation model, or the metal. sigilOS is built to carry all of it on one safe language — which is exactly the combination this vertical has never been able to buy off the shelf. See the full dimension-by-dimension comparison.
The standards we're building toward
The architecture maps directly onto what these frameworks ask for — memory safety, freedom from interference between partitions, deterministic behavior, and a trustworthy toolchain with traceable evidence:
- Medical — IEC 62304 (software lifecycle), IEC 60601 systems.
- Avionics & defense — DO-178C with DO-330 tool qualification; MILS-style separation.
- Industrial — IEC 61508 functional safety (the SIL framework).
- Automotive — ISO 26262 (ASIL).
Our provable-by-construction model is designed to turn a large part of these assurance arguments from "test until we believe it" into "the toolchain guarantees it, here is the evidence."
Where we actually are — no hype
We hold ourselves to one rule: "working" means observed on real hardware, not a green checkmark. Applied to this packet:
- sigilOS boots on real x86-64 hardware to a rendered login; the capability model, effect-typed contracts, and self-hosting reproducible compiler are real and in the tree today.
- SHIPPING The Sigil language and native tooling run now; you can read the code, build it, and evaluate the model.
- IN PROGRESS Raspberry Pi 4B bring-up and full driver coverage are active work, in the open on our blog and changelog — including the honest hard parts.
- NOT YET sigilOS is pre-1.0 and not certified to any of the standards above. We will not tell you to put it in a pacemaker or a flight computer today. What we offer now is the architecture that makes that certification path credible — and a partner to walk it with, in the open.
Who this is for
Teams building the next generation of a safety-critical product who are tired of paying the C-and-audit tax, and who plan on a multi-year horizon — where starting on a substrate that is memory-safe, capability-isolated, and provable by construction changes the shape of the whole certification effort. If you need a shipping, certified RTOS in production this quarter, we'll tell you plainly: that's not us yet. If you're architecting for the decade, let's talk.