Represent manufacturing actors, facilities, machines, processes, materials, capabilities, capacity and evidence.
Output: normalized provider/capability records.Methodology · reproducibility · attribution
How ManuNexus works.
This is the system-wide method and resources page for Atlas, Compare, Mesh and Disruption Lab. It documents what each module decides, how the modules connect, which equations and optimization/simulation methods are used, what is validated, and which external resources support the implementation.
Reproducibility rule: decision outputs use explicit scenario, provider, cost, capacity, routing and disruption inputs. Synthetic values are labelled as synthetic and must not be interpreted as supplier quotations or verified industrial operating data.
System method
One workflow, four modules
The modules are decision layers over one shared ManuNexus data model rather than separate standalone systems.
Evaluate technology/provider economics and feasibility for a defined part, quantity and deadline.
Output: feasible alternatives, cost curves, break-even regions and sensitivity thresholds.Combine feasible providers into a production network and allocate demand with logistics and optimization.
Output: nodes, quantities, routes and Pareto configurations.Stress-test a selected network under availability shocks and compare frozen versus diversified reallocation.
Output: service probability, fill rate and re-orchestration evidence.Module methodology
Decision logic by module
ManuNexus Atlas
Decision role: establish the manufacturing system that later modules are allowed to reason over.
Inputs
- Organizations, facilities and locations
- Machines/processes, materials and capabilities
- Capacity/availability fields
- Evidence source, verification state and freshness
Method
Atlas normalizes provider records into shared organization, facility and production-cell concepts. Search/filtering exposes only recorded attributes; missing evidence remains missing rather than being inferred as fact.
Output
An evidence-aware provider pool that Compare and Mesh can consume using the same identifiers.
ManuNexus Compare
Decision role: determine which individual manufacturing technology/provider is economically feasible for the stated scenario.
Inputs
- Quantity, deadline and part/material assumptions
- Engineering, setup, tooling and material costs
- Machine/process time, batch/build size, yield/scrap
- MOQ, order limits and available machine time
Method
Total expected cost is recalculated for each feasible alternative. Integer quantity scans identify changes in the cheapest feasible technology. One-way sensitivity analysis changes one assumption while holding the others constant.
Output
Technology/provider recommendation, cost curves, discrete break-even boundaries and assumption thresholds.
ManuNexus Mesh
Decision role: configure a production network rather than choose only one provider.
Network-builder mode
Filters nodes by compatibility/capacity/deadline, then allocates quantity according to the selected objective. Cost, time, distance and reliability can be used in the displayed balanced score.
Integrated optimization mode
A mixed-integer model jointly considers manufacturing allocation, provider activation, vehicle assignment, pickup flow and route timing. The current advanced mode samples an epsilon-constraint grid across total landed cost, fulfilment time and logistics CO₂e.
Output
Feasible allocations, routes, landed-cost components and a sampled nondominated configuration set.
ManuNexus Disruption Lab
Decision role: evaluate how the selected network behaves when provider availability deteriorates.
Inputs
- Immutable selected-network snapshot
- Baseline operational availability
- Additional outage probability
- Simulation iterations and random seed
Method
Monte Carlo availability sampling compares a strict/frozen strategy with diversified reallocation. Operational availability is treated separately from a generic reliability score.
Output
Service probability, mean fill rate and evidence of whether diversification improves or preserves service under the tested shock.
Core equations & optimization semantics
What the engines calculate
Expected manufacturing cost
Total = engineering + setup + tooling/replacement + material usage + machine/process cost + other explicit provider costsTooling life, batch/build/cycle counts and completed attempts introduce integer step effects.Good-part capacity
usable quantity = completed production attempts/batches within the available production window × expected yieldFractional unfinished builds/cycles are not counted as finished capacity.Balanced network comparison
score = Σ weightᵢ × normalized displayed criterionᵢThe score is scenario-relative; weights are normalized and the criteria shown to the user are the criteria used.Total landed cost
manufacturing cost + fixed dispatch + distance cost + vehicle-time cost + explicit provider handling costVehicle and handling parameters are scenario inputs; starter values are synthetic examples.Transport CO₂e planning approximation
distance × empty-vehicle factor + carried-load tonne-km × load factorThis is a transparent planning approximation, not a full speed/fuel/traffic physics model.Effective operational availability
baseline operational availability × (1 − additional outage probability)Used by the current stochastic disruption prototype; correlated hazards and repair trajectories are not yet modeled.Validation
How the system is checked
Golden mathematics
Hand-checkable cost, capacity, allocation, routing and emissions cases test the numerical engines independently of the UI.
Cross-module scenarios
The public validation suite runs six synthetic cases across the shared provider pool, Compare, Mesh, integrated Pareto optimization and Disruption Lab.
Versioned evidence
Public release records disclose regression results, production certification evidence, known limitations and what changed between releases.
Research basis
Methodological references
These sources inform model structure or interpretation. Their numerical values are not silently copied into ManuNexus starter inputs.
Technology economics
Compare exposes its detailed cost-method references and formula guide through its machine-readable methodology endpoint.
Integrated manufacturing & logistics
The Mesh advanced-mode metadata records the production-routing, distributed-manufacturing and epsilon-constraint literature used to frame the v4.3 decision engine.
System architecture
The shared product-family API exposes the module objectives, common services, data domains, workflow and architecture principles.
Software & public resources
Dependencies and attribution
FastAPI
Python API/backend framework used across the ManuNexus service.
Google OR-Tools / CBC
Used for integer and mixed-integer optimization in manufacturing allocation and integrated planning.
Leaflet 1.9.4 + OpenStreetMap
Used for interactive provider/network maps and geographic context.
OSRM
Used when available for road-network distance/duration estimates; the public routing service has no ManuNexus-controlled SLA and is not live traffic.
Chart.js
Used for browser-side visualization of technology-economics and sensitivity results; calculations remain server-side.
ORNL AMCAC
Reviewed as an external additive-manufacturing cost-assessment reference. Its code/workbook formulas are not copied into ManuNexus.
GitHub
Hosts source control and selected durable source-of-truth data/evidence records.
Render
Hosts the deployed ManuNexus web service and performs production deployments from the repository.
Uvicorn
ASGI application server used to run the FastAPI production service.
Machine-readable resources
Key public API endpoints
| Scope | Endpoint | Purpose |
|---|---|---|
| Architecture | GET /api/manunexus/products | Products, workflow, shared services and data domains. |
| Shared provider pool | GET /api/manunexus/shared-pool | Normalized cross-module provider/capability data. |
| Compare | GET /api/manunexus/compare/resources | Detailed Compare formulas, method steps and references. |
| Compare | POST /api/manunexus/compare/analyze | Run the technology-economics decision model. |
| Mesh | POST /api/manunexus/mesh/optimize-multitech | Run explicit multi-technology network allocation. |
| Integrated Mesh | GET /api/manunexus/v4.3/meta | Objectives, Pareto semantics, scope and research references. |
| Integrated Mesh | POST /api/manunexus/v4.3/mesh/pareto | Run manufacturing-routing/Pareto planning. |
| Validation | GET /api/manunexus/validation-matrix | Six cross-module validation cases and expectations. |
| Data quality | GET /api/manunexus/data-quality | Shared-pool data-quality summary. |
| Versions | GET /api/manunexus/versions | Release history, certification evidence and limitations. |
Interpretation boundaries
What ManuNexus does not establish automatically
Current provider economics/capacity validation data remain synthetic unless explicitly replaced with verified provider inputs. Multi-technology functional equivalence requires independent engineering, quality and compliance confirmation. The Pareto set is sampled rather than exhaustive. Transport CO₂e is a planning approximation. Public OSRM estimates are not live traffic. Disruption Lab does not yet model correlated hazards, repair/MTTR trajectories, inventory or multi-echelon ripple effects. Runtime storage is not yet a durable authenticated multi-user workspace.