Make it say no
MIS 752 · Lab 10 Lite · Book Ch. 24 · no coding · every request, number and note here is invented
At the pharmacy
an automatic screen flags the order➜
the pharmacist reads it➜
the label is checked➜
the monthly report counts both mistakesIn AI
🧾a rule filter checks shapes
➜
🧑⚕️an AI judge reads the request
➜
🏷️the answer's form is checked
➜
📊count caught, missed, and wrongly refused
A pharmacy runs several checks before a prescription leaves the counter. Each one stops some bad orders, and each one can also
send a good patient home with nothing. An AI guardrail works the same way, and it fails in two directions: a bad yes lets harm
through, and a false no turns away the person the service exists to help. What a system refuses is a design choice.
📖 Read Chapter 24, Sensitive Use Cases: End of Life, Mental Health, and Pediatrics (p. 565) in the course textbook ➜
Same book on Canvas: course files.
Guardrails in general: Ch. 19, Guardrails for Autonomous Systems (p. 452).
Photos: Benjamin Richards, Josh Hawkins and Becca Schwartz, UNLV. Real UNLV spaces; every request, number and note in this lab is invented.
Why this matters
💡 THE IDEAA guardrail is a classifier: a check that sorts every request into "refuse" or "answer".
So it can be wrong in two directions, and this lab counts both.
🏥 HEALTHCAREA bad yes can leak a patient's identifier or help someone misuse a controlled drug.
A false no leaves a patient on warfarin unanswered, so they guess or ask a chatbot nobody checks.
💼 BUSINESSVendors usually report only the attacks they stopped, yet a filter that refuses everything stops every attack and serves no one.
Counting both mistakes is how you decide how strict to be, and who pays for it.
🎯 BY THE ENDyou will be able to count what a guard caught, missed and wrongly refused;
set how strict it should be and defend that with numbers; and write what a service in your own field must refuse, and must never refuse.
0 · Connect a model
Paste the free OpenRouter key from Lab 1. It stays in this browser tab only: it is never saved and never sent anywhere except OpenRouter. (Instructor's computer: leave it empty to use the local model.)
1 · Two guards, two kinds of mistake
Every guard sorts requests into "refuse" and "let through". It can be wrong in two different ways, and they land on different people.
🛑 the guard REFUSES
✅ the guard LETS IT THROUGH
it should be refused
✅ CAUGHT ITthe bad request stops here
❌ BAD YESharm gets through
it should be answered
🚫 FALSE NOa patient is turned away
✅ LET IT THROUGHthe service does its job
Everyone reports the top row: "our guard caught 10 out of 10." Almost nobody counts the bottom left, the people it turned away. This lab counts both.
🔎 What this shows: every decision a guard makes lands in one of these four boxes, and the two mistake boxes hurt different people:
a bad yes harms the patient whose record leaks or who gets dangerous help, while a false no harms the patient who leaves with nothing.
The two guards also look at different things, shapes or meaning, so each one will miss some of what the other catches.
🔒 Every identifier on this page is invented from ranges never issued to anyone: Social Security numbers starting 000 or 900, the 555-0100 to 0199 fictional phone block,
example.com email addresses, and dates that never happened, like February 30. A lab about protecting records must not contain anything that could be one.
7 · The guard that stops everyone
Meet a third guard. It refuses any message with a digit, an @, a web address, or a medical word such as dose, tablet or a drug's name. Then run all 20 practice requests through all three guards, the way a pharmacy writes its monthly report.
🎯 GOALSee which guard is actually best when you count both kinds of mistake.
❓ QUESTION“Our guard stopped every attack. Is it good?”
💡 WHYThe paranoid guard will stop all ten bad requests. Watch what else it stops. Twenty requests: ten the pharmacy must refuse, ten it must answer.
🔎 What this shows: stopping every bad request is not the same as being a good guard. The score subtracts the share of good questions
turned away from the share of bad requests stopped, so a guard that refuses good and bad alike earns nothing for its catches, and a team that reports only
"bad requests stopped" can ship a guard that helps no one.
8 · The strictness dial
The AI judge gives every request a risk score from 0 to 1. One number decides where "refuse" starts. Slide it and watch both kinds of mistake move.
🎯 GOALFind a setting you could defend with numbers, not with a feeling.
❓ QUESTION“How strict should the judge be?”
💡 WHYLike the sensitivity dial on a smoke detector: turn it down and it stops screaming at toast, but somewhere it starts sleeping through real fires.
🔎 What this shows: the strictness setting is a policy decision with a number attached: turning it toward lenient can only hold or lower
the false nos, at the risk of more bad yeses, and turning it toward strict does the reverse. Whoever picks the number is deciding which patients absorb
the errors, so the choice deserves a written reason and the numbers behind it, not a default nobody questioned.
9 · The label check
Before a bottle leaves the counter, someone checks the label. The assistant's answer is a counselling note with required lines, and a fluent note can still be unusable.
🎯 GOALSee the one mistake neither guard at the door can see.
❓ QUESTION“Which of these five notes is the dangerous one?” Click it, then run the check.
💡 WHYEvery note must have every line, a risk level of low, moderate or high, and one clinical rule: a high-risk note goes to a pharmacist.
🔎 What this shows: guarding the question is not enough, because the answer can fail too. A note can be fluent, in scope
and free of identifiers and still send a high-risk patient to nobody, and a clinical rule like "high risk goes to a pharmacist" only protects anyone
once it is a check that runs on every answer, however well the answer reads.
10 · Design your own guardrail
This is the real skill. Pick a service from your own field, write what it is for, and decide what it must refuse. Then test it with one request it must refuse and one innocent request a clumsy guard would block. No code: just plain English.
🎯 GOALWrite the brief an AI judge reads, and a list for the rule filter, for a service you know.
❓ QUESTION“What must your service always refuse, and what must it never refuse?”
💡 WHYEvery system has a refusal policy, whether or not anyone wrote it down. Writing it down is how you find out what it costs.
🔎 What this shows: the two mistakes you just tested are the same two your own field faces, and the brief you wrote is a refusal
policy that otherwise goes unwritten. A brief that lists only what to refuse makes a judge that refuses too much, and a word list cannot tell an innocent use
of a word from a dangerous one, so both need testing on requests you already know the right answer to.
11 · Your turn: try to break it
Round 1: get a request past the pharmacy's guards that they should refuse (a bad yes). Round 2: write a perfectly reasonable question that they refuse (a false no). Ideas: reword it, split a number across the sentence, use a format the shape checks do not know, or ask an ordinary process question that contains a scary word.
🔎 What this shows: real users push on a guard from both sides: attackers reword a request until something gets through,
and honest people stumble into refusals without trying. Every request you found that fooled a guard belongs in the team's labelled test set, the list of
requests with known right answers that is run again every time the guard changes.
What you learned, and why it matters
You saw one idea from several sides: a guardrail is a classifier, so it fails in two directions, and only counting both tells you whether it helps.
The rule filter and the AI judge failed in different places, which is why guards are stacked in layers, and the monthly report showed that a guard
can stop every attack and still be worth nothing once you count the patients it turned away.
The strictness dial showed that how strict to be is a choice someone makes with a number, and the label check showed that a fluent answer can still break
a clinical rule that only a check in software will enforce.
In your own field, a fraud screen, a hiring filter or a customer chatbot makes the same two mistakes, so ask for both numbers before you trust one. In your project proposal, if your system answers people or flags them, write down what it must refuse, what it must never refuse, how you will count both mistakes, and who a refused person reaches next.
In your own field, a fraud screen, a hiring filter or a customer chatbot makes the same two mistakes, so ask for both numbers before you trust one. In your project proposal, if your system answers people or flags them, write down what it must refuse, what it must never refuse, how you will count both mistakes, and who a refused person reaches next.
12 · Hand it in (Canvas, Lab 10)
1. Download your submission with the button below, then upload the file to the Lab 10 assignment on Canvas. It holds every request, your predictions, both guards' decisions, your monthly report, your dial setting, the label check, your own guardrail, and everything you wrote.
2. Answer these five, a few sentences each. Each asks why:
2. Answer these five, a few sentences each. Each asks why:
- When your prediction was wrong, what had you assumed about the rule filter or the AI judge that turned out not to be true?
- The paranoid guard stopped every bad request. Using your monthly report, explain why it is still useless, and why a team that reports only its catch rate would ship it anyway.
- Which strictness setting would you ship? Argue for it with your numbers, and name who absorbs the cost of your choice.
- The warfarin note marked high risk with no pharmacist review was fluent, in scope and free of identifiers. Why does a rule like "high risk needs a pharmacist" belong in software, and who should own it?
- Your own guardrail: which mistake costs your field more, the bad yes or the false no, and who pays for each? What should a refused person be told, so they do not go around the guard?
Nothing you type is stored anywhere. Download your file before you close the tab.