ConceptIntermediateQuality, Cost & Token Economics / Quality metrics: accuracy vs usefulness vs trust / #14

Explain the difference between helpfulness and harmlessness as product properties.

Helpfulness and harmlessness are not two ends of one dial. They are two separate scores, and a homework bot can max one out while quietly failing the other.

The direct answer
Helpfulness and harmlessness are two separate scores, not one dial, and a homework bot can max one while failing the other completely. Build a graduated response for anything close to the line: real help plus a stated boundary, never a flat yes or a flat no. Then watch a hand-graded sample of real requests every month, because no classifier draws that line perfectly on its own.
Do this, in order
  1. Build a graduated response for anything close to the line: real help plus a stated boundary, instead of a flat yes or a flat no.Why: a flat refusal and an unguarded full answer are the only two options that don't take any real design work; everything worth building sits in between.
  2. Never let one classifier score decide a hard yes or no by itself.Why: the model's guess at whether a request is real confusion or a request to do the whole thing is a probability, not a fact, so a hard cutoff bakes that guess in as if it were certain.
  3. Cap what a single response can produce, so even a missed call can't hand over one finished, submittable answer.Why: the boundary can't live only inside the classifier's head; the shape of the reply has to hold the line too.
  4. Watch who actually gets refused, split by how the question was phrased, not just how many refusals fire that week.Why: a normal-looking refusal count can hide a refusal that lands almost entirely on kids who ask in plain, blunt words.
  5. Hand-grade a monthly sample of flagged conversations against a real answer key.Why: that's the only number that tells you whether the boundary is catching real cheating or just catching kids who don't know the safe way to phrase a question.
  6. Track how many kids close the chat right after a refusal.Why: a kid who leaves after "I can't help with that" didn't get safer, they just got unhelped, and nobody writes that down as a loss.

How to answer this, stage by stage

Nobody's grading whether you'd add a safety rule. They're grading whether you know a safety rule can create its own kind of harm, and whether you can say plainly who it lands on.

1
Ground it in one product before talking about safety in the abstract
Say it like this
"Let's make this concrete. Chalkline is a homework chat app for middle and high schoolers. It doesn't just hand over answers, it walks a kid through a problem. Suki Kettler runs trust and safety for it."
Why this works
A safety question answered with no product in it turns into a lecture on ethics nobody can grade. One app, one person, makes it a decision I can actually defend.
2
Say what the question is really testing
Say it like this
"This isn't really asking me to define two words. It's asking whether I know a product can be maximally helpful and still be doing real harm, and whether I've got a plan for the version of harm that comes from being too careful, not just the version from being too loose."
Why this works
Naming the real question up front stops the generic answer, where a candidate just promises to "be careful" without saying what that costs.
3
Give the direct answer, cold, before any story
Say it like this
"Helpfulness and harmlessness are two separate scores here, not one dial. So instead of one refuse-or-answer switch, I'd build a graduated response, real help plus a clear boundary, for anything that sits close to the line."
Why this works
A reader who stops here already knows the whole answer. Everything after this is proof.
4
Name both people the decision falls on
Say it like this
"Two people sit on either end of every one of these calls. The kid asking, who might genuinely be stuck on factoring at nine at night. And whoever's downstream if we get it wrong: the kid's own grade if we just hand over the answer, or the kid's own evening if we wrongly shut the door on a real question."
Why this works
Naming both sides stops the answer from treating safety as a one-sided problem with only one kind of victim.
5
Name who can't push back, and why that's the sharpest part of the answer
Say it like this
"Here's the part most candidates skip. If Chalkline wrongly refuses a kid who asked something totally fine, that kid has no one to appeal to. It's nine at night, there's no teacher watching the chat, and the bot just said no. So they close the app, or they learn to reword the question until something slips through, which is worse."
Why this works
This is GUARD's sharpest move: naming the person with no lever, not just naming that harm exists somewhere.
6
Close with the fix and the number that proves it worked
Say it like this
"The fix is a graduated response plus a real check: a monthly hand-graded sample against a golden set. Before the fix, plain-worded requests got refused about 22 percent of the time, nearly four times the rate for the same request phrased politely. After the fix, that gap was under a point by week eight, and the rate of a full essay actually slipping through never moved."
Why this works
Closing on two numbers, not a feeling, is what makes it sound like a decision instead of a promise.
If you remember one thing A refusal rate going up can look exactly like safety working. Check who it's actually landing on before you believe that.

