Why does OCaml matter here? Untrusted code running on a satellite is a huge security risk, and OCaml is an ideal safe language to run in space. In his ICFP 2022 keynote, KC Sivaramakrishnan looked back on the decade-long engineering effort that produced OCaml 5, the release that put safe and performant multi-threading into the OCaml runtime.

KC ended his talk speculating that OCaml 5.0 would go to the moon, due to its language features that would deliver C/Rust-like performance on demand while keeping the mathematical rigour of classic ML. Here at Parsimoni, we took his words a bit too literally :-)

The host satellite circles the Earth every ninety minutes or so. A few months after Virgile Robles and I hacked on this over Christmas, we (virtually) jumped around when we saw this:

2026-04-23 18:48:06  SpaceOS/Borealis (BPv7, BPSec, OTAR) by Parsimoni
2026-04-23 18:48:06  ClusterGate-2 proxy [single iteration]
2026-04-23 18:48:06  Config: scid=100, tm_vcid=0, tc_vcid=4, tm_spi=1, tc_spi=2, tm_frame_len=1115
2026-04-23 18:48:06  Session keys: EK=0x0100 AK=0x0101 active
2026-04-23 18:48:09  Telemetry health: { ... "status": "healthy" }

What is actually running

Borealis is a daemon. On both the ground and the satellite it speaks a normal client-server protocol (telemetry queries, commands and responses, OTAR rekey requests), the same shape as any production server. What is unusual is the wire underneath.

The protocol stack is a pure-OCaml implementation of CCSDS, the protocol family that links spacecraft to the ground. It covers every layer from radio framing up through Bundle Protocol and the security extensions on top; the binary formats are described as ocaml-wire codecs.

On ClusterGate-2, only the upper layers of that stack are exercised. The satellite has no network connectivity from outside. The only ground link is filesystem upload and download via DPhi's API: a file written to the uplink directory is forwarded by DPhi on the next pass, and downlink works the same way. Borealis treats that filesystem as a delay-tolerant network. Every command, response, telemetry sample and image chunk is serialised into a BPv7 bundle and written to disk; DPhi forwards the file as opaque bytes.

BPSec wraps each bundle in two extension blocks: one encrypts the payload, the other authenticates it. Sequence numbers reject replays, and the pre-shared keys (rotated by OTAR, below) keep the routing path out of the trust path. The satellite operator sees only opaque bundle bytes; nothing in the routing path can read, modify, forge or substitute the contents.

This matters because we are tenants on someone else's hardware. On a hosted-payload satellite multiple tenants share a single bus, and container isolation alone would not suffice. A shared Linux kernel means kernel-level CVEs regularly break the tenant boundary, and the same primitives keep resurfacing in new forms: Dirty Frag (a universal Linux LPE published this year), Fragnesia (a close cousin in the same family), and "Copy Fail", a Linux kernel privilege escalation disclosed in late April that hit every major distribution at once. Earlier rounds (Dirty Pipe in 2022, the nf_tables use-after-free exploited for container escape in 2024) suggest there will be more. On a ground server you can run the package manager and reboot; in orbit, kernel patching is its own delivery problem with its own delay, and is sometimes not possible at all. The cryptographic envelope around each bundle is the only durable guarantee.

Beyond confidentiality and authenticity, the long-mission threat model needs key rotation. Borealis supports OTAR (Over-The-Air Rekeying) for its post-quantum signing keys (ML-DSA-65). Those keys live for the life of the satellite (ten to fifteen years), which is why NASA's Space System Protection Standard (NASA-STD-1006A) treats post-quantum command authentication as a requirement rather than a future option. OTAR lets us rotate the post-quantum keys without re-flashing the satellite. To our knowledge this will be the first public in-orbit demonstration of post-quantum OTAR; we plan to exercise the rotation on a later pass.

Borealis runs as a guest on DPhi's hosted-payload module: an Arm SoC (four Cortex-A53 cores, 4 GB RAM) running Linux. The flight binary is 5-10 MB, statically linked, shipped as a FROM scratch Docker image. It polls the bus for telemetry (angle, speed, position) and an onboard camera (a low-quality fish-eye, good for demos only). The core of the satellite-side loop looks like this:

let send_telemetry t ~prefix payload =
  let bundle =
    make_bundle t ~source:Eid.sat_telem
      ~destination:Eid.ground_telem ~payload
  in
  match protect_bundle t bundle with
  | Ok protected ->
      ignore (write_bundle t ~dir:(downlink_dir t.config) ~prefix protected)
  | Error _ -> log t "Failed to protect telemetry bundle"

protect_bundle applies BPSec with keys from the SDLS Security Association, the cryptographic parameters ground and satellite agreed on at provisioning. If any of that fails, no bundle leaves the satellite.

The uplink path mirrors the downlink path. The satellite reads bundles from /data/uplink/, unprotects each with BPSec, and routes by destination at the bundle layer:

if dest = Eid.sat_cmd  then handle_command t payload
else if dest = Eid.sat_otar then handle_otar t payload
else log t "Unknown destination"

Text commands are short UTF-8 strings parsed into an ADT; the typechecker enforces exhaustive dispatch:

type cmd = Ping | Check | Capture | Halt

let dispatch t = function
  | Ping    -> send_response t ~prefix:"pong" "PONG"
  | Check   -> run_self_check t
  | Capture -> capture_and_send t
  | Halt    -> t.shutdown_requested <- true

Adding a new command means adding a constructor; the compiler then flags every place it is not yet handled.

OTAR rekey messages take the other branch. The payload is binary rather than text, encrypted under a master key that was loaded onto the satellite at integration time and lives in process memory on the module (the module has no TPM or secure element, because building a radiation-tolerant one is still an open hardware problem). The satellite decrypts the new keys, holds them in a staging slot, and activates them. The current flight loop activates on receipt; the protocol also supports a separate ground-driven activation step where the operator verifies the install before committing, and switching to that path is a flight-loop change, not new code.

The master key itself has no rotation path. It was installed on the payload before the satellite was mated to the launcher, and there is no more-trusted channel to deliver a new one once the spacecraft is in orbit. If the master key is lost, this stack is unreachable. That is the honest failure mode for a long mission with no hardware-backed key storage.

What is coming next: OxCaml

OxCaml is Jane Street's compiler branch on top of OCaml. Its mode system matters on the satellite hot path. Locality lets us mark allocations stack-bound, so they never reach the heap and never reach the GC. Uniqueness and capabilities track shared mutable state in the type system, turning data races into compile-time errors on the parallel parts of the stack.

The hot path on the hosted-payload module is CCSDS dispatch: every CFDP segment, every COP-1 frame, every camera packet flows through a Space Packet header decode and an APID-based routing step before the payload reaches the application logic. Real-time on-board dispatch with hard scheduling deadlines on every pass is exactly the workload the EU ORCHIDE Horizon Europe project was set up to address (the consortium where this on-board work first started inside Tarides, and which eventually led us to spin Parsimoni out as a dedicated space-software company).

Switching to OxCaml with exclave_ stack_ annotations drops p99.9 latency from 29 ns to 9 ns per packet on the dispatch hot path, and removes GC pressure entirely (394 minor GCs to zero over 25 million packets). Throughput is comparable; the win is jitter, and on a hosted-payload module with hundreds of microseconds of jitter budget, that is the whole game.

The recipe is mechanical: turn a per-iteration heap allocation ({ apid; seq_count; data_len }) into a stack-allocated one (exclave_ stack_ { apid; seq_count; data_len }), and require the consumer to take it @ local. The type system proves the record cannot escape the dispatch scope; the compiler emits no heap traffic; the GC has nothing to collect.

Setup. Apple M5 Max, macOS 25.4. Stock OCaml 5.3.0 versus 5.2.0+ox (Jane Street's OxCaml fork). Workload: 100 000 batches of 256 CCSDS Space Packet header dispatches each (about 25.6 M packets total), each routed through an [@inline never] handler so the record genuinely escapes. Median of 10 runs.

Why OCaml

Around 70% of severe CVEs in C/C++ codebases trace to memory corruption (buffer overflows, use-after-free, integer overflows), based on Microsoft's MSRC analysis (2019) and Chromium's 2020 study. Our security extensions (SDLS, BPSec, and OTAR) all handle ciphertexts and key material, which is exactly where memory bugs hurt most. The C-based incumbent in this domain, NASA CryptoLib, has had its own such bugs: for instance, a heap buffer overflow in the TC frame parser, triggered by an integer underflow on a crafted frame. An OCaml implementation removes that class of attack surface from the application logic by construction. The runtime, the kernel underneath, and the bootloader are still C and still in the TCB: memory safety helps where it helps, and is not a substitute for a trusted compute base audit.

Beyond what OCaml gives us today, the language itself keeps advancing. Jane Street maintains OxCaml, an experimental branch of OCaml. Its design goal is safe, predictable control over the performance-critical parts of a program, opt-in only where you need it, and still in OCaml: every valid OCaml program is also a valid OxCaml program. OxCaml Labs (Anil Madhavapeddy's group at Cambridge) and FP Launchpad (KC Sivaramakrishnan's lab at IIT Madras) are pushing OCaml forward; Tarides upstreams the pieces that are ready into the mainline.

I somehow focused on the moon :-) Going to orbit first meant prioritising correctness over performance, because protocol bugs in orbit are expensive to fix. The defence runs through every layer of the stack: type checking, formally verified cryptographic primitives (libcrux, fiat-crypto), interop testing, and dependency audits.

