--- title: Deep Cost Modeling description: Bottom-up cost decomposition, lot-size economics, learning curves, and breakpoints. --- # Deep Cost Modeling Every ARCNM quote is a **curve over batch size**, not a single number. Setup amortises over more units, fixtures amortise once, tooling has a finite life, learning compounds. Deep Cost Modeling decomposes all four — bottom-up, per process, per coefficient — so every euro of the unit price traces back to a named source. --- ## The cost equation ``` unit_cost = material_cost + (setup_time / n) × labour_rate ← amortised setup + cycle_time × labour_rate ← run labour + cycle_time × machine_rate ← machine burden + tooling_amortisation + overhead_variable + overhead_fixed + calibration_adjustment ← see Calibration ``` Each coefficient (labour rate, machine rate, feed, overhead) resolves through the [environment cascade](./calibration-environments.md). Material mass uses a **discipline-aware blank**: - Milling: rectangular blank (raw bar minus envelope + chip-overrun) - Turning: cylindrical bar - Sheet metal: sheet blank - Casting: poured-mass-plus-runner Setup time is **amortised into labour** (operator-present during setup — HGB §255 / IAS 2 convention), not split into a separate line item. --- ## The lot-size curve `POST /parts/calculations` always returns the full curve. Default grid: ``` n = 1, 5, 10, 25, 50, 100, 250, 500, 1000, 2500 ``` Each grid point carries: ```json { "quantity": 50, "unit_cost_eur": 12.84, "direct_unit_cost": 10.62, "overhead_var": 1.45, "overhead_fixed": 0.77, "machine_id_at_n": "machine_haas_vf2" } ``` `cost_at(n)` linearly interpolates between grid points. For curves where you need a non-default grid (e.g. `n = 7, 350`), pass `lot_grid` on the request and the exact points are computed. ### Why `machine_id_at_n`? Optimal machine choice **changes with batch size**: - n = 1: a 3-axis vertical mill with manual setup. - n = 50: 5-axis mill with a vise tombstone. - n = 1000: a dedicated horizontal machining center with a pallet changer. `machine_id_at_n` records which machine was selected at each point so the audit row tells you *why* the price stepped. --- ## Breakpoints — the economically meaningful kinks The curve isn't smooth; it has kinks. We surface them as `breakpoint` records so a UI can render "the price drops at n=50 because setup amortises here": ```json { "breakpoints": [ { "kind": "setup_run_crossover", "quantity": 25, "unit_cost_eur": 18.42, "rationale": "Per-unit amortised setup falls below cycle-time labour" }, { "kind": "machine_class_crossover", "quantity": 250, "unit_cost_eur": 11.20, "rationale": "5-axis machining-center cheaper than 3-axis at this volume" }, { "kind": "tool_life", "quantity": 500, "unit_cost_eur": 10.85, "rationale": "Carbide endmill life expires, tool-amortisation step" }, { "kind": "learning_curve_kink", "quantity": 100, "unit_cost_eur": 11.97, "rationale": "Learning curve crossover" } ] } ``` All breakpoint kinds: | `kind` | What it means | |---|---| | `setup_run_crossover` | Amortised setup falls below cycle-labour cost | | `fixture_amortisation` | Custom-fixture cost fully amortised | | `tool_life` | A tool wears out, replacement amortises into the next unit | | `eoq_optimum` | Economic-order-quantity sweet spot | | `machine_class_crossover` | A different machine class becomes cheaper | | `learning_curve_kink` | Cumulative-average learning reaches a step where the unit cost re-levels | Walk `breakpoints` directly to drive a tooltip or "best value at" UI. --- ## Learning curve Cumulative-average learning is applied by default — as cumulative volume grows, the average time per unit comes down. The learning rate is environment-tunable per discipline and per machine class through calibration. If your shop learns faster on aluminium 5-axis than on titanium turning, calibration picks that up from your observations. --- ## VDI 3258 (overhead-rate framework) For German manufacturing customers, ARCNM emits a VDI 3258-conformant overhead breakdown — variable vs fixed, machine hour vs labour hour, allocated vs absorbed: ```json { "vdi_3258": { "machine_hour_rate_eur": 78.40, "labour_hour_rate_eur": 42.10, "overhead_variable_pct": 18.5, "overhead_fixed_pct": 22.0, "absorbed_at_n": 50 } } ``` Auditors recognise the structure; finance teams reconcile it directly against ERP. --- ## Cost decomposition by line item A cost breakdown like this is available within the calculation's `analytics` blob (the top-level response carries `unit_cost`, `total_cost`, `setup_cost`, and `currency` — see the [Calculations reference](../api/calculations.md#get-calculation)): ```json { "material": 3.21, "setup": 1.05, "cycle_labour": 4.12, "machine": 3.66, "tooling": 0.18, "overhead_variable": 0.62, "overhead_fixed": 0.85 } ``` The line items sum to the unit cost. ### Where calibration enters Geometry, features, machine selection, and process planning are derived from industry-standard manufacturing theory and don't change as you calibrate — calibration applies a conservative, fully-logged adjustment to the final price. This separation is what makes the audit trail defensible: you can always tell what's "the engine's view of reality" and what's "your environment's correction". A conservative safe band caps the adjustment per quote; values outside that range are logged + suppressed, never silently applied. --- ## Currencies All cost fields are EUR by default. Pass `currency` on the request to get the response converted at the daily ECB middle rate: ```json { "currency": "USD" } ``` Supported currencies: EUR, USD, GBP, CHF, JPY, CAD. Conversion is **at quote time, not at retrieval time** — re-quote to pick up a fresher FX rate. --- ## See also - [Concepts → Extraction](./extraction.md) — feeds the cost model. - [Concepts → Calibration & environments](./calibration-environments.md) — how rates resolve. - [Concepts → Audit & provenance](./audit-provenance.md) — every term traces back. - [API → Calculations](../api/calculations.md) — endpoint reference.