Let's learn

Chalkline is a homework chat app for middle and high schoolers. A kid types in whatever's due tomorrow, a stuck algebra problem, an essay prompt, and instead of handing over an answer, it walks them through getting to one.

When Chalkline first shipped, it would try to help with almost anything a kid typed, including "just write the whole thing for me." About 1 in every 14 requests came back as a complete, ready-to-submit piece of work: a finished paragraph, a full proof, a five-paragraph essay with nothing left to do. Teachers noticed inside a month. Two schools paused their trials in the same semester.

Knowledge spark: what's an intent classifier? A small model that reads a request before Chalkline answers and guesses what kind of ask it is: "help me understand" or "do it for me." That guess is a percentage, not a fact. It's right most of the time and wrong sometimes, in both directions.

So the team built a refusal system: an intent classifier that scored each request and decided whether it looked like real confusion or a request to skip straight to a finished answer. Anything that scored high on the second kind got a flat "I can't help with that."

It worked, in the sense the team was watching for. Full-essay leakage dropped from about 1 in 14 requests to under 2 in 100. But refusals climbed with it, and by the third month Chalkline was refusing about 1 in every 8 requests overall. Split a different way, the number got worse. Kids who typed plain, blunt asks, "i dont get this just answer it," "write this for me," got refused about 22 percent of the time. Kids who phrased the identical underlying question more politely, "could you help me draft a version of this paragraph," got refused about 6 percent of the time.

Refusal rate, by how the request was phrased
25% 0% 22% Plain wording 6% Polished wording
Plain, blunt wordingPolished, teacher-style wording
Same underlying request, asked two ways. Nearly four times the refusal rate for the kid who didn't already know how to phrase it the "safe" way.

Nobody built the classifier to sort kids by vocabulary. It learned to anyway. The training examples marked "fine" were stacked with polished, teacher-style phrasing, so plain wording started reading as more suspicious, without anyone deciding that on purpose.

Hand sketched comparison titled Two people, one score, only one side can appeal it. Left, the classifier drawn as a scale, one score decides help or refuse. Right, the kid asking, drawn as a person, gets the answer with no way to push back.
One side of this decision holds a score. The other side just finds out what it said.
The refusal rate looked like safety working. It was actually the exact kids who needed help most, learning the app had nothing for them.

A kid refused at nine at night has nobody to ask. There's no teacher watching the chat. So one of two things happens. They close the app and skip the homework, or they reopen it and keep rewording the same question until something slips past the filter, which teaches them that gaming the wording works and asking plainly doesn't.

At its worst, this costs Chalkline exactly the kids it was supposed to help most: the ones without a parent free at nine at night, without private tutoring, without polished academic English yet. The refusal system built to stop the product from being a cheating tool became the reason the kids who needed a study aid the most quietly stopped opening it.

The decision that mattered The team built one classifier and let its output decide everything: a full answer, or nothing at all. That made sense when the only thing being watched for was whether a whole essay got written. It stopped making sense the day anyone noticed which kids the refusals were actually landing on.

What I would leave alone: a flat refusal is still exactly right for requests with no legitimate version at all, "write me a fake sick note," "do my exam while it's open right now." Building a graduated middle ground for those would be its own mistake. Some requests genuinely don't have a helpful half.

The lesson: a refusal nobody can push back on doesn't feel like safety to the kid on the other end of it. It feels like the app didn't want to help them, and a kid who decides that once mostly doesn't come back to find out if it was true.

Now here is the same thing as a story

The short version is above. This is for when you want to feel why the equity gap mattered, not just know the number.

Chalkline lives on a phone, mostly. A kid opens it between dinner and bed, types in whatever's due tomorrow, and either gets walked through it or gets told no.

Suki Kettler has run trust and safety for AI products for eight years, the last two of them at Chalkline. She built the refusal system that ended up causing the problem, and she was also the one who unwound it.

