Constrain the AMD commitment to lab validation on an MI300 rather than promising CIQ will acquire one
Situation
In the group DM with Bjorn Hovland and Adam Jackson on Sept 9, after Adam reported progress on the AMD motion, Peter cut back what could be promised. He told Adam to be careful about promising CIQ will acquire MI300s, allowed the exception that if Adam actually has one in hand from a contact then fine, and said that otherwise he does not think CIQ could get one in the timeline that matters. He substituted the commitment CIQ can keep: telling AMD that CIQ will run validations on a 300 is fine, because he is confident Scott Shinn can get CIQ test access in AMD own lab. He bracketed the correction with support, telling Adam the work is awesome and to let him know how Engineering can support. In the same thread he raised the harder problem nobody had asked about - that AMD will not leave themselves partly on Rocky and partly on Ubuntu, so CIQ needs to get into the weeds on what a cutover looks like and make sure plans are in place, or AMD will keep deploying Ubuntu because their setup and management infrastructure is all designed and tested for it.
Reasoning
The same discipline Peter applied to the Core42 date: the deliverable is the validation result, not the hardware. Separating those lets CIQ meet the partner actual need using the partner own lab and deletes the procurement risk entirely. The binding constraint he named was timeline rather than budget - he is not refusing to spend, he is refusing to promise a lead time he does not control. Giving the escape hatch first lets Adam keep the stronger promise if he has real cover for it, which corrects the commitment rather than the person. Then, having removed a promise CIQ cannot keep, he immediately substituted a problem worth solving - the Rocky to Ubuntu cutover plan - so the thread ends with more engineering engagement rather than less.
Additional Context
Runs alongside the Core42 guarantee decision in the same window, and applies the same test: does the commitment depend on something inside CIQ control. Peter treats timeline as the quantity to reason about, consistent with the Aug 28 decision to buy the live-patching timeline through Google co-development rather than wait on a hire.
Observed Evidence
Direct quote giving the correction, the exception and the substituted commitment; a second quote raising the cutover problem; a third establishing the supportive framing around the correction.
Matching Patterns
Confidence Breakdown
Reasoning Depth Analysis
Related Context
slack
So - careful about promising that we will acquire 300s. IF you actually have one in hand from a contact - sweet. But otherwise I do not think we could get one in the timeline that matters. Telling they we will run validations on a 300 is fine, I am confident Scott can get us test access in their lab.
slack
There is going to be more to it than that though Adam. There is no way they will leave themselves partly on rocky and partly on ubuntu. So we need to get into the weeds on what a cutover looks like and make sure there are plans in place for one... or they will keep deploying Ubuntu because their setup and managment infrstrucuture is all designed for it and tested to work with it.
slack
Regardless, this is awesome Adam. Let me know how Eng can support and we will.
Outcome
No outcome recorded yet.
Decision ID: ac2498c5-de32-491c-a816-cf287ffe937c