MirrorEthic

MirrorEthic / Writing / The Substrate Series

BONUS: The mesh grows a body

Garret Sutherland · The Substrate Series

A 3D printer mid-print at night: a dark glass-fibre part on the bed catching the printer's work light, one warm lamp behind — the mesh's first hands.

The Substrate Series · Bonus post — New capability (after the 10-part series)

The capstone said you build a system that absorbs capability. Here's the bonus receipt that landed after the series wrapped: the mesh absorbed physical fabrication — design, print, and inspect — and the architecture above it didn't move.

From bits to atoms

The capstone closed with a line: you don't build a homelab, you build a system that absorbs capability. That's an easy thing to assert and a hard thing to prove, because the honest proof is a capability you didn't have when you wrote the sentence slotting in after you wrote it, without a rebuild. This post is that proof. In the weeks after post 10 went out, the mesh grew the ability to make physical objects — to take a constraint in text, turn it into geometry, slice it, print it, and inspect the result with a camera and a vision model — and it did so as an addition to the existing substrate, not a parallel project bolted on the side.

The thing to notice up front, before any of the parts: a 3D printer is not architecturally special. It is a substrate with a role, exactly like a V100 or a Jetson. It gets a node contract. It gets a tier. It gets a place in the routing and the monitoring. The reason an entire fabrication stack could land in weeks rather than months is that every layer it needed already existed — the registry to declare it, the watchdog to monitor it, the MCP surface to drive it, the agent-operable dispatch to author work for it. The fabrication capability is new. The scaffolding that absorbed it is the same scaffolding the previous ten posts built.

This is also the post where the series' recurring image stops being a metaphor. The cognitive mesh designed and printed a cooling shroud that dropped one of its own V100s from 81 °C to 61 °C. The system improved its own thermal envelope — the exact problem post 04 was about — by fabricating a part for itself. I'll get to that receipt in full. It's the cleanest single thing the lab has done.

The loop, and where it deliberately stops

The fabrication subsystem runs a five-stage loop, and the most important design decision is the last stage:

SENSE    → mesh telemetry: a V100 running hot, a missing bracket, a needed part
DECIDE   → an agent authors parametric geometry (OpenSCAD) or lifts an image to a mesh
MAKE     → slice (OrcaSlicer CLI) → print (Klipper / Moonraker)
QA       → actuated arm + dual camera + a vision model on the Orin → classify, capture, log
INSTALL  → HARD STOP. A human mounts the part. Always.

Four of those five stages are automatable and automated. The fifth is a wall, on purpose. An agent can design, slice, print, and inspect; it cannot install. A human picks up the finished part, checks it, and physically mounts it. This is not a limitation I'm apologizing for — it's the safety boundary that makes the rest of the loop something I'm willing to leave running. The same separation-of-concerns discipline that isolates a V100 fan failure from the compute box (post 04) and a misbehaving agent from the things it shouldn't touch (post 07) draws a hard line between "the mesh made a thing" and "the thing is now load-bearing in the physical world." Crossing that line is a human's job and stays a human's job.

That boundary shows up again, quieter, in how the fabrication services are contracted. Every fab service in the node registry is marked critical = false. A failed print, a stalled board, a printer that needs a nozzle change — none of those page me the way cortex-down does. A printer being offline is a "walk over and look at it" event, not a mesh-healing emergency. Encoding that as a flag in the contract (post 08's [[node_services]] blocks, read by post 07's reconciler) means the watchdog watches the printers without ever treating a botched print like an infrastructure outage. The blast radius of a fabrication failure is one wasted spool-meter of filament, by design.

The fab node: a printer is just another substrate

The actuator is a Raspberry Pi 5 8 GB running MainsailOS — logical node fab, on its own static-IP cat5e run to the basement. It started life as a Pi 4B; that board red-screened during an EEPROM update and took the bootloader recovery down with it, so it got replaced with a Pi 5 and the dead 4B was parked for salvage. The node contract records all of this, because the contract is the thing that survives hardware death — the logical node fab is stable even though the silicon under it got swapped.

One Pi drives two printers, each with its own Klipper + Moonraker instance:

The thing to notice is the same thing post 08 kept noticing: this is a role, not a machine. The fab node declares its tier (DEV — it thrashes, prints fail, boards get reflashed), its hardware, and the always-up services the watchdog should keep alive (the two Klipper instances, the two Moonrakers, the camera streamer), every one of them critical = false. The printers slotted into the registry the same way Thundercompute did — a contract in the same directory, the same schema, read by the same tools. The mesh didn't learn a new concept to absorb a printer. It already had the concept.

The generative-to-physical pipeline

There are two paths into the MAKE stage, and they cover the two kinds of thing you actually want to fabricate.