For the first two months after the classifier shipped, everything looked exactly like what the team had hoped for. Full-essay leakage, whole finished pieces of work handed straight to a kid, dropped hard. Two schools that had paused their trials came back. The weekly safety review, which used to run long, started wrapping up early.

Refusals climbed steadily under that calm. Nobody thought much of it. Refusals were the whole point of the filter, so more of them looked like the filter doing its job.

Then, in her fourth month, a new data scientist joined the trust team and pulled the refusal numbers a way nobody had before: not by subject, not by grade, but by how the request was worded. Blunt asks against polished ones.

The gap was enormous. A kid who typed "i dont get this just answer it" got refused something like one time in four or five. A kid who typed "could you walk me through this, and if it's easier just show me a similar one solved" almost never did, for what was often the exact same underlying ask.

Suki's first instinct was to retrain the classifier on more examples of blunt-but-legitimate requests. That would have helped, some. It also would have taken months, and it still would have left the same design underneath it: one score, one hard cutoff, real help on one side of it and nothing at all on the other.

The decision that opened the door had been made in the very first design meeting, over a year earlier, before the classifier even existed. Someone asked whether a refused request should get anything else at all, a partial answer, a next step. The answer at the time was no, because the team was racing to stop full-essay leakage before the pilot schools pulled out, and "no" was the fastest thing to ship. Nobody planned for that fast decision to become the permanent shape of every refusal after it.

Run the same fourth month again with one change. A request that scores in the risky middle, not clearly fine and not clearly a full-essay ask, doesn't get a flat no anymore. It gets an outline, or two guiding questions, and one plain line: "I can go further, I just can't write the whole thing for you to hand in." The blunt-worded kid gets the same door the polished-worded kid always had. By week eight of the new version, the gap between blunt and polished refusal rates had closed to under a point. The full-essay leakage rate, the number that started all of this, hadn't moved. It sat right where it had before, under 2 percent, the entire time.

One design let a single guess decide everything a kid got that evening. The other always gives something, and holds the real boundary somewhere else: in the shape of the response, not in a yes-or-no switch.

What I'd tell myself, back in that first meeting: the fastest safe-sounding answer and the actually safe answer aren't always the same thing, and the gap between them tends to land on whoever already had the least polished way of asking.

GUARD, when the danger is being too careful

Not a diagnosis of a bug. GUARD run on a safety system that was quietly punishing the wrong people for asking plainly.

GGroups. Who this decision actually touches.
Two groups sit on either end of every graded request. The kid asking, who might genuinely be stuck, or might be trying to skip the work entirely, and the words alone don't always say which. And whoever's downstream of getting the call wrong either way: the kid's own grade and the teacher's trust in the tool if a full answer gets handed over when it shouldn't, or the kid's own evening if a fine request gets wrongly shut down.
Naming only the person who might get too much help misses the mirror problem: someone gets hurt by too little help too, and it's rarely the same someone.
UUnequal. Where the cost actually lands.
This tension doesn't land evenly. A kid asking in blunt, plain words got refused about 22 percent of the time. A kid asking the identical underlying question in polished, teacher-style phrasing got refused about 6 percent of the time. The classifier never meant to sort kids by vocabulary. It learned to anyway, because its training examples were stacked with polished requests marked fine.
This is the step most answers skip: not just that harm exists somewhere, but that it lands hardest on the group least equipped to argue its way around it.
Hand sketched decision tree titled Where the appeal step should be, and isn't. Root: a request close to the line. Three branches: reads like real confusion leads to gets an answer, reads like do it for me leads to flat refusal, kid tries to explain more leads to no box for this.
Two branches were designed on purpose. The third one, where a wrongly refused kid tries to explain, was never built at all.
AAbility to contest. Who has no lever.
A kid refused at nine at night has nobody to appeal to. No teacher is watching the chat. There's no "actually, let me explain" button anywhere in the product. So they either close the app and skip the work, or they keep rewording the same question until one version slips past the filter, which teaches them that gaming the wording works and asking plainly doesn't.
GUARD's sharpest question, worth saying plainly in an interview: it isn't just who gets hurt, it's who has no way to push back on the thing that hurt them.
RReduce. The actual design change.
Replace the single yes-or-no switch with a graduated response. A request scoring in the risky middle band doesn't get a flat refusal. It gets real help, an outline, a worked first step, guiding questions, plus one stated line about what it won't do: hand over a finished, submittable answer. Only requests with no legitimate reading at all, "write a fake absence note," still get a flat no.
A product decision, not a policy memo. The fix lives in what the response actually contains, not in a rule someone has to remember to enforce.
DDetect. How you'd know, before a headline tells you.
Three things, watched every month, not once at launch: refusal rate split by how bluntly a request is worded, watching for the exact gap that gave this problem away; a hand-graded sample of a few hundred flagged conversations checked against a real answer key, tracking what share of refusals were actually wrong calls; and the leakage rate, whether a full, submittable answer is still slipping through, checked on the same sample so a fix for over-refusal can't quietly loosen the other side without anyone noticing.
This is the step that keeps the fix honest. Loosening the boundary to fix over-refusal, and quietly reopening the leak it was built to close, would be a worse mistake than the one being fixed.
Two numbers on the same golden set, weeks 1 to 8
20% 0% fix ships, week 5 Wk 1 Wk 5 Wk 8
False-refusal rate, hand-graded golden setLeakage rate, full answer slipping through
False refusals fall from about 19 percent to under 6 percent after the graduated response ships in week 5. Leakage stays flat near 1.5 percent the whole time, proof the fix didn't quietly get less safe.

