Meridian is evaluating two cloud ML platform vendors for the ramp-safety computer-vision system, which needs GPU-accelerated real-time inference and the option to run inference at the edge (on-site, near the cameras) due to connectivity constraints on the ramp. One vendor is cheaper but offers only cloud-hosted batch inference with no edge deployment option; the other costs more but supports real-time GPU inference and edge deployment. What should guide the PM's platform decision?
Select an answer to reveal the explanation.
Short Explanation
Cheap-but-can't-do-the-job beats nobody — match the platform to what the project actually needs (real-time, edge) before you look at the price tag.
Full Explanation
Assessing ML platform capabilities against actual project requirements is a named Domain III enabler, and here the cheaper platform's inability to support real-time inference or edge deployment makes it unfit for a ramp-safety system with genuine connectivity constraints and safety-critical response-time needs — cost alone cannot override a hard technical requirement the platform cannot meet. Always choosing the lower-cost option regardless of fit is wrong and is exactly the kind of decision this Domain III enabler exists to prevent — it would leave Meridian with a platform structurally unable to deliver the real-time, edge-capable system the ramp environment requires. Claiming platform capability is irrelevant as long as the data science team is skilled is wrong — no amount of team skill can make a batch-only cloud platform perform real-time edge inference it wasn't built to support. Defaulting to whatever the unrelated predictive-maintenance team already uses is wrong because it ignores that this project has distinct technical requirements (real-time, edge) that the other team's use case may not share — platform fit has to be assessed per project, not copied by default.