Moduloa Manufacturing is built as five projects that together would take a product from its design to its customer's door: the price, the suppliers, the route, the floor and the record. All five would stand on one shared foundation: a data model, not yet written, and one worked example. Every task is listed here with a plain test for done, and several people can work on the same task, each with its own deliverable.
Stage 0 · nothing is built · two seats · twenty-three open tasks · no commitment accepted yet · reviewed 5 October 2026, next by 2 November 2026
To take a task, open it and use its Ask to commit link. How committing works
Moduloa at the top, five projects under it, one foundation under all five, and the tasks inside each.
Moduloa From your design to your customer's door
Every line counted in the open, with no margin added
Three tasks · three open · research: strongTested once against an independent standard, so no customer has to test it again
Four tasks · four open · research: thinEvery route chosen by one published rule set, and written down with its reasons
Four tasks · four open · research: someThe same blueprint and the same jigs, so a part made at one hub fits at another
Four tasks · four open · research: strongEvery unit marked, and traceable to how it was made
Three tasks · three open · research: someCHARTER Factory OS data model v0.1 · EX-100 open dataset Three tasks · research: some
Moduloa as a whole: the expert calls, the pilot product, the funder's read and the story
One home for every fact, and one logged way to change a rule.
In the design, every fact Moduloa runs on has one home: one identity per part and unit, one log of what happened, one published way to change a rule. A second copy beside the OS is where a record stops being complete, so the OS has to remove the reason for it: a change request would be logged and answered with a date, and the fix would reach every hub. Nothing is built yet. One system for everything is the wrong goal at the edges. Your ERP stays yours and would read the record through a published API, machines keep their own controllers, and a spreadsheet stays welcome at intake as an on-ramp, converted and echoed back for your sign-off.
Sources Why a second copy fails: NTSB, Boeing 737-9 door plug report AIR-25-04, 2025 · FDA, Warning Letter 320-17-17, 2017 · Why second copies grow: Rakovic, Duc and Vukovic, JEEMS 25(4), 2020 · Kopper, Klotz, Westner and Strahringer, JITM 30(4), 2019 · Where one system stops: ISA-95 / IEC 62264 · Fowler, Bounded Context, 2014
Twelve further pieces of the work could each look like a project of its own. None is: each is something one of the five has to achieve, and where a piece leans on a second project, the table says so.
| Piece | Lives in | How it fits |
|---|---|---|
| Pricing reserved capacity | CHEQUER | The yearly fee is the second line of every quote (C-03). |
| Delivery terms and duty in the price | CHEQUER | The delivery term decides which lines the price includes (C-02).Who imports in each market is WAYBILL's question. |
| What a supplier's quality system must prove | PYX | It is the qualification standard itself (Q-01, Q-02). |
| Obsolescence and continuity | PYX | Qualification covers what may be supplied as well as who: end-of-life notices and qualified substitutes (Q-04).The cost of a last-time buy lands in CHEQUER, and a redesign it forces is a new JACQUARD revision. |
| Importer of record and cross-border routing | WAYBILL | It decides which lanes can be delivered at all (B-04).The duty it creates is a line in CHEQUER's price. |
| Regulated products, only to hubs certified for them | WAYBILL | A rule the route reads before it compares cost (B-01).The certification it reads is JACQUARD's, and adding a hub stays the customer's quality decision. |
| Hub certification by domain and size | JACQUARD | What a floor must show before it runs blueprints (J-01).It borrows PYX's method (evidence on top of ISO, checked again, lost and regained), and WAYBILL reads it before it compares cost. |
| Portability of a qualified process | JACQUARD | The transfer protocol (J-03), the nearer test behind claim P-27. |
| Machine and robot interfaces | JACQUARD | How a blueprint's robot tasks reach a machine (J-04).The other side of the same seam, the customer's ERP, is TOUCHMARK's. |
| Traceability and identity | TOUCHMARK | One code per part, a tree of codes per unit (R-02).Suppliers mark their parts under PYX, and the floor mints a code for each closed sub-assembly under JACQUARD. |
| APIs to customers' ERP and MES | TOUCHMARK | The read API and its mapping (R-01). |
| Complaint to correction | TOUCHMARK | From complaint to fix, with response time on record (R-03).The fix itself is the next JACQUARD revision. |
A new manufacturer has no track record to point to. What the five projects would produce together is trust without one: a price you can check line by line, suppliers qualified against a published standard, routes logged with their reasons, the same blueprint and jigs at every hub, and a record you can open. None of it is history yet. It is how history would be recorded.
The habit that earns that trust is not a sixth project either. It is the public record, practised in all five and already running here: the predictions register, terms published before anyone signs them, and the scorecard with its own ledger. The predictions register · The terms · The hub scorecard
The thesis describes the system in five layers, and the five projects are the work that builds it. They do not line up one to one: Layer 04, the factory OS, is the shared foundation; portable blueprints, humanoids as the design target and certified hubs are JACQUARD's work, and WAYBILL reads the certification; capacity as infrastructure is priced in CHEQUER. PYX and TOUCHMARK have no layer of their own: the thesis files suppliers under intake and the unit record under the factory OS.
Twenty-five tasks across five projects, the foundation and Moduloa as a whole. Each row opens its full card: the test for done, the effort, who it suits and what to read first. Looking by role? Each open invitation lists the tasks that suit it.
Pick a task, or name your own, and send a commitment request: the task, what you will deliver, and a date no more than three months after it is accepted. Moduloa answers yes or no. Once accepted, the commitment shows on the task and on your seat card with its date, and your first one takes the next number on the register. Several people can work on the same task, each with its own deliverable. A missed date is marked lapsed and a task handed back early is marked released; both stay on the record, and the task opens again.
Questions about any task go to seat 001, the founder, through the same page.
Some Stage 0 work belongs to no single project: being one of the expert calls, choosing the pilot product, reading the model as a funder, and telling the journey. These four tasks are work for Moduloa itself, not pieces of the system. The rest of that work, from the thesis revision to the investor thesis, stays on the Stage 0 plan as Moduloa's own.
W-01Open
W-02Open
W-03Open
W-04Open
Two seats so far. A seat card shows what its holder has committed to, with dates.
Owner · no CLA needed
Moduloa's own
Aboard from the start, before seats had states.
The founder's seat needs no contributor licence agreement (CLA) with itself, and its card says so. The register, with every seat in full →