Loading
Because production systems handle repeat manufacture. A custom or engineered-to-order job has design time, procurement lead times and a customer date, and none of that fits a repeating work order.
So it is tracked in a spreadsheet, and the customer date is promised from a feeling about how the last one went.
The build is a project: design phases, procurement with real lead times, assembly and commissioning, with dependencies between them.
Components draw from stock and purchase orders in Books, labour from attendance in Nest, so the cost of the build is real rather than standard.
It will not schedule the shop floor. Capacity here is people and phases, not machine loading.
It also will not forecast component lead times — it records the ones you enter.
The date promised to the customer accounts for the component with a nine-week lead time, because that dependency is in the plan.
Margin per build is visible, so the pattern across a product family — where quoting has drifted from real cost — becomes readable.
Products, not integrations. Each one reads the same record, so a join is a permission rather than a sync job with a mapping screen behind it.
Yes, in Books, and consumption posts against the build.
Yes, as versioned docs on the project.
A phase like any other, with its own visit records.
Half an hour on your own numbers is usually enough to say whether Loop is the right place to start.