Start with the Decision

A model output is not the business outcome

A vague request such as use AI to reduce outages does not yet define a learnable problem. Start with the decision the system will support: perhaps route an alert to a specialist, estimate tomorrow's traffic, or rank incidents for review. Then define the prediction target - the exact quantity or class the model should produce - and the moment when that prediction must be available.

Scenario: An operations team says it wants to predict incidents. After questioning, the real decision is narrower: every five minutes, decide whether to page an on-call engineer because the service is likely to breach its latency objective within 30 minutes. That wording identifies the row unit, prediction time, target window, and costly action.

input available now: error rate, queue depth, recent latency
target observed later: breach within 30 minutes? yes/no
decision: page only when predicted risk crosses an agreed threshold

Also name who acts on the result and what happens when the model is uncertain. A probability is useful only after a policy converts it into action. Sometimes the best first solution is a dashboard or deterministic threshold rather than ML, particularly when rules already describe the decision reliably.

Tip: Write a one-sentence contract: Given information available at TIME, predict TARGET for UNIT so ACTOR can make DECISION. If that sentence remains fuzzy, collecting more data will not rescue the project.