Take three of those layers as concrete examples. The wire-format codecs are generated from a typed schema, reject malformed bytes at decode time, and feed Microsoft's EverParse parser generator, which produces C validators formally verified in F*. The protocol state machines are encoded as GADTs, so the typechecker rejects invalid transitions at compile time. An interop pipeline runs against existing reference implementations, catching what the type system cannot express and surfacing defects in upstream libraries along the way.

Beyond what these layers catch, the functional core lets us ship the same code as flight software, ground software, and test oracle. The protect_bundle above is the same function in all three roles. We feed recorded traffic from one role to the others and compare outputs byte-for-byte. The OCaml code is also the reference implementation that other implementations are validated against. This is the nqsb-TLS approach (Kaloper-Mersinjak, Mehnert, Madhavapeddy and Sewell, USENIX Security 2015), and it has held up in TLS for a decade. Nitrokey's NetHSM runs the same OCaml TLS stack in shipping hardware security modules today.

Borealis is no exception. It might look like we wrote a full CCSDS protocol stack from zero to in-orbit demonstration in a couple of months. That is not what happened. The core libraries come from MirageOS, and have been running in production on the ground for the last decade. A library operating system is, by definition, a large toolset where you pick the pieces you need.

The ASPLOS 2013 unikernels paper asked whether sealed, single-purpose images could improve cloud infrastructure. A decade later, the same libraries run in Docker Desktop on hundreds of millions of laptops. Now they run in space, on ClusterGate-2, doing the system-level plumbing as a Linux process rather than a unikernel, in places I did not predict when we first designed them.

If you are building payload software, considering hosted payloads on your bus, or want to compare notes on OCaml in flight, talk to me or write to the Parsimoni team.

