Reverse-logistics simulator — how the dashboard numbers are computed
Companion to 2026-06-23-nvidia-repair-flow-economic-model. Source code:
lab/reverse-logistics-sim/index.html — model() (volumes and costs at a
given τ), savings() (the three impact bars), and metrics() (the KPI
strip + recreated dashboard).
Updated 2026-06-26 to the v2 model (Greg en-route call, 2026-06-26-greg-call-en-route-back-to-explain-the-process). Two structural changes since the first cut: the single τ is now split into a serial repair clock and a customer replacement clock (decoupled by the spares pool), and the approval gauntlet is modeled as a separate, fast-trackable latency. The impact panel is now three bars (revenue / net cost / total) plus a cost-per-chip readout — the older rep/cap/leak three-bucket description is retired.
The “Impact relative to baseline” bars are differences between the live state at the current serial τ and a frozen baseline snapshot at τ₀ = 60 days (RMA tracking off, fast-track off). Baseline recomputes only when an assumption is edited; everything else is live as you drag the τ slider.
Inputs
| Symbol | Meaning | Default | Basis |
|---|---|---|---|
| N | installed GPU base | 100,000 | guess |
| f | annual failure rate | 9% | estimate |
| e | entitlement share (returns NVIDIA owns) | 99% | interview — <1% of RMAs ever rejected [G-0626] |
| P | unit price (lost sale / unsellable GPU) | $30,000 | guess |
| δ | cost of capital on tied-up inventory | 12%/yr | assumption |
| ℓ | owed-back leak rate when tracking is off | 5% | guess |
| τ | serial turnaround days (the lever) | 60 today, ~30 best case | interview [G-0626] |
| r̄ | technical repair ceiling | 90% | interview — “chip rarely the problem” [G-0626] |
| κc | reman-line capacity cap on r | 75% | interview — repair vs revenue [G-0626] |
| τₐ | approval gauntlet (pre-warehouse) | 10 days | interview [G-0626] |
| κ | known-defect share (fast-trackable) | 90% | interview [G-0626] |
| τc-ship | ship-from-stock time | 7 days | assumption |
| ρ / μ | refurb tail share / cost multiple | 10% / 2× | interview mix; μ strawman [G-0626] |
Derived quantities
rate(τ) = clamp(0.60 + 0.0045·(60 − τ), 0.35, 0.90) technical repaired-in-time rate
rEff(τ) = min(rate(τ), κc) capacity-capped repair rate
Crf(τ) = 1,500 + 300 + 150·τ raw cost per repair (parts + op-floor + op-slope·τ)
crEff(τ) = Crf(τ)·(1 + ρ(μ−1)) blended incl. pricier refurb tail (= Crf·1.10 at defaults)
Per-repair cost falls as τ falls because the operational layer (labor, freight, coordination) shrinks while the $1,500 parts floor stays. At τ = 60d, crEff ≈ $11.9k; at τ = 30d, crEff ≈ $6.9k. The capacity cap κc = 75% only binds below τ ≈ 27d — speed alone lifts r into the mid-70s, but pushing past κc needs a reman-line allocation decision, not faster logistics.
Volumes: R = N·f = 9,000/yr returns; F = e·R ≈ 8,900/yr entitled.
The two clocks (new in v2)
effApproval = fastTrack ? round(τₐ·(1−κ)) : τₐ 10 days, or ~1 day when known-defect batches are fast-tracked
stockoutFrac(τ) = clamp((τ − 30)/60, 0, 0.6) how often the pool can't cover the customer
τc(τ) = effApproval + 7·(1−s) + τ·s CUSTOMER replacement clock, s = stockoutFrac
The serial clock τ (warehouse → stock) drives Crf and trapped capital. The customer clock τc (case-submit → replacement) is what the customer feels — short (~1–2 weeks) while the spares pool has stock, ballooning toward τ on a stockout. Faster τ buys customer SLA indirectly, by keeping the pool full; fast-tracking approval buys it directly, at ~zero physical cost.
model(τ) — the annual loss
replaced = (1 − rEff)·F filled from new inventory (lost sale at P)
repaired = rEff·F fixed and returned to the pool
lostRepl = replaced·P
repairSpend = repaired·crEff
leakLoss = tracking ? 0 : ℓ·R·P owed-back cores never reconciled — a software (not speed) lever
total = lostRepl + repairSpend + leakLoss
At the baseline (τ = 60d): replaced ≈ 3,560 → lostRepl ≈ $107M; repaired ≈ 5,350 → repairSpend ≈ $63M; leakLoss ≈ $13.5M (tracking off). Total ≈ $184M/yr.
savings(m) — the three impact bars
revSaved = (BASE.replaced − m.replaced)·P chips no longer pulled from production, sold at full P
netCostSaved = BASE.repaired·BASE.cr − m.repaired·m.cr fall in total repair spend vs baseline
revSavedNet = revSaved + netCostSaved total financial impact
- Top-line revenue contribution (
revSaved) is rate-driven: faster τ → higher rEff → fewer scrap-and-replace → more chips back on the open market. - Net cost savings (
netCostSaved) nets the cheaper per-unit repairs against the cost of repairing the extra units, so it can’t double-count the revenue bar. - Total financial impact is their sum.
At τ = 30d vs the 60d baseline: revSaved ≈ +$36M, netCostSaved ≈ +$18M, total ≈ +$54M/yr — matching the illustrative table in the model doc. A fourth readout shows cost to repair / chip ($11.9k → $6.9k) as a number, not a bar (different scale).
Owed-back capital is no longer a bar; it surfaces as the live Units Owed
Back KPI and the leakLoss term in total, cleared by the RMA-tracking
toggle independently of τ.
metrics() — KPIs and SLA
SLA(τ) = clamp(round(100 − 1.9·(τc(τ) − 8)), 5, 99) % within the 30-day CUSTOMER SLA
SLA is now driven by the customer clock, so it responds to both levers: today (τ = 60d, no fast-track) ≈ 32%; τ = 30d ≈ 83%; τ = 30d with approval fast-tracked → 99%. The “Repair throughput (serial)” KPI shows τ itself; the POOL and CMs node panels expose the two clocks, the approval latency, and the capacity-capped repair rate side by side.
Controls that map to levers
- τ slider — the serial repair clock (physical + logistics lever).
- Today / With visibility — presets: Today = τ 60, tracking off, fast-track off; With visibility = τ 30, tracking on, fast-track on.
- Auto-fast-track approval toggle — collapses τₐ (10 → ~1 day) for the known-defect share; moves the customer SLA at ~zero physical cost.
- RMA tracking — eliminates the owed-back leak; a software lever the speed lever can’t touch.
Sources: lab/reverse-logistics-sim/index.html;
2026-06-23-nvidia-repair-flow-economic-model;
Greg en-route call, Jun 26.