Modular

Modular

Designing industrial processes like modular software. Each process step is a module with a published descriptor and typed ports, like a package with an interface. A deterministic kernel composes the modules into a plant, a compiler validates routes before anything runs, and a conformance harness tests every module against the MMS standard, the way a test suite gates a release.

Modular is a software model of a materials plant built from robotically exchangeable process modules: an Earth testbed with a glass line and a steel line today, a lunar pilot as the target. One deterministic kernel composes, plans, simulates and operates the plant, and a three.js twin shows it running.

The design started from an August 2026 reference architecture. Five review teams (process engineering, software architecture, safety and contamination, robotics and lunar operations, simulation fidelity) then attacked it in an adversarial audit. They raised 103 findings, and every Critical and High finding was resolved in the revised spec before the code followed.

What it does

• Runs two live lines in 3D. Glass (batch house, tank furnace, forehearth, forming rolls, annealing lehr, cut and inspect) and steel (iron powder feed, induction melt, ladle refining, continuous caster, cooling bed, billet yard). Each machine is bound to the running kernel; one the frame doesn't report goes dark.
• Injects faults and shows the response. Kill the melt, strand a transport mule or drift the QC gauge, and watch ISA-18.2-style alarms (first-out, acknowledge, shelve) and the recovery in the decision stream.
• Tunes itself on a headless twin. The agent debugger replays the campaign deterministically, searches the operating policy and offers the result: in one run, 15 replays found a policy that finished the campaign 217 minutes sooner (27.71 h against a 31.32 h baseline).
• Compiles processes. The process-compiler playground turns a flowsheet into a schedule with resource leases and a site power cap. Two 350 kW melt cells serialize under a 500 kW cap and run in parallel at 800 kW.
• Discovers new processes. Discovery & Planning researches a process with sources, drafts a flowsheet and compiles it into the library only if the real compiler accepts it. A discovered route (for example, lunar sulfur extraction) then runs as a headless campaign beside the 3D lines.

How it works

Every module family is a separate component behind one interface: a descriptor in, typed material streams in and out, telemetry events out. No module imports another; they compose only through the kernel and typed ports. Streams carry phase, composition, temperature, pressure, hazard flags and genealogy, and the compiler checks port compatibility rather than assuming it.

The kernel is a hybrid discrete-event engine. Batches, robots and scheduling are events, with continuous process integration between them. A given scenario and seed replays identically, in the browser or headless on Node, and the front end sees state only through snapshot and delta frames.

The planners, scheduler, state-machine guards, alarm engine and conformance audits are plain TypeScript with no LLM and no network. The research agent and ops copilot use the Anthropic API, and each has a deterministic offline fallback, so the app and CI run without an API key.

The MMS standard

The project also produced a draft standard, MMS (Modular Materials System), so that modules from different authors can be exchanged and checked. It builds on existing standards rather than replacing them: VDI/VDE/NAMUR 2658 (MTP), ISA-88, ISA-95, PackML, ISA-18.2, ISA-101, OPC UA practice and VDA 5050, with crosswalks so an adopter maps rather than rewrites.

• Nine parts, from the module descriptor and kernel-guarded state model through typed streams, alarms, routes, plans and robot logistics to the conformance program.
• Mass-honest custody. Mass must close exactly over a campaign (feed = product + waste + rework + WIP), and a faulted module or stranded robot keeps custody of its material until a commanded drain or rescue moves it.
• Four conformance levels, C0 Described to C3 Foundry. The reference plant holds C3.
• Machine-checked conformance. An oracle runs the reference campaigns with faults injected and produces the evidence table; a claim must name its level and the versioned ruleset it was judged against. The standard is now at 1.5.4-draft; version 1.2.0-draft passed with a 188-test suite.

Status: prototype. Simulation parameters are uncalibrated handbook values and are labelled that way throughout.