§0 — The one line
These four terms are rungs on one ladder: cycle counting keeps your inventory data honest, so material management can plan against it, so the system can tell you what you’re Clear to Build, so you can decide what you’re Available to Commit to a customer. Get the bottom rung wrong and every promise above it is a guess. That is exactly NVIDIA’s problem — they’re committing and building off “suspect sheets,” not off trustworthy counts.
A note on grounding: only material management showed up by name in our interviews. Cycle counting, Available to Commit, and Clear to Build are the formal ERP/planning terms for pains Lonny, Greg, and Alex described in their own words (“suspect sheets,” “we don’t know the score,” “60 of 100”). Where I map a term onto their words, I say so.
§1 — Cycle counting
What it is. A way to keep perpetual inventory records accurate without shutting down to do a full physical count. Instead of counting everything once a year, you count a rotating subset every day or week. Usually ABC-stratified: high-value “A” items get counted often (e.g. monthly), cheap “C” items rarely. The output is an accuracy number — what % of locations match the system — and a list of discrepancies to investigate.
Why it matters. Every planning calculation downstream assumes the system’s inventory numbers are real. If they’re off, Clear-to-Build and Available-to-Commit are computing on fiction.
Map to NVIDIA. This is the missing discipline behind the consignment headache. NVIDIA-owned chips and boards sit as consignment inventory at the contract manufacturers, and today a material manager reconciles what the CM claims it consumed against 1990s spreadsheets — the “suspect sheets” [A, 2026-05-27]. Consignment GPUs are the textbook “A” item: highest value, count them most often. Disciplined cycle counting at the CMs is the boring fix that makes the whole consignment model auditable. Not named in our interviews — but it’s the named practice for the reconciliation pain Alex described. See Alex Zhu interview.
§2 — Material management
What it is. The end-to-end discipline of planning, procuring, storing, moving, and accounting for materials through production. In SAP it’s literally a module (MM). It owns: what do we need, when, where is it, who owns it, and what did it cost.
Map to NVIDIA. This is the one term they used directly — Alex called out “material management complexity” [A]. The complexity is two parallel inventory streams that have to be managed differently:
- Consignment — NVIDIA owns it (chips, boards), CM holds and consumes it → needs reconciliation.
- Turnkey — CM procures it (cables, third-party parts from Taiwan/China) → needs purchase signals.
Alex’s line — “man this thing cost a lot of money… the tracking, the movement, everything needs to be tracked perfectly” [A] — is a material-management problem stated by someone doing it by hand. Greg’s framing is the same wound one level up: “we don’t even really know the score of the game” [G+L, 2026-06-17]. Material management is the scoreboard.
§3 — Clear to Build (CTB)
What it is. A manufacturing-readiness check: do I have every component needed to actually complete this unit? A CTB report sorts open orders into “buildable now” vs. “blocked, missing part X.” It’s a parts-availability gate, not a promise to anyone — it answers “can the line start?”
Map to NVIDIA. This is precisely the repair-throughput bottleneck. A repair completes only if the CM has both the right consignment part and the turnkey materials on hand. Alex’s “~60 of 100” repair-sufficiency number [A] is a Clear-to-Build statistic: roughly 40 of 100 returns can’t be completed on arrival because something needed isn’t there, so they get filled from new inventory instead — pushing units onto the expensive $P replacement path rather than the cheap $C_r repair path. In the economic model, weak CTB is what drags the repair rate r down and the loss up. See repair-flow economic model and RMA process map.
§4 — Available to Commit (ATC)
What it is. A planning answer to “how much can I promise a customer right now?” It’s the more aggressive cousin of Available-to-Promise (ATP). ATP looks at finished stock plus already-scheduled supply; ATC also factors in supply you could still pull in — capacity and components you could convert if you committed to the order. It’s the number a planner stands behind when they say “yes, we can ship you a replacement by Friday.”
Map to NVIDIA. This is the promise made every time a customer opens an RMA — especially Advance Replacement (ARMA), where NVIDIA ships a good unit before the bad one comes back. Can ops commit to that ship date? It depends on the services spares pool plus how fast repairs are replenishing it — which depends on CTB, which depends on material management, which depends on accurate counts. Alex’s plea — “unless I receive a signal from a planning team, how am I supposed to know what I’m supposed to buy?” [A] — is the absence of an Available-to-Commit signal. The $2M+ SAP planning project is, in effect, an attempt to buy a trustworthy ATC number [A].
Greg’s 2026-06-26 walk-through sharpens why ATC is the binding constraint here [G, 2026-06-26]. There are two decoupled clocks: the customer gets a replacement from stock in ~1–2 weeks, while their own serial takes 30+ days to repair and return to stock. So the ARMA promise is a pure ATC question — can the spares pool cover the commit while the returned unit is still in the 27–40-day repair pipeline? And the gate that should protect that promise doesn’t: the three approval gates before shipment (case management → quality → finance) reject less than 1% of RMAs ever [G, 2026-06-26]. They aren’t filtering eligibility — eligibility is almost never the problem — so the real constraint on what NVIDIA can commit is spares (CTB), not approval. The ~1–2 weeks the gauntlet adds is latency against the commit, not protection of it.
§5 — How they stack (and why it’s our wedge)
Cycle counting → accurate inventory data (is the count real?)
Material mgmt → plan/track/cost the materials (what do we have, who owns it?)
Clear to Build → parts availability per unit (can we complete this repair?)
Available to Commit → promise to the customer (what can we ship, and when?)
Each rung depends on the one below. NVIDIA is trying to deliver the top rung (commit to hyperscale customers on replacements) while the bottom rung is spreadsheets and reconciliation by hand. That inversion — making confident commitments on untrustworthy data — is the operational gap behind the loss function Loss = Nf[(1−r)P + rC_r]: bad CTB lowers r, slow turnaround traps capital, and weak ATC turns repairable units into full-price replacements.
Open questions for the next conversation
- Does NVIDIA (or the CMs) run cycle counts on consignment today at all, or only the annual/spreadsheet reconciliation Alex described?
- Is there any formal Clear-to-Build report at the repair CMs, or is “60 of 100” discovered at the bench?
- Where does the SAP project draw the line — is it buying ATC, CTB, both, or just demand forecasting?
- If <1% of RMAs are ever rejected, what are the three approval gates actually for — and what would break if known-defect batches skipped them entirely? (Lonny owns the approval criteria; Greg doesn’t.)
[G, 2026-06-26]
Sources: Lonny Orona 2026-05-12; Alex Zhu 2026-05-27; Greg + Lonny 2026-06-17; Greg en-route call 2026-06-26; RMA process map; repair-flow economic model