Transit leadership cares whether the rider assistant stays available when morning peak load hits. Which reliability metric should the SLO board treat as first-class?
Select an answer to reveal the explanation.
Short Explanation
You care about whether riders can reach the assistant when morning demand is highest, not just whether it works overnight. Put peak-period availability on the SLO board, like checking elevators at rush hour rather than at midnight.
Full Explanation
Transit leadership wants to know whether the rider assistant stays available when morning peak load hits, so peak-period availability should be a first-class reliability metric on the SLO board. Riders depend on the assistant for schedules, delays, and service changes during this period; an SLO averaged across quiet overnight hours can look green while rush-hour failures strand residents. Defining availability during the morning peak aligns reliability with civic demand, much like measuring elevators at rush hour rather than at midnight. Average meeting length of the AI steering committee is a governance process measure, not a serving SLO. Counting spare laptops in the transit IT closet monthly measures inventory, not assistant availability under load. Color theme preference on the rider mobile app is a UX cosmetic and does not show whether the assistant answers during peak. Exam caveat: define the peak window explicitly, such as weekdays 06:30–09:30, and specify success, such as a successful response within the latency budget, or the SLO may be unenforceable. Practical check: mark the morning peak on the SLO board, calculate availability for that window (and overall separately if useful), load-test against peak QPS, and page on a peak-availability breach even when daily averages look acceptable.