Describe how internal tooling can become the source of your eval data.

Interviewer's question: "Describe how internal tooling can become the source of your eval data." Simone Aduba runs operations at Millhaven Wholesale Bakery, where an internal AI tool drafts exception reports, short-shipments, substitutions, for staff to confirm before an order goes out.

How to answer this, stage by stage

Nobody is grading whether you can say "internal data is useful." They're grading whether you know exactly when that data is trustworthy enough to build a real eval set from.

Let's learn

Here is what happens when a correction log gets read as noise to clear from a queue instead of the eval data it actually is.

Millhaven's AI tool reads a wholesale order against the warehouse's actual stock and drafts an exception report, a short-shipment, a substitution, for an ops staffer to confirm before the order goes out. Before the tool, a staffer built the same report by hand from the pick list, about twenty minutes an order.

The tool's draft accuracy looked solid from week one. What nobody was watching closely was the correction log itself, the record of every time a staffer said "no, actually, it's this" instead of confirming the draft.

Four steps, and the third one is where a genuinely rare case quietly loses its own shape.

The turn: the correction log was never just cleanup work. It was real, free eval data arriving months before any customer-facing eval effort would exist at all, and treating it as noise to clear meant throwing away the exact cases that mattered most.

At its worst: leadership sees a rising acceptance rate, assumes the tool has genuinely learned the hard cases, and greenlights a customer-facing version built on a correction log that's actually forty repeats of the same one case, dressed up as broad coverage.

What I would leave alone: routine, non-allergen substitution corrections don't need this level of scrutiny at all. The graduation rule exists for categories where a wrong answer actually matters, not every minor correction in the log.

The lesson: a correction log is either the richest eval data you'll ever get for free, or a pile of noise, and the only thing that decides which one it is is whether anyone actually reads it like data.

Now here is the same thing as a story

The short version above is what you'd say to Millhaven's leadership. Read this one for how the real pattern actually got noticed.

The loading dock gets busiest right before the 6am trucks roll out, every staffer moving fast through the exception queue before the first shipment leaves.

A new ops hire, still new enough to ask questions the rest of the team had stopped asking, noticed something odd in her second week: the tool kept flagging the same kind of oat-based substitution as "likely fine," and staff kept quietly correcting it to "flag for allergen review" without anyone seeming surprised. "Why does it keep getting surprised by this?" she asked. "Shouldn't it have learned by now?"

Five months of the same correction happening quietly, and a new hire's honest question is what finally connected it.

Simone Aduba pulled the correction log that afternoon, properly, for the first time treating it as a dataset instead of a queue to clear. The oat-based substitution had been corrected the same way 41 times. Every single correction had been logged identically, a quick tap of the same "flag for allergen review" button, with no note on why, no variation in wording, nothing that actually taught the tool the underlying reasoning.

Simone set a real rule after that: a correction category only counts as ready for the eventual customer-facing eval set once it has genuinely varied real examples, not repeats, and a food-safety expert has actually sampled a slice of them to confirm the diversity is real.

LEAD, in one screenNot a data pipeline diagram. LEAD is what tells you when a log becomes real evidence instead of noise.

One of these two things is a real fix. The other one just looks like it on a dashboard.

The recap, one line per letter: link is eval-set quality as the real outcome, early signal is real correction patterns arriving months ahead of any synthetic effort, abuse is a gamed acceptance-rate metric hiding unfixed judgment, and decision is a real graduation rule built on diversity, not count.

And if you want to be sure it really works, try it somewhere elseSame four letters, a pest control service instead of a wholesale bakery. Nothing else about the two jobs is alike.

Briar & Bower Pest Control uses an internal AI tool that drafts technician visit-summary reports, the ones that will eventually seed a customer-facing "what did the technician find" report generator.

High volume alone isn't the tell. The category worth trusting sits high on both axes at once.

Mapped onto LEAD: link is a trustworthy customer-facing summary generator. Early signal is technicians' corrections to draft visit summaries surfacing genuinely rare pest-sighting patterns months before any eval writer would think to test for them. Abuse is technicians learning to tap a generic "looks fine" correction to clear the queue fast, without actually noting what was really found. Decision is a pest-finding category graduating into the customer eval set only once it has many varied real examples, confirmed by an entomologist on staff, not just a high correction count.

Four requirements, and volume alone only satisfies one of them.

Swap the trigger and it still runs.
Speed: an interviewer caps you at thirty seconds. Say "internal corrections are free eval data, but only once a category shows real diversity, confirmed by an expert, not just a high count," and stop.
Cost: if there's no budget for a dedicated expert review, at minimum flag any category where one correction pattern repeats more than a handful of times, since that alone is a sign the count is hiding a blind spot.
The model gets better, for real: if the tool's draft accuracy improves overall, the correction log still matters, since a better model makes the remaining rare corrections even more valuable, they're the genuinely hard cases left standing.

Three tests, and the third one is the trap that a rising correction count alone would have missed.

Where people run it wrong.
They treat a rising correction count alone as proof of readiness, without checking whether it's genuine diversity or one repeated blind spot.
They watch an acceptance-rate metric without noticing staff have learned to phrase things toward it.
They never bring in a real domain expert to sample the log, and trust the numbers instead of the actual content.

How to use it live. When someone asks you how internal tooling becomes eval data, ask yourself first: is this log actually varied, or is it the same case wearing a different order number every time. Answer that before trusting the count.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0