What should the machine predict?

Name the job the output must do

An equipment coordinator has limited time to review requests. A helpful tool might estimate waiting time, flag urgent requests, group similar problems or choose the next request to review. These outputs are different. “Use AI” does not define which problem is being solved.

A task contract states who uses the system, what information enters, when that information is available, what comes out and how success will be evaluated. Include a costly mistake and an excluded use. A review-support tool should not quietly become an automatic allocation system just because both involve the same requests.

Match the task type to the output

Classification predicts a category, such as urgent or ordinary. Regression predicts a number, such as minutes until equipment is ready. Clustering groups examples using a chosen notion of similarity without supplied target categories. Action selection chooses what to do under an objective and constraints, such as selecting the next request while respecting review capacity.

The lab’s input-output-evidence diagram changes with the chosen task. Notice that a numerical estimate needs units and an error measure in those units. A cluster is not automatically a true real-world category. Predicting urgency does not itself choose or execute a review schedule.

These task types do not require a particular implementation. Classification could use a handwritten rule or a learned model. A programmer specifies the rule directly. A learned model adjusts parameters using examples and an objective. Either can fail if its output does not match the user’s actual need.

Define the target before collecting labels

“Urgent” could mean that an event is within 24 hours. It could instead mean that work is currently blocked by missing equipment. In the lab, the same four requests receive different labels under these definitions. Both definitions produce two positives, but they do not identify the same requests.

The target is what you want predicted. A label records a target value for an example. An ambiguous target can produce inconsistent labels even when everyone acts in good faith. Improve the definition and collection process before assuming a larger model will solve disagreement.

Ask affected users what the output should support. The person filling in a request, the coordinator acting on a flag and a student whose request is delayed may have different concerns. A task contract should make those consequences discussable.

Check the clock on every input

An input feature is information available to the prediction. The stated event time can exist when the request arrives. Tomorrow’s final reviewer decision does not exist yet. Giving that future decision to a model that predicts the decision is leakage: it answers the evaluation using information that would not be available in real use.

Write the prediction time explicitly. A value may be valid for an after-the-event audit but invalid as a before-the-event input. Data availability is part of the contract, not just a software detail.

Define success as evidence, not a slogan

For wait-time estimates, inspect the difference between predicted and actual minutes, including long waits. For urgent flags, count misses and unnecessary reviews. For a schedule, account for capacity, effort and unresolved requests. “95% accurate” without a target, sample and consequences is not a complete success definition.

The lab asks you to draft a contract and practice identifying output types. The note is not graded for quality or saved as independent project evidence. Later lessons turn counts into metrics, examine uncertainty and compare baselines. Start by making the task precise enough that another person can explain what a failure would look like.