The functional path: text to CAD. For brackets, shrouds, gaskets, mounts — parts defined by constraints and dimensions — an agent authors parametric OpenSCAD: geometry as code. "A blower shroud with a 50 mm flange, flange-down so it prints support-free, sealed around the EPS12V pass-through" becomes OpenSCAD source, which renders to an STL, which renders to a preview PNG the agent can actually look at before committing. This is the path that matters most, because functional parts are specified the way code is specified — in constraints — and an agent that can write code can write constraint-driven geometry. Text-to-CAD was the first capability proven (early June), and it's the backbone of the loop.

The organic path: image to mesh. For shapes that aren't naturally describable in constraints — anything sculptural or organic — the pipeline goes through generation instead. FLUX generates a source image; Hunyuan-3D lifts that 2D image into a 3D mesh; the mesh gets cleaned, oriented, and sliced like any other. The first fully generation-driven design through the whole loop end-to-end was a mushroom — FLUX painted it, Hunyuan-3D gave it volume, the slicer and printer gave it mass. It is a slightly absurd first artifact and exactly the right one: it proves the path from "a model imagined a shape" to "the shape exists on the bed" with no human modeling step in the middle.

Both paths converge on the same MAKE stage: slice with the OrcaSlicer CLI against a profile (dialed per material — more on materials below), upload and start through Moonraker, monitor live temperature and progress over Moonraker's WebSocket. From the agent's side it's all one interface, which is the point.

A desktop robot arm craning a camera and work light low over a freshly printed part — the QA pass, with nobody watching.

The QA loop: a camera, an arm, and a vision model that learned what "normal" looks like

A print that finishes isn't a print that's good. Closing the loop means inspecting the result, and this is where the fabrication subsystem stops being a remote-control printer and becomes something the rest of the series would recognize as architecture.

The eyes. The inspection rig on the Ender carries two cameras: an OV9281 — a monochrome global-shutter USB camera, 1280×720, the wide-context eye — and an IMX477, a 12-megapixel colour sensor, the detail eye. A small light bar (a Feather microcontroller driving 72 addressable LEDs, current-capped at 1 A) sits coaxial with the camera and pulses per inspection sweep.

The hand. A Waveshare RoArm-M1 — a five-servo robot arm with the camera payload on the end — moves the eyes to taught inspection poses over the bed. The arm is deliberately dumb and bounded: it only moves to a handful of poses a human physically taught it (torque off, aim by hand, read the joint angles back, persist them), it operates under a policy file that defines safe zones and roles, and every single motion is appended to an audit log. Its HTTP control surface has no authentication, so it's reachable only through a broker that enforces the policy — the same "the contract is the surface, not the box" pattern from post 07, applied to a thing that can physically move. An arm that can only strike taught poses, inside declared zones, with every motion logged, is an arm whose blast radius you can actually reason about.

The brain. Inspection frames go to the Orin (the Jetson edge node from post 08), which runs a DINOv2 vision transformer in what I call delta mode: for each pose, it compares the current print's embedding against a baseline captured from the first clean sweep, and flags deviation from the learned "normal print" manifold. It doesn't need a labelled defect dataset to start; it needs to know what this print looked like when it was going well, and notice when it stops looking like that.

The most interesting finding in the whole subsystem is a vision result. Early delta-mode QA had a growth false-positive problem: as a print grows layer by layer, the image changes — naively, "the picture is different from the baseline" fires on every print, because the part is supposed to get taller. The fix was to stop inspecting raw RGB and start inspecting surface relief via photometric stereo — capturing the same view under several light directions (the light bar and a colour-multiplexing trick give you directional illumination) and computing surface normals from the shading. Uniform vertical growth produces no new normal discontinuities — a taller-but-correct print has the same surface character as a shorter-but-correct one — so a relief-based signal is growth-invariant. The defects you care about (layer shifts, blobs, spaghetti, warping) are normal discontinuities and light right up. Moving from three colour channels to a six-channel photometric representation is what made the QA signal mean something. That's a real engineering result with a real "huh" in it, and it came out of the loop running on actual prints.

The current model is honest-early: a CAXTON-pretrained baseline, no rig-specific fine-tune yet, scoring around 0.72 mean AUC at ~11.5 ms per frame on the Jetson. Strong on extrusion and feed faults, weak on the nozzle-state classes. The point isn't the number; it's that the data to improve it generates itself — every print lays down fresh inspection frames and per-print relief baselines onto a 16 TB corpus, and a teacher-distillation pipeline runs the heavy labelling on MirrorForge's second V100 while the first serves inference. The QA model gets better every time the lab prints, with no manual labelling, because the inspection loop is also a data-collection loop.

And the safety posture matches the INSTALL wall: the QA model never auto-aborts a print. On two consecutive anomalous sweeps it captures the evidence (wide OV sweep plus a 12 MP detail shot), pushes an ntfy alert, and lets a human decide. Diagnosis is automated; the destructive action stays with a person — the same self-diagnosing-not-self-overriding line post 07 drew for a diverged training run.

fab-mcp: the actuator is remote, the brain is on the captain