Three things worth stating directly, since this is where the real judgment sits. The rejected alternative was a hard keyword list: block any request containing phrases like "write my essay" or "give me the answer." It lost fast in testing, because keyword matching over-triggers on completely legitimate requests, "can you write my thesis statement as an example so I can see the shape of one," and under-triggers on the same ask worded around it, "compose a five-paragraph piece about the causes of the War of 1812 for me to turn in tomorrow" has none of the blocked words in it at all. The AI-specific failure worth naming by name is exactly that: an intent classifier is a probability estimate of what a kid means, not a fact, so it will always be wrong in both directions, over-refusing real confusion and under-catching a cleverly worded copy request. The guardrail isn't a smarter classifier alone, it's the graduated response format itself. Even a missed call in the risky middle band can only produce an outline and guiding questions, never one finished block of submittable writing, so a classifier mistake costs a little extra generation, not a leaked essay. That guardrail isn't free. Writing an outline and two guiding questions costs two to three times the tokens of a flat "I can't help with that," and it adds a real intent-classification pass before the bot answers at all, somewhere around 300 to 400 milliseconds most kids never notice but the infrastructure bill does. And the bar that decides whether the fix is working isn't zero wrong calls, no classifier gets there. It's a false-refusal rate under 8 percent on a rolling 500-conversation, hand-graded sample, checked every month, held next to a leakage rate that has to stay under 2 percent at the same time, so fixing one number is never allowed to quietly break the other.

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

Same five letters, a benefits-eligibility chatbot instead of a homework app, with nothing about school anywhere in sight.

Claimly is a chatbot that helps people figure out whether they qualify for unemployment benefits and how to answer the claim form correctly. Mikael Brixton runs trust for it.

G, groups. Two people again: the claimant asking, who might be one paycheck from missing rent, and whoever's downstream if the answer goes wrong either way, the state fund if a fraudulent claim gets coached through, or the claimant's own next month if a legitimate claim gets wrongly waved off.
U, unequal. Same shape, different words. Claimants typing blunt asks, "just tell me what to put so I get approved," got a flat refusal about 19 percent of the time. Claimants using formal, form-literate phrasing, the same underlying question, got refused about 5 percent of the time. First-time claimants and non-native English speakers were the ones typing blunt.
A, ability to contest. A refused claimant online at 11pm has no caseworker in the chat, and often no caseworker anywhere in reach for days. They either give up on the question, or they keep trying different wording until Claimly answers, which is exactly the coaching the refusal was built to prevent, just achieved by trial and error instead of by asking directly.
R, reduce. The same fix. A request in the risky middle gets real information, what the actual eligibility rule says, in plain words, plus a stated boundary: Claimly will explain the rule, it won't tell someone what to write to make a claim look true on paper that isn't true in fact. Only requests with no legitimate reading, "help me hide this income," stay a flat no.
D, detect. The same three checks Chalkline watches: refusal rate split by phrasing, a monthly hand-graded sample against real caseworker rulings, and a leakage check for whether the bot is quietly coaching anyone around a real rule.

