Frame the score labeler experiment

Success is not “I followed the tutorial.” Success is producing evidence that: three float scores and one threshold produce deterministic yes/no labels plus a positive count without repeating the rule. The accepted input is narrow on purpose: a list of numeric scores in 0..1 and a threshold in 0..1. That narrowness is what lets you inspect every field and prevents a toy demo from being narrated as a production system.

Record the baseline you must beat: hand-label the three scores on paper before writing the function. If the finished artifact cannot beat that baseline on the fixture below, stop and revise the claim before writing more code.

scores = [0.2, 0.9, 0.4]
threshold = 0.5
expected = ["no", "yes", "no"]
print({"scores": scores, "threshold": threshold, "expected": expected})

Expected output:

{'scores': [0.2, 0.9, 0.4], 'threshold': 0.5, 'expected': ['no', 'yes', 'no']}

The boundary rule is explicit: a score equal to the threshold is "yes". Writing the expected result before implementation prevents the code from quietly defining its own success.

For the threshold score labeler (scores.py), a decorative win often looks like a clean run that never checks boundary labels at 0.49/0.50/0.51 and empty-list positive count 0. Write the metric down now so later pages cannot redefine success after the fact. Also note the operational threat you will eventually gate on: eval() on pasted score text or logging raw learner identifiers beside scores.

For python-only-what-you-need, write the claim on a sticky note in this exact shape: “Given a list of numeric scores in 0..1 and a threshold in 0..1, the score labeler will …”. Fill the ellipsis with the observable part of: three float scores and one threshold produce deterministic yes/no labels plus a positive count without repeating the rule. Tape the baseline beside it: hand-label the three scores on paper before writing the function. If someone later replaces your metric with a vibe check, the sticky note is how you push back.

Also sketch the one-sentence user story: a person uses this output to accept or reject a model score using one shared cutoff. If that sentence needs a dashboard, a model zoo, or five services, the lab scope is too wide—shrink the fixture (scores=[0.2,0.9,0.4], threshold=0.5) until the story fits on one screen.

Decide now whether live network calls are allowed on page 1. For this lab they usually are not; inventory and contracts should run offline against scores=[0.2,0.9,0.4], threshold=0.5. Note the metric you will eventually require (boundary labels at 0.49/0.50/0.51 and empty-list positive count 0) so page 4 cannot invent a softer target. The characteristic failure to keep in mind is string scores that compare lexicographically, or IndentationError that hides a wrong cutoff.

Frame a temperature alert with readings [18.0, 24.5, 30.0] and a limit of 30.0. State whether equality triggers an alert, write expected labels, and name one result that would falsify your claim. Do not write the implementation yet.

ML Python starter

Next