Trust in computing is treated as a binary. Either you trust something or you do not. This is wrong. Trust is a graph, with nodes for vendors and components and firmware, edges for what depends on what, and weights for how much you would mind being wrong about each. Most of us do not draw the graph. We trust by default, because the alternative is unaffordable for any individual computer.

The slate is a small attempt at drawing the graph properly for one device.

Here is what I trusted, what I did not, and where the line ended up.

Compute: CM5 over the alternatives

The Raspberry Pi Compute Module 5 is the foundation. Two facts decided this against alternatives like the Radxa CM5 (a different CM5, confusingly), the LattePanda, or the Khadas VIM.

First, the BCM2712 SoC has stable mainline kernel support. I do not depend on a vendor kernel branch maintained by a small team in another country. Second, the Raspberry Pi Foundation publishes errata, ships LTS-aligned firmware, and is responsive to security issues in a way that the smaller-volume SBC vendors are not.

The CM5 carries some compromises I have decided to accept. The wireless variant uses Broadcom BCM43455 for Wi-Fi and Bluetooth, which loads a closed firmware blob via brcmfmac. I would prefer this not to be there. I keep it because the alternative — soldering down an Atheros or MediaTek chip whose Linux support is genuinely mainline — was not worth the carrier-redesign cost for this revision. I am explicit about the compromise rather than ignoring it.

Carrier: Waveshare for the CM5, custom for everything else

For the CM5 itself I am using Waveshare's CM5-IO-BASE-B, because its layout is documented, its schematic is public, and the SBC community has been testing it for years. The board is a known quantity.

For the USB hub and PD charge input — which sits next to the CM5 inside the case — I am drawing my own board. This is the decision in the project I argued with myself most about. The pragmatic option was a £15 four-port GL3523 hub PCB from AliExpress. The reason I did not take that option is that the AliExpress board ships with a pre-programmed SPI flash containing the hub configuration descriptor, and I cannot read what is in that flash without lifting it off the board. Even then, I cannot prove that what is in the flash matches what arrived from the factory.

So I drew the carrier myself. Four layers, 90 × 60 mm, GL3523 hub, INA219 power monitor, IP2721 PD sink. Two boards populated per deck — one for internal accessories, one for the front-panel ports — with the SPI flash programmed before solder, on a flat-bed CH341A programmer, from a binary I wrote myself.

It cost an extra £200 and several weekends. What it bought me is the certainty that every component on those two boards is something I chose for a reason I can describe. The gerbers are at JLCPCB now. The first boards arrive in January. If they do not work, post four will have a different middle.

Radios: the SDR community as a trust source

Two software-defined radios.

The HackRF One is from Great Scott Gadgets. Open hardware design, open firmware, a maintainer (Michael Ossmann) who has been transparent for years about how the device is built and why. I am buying from an authorised reseller. The SMA antenna ports are an attack surface; the SDR's provenance is not, in the sense I worry about.

The RTL-SDR Blog V4 is the receive-only counterpart. Carl Laufer's team has earned a reputation in the community over a decade of iterations. The hardware is well-understood — R828D plus RTL2832U, with a TCXO good enough for the work I do. Replaceable if it fails, traceable if it misbehaves.

The Alfa AWUS036ACM is the external Wi-Fi adapter. The reason it is in the build rather than a higher-spec card is that the AWUS036ACM uses the MediaTek MT7612U, which has mainline mt76 driver support. No vendor blob, no out-of-tree kernel module. Monitor mode and packet injection work on stock Ubuntu without me trusting code from a third party.

Storage: Samsung over fashion

The NVMe SSD is a Samsung 980, 1 TB. There are faster drives and there are drives from boutique brands with higher endurance figures. I am using a Samsung because the firmware update process is documented, the warranty channel is real, and the failure modes are well-understood by the community. I would rather a known-quantity drive than a clever one.

The microSD for the recovery partition is a Samsung Pro Endurance — high write tolerance, low failure rate in 24/7 applications. Not because I will write to it constantly, but because the failure mode is what matters when the recovery partition matters, which is precisely when the rest of the system has failed.

Mechanical: ASA, brass, no glue

The chassis is 3D-printed in Polymaker PolyLite ASA, matte black. ASA over PLA for UV stability and Tg; matte over gloss because matte does not flag as "3D-printed plastic" in a way that gloss does; Polymaker because their batch consistency is what I have measured over half a dozen filaments for other projects.

Every screw boss has a Ruthex M3 brass heat-set insert. There is no glue in the assembly. Every component is on a connector. Every subsystem can be removed and replaced without destroying the surrounding structure. This is the maintainability principle from the design doc, but it is also a supply chain decision: if a component fails or proves to be a bad bet, I can swap it without throwing the case away.

The 3.3 V LDO that almost wasn't

The smallest decision, and my favourite.

The carrier PCB has a small 3.3 V LDO regulator (AP2112K) to feed the USB hub. On the front-panel carrier I populate it from the local 5 V rail. On the internal-accessory carrier — physically identical board — I leave the LDO off and bridge a jumper to draw 3.3 V from the mainboard's auxiliary rail instead. The mainboard already has a 3.3 V supply; running it through a second LDO is wasted heat.

This saves me about a milliamp.

It is not interesting because it saves a milliamp. It is interesting because, having identified the saving, I had to choose whether to take it. Taking it means the internal carrier depends on the mainboard providing 3.3 V cleanly. Not taking it means an extra component in the supply chain. I took it. The reason — and I want to be honest about this — is not the milliamp. It is that removing the LDO removes one more part with its own datasheet, its own failure mode, and its own supplier-trust question. Every component is an obligation. The cheapest obligation is the one you do not take on.

What this leaves me with

A device whose supply chain I can describe out loud, with three remaining honest compromises: the BCM43455 Wi-Fi blob on the CM5, the proprietary firmware on the Samsung NVMe and microSD, and the closed firmware on the HackRF MAX2837 RF front-end. Three points on the graph where I have decided that the cost of removing the trust is higher than the cost of accepting it, and where I am writing them down so I do not later pretend otherwise.

What is next

Post four is subtraction — the things I deliberately left off, and the question that flushed each one out.

The slate itself is the prop. The argument is the thing.