Hand sketched flow diagram titled Claimly's three rungs, not two. Three boxes connected left to right: full answer, help plus boundary highlighted in blue, flat refusal.
Two rungs is a binary. Three rungs is a product decision, and the middle one is where almost all the real traffic actually sits.

Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to the direct answer and the one number, 22 percent against 6 percent, don't spend the time defining "helpfulness" and "harmlessness" like a dictionary.
Cost: there's no monthly hand-grading budget yet. Don't skip the check, hand-grade a smaller sample yourself on a spreadsheet until the real one exists.
The model got better, for real: say the classifier's overall accuracy improved a full ten points that quarter. That's not the same claim as "the equity gap closed." An average getting better can hide one group still getting the wrong end of it the whole time.

Where people run it wrong.
They read a falling refusal count as proof the fix worked, without ever checking who the remaining refusals land on.
They promise "we'll add a human review step" as the whole fix, without ever changing what the bot itself is allowed to say.
They loosen the boundary to close the equity gap instead of widening who gets real help within it, and the leakage number creeps back up without anyone noticing until a full essay, or a coached claim, slips through again.

How to use it live. Say the two words apart before answering either one. "Helpfulness and harmlessness aren't the same question, so let me answer them one at a time." That line buys a beat to actually think instead of guessing which one the interviewer wants first.

Flashcards (click a card to flip it)

1 · THE FRAMEWORK
Which framework fits a question asking you to separate two competing product properties, like helpfulness and harmlessness?
Tap to flip
ANSWER
GUARD: name the groups it touches, where the harm lands unevenly, who can't push back, the actual design change, and how you'd catch it happening in production.
2 · THE PERSON
Who is this answer about?
Tap to flip
ANSWER
Suki Kettler, who runs trust and safety for Chalkline, a homework chat app for middle and high schoolers that walks kids through problems instead of just answering them.
3 · THE ASSUMPTION
What assumption did Chalkline's first refusal system carry, without anyone deciding it on purpose?
Tap to flip
ANSWER
That one classifier score could safely decide everything a kid got, a full answer or nothing at all. It also quietly learned that blunt, plain-worded requests looked more like cheating than polished ones did.
4 · THE TWO SCORES
What's the two-score idea this whole answer turns on?
Tap to flip
ANSWER
Helpfulness (did the answer actually help the kid) and harmlessness (should it have been given at all) are separate measurements. A product can score high on one and fail the other completely.
5 · THE OLD DECISION
What decision would you take back?
Tap to flip
ANSWER
Treating every close-to-the-line request as one binary call, answer in full or refuse in full, instead of building a graduated response with real help plus a stated boundary.
6 · THE NUMBER
Fill in the blank: plain-worded requests got refused about ___ percent of the time. The same request phrased more politely got refused about ___ percent of the time.
Tap to flip
ANSWER
22 percent versus 6 percent, nearly four times the gap, for what was often the identical underlying question.
7 · THE REPLAY
Same fourth month, new design, what changes?
Tap to flip
ANSWER
A risky-middle request gets an outline and guiding questions plus a stated boundary instead of a flat no. By week eight the blunt-versus-polished refusal gap closed to under a point, and the full-essay leakage rate never moved off under 2 percent.
8 · CROSS-PRODUCT TRANSFER
Section 4 answers this same question again for a different product. Which product, and what stayed the same?
Tap to flip
ANSWER
Claimly, a benefits-eligibility chatbot run by Mikael Brixton. Same five letters, same shape: blunt-worded claimants got refused far more than polished ones for the identical question, closed by the same graduated-response fix.

Check yourself Score: 0 / 0

True or false
1. True or false: the safest version of a homework bot is the one that refuses the most requests.
  • True
  • False