The whole subsystem is exposed as fab-mcp — a dozen tools (design_part, preview_part, slice_fdm, print_fdm, monitor_fdm, qa_frame, abort_fdm, the arm broker calls, and the resin-prep pair) — and the deployment detail is itself a separation-of-concerns decision worth stating. fab-mcp runs on Legion, the CAPTAIN node, not on the fab Pi. It drives the printers remotely over the LAN through a single stdlib client. The actuator (the Pi, DEV tier, critical = false, allowed to thrash and fail) is cleanly separated from the control surface (the MCP, on the stable captain). It's mesh-local with no public tunnel by design — the trust model is "anything on the tailnet/LAN can drive the printers," which is the right scope for a thing that moves physical hardware in my basement and exactly the wrong thing to expose publicly.

There's one more piece that closes a loop a fully-automated system couldn't: a human-QA upload server, also on Legion. I photograph a finished part with my phone, upload it, and the server binds the image into a structured evidence object — image hash, timestamp, which printer, which job, and my own observation and measurement — then files it into a per-machine commissioning ledger. This is the bridge between the agent's camera-and-model QA and a human's eyes and calipers. It earned its place immediately: a phone upload caught a slicer artifact (a randomized seam interacting badly with Z-hop) that was showing up on both printers, which led to fixing every profile at once. The automated QA watches the manifold; the human upload catches the thing the manifold didn't know to look for. Both feed the same ledger.

Receipts

The series runs on receipts, so here are the fabrication ones, with the self-referential one first because it's the whole thesis in one part.

The V100 shroud — the lab cooling itself. Post 04 spent two thousand words on the V100 thermal problem: a passively-cooled server card in a desktop case, power-capped to 220 W to hold ~70 °C, hitting 81 °C at full 250 W. The fabrication subsystem's first serious functional part was a blower shroud for exactly that card — five design iterations, printed in glass-fibre-reinforced high-temp PLA, flange-down for support-free printing, sealing a blower onto the card's heatsink. Installed June 11. Result: 81 °C → 61 °C at 100 % sustained load. A 20 °C drop. A second slim variant for the second V100 held both cards at ~60 °C average through a fifteen-minute dual-GPU burn. The cognitive mesh identified a thermal constraint on its own hardware, designed a part to fix it, printed it, and a human bolted it on — and the card the series spent a whole post learning to cool now runs twenty degrees cooler because the lab made itself a part. That is the velocity argument from post 10 with a physical object at the end of it.

The other receipts, briefly:

Cost of the whole capability: the Ender was already owned and upgraded over time; the SV04 was $140 used; the arm, cameras, and light bar are tens of dollars of parts each; the Orin and the fab Pi were already mesh nodes or cheap SBCs. The fabrication capability is, in incremental-dollar terms, a rounding error against the lab total from post 10 — which is the point being made one more time. The capability is expensive in skill and integration, cheap in parts, and the integration was cheap because the mesh was already there to integrate into.

Honest calibration

This series earns trust by saying what things aren't, so:

This is not lights-out manufacturing. It is agent-authored fabrication with a hard human install step, and the install step is permanent, not a phase-one limitation. The SENSE→MAKE trigger — the part where the mesh notices a thermal problem and decides on its own to print a fix — is still manual: I'm the one who connects "this card is hot" to "design a shroud." The autonomous version of that decision is deliberately not wired, because an agent that can decide to manufacture without a human in the decision is a different and much more careful project than an agent that can execute a manufacturing task a human scoped. The QA model is early (a CAXTON baseline, not yet fine-tuned on its own rig data). The resin path is scaffolded but not exercised. What's actually closed and running today is the FDM loop end-to-end: design or generate, slice, print, inspect with arm-plus-camera-plus-model, capture incidents, and log — across two printers, with a real QA pass, hands-off until the part comes off the bed.

What it proves is narrower and more durable than "the lab makes things by itself": it proves that the substrate the previous ten posts described is general enough to absorb a category of work it was never designed for. Nothing about the registry, the watchdog, the MCP surface, or the agent-operable dispatch was built with 3D printing in mind. They were built for compute. A printer slotted into them as a substrate, a print job slotted in as a workload, an inspection slotted in as telemetry, and an MCP slotted in as the control surface — and the layers above never had to know that this particular workload ends in plastic instead of a checkpoint file.

A wall-mounted box with a soft green ring glowing through its translucent lid in a dark room — power going out, health coming back as light.

The close

Post 10 said you build a system that absorbs capability, and used an agent operator slotting in as the proof — a new kind of operator the architecture absorbed without rebuilding. This is the same proof in a different medium: a new kind of work, reaching out of the digital substrate and into physical matter, absorbed the same way and for the same reason. The mesh that routes tokens now also moves an arm, fires a light bar, and lays down hot plastic — and it does it through the registry, the contracts, the watchdog, and the MCP surface that were already there.

The mesh grew a body. The architecture above it didn't move. That was always the whole idea.

The Substrate Series was ten posts on building a system that survives change. This is a bonus — an eleventh that exists only because the system did the thing it was built to do and absorbed something new after the series had already wrapped. That's the only proof of the thesis that actually counts.