The library-OS idea has a pedigree at Cambridge. Nemesis came out of the Computer Lab in the 1990s. Xen, the hypervisor that provides the secure low-level runtime for such designs, followed from the same lab in the 2000s. In the 2010s, in Jon Crowcroft's group at Cambridge, we built MirageOS on top (Anil, Balraj Singh, Richard Mortier, and others) as the higher-level library OS written entirely in OCaml. We coined the term "unikernels" for these single-purpose, sealed images (the paper describing this line of research received a test-of-time award in 2025 and I wrote about that part of the story in February). In 2015, Anil, Balraj, and I spun out Unikernel Systems to bring MirageOS to production. We brought together the MirageOS team at Cambridge with the key maintainers of Rumprun, a unikernel toolchain built on NetBSD's rump kernels. Justin Cormack (who became Docker's CTO a few years later) was among them. Mosaic Ventures, who supported us very early on, put it this way: "MirageOS was a great technology, and had a number of applications. We weren't the only ones who saw its potential." Docker acquired our company a few months later, and we became the "Piñata" team inside Docker.

At Docker, we built what nobody was expecting us to build: a desktop app. I was lucky enough to manage the first releases of what would become the most-desired developer tool in every Stack Overflow Developer Survey since 2019: Docker for Mac and Docker for Windows. The beta shipped on Docker's third birthday, in March 2016. It has been downloaded hundreds of millions of times since. The launch post credited MirageOS directly: "the translator between Linux and Mac OS X networking uses the MirageOS TCP/IP implementation." That translator was vpnkit, an OCaml unikernel (running as a userspace service) built on MirageOS libraries that acts as the network proxy inside Docker Desktop.

Read the paper to know more (and find the full team credit in the acknowledgments)!

However, scanning HTML snippets comes with downsides. When the HTML is generated (either statically by a blog engine, or dynamically with browser apps), the strategy falls short. Tailwind proposes various strategies to overcome this (like embedding static CSS classes in its config file), but I don't find them very helpful when I'm developing in OCaml.

So six months ago I started reimplementing Tailwind in OCaml. tw began life targeting v3, where classes project directly to CSS values; it has since fully migrated to v4, a substantial architectural change that swaps concrete values for a variable-based theme layer. It passes the 905 upstream tests extracted from Tailwind's own TypeScript suites, and the tw CLI emits CSS that is byte for byte identical to the reference tailwindcss under --optimized --minify. Here is tw compiled to JavaScript with js_of_ocaml. Paste any HTML snippet on the left and the CSS regenerates in a sandboxed iframe on the right:

Under the hood, Tw.of_string parses each class and Tw.to_css compiles the set into a v4 stylesheet. Unknown classes show up in the red panel. The palette, arbitrary values (bg-[#ff00ff], bg-[oklch(60%_0.2_30)]), and every variant combination (hover:, dark:md:, group-hover:) work. What doesn't is Tailwind's config-level machinery (@theme, @apply, custom tokens); those are exposed on the OCaml side via a Tw.Scheme.t argument to Tw.to_css.

A Tailwind v4 bonus

Since Tailwind v4, every utility resolves through a CSS custom property (var(--color-gray-900), var(--spacing), and so on). That makes the v4 engine substantially more complex than v3, where utilities were emitted as concrete values, but it also makes the output tweakable from the browser at runtime: change a token, the whole page restyles. tw inherits this along with everything else Tailwind v4 gives for free. Drag a colour or spacing below and look around the page:

Why an OCaml port

My OCaml web stack had one irreducible dependency on Node. Generating a Tailwind stylesheet meant invoking the npm package or bundling the Rust-compiled standalone binary. Nothing else in an OCaml web project still required a non-OCaml toolchain.

The trigger was mirage-www, the MirageOS homepage. It is a 1,100-line OCaml application serving TLS traffic through an OCaml stack: HTTP, TLS, TCP/IP, and the ethernet and block-device drivers are all written in the same language and linked into one self-contained binary. The stylesheet was the one thing the build could not produce from its own dependencies. Contributors on FreeBSD and Windows kept hitting missing binaries and npm drift; Tailwind has improved its platform coverage since, but for a project whose other inputs are all OCaml, the gap was awkward. Pull request mirage-www#860 deletes the tailwindcss script tag and the npm dev-dependency and replaces them with tw.html directly. Once the PR lands, the build needs only an OCaml compiler and opam.

What it covers

tw implements every core Tailwind v4 utility and both official plugins, @tailwindcss/typography and @tailwindcss/forms. Responsive variants, state variants, dark mode, group and peer modifiers, pseudo-elements, OKLCH colours, the color/opacity syntax, arbitrary values like min-h-[6rem], and the preflight reset all behave the way they do in the reference binary. The tests themselves come straight from the upstream project: each case pairs an input class with the expected CSS from Tailwind's own suites. tw's runner reparses both sides so that whitespace differences do not matter, and any other difference fails the test.

The string API sits on top of a typed OCaml AST. Tw.of_string parses each raw class into that AST, which is then lowered through several stages into the final stylesheet. Building the AST directly instead of going through strings catches misspelled utilities as compile errors, and the combinators reject invalid combinations:

open Tw

let button =
  [ flex; items_center; gap 4; px 6; py 3;
    bg blue; hover [ bg ~shade:600 blue ];
    rounded_lg; shadow_sm;
    dark [ bg ~shade:800 gray; text ~shade:100 gray ] ]

The same binary produces the utility strings for HTML and the CSS for the stylesheet, from one source, in one dune build.

Shipping HTML and CSS together

OCaml has several mature libraries for composing HTML fragments type-safely. Tyxml gives you a W3C-accurate AST; Dream has Dream.html; Htmlit is a small combinator library; Eliom crosses the client/server boundary. None of them answer the CSS question. Styled fragments either carry inline style="..." attributes (no caching, no variants, no hover states) or refer to classes defined in a separate hand-maintained stylesheet.

Classes in tw are first-class OCaml values. A UI fragment carries the styles it needs as part of its type, and the build collects every class used across every fragment into one stylesheet:

open Tw_html

let card ~title ~body =
  div ~tw:Tw.[ flex; flex_col; p 6; bg white; rounded_lg; shadow_md ]
    [ h2 ~tw:Tw.[ text_lg; font_semibold; mb 2 ] [ txt title ];
      p  ~tw:Tw.[ text_sm; text ~shade:600 gray ] [ txt body ] ]

Reusing card from another page adds the eleven utilities it needs to the generated CSS, deduplicated with the rest of the site. The contract between the HTML tree and the stylesheet is two functions:

Tw_html.to_tw : Tw_html.t -> Tw.t list
Tw.to_css     : Tw.t list -> Cascade.Css.t

No source scanner, no safelist, no content: [...] configuration. Reusable components can be packaged as opam libraries and exchanged between projects without a CSS-sharing protocol.

Matching byte for byte

Tailwind v4's engine is a CSS generator, so verifying the port means comparing two stylesheets structurally, not as byte streams. A string diff over 50,000 lines of minified CSS is unreadable; a byte-for-byte target is only useful if you can see which rule differs and how when it breaks.

Existing CSS diff tools either predate Tailwind v4 or are limited to CSS Syntax Level 2/3, so they do not handle @layer, @container, nesting, or modern colour spaces. So, as I have discussed before, I had to write one: Cascade, whose cssdiff CLI parses both stylesheets into a typed AST (CSS Syntax Level 3 through Selectors Level 5) and reports rule-level differences: this selector's margin-top changed from 1.25em to 1em; this @layer has a new declaration; this @container rule moved from position 10 to position 200. The tw CLI wraps both halves. tw -s <class> asks the basic question, what CSS is generated for this class, and tw -s <class> --diff compares that output against the reference tailwindcss using cssdiff (forcing --optimized --minify on both sides). Porting Tailwind became a tight loop around that second one-liner: run, diff, fix, repeat. The same one-liner now drives a big chunk of the test suite: differential testing against tailwindcss, one class at a time.

The kind of bug cssdiff caught is the kind I would not have found by reading the spec. A few examples from the commit log:

• Width precision. w-1/3 should print as 33.3333%, not 33.333333%. Tailwind rounds fractional widths to four decimal places. CSS does not require this; Tailwind does it for stable diffs.
• Hex shortening. Tailwind compresses 8-digit hex colours to 4-digit form when each pair is repeated: #ffffffcc becomes #fffc, but only inside opacity-modifier output.
• OKLCH out-of-gamut. Some OKLCH colours fall outside the sRGB triangle; Tailwind's fallback renders the gamut-mapped sRGB approximation per CSS Color Level 4. Implementing the mapping algorithm was a small detour through colour science.
• Variant ordering. Doubly-nested hover:group-[&_p]:hover:flex must sort after both single-nested forms, otherwise the optimiser cannot merge their selectors. The comparator distinguishes three nesting levels.

None of these are wrong; they are choices the reference binary makes that only a strict diff would surface.

Getting it

opam pin add tw https://github.com/samoht/tw.git

The code is on GitHub under the ISC licence. An opam release will follow once the API stabilises. Try it, and tell me what breaks.

The Tailwind Labs team built the framework this library targets; the reference tailwindcss binary is the oracle every tw output is checked against. If you ship anything built with tw, sponsor them.

The protocol suite that handles this is CCSDS (Consultative Committee for Space Data Systems), a set of standards maintained since 1982 by NASA, ESA, JAXA, and most other space agencies. Nearly every satellite launched in the last 30 years speaks some subset of CCSDS. If you want to talk to a satellite, this is the stack you need to understand.

Most implementations are proprietary C libraries inside ground segment frameworks. I wanted something I could test in a browser.

So I have been implementing these protocols in OCaml using the typed binary codec approach I described in the wire formats post. The demo below runs the real parser in the browser, so you can play with the encodings directly. Type a message and watch it get wrapped into a telemetry frame (Space Packet inside a TM frame, exactly as a satellite would transmit it). Hover any byte in the hex dump to see which protocol field it belongs to.

The layers

CCSDS protocols were designed to run on spacecraft with kilobytes of RAM, fixed-point processors, and no operating system. The formats are deliberately simple: small headers, fixed fields, no optional extensions, no negotiation. A flight computer from the 1990s can parse them. The layers that matter for most missions are described in the Blue Books (the ratified standards). The newer stuff (recommended practices like delay-tolerant networking) lives in the Magenta Books, and the really new stuff (experimental specifications like post-quantum crypto) in the Orange Books.

From top to bottom:

Space Packets are the application-layer unit (CCSDS 133.0-B-2). A Space Packet is a 6-byte header followed by up to 65,536 bytes of data. The header contains a version number, an application identifier (APID, 11 bits), a sequence counter (14 bits), and the data length. That is it. No checksums, no encryption, no retry logic. Space Packets are deliberately simple because everything else is handled by the layers below.

Transfer Frames carry Space Packets over the radio link. There are two classic flavours: TM frames (CCSDS 132.0-B-3) for telemetry (satellite to ground) and TC frames (CCSDS 232.0-B-4) for telecommand (ground to satellite). A TM frame has a 6-byte header with a spacecraft ID (10 bits), a virtual channel ID (3 bits), and two frame counters. TC frames are similar but smaller, designed for low-bandwidth uplinks. Both carry Space Packets as payload.

Two newer frame types exist for missions that need more flexibility: AOS (CCSDS 732.0-B-4) adds an 8-bit spacecraft ID and 6-bit virtual channel ID with a 24-bit frame counter, and USLP (CCSDS 732.1-B-2) unifies all four frame types into a single format with a 16-bit spacecraft ID.

Security sits between the frame header and the frame data. SDLS (CCSDS 355.0-B-2) adds authentication (MAC), encryption (AES-GCM), and anti-replay protection. Without SDLS, anyone with a dish and the right frequency can send commands to a spacecraft. With SDLS, every command is authenticated and every telemetry frame is encrypted.

Reliability is handled by COP-1 (part of CCSDS 232.1-B-2), a retransmission protocol for telecommand. The ground sends a command, the spacecraft acknowledges receipt via a CLCW (Command Link Control Word) embedded in the next telemetry frame. If the acknowledgement is missing, the ground retransmits. This is where the 10-minute pass window hurts most: every missed acknowledgement costs seconds that cannot be recovered.

How they compose

A typical downlink looks like this: the application generates data, wraps it in a Space Packet (6-byte header + payload), the packet is placed inside a TM frame (6-byte frame header + packet + optional error-correction trailer), SDLS encrypts and authenticates the frame, and the frame is transmitted over the radio link. The ground station receives the signal, decrypts the frame, extracts the packet, and delivers the data to the mission control system.

A typical uplink is the reverse: the operator creates a command, wraps it in a Space Packet, places it in a TC frame, SDLS authenticates it, and the frame is transmitted during the next pass window. COP-1 handles retransmission if the spacecraft does not acknowledge.

The key insight is that each layer is independent. The Space Packet does not know whether it is riding inside a TM frame or a USLP frame. The security layer does not know what the packet contains. This is the same separation that makes TCP/IP work: you can replace Ethernet with Wi-Fi without changing HTTP.

The OCaml implementation

Each layer described above has its own library (one per frame type, plus security and the feedback word):

I also have implementations of the file delivery protocol (CFDP), the ground station interface (SLE), the delay-tolerant networking stack for deep-space missions (Bundle Protocol, LTP, Contact Graph Routing), and most of the other Blue Book protocols. I will write more about them in the coming months and release the code properly on GitHub once the APIs stabilise.

All the libraries in the table use ocaml-wire to generate parsers and serialisers from a single typed definition. The wire description is the specification: a typo in a field width is a type error, not a runtime bug.

The parser descriptions are pure OCaml with no system dependencies. The same definitions compile to JavaScript via js_of_ocaml and to verified C via EverParse. The demo above runs the real space-packet parser in your browser, and the SDLS crypto! The same code runs in the test harness on my laptop. The EverParse path is still work in progress, but the generated C is zero-copy and allocation-free, so there is no obvious blocker to embedding it on a constrained target once the right glue code is written. Building for the browser first meant I could encode a frame, tweak a field, and watch the hex change before writing a single test. Same compilation story as the CSS engine and the conjunction assessment dashboard.

Each library has an alcotest suite with hand-written cases drawn from the blue book examples, plus round-trip fuzz tests using Alcobar (a Crowbar fork with an Alcotest-compatible API). The fuzz tests caught real bugs (an OCF/FECF masking error in the AOS encoder, for instance).

Several libraries have interoperability suites that round-trip frames against external implementations: SDLS against NASA CryptoLib 1.5.1 (byte-identical TC frames with AES-256-GCM), USLP against spacepackets-py (18 reference frames), LTP against NASA JPL's ION 4.1.4 (SDNV encoding), and CFDP against both spacepackets-py and dariol83/ccsds (Java). The CFDP interop tests found a byte-order bug in spacepackets-py 0.31.0, which is already fixed: KeepAlivePdu.pack() was using native endian instead of big-endian for the progress field, producing wrong bytes on every x86 and ARM machine. The CryptoLib interop tests also surfaced questions about IV handling in AOS that may be related to a confirmed bug in SA Create. More interop suites are in progress.

The wire approach I described in an earlier post is what keeps these parsers compact and correct across every layer. The whole stack is open source and being developed at Parsimoni as part of a larger effort to bring modern tooling to satellite software. If any of this is useful to you, do drop me a line -- I would love to hear about it.

I wanted to see what it takes to build a conjunction assessment system from scratch. I wrote an orbit propagator, a screening pipeline, and a 3D globe to visualise the results. The screening algorithm matches the TraCSS answer key (spherical hard-body test cases), and the whole thing runs in the browser.

Cosmos 1408

On November 15, 2021, Russia destroyed the Cosmos 1408 satellite with a missile. The debris cloud (over 1,500 trackable fragments) passed through the ISS orbit repeatedly. The crew sheltered in their escape capsules.

ISS (blue) and Cosmos 1408 debris (red) on November 15, 2021. Orbital elements are approximate (for illustration, not operational use). The animation starts 30 minutes before closest approach and runs at 60x speed. Drag to rotate, scroll to zoom.

This is the kind of event conjunction assessment exists to predict. Two objects in low Earth orbit approach each other at 10-15 km/s. Ground stations track both, but no position estimate is exact. Each one comes with an uncertainty envelope: not "the satellite is here", but "the satellite is probably within this region". Collision prediction takes those two uncertain positions at the moment of closest approach and computes a probability: how likely is it that the objects actually overlap? If the probability exceeds a threshold (typically 1 in 10,000), the operator fires thrusters to move out of the way.

The maths for computing that probability are well understood (a 2D integral over projected uncertainties, first published by Foster and Estes in 1992). The hard part is not the algorithm. It is knowing whether your implementation is correct. Getting a number is easy. Trusting the number requires open specifications you can read, and test data you can run your code against. Until recently, neither was easy to get.

Five components, one pattern

A conjunction assessment system needs five things:

Orbit propagation. Given a satellite's orbital elements (published as Two-Line Element sets on Space-Track and other catalogues), predict where it will be at any future time. The standard algorithm is SGP4 (Spacetrack Report #3), designed by NORAD in the 1980s and still the baseline for all catalogued objects. Vallado's Revisiting Spacetrack Report #3 is the modern reference; the TraCSS verification dataset provides test vectors.

Coordinate transforms. The propagator outputs positions in one reference frame, the collision geometry needs another, and the visualisation needs a third. Each conversion involves Earth rotation models and is easy to get subtly wrong. The IAU SOFA library documents the standard algorithms; Vallado's Fundamentals of Astrodynamics and Applications covers the practical implementation.

Message parsing. Collision warnings arrive as Conjunction Data Messages (CDMs), defined in CCSDS 508.0-B-1. A CDM contains the predicted time of closest approach, the miss distance, the relative speed, the uncertainty envelopes for both objects, and metadata about the data source. The CDM format is another CCSDS standard, similar to the ones I described in the wire formats post. There are at least three serialisation variants in active use (CSV from TraCSS, JSON from Space-Track, and the CCSDS text standard).

Probability computation. Project the two 3D uncertainty envelopes onto the plane where collisions happen (perpendicular to the relative velocity), then integrate the overlapping region. The result is a single number: the probability of collision. Foster and Estes (1992) describes the 2D method; the TraCSS dataset includes spherical test cases with expected results for validation.

Visualisation. Render the orbital geometry so an operator can see what is happening. Two satellites converging at 14 km/s look identical in a spreadsheet; on a globe, the crossing geometry is obvious. For an operator deciding whether to manoeuvre in a window of minutes, visual context matters.

The five components are standalone: I can test each one against its own reference data before connecting them. Without Vallado's test vectors I would not know if my propagator is correct; without the TraCSS dataset I would not know if my probability code gives the right answer. We learnt this in the MirageOS community when we built an email parser and had to release a corpus of a million messages because nobody had public test data. Open standards need open test data.

ssa.space

The result is ssa.space, a conjunction assessment dashboard. It loads the TraCSS verification dataset, propagates every tracked object, computes the collision probability for each close approach, and renders the results on a 3D globe. Close approaches are colour-coded by risk: red for dangerous, orange for watch-list, green for low. Click one to zoom in and see the orbital geometry at the moment of closest approach.

This runs on test data today (the TraCSS dataset includes difficult cases but is not live operational data). The entire stack is pure OCaml with no system dependencies, so it runs in the browser (via js_of_ocaml), on a server, and could run as a MirageOS unikernel on a satellite (the same architecture I described in the ASPLOS post). That is the direction we are pursuing with SpaceOS.

Today, collision avoidance runs through ground stations. A conjunction warning arrives 24-72 hours before closest approach, but the ground loop (downlink, screening, decision, command uplink) can consume most of that window. If the satellite runs the same screening algorithm on board, it can flag close approaches and pre-compute candidate manoeuvres before the next ground contact. The ground still approves, but time to first assessment drops to seconds.

What comes next

The application is live at ssa.space. The underlying libraries (sgp4, coordinate, cdm, collision, globe, cam) are work in progress and will be properly open-sourced when a full review is completed (currently validating against GMAT, NASA's General Mission Analysis Tool). The immediate goal is live data from TraCSS, Stargaze, or EUSST. If you have ephemeris data or screening results, get in touch.

That meant porting Tailwind's CSS generation to OCaml. To make sure the port was correct, I needed to compare its CSS output against the JavaScript original. The existing CSS diff tools are either abandoned or limited to CSS 2/3, and none of them handle @layer, container queries, nesting, or the modern colour spaces that Tailwind v4 generates. So I started writing one. Which needed a complete parser. Which grew into a typed AST and an optimiser, and ended up being useful on its own.

The result is Cascade, a 30,000-line OCaml library for parsing, generating, optimising, and diffing CSS. One of the tools it ships is cssdiff, a structural CSS comparison tool. Since Cascade is pure OCaml, it can be compiled to JavaScript via js_of_ocaml and run in the browser. Try it, or pick one of the examples below:

The toolkit

Cascade parses CSS strings into a typed AST, and provides a small eDSL to build the same AST from OCaml code. From that AST, it can render (pretty-print or minify), optimise (deduplicate and merge rules), and structurally diff two stylesheets. The parser uses hand-written recursive descent (does Claude have hands?) covering CSS Syntax Level 3 through Level 4 and 5 (modern selectors, colour spaces, @layer, container queries, nesting).

let css = Cascade.Css.of_string {|
  .btn {
    display: inline-block;
    background-color: #3b82f6;
    color: white;
    padding: 0.5rem;
  }
  .btn {
    background-color: #2563eb;
  }
|}

open Cascade.Css

let btn = Selector.class_ "btn"

let rules =
  [ rule ~selector:btn
      [ display Inline_block
      ; background_color (hex "#3b82f6")
      ; color (hex "#ffffff")
      ; padding (Rem 0.5) ]
  ; rule ~selector:btn
      [ background_color (hex "#2563eb") ] ]

.btn {
  display: inline-block;
  background-color: #3b82f6;
  color: #fff;
  padding: 0.5rem;
}
.btn {
  background-color: #2563eb;
}

.btn {
  display: inline-block;
  background-color: #2563eb;
  color: #fff;
  padding: 0.5rem;
}

The .btn example uses a few properties, but the library has 100+ typed constructors covering layout (box model, flexbox, grid), visual (typography, transforms, animations, filters), and logical properties.

Testing against Tailwind

How do you know a CSS parser is correct? The usual answer is "read the spec", and the W3C test suite covers parsing for individual features. But those tests check that browsers apply CSS correctly, not that a tool can safely transform it. How do you know that merging two rules across cascade layers or deduplicating a property does not change what the page looks like?

One approach that I found works well in practice is differential comparison against a reference implementation. For instance, to port Tailwind to OCaml, I run the JavaScript Tailwind CLI on the same input, then run the OCaml port, and compare the two CSS outputs byte for byte. The comparison is strict: same characters, same order, same whitespace. Not "structurally equivalent" (that would hide bugs in the comparison tool itself).

When the outputs diverge (and they do, constantly, during development), I need to know which rule changed and how. A 50,000-line string diff is unreadable. That is what cssdiff is for: a structural diff that says "rule .mt-4 changed margin-top from 1rem to 16px" is actionable. It works at the AST level, so a rule that moved from line 10 to line 200 shows as reordered, not as a deletion plus an addition. It handles @media, @layer, @supports, and @container blocks. This is the same tool running in the demo above.

The byte-for-byte target also keeps the optimiser honest. It would be easy to produce "correct" CSS that differs in harmless ways (different property order, different hex capitalisation). But allowing those differences means the diff tool would need to know which differences are harmless, which is exactly the kind of subtle bug that hides semantic errors. Matching the reference output exactly eliminates that class of problems.

Getting started

Two CLI tools ship with the library: cascade (format, minify, optimise CSS files) and cssdiff (structural comparison).

brew install samoht/tap/cascade

Or via opam:

opam pin add cascade https://github.com/samoht/cascade.git

The library requires OCaml 4.14 or later. The README has the full API overview and CSS specification coverage table.

I wrote Cascade because I needed it for my blog. It turned out to be useful beyond that: any OCaml project that generates, parses, or compares CSS now has a typed alternative to string manipulation. The source is on GitHub.

EverParse has a good answer to that problem, for on-earth software. It generates C validators and parsers with proofs of memory safety, arithmetic safety, double-fetch freedom, and correctness. It is part of Microsoft's Project Everest, which ran from 2016 to 2021 around F* (a dependently typed language from the ML family) and produced software that ended up in the Windows kernel, Hyper-V, Linux, Firefox, and Python.

The EverParse compiler seems like a perfect fit for embedded satellite software. I wanted to try it, but I did not want to write .3d files by hand (how do you maintain those? and how do you write serialisers from them?). So I wrote ocaml-wire, a combinator library that lets me describe a format once in OCaml, automatically write zero-allocation (when possible) parser and serialiser codecs, and generate the .3d schema and C glue from the same description.

I will use CCSDS Space Packets as the running example, because they are small, bitfield-heavy, and annoying to parse by hand.

EverParse

For a CCSDS Space Packet header, the .3d format is already close to the specification:

module SpacePacket

typedef struct SpacePacket {
  UINT16BE Version:3;
  UINT16BE Type:1;
  UINT16BE SecHdrFlag:1;
  UINT16BE APID:11;
  UINT16BE SeqFlags:2;
  UINT16BE SeqCount:14;
  UINT16BE DataLength;
} SpacePacket;

You can read this as two 16-bit words of bitfields, followed by a 16-bit DataLength field. EverParse turns this into a C validator you could link into flight software. The guarantees are useful: memory safety, arithmetic safety, double-fetch freedom, and correctness with respect to the .3d specification. They do not prove that the .3d file matches the blue book, nor that the C extraction from F* or the C compiler are bug-free. Still, this is exactly the kind of low-level code where mistakes hurt.

What .3d does not give me is the OCaml side. I would still need separate code for decoding, encoding, and field access.

The Same Header in OCaml

ocaml-wire lets me describe the same header once in OCaml, then use it directly in OCaml and project it to EverParse .3d. It can also generate the OCaml/C glue to call the verified validator. So, for the Space Packet primary header at least, I get an OCaml codec and a C validator from the same source.

Define named fields with Field.v, bind them to record projections with $, and assemble a codec with Codec.v:

open Wire

type packet = {
  version : int; type_ : int; sec_hdr : int; apid : int;
  seq_flags : int; seq_count : int; data_len : int;
}

let f_version   = Field.v "Version"    (bits ~width:3  U16be)
let f_type      = Field.v "Type"       (bits ~width:1  U16be)
let f_sec_hdr   = Field.v "SecHdrFlag" (bits ~width:1  U16be)
let f_apid      = Field.v "APID"       (bits ~width:11 U16be)
let f_seq_flags = Field.v "SeqFlags"   (bits ~width:2  U16be)
let f_seq_count = Field.v "SeqCount"   (bits ~width:14 U16be)
let f_data_len  = Field.v "DataLength"  uint16be

(* Bind fields before building the codec. The same bound fields are then
   reused for get/set. *)
let bf_version   = Codec.(f_version   $ fun p -> p.version)
let bf_type      = Codec.(f_type      $ fun p -> p.type_)
let bf_sec_hdr   = Codec.(f_sec_hdr   $ fun p -> p.sec_hdr)
let bf_apid      = Codec.(f_apid      $ fun p -> p.apid)
let bf_seq_flags = Codec.(f_seq_flags $ fun p -> p.seq_flags)
let bf_seq_count = Codec.(f_seq_count $ fun p -> p.seq_count)
let bf_data_len  = Codec.(f_data_len  $ fun p -> p.data_len)

let packet_codec =
  let open Codec in
  v "SpacePacket"
    (fun version type_ sec_hdr apid seq_flags seq_count data_len ->
      { version; type_; sec_hdr; apid; seq_flags; seq_count; data_len })
    [ bf_version;
      bf_type;
      bf_sec_hdr;
      bf_apid;
      bf_seq_flags;
      bf_seq_count;
      bf_data_len ]

The generated .3d is a projection of that OCaml description. It is not a second source of truth:

entrypoint
typedef struct _SpacePacket(mutable WireCtx *ctx)
{
   UINT16BE Version : 3 {:act WireSetU16BE(ctx, (UINT32) 0, Version); };
   UINT16BE Type : 1 {:act WireSetU16BE(ctx, (UINT32) 1, Type); };
   UINT16BE SecHdrFlag : 1 {:act WireSetU16BE(ctx, (UINT32) 2, SecHdrFlag); };
   UINT16BE APID : 11 {:act WireSetU16BE(ctx, (UINT32) 3, APID); };
   UINT16BE SeqFlags : 2 {:act WireSetU16BE(ctx, (UINT32) 4, SeqFlags); };
   UINT16BE SeqCount : 14 {:act WireSetU16BE(ctx, (UINT32) 5, SeqCount); };
   UINT16BE DataLength {:on-success WireSetU16BE(ctx, (UINT32) 6, DataLength);
                         return true; };
} SpacePacket;

The annotations in the output show how EverParse uses the codec at validation time. :act writes each validated field value into an output structure (via the WireSet* callbacks); :on-success is the longer form that can conditionally fail. So the generated C parser validates and extracts in a single pass.

The same codec also gives zero-copy field access on the OCaml side:

(* Stage once, reuse the closure *)
let get_apid = Staged.unstage (Codec.get packet_codec bf_apid)
let set_seq  = Staged.unstage (Codec.set packet_codec bf_seq_count)

let apid = get_apid buf 0        (* zero allocation for int fields *)
let () = set_seq buf 0 42        (* read-modify-write for bitfields *)

(* Full record decode/encode when needed *)
let pkt = Result.get_ok (Codec.decode packet_codec buf 0)
let () = Codec.encode packet_codec pkt buf 0

The Space Packet header has a fixed layout, but many formats have variable-length payloads. For those, dependent sizes use Field.ref to let one field's value determine the size of another:

let f_len  = Field.v "Length" uint16be
let f_data = Field.v "Data" (byte_array ~size:(Field.ref f_len))

Testing against C

The same description drives testing against the C path:

let schema = Everparse.schema packet_codec
let () = Wire_3d.run ~outdir:"schemas" [ schema ]
let () = Wire_stubs.generate ~schema_dir:"schemas" ~outdir:"."
           [ C packet_codec ]

Wire_3d.run writes the .3d files, invokes EverParse, and produces C validators. Wire_stubs.generate writes the OCaml/C FFI glue (external declarations and C stubs) so OCaml code can call the verified validators directly.

The fuzz/ tests use Crowbar to check that the OCaml codec does not crash on random input. Separately, test/diff/ generates random schemas, runs EverParse to produce C validators, and checks that OCaml and C agree on every random input. One OCaml description defines the codec, the schema, and the test oracle.

Performance

Describing a format is one thing; the question is whether the generated codec stays fast enough for real-time packet processing. The benchmarks below measure three common operations (routing, frame reassembly, status polling) and compare the Wire OCaml path with C loops built on EverParse validators (generated from the same OCaml codecs). The protocols come from CCSDS (Space Packets, TM Frames, CLCW words), which travel over SpaceWire links at up to 200 Mbit/s.

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Versi|T|S|        APID         |Seq|         SeqCount          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          DataLength           |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |C|CLC|Statu|COP|   VCID    |Spare|N|N|L|W|R|FAR|  ReportValue  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |Ver|       SCID        |VCID |O|    MCCount    |    VCCount    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |S|S|P|Seg|     FirstHdrPtr     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The chart below shows wall-clock time per operation (lower is better). Each benchmark has two bars: the C baseline (blue, using EverParse validators) and the Wire OCaml path (orange). The ratio column shows how much slower (or faster) Wire is compared to C. A ratio below 1.0 means Wire wins.

Reading the chart from top to bottom: packet routing is 2.6x slower than C, which sounds like a lot until you note that 14.1 ns per packet gives 71 Mpkt/s (a SpaceWire link at 200 Mbit/s with 128-byte packets carries roughly 200 kpkt/s, so Wire has 350x headroom). Frame reassembly is at parity. And status polling is the surprise: Wire is faster than C.

One caveat: the C baseline uses EverParse validators that extract all fields (7 for a Space Packet, 13 for a CLCW word), while the OCaml path uses Staged.unstage (Codec.get ...) to read only the fields it needs. That makes the comparison slightly unfair to C, but it reflects how the two paths would be used in practice. Wire wins on CLCW precisely because it loads the 4-byte word once and extracts only the 4 fields the polling loop needs.

Additional per-field micro-benchmarks confirm the pattern. Reading an 11-bit bitfield like SpacePacket.apid takes 3.4 ns with zero allocation. Writing a bitfield (read-modify-write) runs at 2–3 ns.

The remaining 2.5x gap in routing comes from three sources of overhead in OCaml's runtime:

• Function dispatch. The staged field readers are closures, not inlined code. Each call goes through an indirect dispatch (about 11 extra instructions per call).
• Thread-safety barriers. OCaml 5 inserts memory barriers on every mutable write to support multicore. C writes are plain stores.
• Register pressure. The compiler cannot keep state in registers across closure calls, so it spills to the stack between reads.

None of this is specific to Wire. It is the cost of OCaml 5's runtime model. OxCaml would address all three (unboxed closures, thread-local stores, better register allocation across calls), but that is the story for another post.

Getting started

To try the examples from this post, clone the repo and build:

git clone https://github.com/parsimoni-labs/ocaml-wire.git
cd ocaml-wire
opam install . --deps-only
dune build

The library requires OCaml 5.1 or later. The codec definitions from this post are in examples/space (Space Packet, CLCW, TM Frame); examples/net does the same for Ethernet, IPv4, TCP, and UDP. Generating .3d files works out of the box; compiling them into verified C needs EverParse (3d.exe in PATH).

Satellite protocols have many binary formats: Space Packets, TM frames, CLCW words, telecommand segments, and more. I do not want to write C parsers and serialisers for each of them by hand. I want to describe the format once in OCaml, get a codec I can use and compose the layers directly, and generate the EverParse .3d and C glue from the same source. ocaml-wire is still experimental, but I already find it quite useful (if only to get ASCII art diagrams of packet headers :-). With OxCaml closing the remaining routing gap, the C side might matter even less (apart from differential testing against a formally verified parser). If you want to try it, the repo is here.

Last month I spent a week in Southern California visiting the people who build satellites. One morning I dropped my daughter at pre-school and walked to the building next door, where fifteen satellites were in simultaneous integration at different stages of assembly. That is what the LA space industry looks like: it is just there, woven into the neighbourhood. Another factory nearby was targeting high-volume production with a backlog of over forty spacecraft. A space avionics manufacturer we have since partnered with, whose hardware has flown on dozens of missions over twenty years. Engineers at NASA/JPL developing a reusable flight software framework. Teams from Techstars Space building ground segment tooling and application software that will run on other people's satellites. All of this within an hour's drive of each other. And the questions were different from 2022 -- not "could this work?" but "how big is the binary, what RTOS do you replace, how do you handle OTA updates, what does your security compliance story look like?"

Launch costs are falling and production volumes are rising, and how you produce space software at scale has to keep up. Ideas I have spent years on (library operating systems, building software that is correct by construction) are turning out to be well-timed. I am looking forward to sending more OCaml code to space this year. Ping me if you are interested ;-)

So I wrote ofpp to test this idea. It parses the complete FPP grammar and generates MirageOS wiring code from FPP topology files. The generated code compiles against the real MirageOS libraries, and NASA's reference fpp-check tool accepts the same .fpp files unchanged. FPP's dependency graph maps directly to OCaml functors, so the rest of the post walks through that mapping.

ofpp is a prototype, not a replacement for the mirage tool or for Functoria -- I built it to explore what a shared architecture language between F Prime and MirageOS could look like.

The mapping

Here is UnixHelloKey, a unikernel that takes a --hello command-line flag (source):

passive component Unikernel {
  async input port start: serial
  param hello: string default "Hello World!"
}

instance unikernel: Unikernel base id 0

topology UnixHelloKey {
  instance unikernel
}

let hello_0 =
  let doc = Cmdliner.Arg.info ~doc:"hello" ["hello"] in
  Mirage_runtime.register_arg
    Cmdliner.Arg.(value & opt string "Hello World!" doc)

let start = lazy (Unikernel.start ~hello:(hello_0 ()))

let () =
  let t =
    let open Lwt.Syntax in
    (* Mirage_runtime init ... *)
    let* _ = Lazy.force start in
    Lwt.return ()
  in
  Unix_os.Main.run t; exit 0

The FPP instance unikernel resolves to the OCaml module Unikernel by convention (capitalised). The param hello declaration generates a Cmdliner term (hello_0) that becomes the --hello command-line flag, passed as a labelled argument to Unikernel.start.

$ dune exec examples/mirage/tutorial/hello-key/main.exe
2026-03-04T13:52:57-08:00: [INFO] [application] Hello World!
...
$ dune exec examples/mirage/tutorial/hello-key/main.exe -- \
    --hello='Bonjour\ MirageOS!'
2026-03-04T13:53:08-08:00: [INFO] [application] Bonjour MirageOS!
...

ofpp handles wiring only. Type safety comes from the OCaml module system: the generated functor applications must type-check against the MirageOS library signatures, so a miswired topology is a compile error.

config.ml vs config.fpp

In MirageOS, each unikernel has a config.ml that describes its device dependencies using Functoria combinators. In FPP, each unikernel has a config.fpp that describes the same dependencies as a connection graph. Here is the network example -- a unikernel that needs a TCP/IP stack:

open Mirage

let main =
  main "Unikernel.Main" (stackv4v6 @-> job)
let stack = generic_stackv4v6 default_network
let () = register "network" [ main $ stack ]

module Unikernel {
  passive component Main {
    async input port start: serial
    output port stack: serial
  }
}

instance unikernel: Unikernel.Main base id 0

topology UnixNetwork {
  import SocketStack
  instance stackv4v6
  instance unikernel

  connections Start {
    unikernel.stack -> stackv4v6.connect
  }
}

The Functoria DSL hides the stack implementation behind generic_stackv4v6. The FPP topology makes it explicit: import SocketStack pulls in a sub-topology that wires Udpv4v6_socket and Tcpv4v6_socket into Stackv4v6.Make. The connection unikernel.stack -> stackv4v6.connect declares that the unikernel depends on the stack.

The FPP version is more verbose. Functoria's combinators are more concise for pure OCaml projects, and generic_stackv4v6 picks the right implementation for each target automatically (FPP makes you spell that out). The payoff is that the topology is a standalone graph, not embedded in OCaml. The same .fpp files can drive C++ code generation, and the connection graph is available for visualisation and tooling.

The device catalogue

Device components live in a shared mirage.fpp. Here are three of the devices used in the UnixPing6 topology shown below:

module Vnetif {
  passive component Make {
    import Mirage_net.S
    output port backend: serial
  }
}

module Ethernet {
  passive component Make {
    import Ethernet.S
    output port net: serial
  }
}

module Ipv6 {
  passive component Make {
    import Tcpip.Ip.S
    async input port connect: Ipv6Connect
    output port net: serial
    output port eth: serial
  }
}

Each FPP construct maps to a specific OCaml concept.

Output ports are functor arguments. Vnetif.Make has one output port (backend), so its generated functor takes one argument: Vnetif.Make(Backend). Ipv6.Make has two (net and eth), so its functor takes two: Ipv6.Make(Net)(Ethernet). The topology connections decide which instance fills each argument.

import declarations are module type constraints. import Mirage_net.S on Vnetif.Make tells ofpp to generate module type Net = Mirage_net.S in the output. The OCaml compiler then checks that the concrete module satisfies that signature.

Port types encode connect signatures. Ipv6Connect is defined elsewhere in mirage.fpp as port Ipv6Connect(conf: Ipv6Conf), so Ipv6.connect takes a labeled ~conf argument. Positional parameters (like _0: string) generate positional arguments instead.

The generated code for UnixPing6 uses all three:

(* from import declarations *)
module type Backend = Vnetif.BACKEND
module type Net = Mirage_net.S
module type Ethernet = Ethernet.S
module type Ipv6 = Tcpip.Ip.S

(* from topology connections + output ports *)
module Net = Vnetif.Make(Backend)
module Ethernet = Ethernet.Make(Net)
module Ipv6 = Ipv6.Make(Net)(Ethernet)

(* from connect port types + connection order *)
let* backend = Backend.connect () in
let* net = Net.connect backend in
let* ethernet = Ethernet.connect net in
let* ipv6 = Ipv6.connect net ethernet in

If a connection is missing, it does not compile.

A larger example

Here is UnixPing6, an IPv6 ping unikernel wired through a virtual network (source):

module Unikernel {
  passive component Main {
    async input port start: serial
    output port net: serial
    output port eth: serial
    output port ipv6: serial
  }
}

instance unikernel: Unikernel.Main base id 0

topology UnixPing6 {
  instance backend
  instance net
  instance ethernet
  instance ipv6
  instance unikernel

  connections Connect {
    net.backend -> backend.connect
    ethernet.net -> net.connect
    ipv6.net -> net.connect
    ipv6.eth -> ethernet.connect
  }
  connections Start {
    unikernel.net -> net.connect
    unikernel.eth -> ethernet.connect
    unikernel.ipv6 -> ipv6.connect
  }
}

module type Backend = Vnetif.BACKEND
module type Net = Mirage_net.S
module type Ethernet = Ethernet.S
module type Ipv6 = Tcpip.Ip.S

module Net = Vnetif.Make(Backend)
module Ethernet = Ethernet.Make(Net)
module Ipv6 = Ipv6.Make(Net)(Ethernet)
module Unikernel = Unikernel.Main(Net)(Ethernet)(Ipv6)

open Lwt.Syntax

let connect = lazy (
  let* backend = Backend.connect () in
  let* net = Net.connect backend in
  let* ethernet = Ethernet.connect net in
  let* ipv6 = Ipv6.connect net ethernet in
  Lwt.return (net, ethernet, ipv6))

let start = lazy (
  let* (net, ethernet, ipv6) = Lazy.force connect in
  Unikernel.start net ethernet ipv6)

(* Mirage_runtime init, then: *)
let* _ = Lazy.force start in ...

Sub-topology composition

Sub-topologies are shared via import. The DNS example imports the socket stack and wires additional layers on top:

topology UnixDns {
  import SocketStack          @ pulls in Udpv4v6_socket, Tcpv4v6_socket, Stackv4v6
  instance stackv4v6
  instance happy_eyeballs_mirage
  instance dns_client
  instance unikernel

  connections Connect_device {
    happy_eyeballs_mirage.stack -> stackv4v6.connect
  }
  connections Start {
    dns_client.stack -> stackv4v6.connect
    dns_client.happy_eyeballs -> happy_eyeballs_mirage.connect_device
    unikernel.dns -> dns_client.start
  }
}

The generated main.ml chains the socket stack connect, then connect_device for Happy Eyeballs, then start for the DNS resolver -- each connection group becomes a lazy binding that forces its dependencies:

module type Udpv4v6_socket = Tcpip.Udp.S
module type Tcpv4v6_socket = Tcpip.Tcp.S
module type Stackv4v6 = Tcpip.Stack.V4V6
module type Happy_eyeballs_mirage = Happy_eyeballs_mirage.S
module type Dns_client = Dns_client_mirage.S

module Stackv4v6 = Stackv4v6.Make(Udpv4v6_socket)(Tcpv4v6_socket)
module Happy_eyeballs_mirage = Happy_eyeballs_mirage.Make(Stackv4v6)
module Dns_client = Dns_resolver.Make(Stackv4v6)(Happy_eyeballs_mirage)
module Unikernel = Unikernel.Make(Dns_client)

let connect = lazy (
  let* udpv4v6_socket = Udpv4v6_socket.connect ~ipv4_only:false ... in
  let* tcpv4v6_socket = Tcpv4v6_socket.connect ~ipv4_only:false ... in
  Stackv4v6.connect udpv4v6_socket tcpv4v6_socket)

let connect_device = lazy (
  let* stackv4v6 = Lazy.force connect in
  let* happy_eyeballs_mirage = Happy_eyeballs_mirage.connect_device stackv4v6 in
  Lwt.return (stackv4v6, happy_eyeballs_mirage))

let start = lazy (
  let* (stackv4v6, happy_eyeballs_mirage) = Lazy.force connect_device in
  let* dns_client = Dns_client.start stackv4v6 happy_eyeballs_mirage in
  Unikernel.start dns_client)

This is something Functoria's flat combinator model does not express cleanly: named sub-topologies that can be imported and reused across unikernels, with cross-boundary connections wired by the parent topology.

Target switching

In MirageOS, you write your application once and compile it for different platforms without changing application code. mirage configure -t unix wires in the kernel's TCP/IP stack; -t hvt wires in MirageOS's own protocol implementations running on a virtual network device. In FPP, each target is simply a different topology.

Shared sub-topologies (TcpipStack, SocketStack, DnsStack) are imported and reused across variants. The caller picks the target by passing it to ofpp:

ofpp to-ml --topologies UnixHello mirage.fpp tutorial/hello/config.fpp
ofpp to-ml --topologies UnixDns --target unix mirage.fpp applications/dns/config.fpp

The --target flag selects the OS main loop: unix (default), xen, solo5, or unikraft. The codegen emits the appropriate entry point -- Unix_os.Main.run, Xen_os.Main.run, Solo5_os.Main.run, or Unikraft_os.Main.run. Target switching in ofpp is very experimental for now: only the Unix target has been tested end-to-end.

Mixing C++ and OCaml components

ofpp already works for building MirageOS unikernels on the Unix backend: describe the topology in FPP, run ofpp to-ml, compile. The interesting next step is mixing C++ F Prime components with OCaml MirageOS components in the same topology.

Three pieces are missing. First, binary serialisation: ofpp already generates OCaml types from FPP enums, structs, and arrays, but matching C++'s wire format for command, telemetry, and event dispatch is not done yet. Second, FFI stubs: I have early experiments with OCaml components running inside F Prime over caml_callback, but they are not ready to open-source. Third, build integration: I have a working (if ugly) CMake + dune bridge, though a cleaner solution might come from Package Managers à la Carte (pre-print).

The end goal: run OCaml components on isolated MirageOS platforms (Solo5, Muen, Unikraft, seL4) inside F Prime deployments, and let MirageOS unikernels integrate with existing C++ flight software.

State machines

FPP also has state machines. ofpp generates typed OCaml modules from them: states become a GADT, signals become a variant, and guards and actions become functor parameters. Here is a toy example:

state machine Door {
  action lock
  guard locked
  signal open
  signal close
  initial enter Closed
  state Closed {
    on open if locked enter Closed
    on open enter Opened
  }
  state Opened {
    on close do { lock } enter Closed
  }
}

type closed
type opened

type _ state =
  | Closed : closed state
  | Opened : opened state

type signal = Open | Close

module type ACTIONS = sig
  type ctx
  val lock : ctx -> unit
end

module type GUARDS = sig
  type ctx
  val locked : ctx -> bool
end

module Make
  (A : ACTIONS)
  (G : GUARDS with type ctx = A.ctx) :
sig
  type t
  val create : A.ctx -> t
  val state : t -> any
  val step : t -> signal -> t
end

Phantom types index the GADT, so pattern matching in step is exhaustive. The caller supplies ACTIONS and GUARDS as functor arguments. ofpp also renders state machines as Graphviz diagrams. In F Prime, components can embed state machine instance declarations that connect a state machine to the component's lifecycle; ofpp does not wire those up fully yet.

ofpp

The tool is called ofpp. I started it in February at the JPL workshop. Rob Bocchino designed FPP with a formal specification and an upstream test suite of 670 .fpp files across 35 categories, which I used to validate the parser. The parser covers the complete FPP grammar (zero conflicts).

The whole thing is about 19k lines of OCaml: 1k for the parser and lexer, 8k for the checker, 2.7k for the code generator, and the rest for tests. ofpp also exports topology graphs to fprime-visual. The example repo covers all of mirage-skeleton: tutorials, device examples, and applications like DNS, DHCP, and Git. Every example has a cram test that builds the unikernel and exercises it.

ofpp is not affiliated with NASA or JPL. It is an independent experiment. If you work with FPP or MirageOS and want to try it:

# macOS
brew tap parsimoni-labs/tap && brew install ofpp

# from source
opam pin add fpp https://github.com/parsimoni-labs/ocaml-fpp.git

ofpp check path/to/file.fpp
ofpp to-ml path/to/file.fpp
ofpp dot path/to/file.fpp | dot -Tsvg -o sm.svg

If you have a MirageOS config.ml, try describing the same topology in FPP and compare the generated main.ml with what Functoria produces. File issues on GitHub.

To understand where the gaps are, it helps to separate the two halves of the stack. Bus software (attitude control, power, thermal) runs on qualified RTOSes and is the satellite manufacturer's domain. Payload software (imaging, communications, data processing) increasingly runs on COTS (commercial off-the-shelf) processors with memory management units (MMUs) perfectly capable of enforcing memory isolation. For LEO missions on COTS hardware, the hardware is there. The software running on it does not use it.

I think three things are missing for anyone wanting to run hosted payloads or patch software in orbit safely:

1. Hardware-enforced memory isolation between payloads and flight software, either through a hypervisor (like Xen or KVM) or a separation kernel (seL4 has a formal proof of functional correctness on specific hardware configurations). Both use the MMU to ensure a compromised payload cannot reach the bus.

2. A standard OTA deployment format so "install this application" means the same thing across different satellites: cryptographically signed, designed for 10-minute LEO pass windows and partial transfers.

3. A metered runtime that enforces resource quotas (CPU, memory, storage, bus bandwidth) so one payload cannot starve the others. Resource requirements should be declarative, embedded in the deployment image, and verified before installation.

The tools to address much of this exist in the terrestrial world: memory-safe languages (roughly 70% of CVEs in large C/C++ codebases are memory-safety issues, a figure consistent across Microsoft, Google, and Android since 2019), verified cryptography, minimal single-purpose OS images. These are not theoretical: Google cut Android memory-safety vulnerabilities by 76% in six years by writing new code in memory-safe languages, and AWS runs millions of serverless workloads on Firecracker, a 50,000-line Rust VMM that boots in under 125 ms. None of these have made it into flight software yet, even as the number of spacecraft in orbit (and the attack surface) has grown sharply. Space Odyssey examined three satellites and found vulnerabilities in all of them, and those are only the ones someone bothered to look for.

Mass launched to orbit (blue) versus publicly disclosed satellite software vulnerabilities (red bars, from CVE/NVD and conference disclosures; data and sources). The gap between the curves is the problem: launch volume has exploded, security scrutiny has barely started.

The evidence is mounting. None of the Space Odyssey satellites had ASLR, stack canaries, or DEP; one had no authentication on its telecommand interface. The Viasat/KA-SAT attack in February 2022 disrupted Ukrainian communications and 5,800 German wind turbines, making the threat operational (Boschetti, Gordon and Falco, ASCEND 2022). At Black Hat 2025, a vulnerability assessment of NASA's core Flight System (cFS) found remote code execution, path traversal, and denial-of-service, all from textbook C memory bugs. NASA's own CryptoLib, the reference implementation of CCSDS encryption, has had recurring buffer overflows in its parsing code (CVE-2025-29909, CVSS 9.8). A memory-safe language eliminates these classes of bug by construction.

The pattern across all of these is consistent: space software engineering has a safety-versus-security bias (Pavur and Martinovic, J. Cybersecur. 2022; Falco, JAIS 2019). Systems are designed for availability and determinism (watchdogs, radiation tolerance, FDIR). Integrity and confidentiality are secondary. This is not irrational: a satellite that loses attitude control is a more immediate problem than one that leaks telemetry. But it leaves software stacks undefended against adversarial threats. Jero et al. (NDSS SpaceSec 2024) proposed a defence-in-depth taxonomy -- secure boot, memory protection, authenticated updates, compartmentalisation -- that overlaps substantially with the three gaps above.

So why does the current stack not provide the three things above? Most small-sat payload software runs on VxWorks, RTEMS, embedded Linux (Yocto, Buildroot), or bare metal. The RTOS path typically runs everything in a single address space: the hardware has an MMU, but most CubeSat missions do not enable memory protection because it requires rethinking memory management, interrupt handling, and DMA buffer allocation. This is exactly the architecture Space Odyssey found vulnerable. Embedded Linux gives you process isolation, but hardening it for multi-tenancy and certifying it for flight remains a substantial undertaking. ESA's OPS-SAT demonstrated deploying new applications before its re-entry in 2024, but it remains the exception.

The isolation and metering techniques are not new. Cloud infrastructure solved analogous problems years ago, and avionics systems (ARINC 653, DO-178C) have their own qualified solutions. The gap is in LEO payload software, where neither stack fits: the cloud stack assumes abundant resources, the avionics stack assumes a single operator and a multi-year qualification budget. I am not going to minimise how much work qualification (under ECSS-Q-ST-80C or equivalent) requires. Calabrese, Kavallieratos and Falco (SCITECH 2024) emulated a cyberattack from a hosted payload on OPS-SAT that compromised the bus, demonstrating why isolation matters. But a real multi-tenant satellite also needs FDIR (Fault Detection, Isolation, and Recovery) integration, thermal management, power budgeting, and link budget allocation. I am focusing on the software infrastructure, but I do not want to pretend the problem ends there.

The regulatory pressure is new. The EU Cyber Resilience Act is pushing toward stronger isolation and update mechanisms. ENISA is calling out the space sector. The White House called for memory-safe languages in critical infrastructure in 2024, a recommendation that applies to flight software as much as to anything on the ground. OCaml, the language Parsimoni and Tarides use, is memory-safe in its default fragment. And the hardware is finally there: radiation-tolerant processors with enough compute for on-board processing are commercially available at CubeSat price points. The missing piece is the software infrastructure.

These are the problems I co-founded Parsimoni to work on. Our payload software platform, SpaceOS, builds on the OCaml ecosystem that Tarides maintains. Our first payload reached orbit on SpaceX Transporter-13 in March 2025. If you are building payload software and running into these constraints, or if you are an operator considering hosted payloads, we would like to hear from you: get in touch.

Five properties fell out of that architecture. None of them are unique to unikernels (a careful Yocto configuration can achieve most of them), but unikernels make them the default. I think they hold up better now than they did in the cloud:

1. Sealed images. The binary is fixed at compile time. No runtime package installation, no configuration files, no shell to log into.
2. Dead code elimination. If the application does not use the filesystem, the filesystem is not in the binary.
3. Single address space. One application, one address space (no internal process isolation, the hypervisor provides isolation between unikernels).
4. Configuration is compilation. Network addresses, TLS certificates, and firewall rules are baked in at build time. No configuration parser at runtime means no configuration parser to exploit.
5. Small trusted computing base. The TCB is the hypervisor plus the application. No general-purpose kernel, no init system, no sshd.

Anil, Balraj and I co-founded Unikernel Systems to bring this to production. Docker acquired us three months later. At Docker, we built Docker Desktop from scratch, adding MirageOS unikernel components to the networking stack via vpnkit (we wrote an ICFP paper about how that works). Millions of developers use it daily. Meanwhile, containers won the cloud and Unikraft took the unikernel deployment model in a POSIX-compatible direction for serverless. The unikernel-as-product did not take over (yet!), but the libraries shipped further than we ever expected.

In 2021, when Tarides joined Cyber@Station F, I pitched unikernels to over thirty internal teams at Thales: cyber, compliance, transport, defence, ... Most were politely interested. The one that clicked was Régis de Ferluc at Thales Alenia Space. His reaction was not "that is interesting" but "that is how we already build embedded systems, but done in a principled way (and where you can safely introduce dynamic behaviour)."

He was right. Satellite flight software ships as fixed binaries, qualified on the ground, no shell access in orbit, no runtime configuration changes. The five properties above are not innovations in space, they are requirements. What satellite software does not have is the type safety, the tooling, and the library ecosystem that OCaml and MirageOS provide.

Régis pushed us to look deeper, introduced us to EU programmes (ORCHIDE via Horizon Europe, CEOS), and SpaceOS was born. Miklos and I co-founded Parsimoni to build it.

The ASPLOS paper asked whether sealed, single-purpose images could improve cloud infrastructure. Twelve years later, I think the more interesting question is whether those same properties matter more in constrained environments (satellites, hardware security modules, embedded controllers) where every kilobyte counts, you cannot ssh in after deployment, and "no unused code" is not an optimisation but a qualification requirement.

F Prime (GitHub) is NASA's open-source framework for building reusable flight software. Before it, most missions started from scratch or copy-pasted code from previous ones. It already flies on Ingenuity (Mars Helicopter), CADRE (autonomous lunar rovers), and Europa Clipper. It is trying to bring standard software engineering practices (modularity, unit testing, reusability, continuous integration) to a domain that has historically resisted them.

The framework has its own modelling language called FPP (F Prime Prime). You describe your system in FPP (components, ports, state machines, topologies) and the toolchain generates thousands of lines of C++ for you (plus a fair amount of CMake glue to wire the build together). That is the point: you write the architecture, not the boilerplate. If you have ever worked with MirageOS, all of this should sound oddly familiar.

For those who do not know, MirageOS (GitHub) is a library operating system where the entire application, from the network stack to the storage layer, is built from OCaml modules wired together by functors. The runtime is minimal (Solo5 provides about ten hypercalls), no general-purpose OS, no libc, just typed interfaces all the way down. Our ASPLOS 2013 paper received the Influential Paper Award in 2025. I think F Prime and MirageOS share a surprising number of ideas. Here is how I see the two relate.

Components are module types. In F Prime, you define a component by declaring its ports, typed interfaces that connect it to the rest of the system. The FPP paper puts it nicely: a port "has a type and a kind; the type is like a function signature." Components have no compile- or link-time dependencies on each other: each component depends only on the types of the ports that it uses.

FPP distinguishes three kinds of components: passive (called synchronously by the caller), queued (has an internal message queue but no thread of its own), and active (has its own thread that drains its queue). This is a concurrency model baked into the component types:

passive component Thermometer {
  sync input port cmdIn: Fw.Cmd
  output port tlmOut: Fw.Tlm
  telemetry Temperature: F32
}

module type THERMOMETER = sig
  type t
  val cmd_in : t -> Cmd.t -> unit
  val tlm_out : t -> Tlm.t
  val temperature : t -> float
end

Both say the same thing: anything that calls itself a thermometer must accept commands, emit telemetry, and report a temperature. The ports are the function signatures. The component type is the module type.

The mapping is suggestive, not exact. FPP ports have directionality (input vs output) and invocation kinds (sync, async, guarded) that a flat OCaml signature does not enforce. In MirageOS we used phantom types on device connectors to recover some of this structure (see Radanne, Gazagnaire et al., 2019) but the parallel is clear enough to be useful.

The concurrency story is interesting too. F Prime's active/passive/queued distinction maps loosely to what OCaml has been working through for years. A passive component is a plain function call. An active component has its own thread that drains a message queue. Compare:

active component Logger {
  async input port logIn: Fw.Log
}

module type LOGGER = sig
  type t
  val log_in : t -> Log.t -> unit Lwt.t
end

In FPP, a component is either passive, queued, or active. In OCaml, you can mix synchronous and asynchronous functions in the same module signature: some values return unit, others return unit Lwt.t. The concurrency model is per-function, not per-component. Queued components sit in between, an event loop without a dedicated thread. OCaml has been moving from monadic concurrency (Lwt.t) to effect handlers in OCaml 5, which delegate scheduling to a library like Eio without colouring every type signature. F Prime bakes the concurrency model into the component kind; OCaml delegates it to the application scheduler.

State machines are GADTs. This one is not specific to MirageOS, it is about OCaml's type system more broadly. FPP has built-in state machine support (states, signals, guards, and transitions). Here is a door controller (from the FPP User's Guide):

state machine Door {
  signal open
  signal close
  guard isLocked

  initial enter Closed

  state Closed {
    on open if isLocked enter Closed
    on open enter Open
  }

  state Open {
    on close enter Closed
  }
}

FPP: a door with two states and a guard.

The generated state machine diagram.

In OCaml, you can encode the same transitions as a GADT. The type parameters track which state you are in and which state a signal takes you to:

type closed
type opened

type _ state =
  | Closed : closed state
  | Open : opened state

type (_, _) signal =
  | Open  : (closed, opened) signal
  | Close : (opened, closed) signal

type guard = Locked | Unlocked

let step : type a b. a state -> (a, b) signal -> guard
    -> (b state, a state) result =
  fun state signal guard ->
    match state, signal, guard with
    | Closed, Open, Locked   -> Error state
    | Closed, Open, Unlocked -> Ok Open
    | Open, Close, _         -> Ok Closed

The type (closed, opened) signal means: this signal is only valid from the closed state, and it produces the opened state. Try to close an already-closed door and the compiler rejects it. The guard is a runtime check (just like in FPP), but the result type makes the self-loop explicit: Error state means the guard blocked and you stayed where you were. FPP's state machine compiler does the same checks at the FPP level; the GADT pushes them into OCaml's own type system.

The wiring is where they diverge. How you describe the way all these components connect into a running system is where the two frameworks take different paths.

In F Prime, you define a topology: a wiring diagram that connects component instances through their ports, the way an engineer connects chips on a board. Sub-topologies let you group and reuse partial wirings (think of them as sub-circuits). The FPP compiler checks that port types match, then the autocoder generates C++ and a fair amount of CMake glue. For the final assembly, users customise init sequences, thread priorities, and buffer sizes through C++ templates and build rules. There are many knobs to turn.

topology Mission {
  instance sensor: Sensors.Thermometer
  instance dispatcher: Svc.CmdDispatcher

  connections command {
    dispatcher.compCmdSend -> sensor.cmdIn
  }
}

module Mission
    (Sensor : THERMOMETER)
    (Dispatcher : CMD_DISPATCHER) = struct
  let dispatch sensor cmd =
    Sensor.cmd_in sensor cmd
  let init sensor =
    Dispatcher.register (dispatch sensor)
end

In MirageOS, a functor is a function from modules to modules: you pass a module satisfying some signature, and you get a new module back. The functor is the sub-topology. People write functor applications by hand all the time in OCaml, and it works fine. But in MirageOS we wanted to automate redeployment across different hypervisors and driver sets (Xen, KVM, Solo5, each with their own network and storage stacks), so we built Functoria, an eDSL that describes the assemblage and generates the build rules and functor applications for each target. That is structurally closer to what F Prime's autocoder does: both take a high-level wiring description and produce glue code for a specific target.

Both check that the wiring is type-correct, but in different places: FPP in its own compiler, OCaml in the host language's type system. FPP gives you a graph-oriented model that maps naturally to how electronic engineers think. Functoria gives you composability (functors are first-class language constructs), but the resulting code can get... involved. (Who said Irmin in the back? :p)

The unit of compute seems settled: small typed components, explicit async I/O, function types as interfaces. The global wiring is not. I have seen it spawn build system rules (Makefile spaghetti), domain-specific languages (FPP, Functoria), and language-specific support (functors). Parnas (1972) told us to hide information behind interfaces. Nobody told us how to wire a thousand of them together ;-)

The last couple of weeks have been pretty intense as I've been moving to LA with my family. I am spending six months here, working on Parsimoni and getting closer to the US space industry.

Last week I visited NASA's Jet Propulsion Laboratory (JPL) and saw Voyager 2's control room -- still running after 48 years. Optimism, Perseverance's ground twin, was rolling over Pasadena sand in a test enclosure next door. I also attended the F Prime workshop and completed two workshops on flight software engineering. F Prime is NASA's open-source flight software framework. Over 100 people attended -- university and student teams, internal JPL product teams, and large projects like HPSC. Only a small bunch of us were not from the US.

The recurring theme in every conversation: flying a helicopter on Mars is now routine, but deploying shared payload software to a satellite is still real science fiction (no pressure!).

On the Tarides side, the team continues to maintain and develop the OCaml platform -- opam, Dune, Merlin, odoc -- while I am on a different timezone. Lots of things are happening (see the Tarides blog) and many more are planned for 2026. In a world where people write apps by chatting with AI bots, core language tools are even more important to make sure we keep trust in our software systems (more on this later in this blog, hopefully).

I intend to write here more regularly this year -- about SpaceOS, the OCaml platform, and what happens when you try to put unikernels in orbit. Stay tuned.