Show hint
Think about what happens to the kid who gets refused, not just what happens to the request.
Show answer
False. A refusal that shuts out a real, legitimate question doesn't disappear as a cost. It just moves the cost onto the kid who needed help and didn't get any, which is a different kind of unsafe, not a safer outcome.
Multiple choice
2. Why did refusing anything that sounded like "write my essay" end up hurting some kids far more than others?
  • A. It didn't. The refusal rate was the same for every kid who asked.
  • B. Kids who asked in plain, blunt language tripped the refusal far more often than kids who asked the same thing in polished, teacher-style wording.
  • C. Only kids who were genuinely trying to cheat ever got refused.
  • D. The classifier only looked at how long the request was.
Show hint
Look at the two refusal-rate numbers, 22 percent and 6 percent, and ask what actually separated those two groups of kids.
Show answer
B. The classifier had learned from training examples stacked with polished phrasing marked as fine, so it treated plain wording as more suspicious, without anyone deciding that on purpose.
Fill in the blank
3. Plain-worded requests got refused about ___ percent of the time. The same underlying request, phrased more politely, got refused about ___ percent of the time.
Show hint
Look at the bar chart in "Let's learn."
Show answer
22 percent and 6 percent. Nearly four times the gap, for what was often the exact same question underneath.
Short answer, name the reversal
4. What's the specific design change (the R step) that replaced Chalkline's flat refuse-or-answer switch, and why did the flat version make sense the day it shipped?
Show hint
Look at the R step in the GUARD recap, and the meeting Suki remembered in the story.
Show answer
Model answer: A graduated response, real help plus a stated boundary for anything in the risky middle, instead of a flat yes or no. The flat version made sense at first because the team was racing to stop full-essay leakage before pilot schools pulled out, and a flat no was the fastest thing to ship. Nobody planned for that fast decision to become the permanent shape of every refusal after.
Short answer, apply it yourself
5. Pick an AI product you use yourself. Name one request it should flatly refuse, with no graduated middle ground, and say why a middle ground wouldn't make sense there.
Show hint
Ask whether there's any honest, partial version of what's being asked, or whether the request only has one real reading.
Show answer
Model answer: An AI writing assistant asked to generate a doctor's excuse note for a specific, named clinic. There's no partial, boundary-respecting version of that request. It's either a real note, which the assistant has no business producing, or a fake one, so a flat refusal is the right and only honest answer.
Multiple choice
6. What's the real risk of fixing over-refusal only by making the classifier smarter, with no cap on what a single response can contain?
  • A. None. A smarter classifier removes the need for any other safeguard.
  • B. A classifier score is a probability estimate, not a certainty, so any request that slips past it can still walk away with one finished, submittable answer, with nothing else stopping it.
  • C. Smarter classifiers always run slower, which is the only real cost.
  • D. It would only affect polished-worded requests, not blunt ones.
Show hint
Think about what happens the one time the classifier itself gets the call wrong.
Show answer
B. A classifier is a best guess, not a fact. The graduated response format is what keeps a wrong guess cheap, an outline and guiding questions aren't a finished essay even if the intent call behind them was wrong.
Before you close the answer
Why this works
Tests whether you know a safety fix can create its own kind of harm, not just whether you'd add a safety fix at all. Most candidates design against the loose failure and never check who a tight one quietly locks out.
Follow-up traps
"Isn't a flat refusal always the safer choice, even if it's less helpful?" Response: no, safer has to include the cost of being wrong that way too. An over-refusal doesn't show up as an incident report, it shows up as a kid who quietly stops opening the app, and that's a real cost nobody files a ticket for.

"How do you know the graduated response doesn't just become a workaround kids learn to trigger on purpose?" Response: structural caps, not trust. Even the graduated tier is built so it can't produce one clean, submittable answer on its own, an outline and guiding questions aren't a finished essay, and the leakage number is watched every month specifically to catch that.
If pressed
The classifier doesn't use one cutoff. Requests scoring under about 0.4 confidence get a full answer, requests over about 0.85 get a flat refusal, and only when there's genuinely no legitimate reading. Everything in between, which is most of the traffic that used to get refused outright, gets the graduated response.
From U2xAI Academy

From answering questions to owning outcomes.

A live workshop where you ship a working AI agent, defend a launch decision, and walk away with a portfolio recruiters can't wave off, not just more questions to study.

  • A live AI agent you actually shipped
  • A launch decision you can defend under pressure
  • An interview-ready portfolio, not more flashcards
Know more