The factory operating system
Layer 04Moduloa's proposed factory operating system for modular manufacturing would connect portable production blueprints to the floor that runs them. This manufacturing OS would manage revisions, layout, tooling, robot tasks, quality gates and unit traceability, with hub capacity and routing included in the thesis's data model. It does not exist yet. The ten objects and release discipline below define what would need to be built and tested.
Not simply an MES
The thesis describes the intended scope: the factory OS is not simply an MES. It is the control layer for reconfigurable production. That scope combines process revisions, physical configuration and traceability. It is a proposal to test, with overlap and integration questions still open.
The floor is a variable, not a constant
The proposed distinction is that the floor's arrangement is part of the production release. Between products, cells may move, fixtures may change, tooling may be swapped, and humanoids are the proposed reconfiguration layer. Layout, station capability, tooling state and robot task definitions would be objects the OS owns, versions and validates before anything physical is touched. Whether existing factory software can already cover that scope is one of the questions to test.
The open questions belong to someone else
The proposed OS specifies robot-task requirements, tooling, schedules and the records a run should return. The execution model assigns the physical work to cells and humanoids. Interfaces to robot controllers and the division of responsibility with MES or ERP remain unspecified; the learning roadmap names those factory-software systems as part of the stack to understand.
"Not simply an MES" is an intent, not a competitive claim: the people who build MES, digital twins and physical-AI platforms today own the layer this would have to become. Three questions are theirs, and they are on the list to ask rather than answered: how much of a working line is genuinely transferable rather than tacit and site-specific, whether OPC UA, MTConnect and OpenUSD interoperate well enough to re-instantiate a process without a rebuild, and who ends up owning a neutral routing layer at all. Corrections from that world are the most useful thing this page can attract. How to contribute → · Contact →
Ten things the OS has to know
The thesis's own data model, reproduced without softening. It is a sketch, and the honest limits below say why. Ten objects is what has been committed to in public so far.
| Object | What the factory OS should know | Specified where |
|---|---|---|
| Product | Part number, revision, BOM, demand, customer requirements | The intake standard |
| Production flow | Revision, station sequence, cycle time, quality gates, WIP policy | Industrialization |
| Station | Capabilities, location, utilities, safety zones, compatible tasks | Execution |
| Tool | ID, revision, calibration, storage, compatibility, maintenance | Quality |
| Fixture | ID, revision, product compatibility, datum strategy, storage, validation status | Industrialization |
| Robot task | Skill, tool required, success rate, safety limits, expected cycle time | Execution |
| Hub | Certification tier, capacity, equipment, supplier access, quality history | The hub scorecard |
| Quality record | Inspection results, test data, deviations, rework, traceability | Quality |
| Capacity slot | Reserved time, available time, cost, customer allocation | The economics |
| Routing decision | Cost, risk, shipping, tariffs, energy, demand proximity | Routing |
The right-hand column is this site holding itself to account. Every object points at something published, no object has running code behind it, and several of those pages specify only part of the object beside them.
Its scope is wider than one factory
Three rows above (hub, capacity slot, routing decision) are not floor concerns at all. They are what makes one hub comparable to another, and comparable is the precondition for routing. This is written for a network of floors, which is why the model treats it as an asset rather than an IT purchase.
Identity is what the model stands on
Every object above is useless if the physical thing cannot say which object it is. That is why the marking requirement is its own document: one part, one code, one globally unique identifier. The model is only as real as the identities that resolve into it.
A factory released the way software is released
Propose, review, validate, approve, release, and only then does anything physical move. Thesis §5 maps the whole GitHub flow onto a factory, repository to rollback.
- Version the process. Industrialization defines the stations, tooling, parameters and quality gates in a production blueprint.
- Choose a capable hub. Routing weighs capability, risk and location alongside the production economics.
- Release the configuration. Validate and approve the revision before assigning this hub's stations, tools and robot tasks.
- Run and record. Enforce the quality gates and bind measurements, tools, timestamps and blueprint version to each unit's traceability record.
- Review the evidence. Deviations and run data inform the next blueprint revision, which goes through validation and approval again.
The rule
Things change because an approved production flow changed, not because someone moved a cart or improvised a station. The same rule runs on the line in execution and on the next blueprint version in learning. One discipline, three places, one system.
Where the analogy breaks
Physical rollback is harder, and some changes cannot be reversed without scrapping WIP, moving materials or revalidating safety zones. So the system 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 matching failure mode is configuration drift, the physical layout quietly diverging from the digital one, answered 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.
Decisions with no human in the loop
Ten decisions, each specified in full on its own page. This is the index, not the specification: the first three run in the playthrough, refusal included. None of it is built.
One of five layers, and the one that carries the other four
No phase of its own, because it runs through all of them. One line per layer.
Layer 01 · Capacity as infrastructure
Capacity slots are OS objects: what turns "we have room in eight weeks" into a priced, reserved, comparable slot. Where the customer meets it →
Layer 02 · Portable blueprints
A blueprint no system versions, validates and deploys is a folder of documents, and a folder of documents is not portable. How a blueprint is made →
Layer 03 · Humanoids as the flexible layer
Robot tasks as OS objects are what make a humanoid a schedulable resource rather than a demo. The tracker →
Layer 05 · Certified hubs
Certification needs evidence, and the OS is what produces it: every gate result, deviation and test record. The hub scorecard →
What is unresolved and what has to be proven
One OS or two: the model has not decided
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.
Nothing is built
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: every screen there is a claim, not a screenshot.
The named risks
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 what that warns about, which is why it is labelled a sketch here, not a specification. Configuration drift is the second named risk, and the one that would void every other guarantee on this page.
The dated claims
The dated claim is P-12: a factory OS, meaning 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 →