How do you write a requirement for a team whose output is a probability distribution?

Graupel is Isohyet's hail severity model. Give it one field on one day during hail season and it hands back a full spread of outcomes, from no damage to total loss, not one flat guess. Lucasta Farrelly owns what the research team gets asked to build. Six weeks into a kickoff requirement she wrote herself, a Tuesday remark from the model's lead researcher, Ezekiel Marrowbone, told her the number everyone had been chasing meant nothing at all.

How to answer this, stage by stage

Nobody is grading whether you can define a probability distribution. They're grading whether you can say, in the team's own words, what a requirement has to contain before it can actually be passed or failed.

Let's learn

What does "correct" even mean for a model that never gives you one answer?

Isohyet builds weather risk tools for crop insurers. Its main model, Graupel, looks at one field on one day during hail season and hands back five numbers: the chance of no damage, minor damage, moderate damage, severe damage, and total loss. An insurer uses the whole spread to decide how much money to set aside for a policy, not one flat yes or no.

A checkbox has one setting. A spread has five, and every one of them matters to an insurer.

For most of Isohyet's four years, requirements were easy to write, because most of what the company built was a plain yes or no. Did a field's satellite picture come through today. Did a claim match a policy on file. Lucasta had written dozens of requirements shaped exactly like that, and every one of them worked, because a yes or no question actually has a yes or no answer.

Then the insurers asked for something new: a model that could tell them, ahead of the season, how much money to set aside for hail. That meant a real spread of outcomes, not a flag. Lucasta wrote the kickoff requirement the way she'd always written one. "The model should correctly predict whether a field will see damaging hail, at least 95 percent of the time."

It sounded sharp in the room. Everyone nodded. Here is the part nobody in that room knew yet: damaging hail only actually happens on about 4 of every 100 field days in hail season. A model that says "no damage" every single time, without reading a single number off the sky, already gets 96 of those days right. Lucasta had asked the team to clear a bar that doing nothing at all had already cleared.

Ezekiel Marrowbone's team spent six weeks chasing that 95 percent anyway. Every week the number climbed a little. Week two, 93.1. Week four, 95.1. Week six, 95.8.

Here is the turn. The six weeks were never the real cost. The real cost is that no team, however good, could have written code that passed Lucasta's requirement and also did the job, because the requirement described something a coin flip had already cleared.

The requirement got a checkmark. The field that actually lost its crop never got a second look.

An underwriting VP heard about the stall and offered a fix that felt reasonable in the room: just run the model against last July's derecho, the worst storm on record, and see if it caught that one. Lucasta turned it down. A single storm, however dramatic, says nothing about how the model behaves across a normal season of small, ordinary hail days, which is most of what it will actually see.

Once Ezekiel's team rewrote the requirement around a graded score instead of a yes or no bar, they backtested Graupel against last season's real claims. Reserve pricing error, the gap between what an insurer set aside and what it actually paid out, fell hard.

One of these numbers is ready the same week. The other one waits for an entire season to finish.

What I would leave alone: Graupel also runs a daily check on whether a field's satellite picture actually came through clean, no clouds blocking the view, no corrupted file. That really is a yes or no question, and a plain pass or fail requirement is exactly right for it. Forcing a graded eval spec onto a data check like that would cost a week nobody needed to spend.

The lesson: a requirement that sounds confident and measurable in a room isn't the same thing as a requirement a team can actually fail. If the honest answer to "can this bar be cleared by doing nothing at all" is yes, you didn't write a bar. You wrote a trap and handed it to your own project.

Now here is the same thing as a story

The short version above is what you actually say in the room. Read this one for the four months it took to write a requirement Graupel's team could actually pass or fail.

Lucasta Farrelly had written requirements for six years before Graupel, four of them at Isohyet. She was good at it. Ask her to spec a fraud check or a claims matching rule and she'd have a clean, testable sentence back to you inside a day, because those systems only ever had one right answer, and she knew exactly how to pin one down.

Both of them doing their job carefully. Neither one had a reason yet to think the number meant nothing.

When the insurers asked for a model that could size up hail risk ahead of a season, Lucasta ran Graupel's kickoff meeting the way she ran every kickoff. A conference room, a whiteboard, the VP of underwriting leaning forward because he wanted a number he could take to a reinsurer. She wrote it on the board herself: "correctly predict whether a field will see damaging hail, at least 95 percent of the time." The room nodded. It felt like the sharpest requirement in the meeting.

For the first two weeks, checking in on Graupel's progress was the best part of Lucasta's Tuesdays. Ezekiel Marrowbone's update always had a climbing number in it, and a climbing number toward a stated target reads exactly like progress.

By week two, 93.1. She asked a couple of questions about the model's features, glanced at a chart, moved on to her next meeting. By week four, 95.1, close enough to see the finish line, and her questions got shorter. By week six, 95.8, and she mostly just said "great, keep going" and closed her laptop.

Nobody decided to stop asking real questions. A climbing number just made it feel like there was nothing left to ask.

Ezekiel wasn't hiding anything either. He'd been chasing that 95 percent honestly, trying new features, tuning a threshold, doing the job the requirement described. That Tuesday evening, week six, he said the thing he'd been sitting with for a few days. "We've hit 95.8 three weeks running. I want to be straight with you. A model that always said no would already score 96."

Lucasta didn't say anything for a second. Then she asked the only question that mattered. "How much of the real damage is it actually catching?"

Three percent.

