The factory operating system

A production execution system normally runs a floor that already exists: the stations are where they are, the line does what it does, and the software's job is to schedule, track and report against that arrangement. This model cannot assume the arrangement. The floor changes shape between products — cells move, fixtures change, tooling is swapped, and humanoids do the moving. So layout, station capability, tooling state and robot task definitions are not configuration a vendor sets once at commissioning; they are live objects the OS owns, versions, and validates before anything physical is touched.

The thesis says the OS should eventually manage product, process, layout, tooling, quality, traceability, robot tasks, hub certification and capacity allocation. Two of those nine — hub certification and capacity allocation — are not floor concerns at all. They are what make a hub comparable to another hub, and comparable is the precondition for routing. The OS is written for a network of floors, which is the whole reason the model treats it as an asset rather than an IT purchase.

Nothing here says existing factory software is bad, and nothing here has earned the right to say it. The honest position is the one already written into the contact map: the people who build MES, digital twins and physical-AI platforms today own the layer this would have to become, and the open questions are theirs to answer — how much of a working line is genuinely transferable versus tacit and site-specific, whether the data models (OPC UA, MTConnect, OpenUSD) interoperate well enough to re-instantiate a process without a rebuild, and who ends up owning a neutral routing layer at all. Those questions are on the list to ask, not answered. Corrections from that world are the most useful thing this page can attract.

Every object above is useless if the physical thing it describes cannot say which object it is. That is why the marking requirement exists as its own published document: one part, one code, one globally unique identifier. An OS with no one standing at the receiving desk cannot interpret a handwritten label, and the object model is only as real as the identities that resolve into it.

Things do not change because someone moved a cart or improvised a station. They change because an approved production flow changed. That is what makes a floor auditable, transferable and scalable — and it is the same rule the execution phase applies on the line and learning applies to the next blueprint version. One discipline, enforced in three places by one system.

Physical rollback is harder than software rollback. Some changes cannot be fully reversed without scrapping WIP, moving materials or revalidating safety zones. The system therefore needs rollback classes, and every blueprint carries a WIP policy decided in advance rather than in a panic: complete, quarantine, transfer, freeze, or scrap. The risk register names the matching failure mode — configuration drift, where the physical layout diverges from the digital one — and answers it with daily robot and camera verification, fixture IDs, tool scans and deviation rules. An OS that cannot detect drift is a document, not a control layer.

Two documents on this site describe the software differently, and it is better to say so than to paper over it. The thesis puts hub, capacity slot and routing decision inside the factory OS's object list — one system that knows both the floor and the network. The people page splits them: "the factory OS that runs a hub, and the supply-and-logistics OS that connects hubs into a network and decides where a product should be produced." Both are defensible. Whether placement is a function of the thing that runs a floor or of a separate network-level system is a real architectural question, and it is unanswered. It matters commercially too, because the second reading is closer to what would be licensed to a hub that Moduloa does not own. This page will be updated when there is an answer, not before.

Capacity is only sellable if it is measured. Capacity slots — reserved time, available time, cost, customer allocation — are objects in the OS, which is what turns "we have room in eight weeks" into a priced, reserved, comparable slot. Where the customer meets it →

The blueprint is the artifact; the OS is the repository, the review pipeline and the release mechanism around it. A blueprint that no system versions, validates and deploys is a folder of documents, and a folder of documents is not portable. How a blueprint is made →

Robot tasks — skill, tool required, success rate, safety limits, expected cycle time — are OS objects, which is what makes a humanoid a schedulable resource rather than a demo. This layer is the model's most-watched bet, and the OS is where its reliability would become measurable instead of anecdotal. The tracker →

Certification needs evidence, and the OS is what produces it: every gate result, deviation and test record from every run. The living certification score is Layer 05's instrument, but the OS carries the records it is computed from. The hub scorecard →

None of this is built. There is no factory OS — no repository, no data model in code, no running instance. The Stage 0 plan lists "factory OS data model sketch" in the 6–12 month band as an output still open, and the task list on the manufacturing page shows it open. The playthrough is the honest version of this: a simulated configurator published so the look and feel can be judged before the machinery exists — no suppliers are contacted, nothing is stored, and the OS behind it does not exist. Every screen there is a claim, not a screenshot.

The risk register names the failure mode this page is most exposed to, and it is not technical ambition — it is scope: the factory OS can become too large too early. The stated mitigation is to start with a minimal production flow data model and expand from real needs. A ten-object model published before a single line runs is exactly the kind of thing that mitigation is warning about, which is why it is labelled a sketch here rather than a specification. Configuration drift is the second named risk: a digital layout that quietly stops matching the physical one makes every other guarantee on this page void.

The dated claim is P-12: a factory OS — software controlling layout, tools, quality and capacity as versioned configuration — is central to flexible manufacturing, due 2036-12-31. It is a claim about the industry, not about Moduloa, and it can fail in two directions: the OS layer may turn out not to be central at all, or it may be central and owned by someone who already has it. P-27 — a certified process transferred between two organizations' cells, dated 2027-06-30 — is the nearer test of whether the portability this layer exists to enable is real. P-10 (validated blueprints move between certified factories) carries a 2036 horizon, so it is the long bet, not the next one. See the register →

This layer needs the people who have actually stood a line up and moved it. If you know how much of a working process survives a site transfer, where the data-model seams really are, or why a neutral control layer will not happen — that is the most valuable thing anyone can send. How to contribute → · Contact →