Concepts

Deep Cost Modeling

Bottom-up cost decomposition, lot-size economics, learning curves, and breakpoints.

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. 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:

{
  "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":

{
  "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:

{
  "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):

{
  "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:

{ "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.