I want to say the problem was that hail is hard to predict. It is. But that's not really the story. Lucasta never had a number in her head for what "done" would actually look like, because the requirement she wrote never described anything a model could be genuinely scored against. She had a percentage that felt like a bar, and it only worked as a bar until someone did the arithmetic on how rare damaging hail actually is.

The decision she'd take back sits in that first kickoff meeting, four months earlier, marker in hand, a room full of people wanting a firm number before lunch. She reached for the shape of requirement that had always worked for her, because nobody in that room, herself included, knew Graupel's output well enough yet to say it needed a different shape entirely.

Run the same four months again, with the requirement written properly from day one. The first two weeks go to building the eval set itself: five hundred real field days pulled from six seasons and forty counties, with enough severe and total loss cases folded in on purpose that they can actually be graded, not drowned out by ordinary days the way they are in raw history. The next three weeks go to tuning against a real target: predicted chance of severe or worse damage within five points of what actually happened, and the top of the forecast within forty dollars an acre of real claims paid. By week five, Graupel clears both. Backtested against last season, reserve pricing error lands at 95 dollars a policy instead of 340. It took five weeks that went somewhere, not six that didn't.

What I'd tell myself, back at that whiteboard: a requirement that sounds confident in a room and a requirement a team can actually fail are not the same sentence. I wrote the first one and called it finished.

LEAD, for a requirement a spread of outcomes can pass or fail

Not a way to prove Lucasta was careless. LEAD is what forces you to say what the requirement should actually track, and to catch a broken one before a season of real money moves on it.

Three parts, every time. Leave one out and the requirement goes back to being a wish with a number attached.

The recap, one line per letter: link the requirement to what the business actually pays for, reserve accuracy, not the model's own internal score. The early signal is recall on a real, graded sample, because it's ready the same week and the business outcome isn't ready for months. Name both abuses plainly, a binary bar a coin flip already clears, and a single dramatic case standing in for a real sample. And the decision is what makes it real: an eval set, a graded score with a cut off, and a written tradeoff, all three, every time.

Two things worth saying outright, since the real judgment sits here. Isohyet considered raising the bar instead of changing its shape, asking for 99 percent accuracy rather than 95. That would have made the trap worse, not better, since it still asks for a single yes or no answer on a question that was never shaped like one. The AI specific failure worth naming by name is base rate masking: a model can score high raw accuracy simply by leaning on whichever outcome is already common, hiding the fact that it has learned almost nothing about the rare cases that actually matter. The guardrail that catches it is watching recall on the minority outcome by itself, as its own tracked number, never folded into one blended accuracy score. And the tradeoff was real and taken on purpose: letting the model miss a few more small, cheap hail events in exchange for catching more of the expensive ones costs some precision on the easy cases, and Isohyet accepted that cost because a missed catastrophic event costs roughly forty times more in reserve error than a false alarm on a minor one.

And if you want to be sure it really works, try it somewhere else

Same four letters, a flash flood routing tool instead of a hail model, and this time the rare event a binary requirement hides is a stranded truck instead of a ruined field.

Freshet runs Spillway, a model that forecasts flash flood risk on trucking routes for logistics companies, so a dispatcher can reroute a load before a road closes under water. Pandora Quraishi owns what Spillway's team gets asked to build, and hit a close cousin of Lucasta's exact problem two months after a similar kickoff.

Same shape of mistake as Graupel's. A flood closes a route on about 3 of every 100 route days, so saying no every time already scores 97.

Spillway's kickoff requirement asked the team to "correctly flag routes that will flood, at least 96 percent of the time." Route closing floods happen on about 3 of every 100 route days during flood season, so a model that never once flagged a route already cleared 97. Under that requirement, Spillway's real recall on actual closures sat near 5 percent for weeks, hidden behind a reported accuracy score that looked almost finished the whole time.

Once Pandora's team rewrote the requirement, closure prediction went from a percentage nobody trusted to a graded eval scored against five hundred real route days, with the team allowed to trade some misses on minor ponding for fewer misses on full closures, since a stranded truck costs roughly twenty five times more than an unnecessary reroute.

Mapped onto LEAD, the shape holds exactly. The link is a dispatcher's real routing cost, not Spillway's own internal score. The early signal is recall on a graded, representative sample of route days, ready the same week, while the true routing cost only shows up after a flood season plays out. The abuse Pandora found was the same one, a binary bar a near empty model already cleared. And her decision matched Lucasta's: a real eval set, a graded score with a cut off, and a written tradeoff, sized to what actually costs the most when it's missed.

Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to it: write it against a real eval set, a graded score with a cut off, and a stated tradeoff, never a yes or no bar.
Cost: no budget this quarter to build a proper labeled eval set. Whoever owns the model pulls a smaller, honest sample by hand, fifty real cases instead of five hundred, a slow real eval still beats a fast fake one.
The model got better, for real: say a new version of Graupel doubles its recall on severe cases out of the box. The eval set and its cut off stay in place anyway, because a stronger model can still be ungraded, and a higher starting number is not the same thing as a bar that means something.

Where people run it wrong.
They ask for a percentage without checking what a model that changes nothing would already score on that same measure.
They swap one dramatic hand picked case for a real representative sample, because it feels like fast proof instead of the slow kind.
They raise the bar instead of changing its shape, asking for 99 percent instead of 95, which only makes a binary trap harder to notice, not less of one.

How to use it live. When an interviewer hands you a question like this, buy yourself a second by asking out loud what a model that did nothing at all would already score. That question is the whole answer in miniature, and it previews everything you're about to say.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0