A municipal boat-ramp wayfinding helper was designed and tested only with English-speaking smartphone users. Night-shift dockhands who use a flip phone and a second language cannot complete the same flow. Which gap is that?
Select an answer to reveal the explanation.
Short Explanation
Think of a boat-ramp helper built only for English smartphone users. Night-shift dockhands with a flip phone and a second language cannot finish the flow. That gap is inclusivity, not more GPUs.
Full Explanation
Inclusivity is about who can actually use and benefit from the system. A boat-ramp helper designed and tested only with English-speaking smartphone users excludes night-shift dockhands on flip phones and a second language—even if the core logic is fair among smartphone users in the pilot. That gap is access and design coverage for municipal field workers, not raw compute capacity in the cloud account or a shortage of GPUs.
A GPU shortage is not solved inclusivity; more hardware does not add language or device support for dockhands who keep the ramp safe after dark. Fairness-as-latency mislabels the problem: flip phones and language gaps are not a milliseconds fairness score. Veracity concerns truth of outputs, not whether a second-language flip-phone flow exists for night-shift staff who need wayfinding under real field constraints.
Exam caveat: inclusivity failures often appear only when you test beyond the original persona. English smartphone-only pilots are a classic blind spot for municipal field tools at ramps, docks, and other outdoor work sites.
Operational check: run the wayfinding flow on low-end phones and in the second language with night-shift dockhands, capture where the flow breaks, and expand supported languages and input modes before calling the helper production-ready for all crews.