Guardrail

A large language model (LLM) produces an answer by choosing words that plausibly follow the ones before them. Ask the same question twice and the two answers won't match, and a wrong answer arrives in a sentence as confident as a right one. That is why a feature built on a model behaves perfectly in a demo and then fails in front of a customer.

Pagedeck learned this directly. Theo shipped a feature that drafts replies to support tickets, and in an internal demo twenty drafts in a row were fine. The week after it went live, a customer asked for a full refund the day after paying, and the draft said Pagedeck issues full refunds within one week. No such policy existed. Sofia sent the draft as written, and the customer read it as a commitment from the company.

The first fix attempted was the prompt. A line saying not to state policies that aren't in the source documents went into the instructions, and the demo passed again. But an instruction is a request, not a guarantee. A few out of every thousand drafts still invented a policy, and those few were still sentences going to customers. A guardrail takes the other approach: rather than asking the model to behave, it puts a check outside the model. Whatever the model produces, code reads the answer before it leaves the company and decides whether it goes.

It makes code, rather than a person, verify on every single request that the answer stayed inside the lines. Answers cross the line in roughly four ways.

1. Claims with nothing behind them. Hallucination is a model stating something untrue in a fluent sentence — the refund policy above. The check compares claims in the answer against the source documents the model was given and holds anything that isn't there.
2. Broken format. When a screen or another program consumes the answer, a small deviation from the agreed shape stops everything downstream. A slot expecting a three-item list gets a paragraph of explanation instead, and the screen renders empty.
3. Content that shouldn't leave the building. Disparaging a competitor, sentences that read as legal or medical advice, promises the company never made. A list of forbidden topics filters these.
4. Input that shouldn't go in. A customer pastes text containing personally identifiable information (PII) and it travels straight to the model provider; or the pasted text tells the model to ignore its earlier instructions. These get caught by inspecting the input before any answer is generated.

What happens when a check fires is also decided in advance, and there are three options: block the answer and send a fixed fallback message instead, send it back to the model with an added condition, or route it to a person for review. That last route is human in the loop. Every firing gets logged. Counting how often each check fires is the only way to learn whether the line was drawn too tight.

Four other measures address the same problem, and none of them replaces the others.

1. Improve the instructions. Prompt engineering is the work of designing what gets sent to the model. It's the cheapest lever and usually the first one pulled, but it remains a request — right ninety-eight times out of a hundred and wrong twice.
2. Supply the source material. Retrieval-augmented generation (RAG) looks up relevant passages from internal documents when a question arrives, attaches them to the instructions, and has the model answer from those passages only. It narrows the room for invention rather than closing it.
3. Narrow the entrance. Replace a free-text box with a set of choices and the range of possible answers narrows with it. Instead of drafting a reply freely, the feature picks one of five pre-approved paragraphs.
4. Have a person approve every message. The most reliable option, and the one whose throughput is capped by headcount — unusable where thousands of messages move a day.

The four sit in a different place than a guardrail. The first three lower the odds that a bad answer is produced; a guardrail decides whether an answer already produced gets sent. Most real products use all of them: lower the odds first, put checks on what remains, and send only the caught cases that need judgment to a person.

"We can't ship this without guardrails. The draft goes straight to the customer."

Nothing stands between the model and the outside, so an output check has to come first.

"The guardrails are too tight. It's blocking good answers — we're at a 30 percent refusal rate."

The line was drawn narrowly and usable answers are being thrown away with the bad ones.

"I don't think that's a guardrail thing. That should be fixed in the prompt."

Better to stop producing the answer than to filter it afterwards.

Pagedeck's reply-draft feature currently runs three checks. Amounts and time periods that don't appear in the source documents block the draft. The words refund and cancellation route it to Sofia. Anything shaped like a national ID or card number is stripped from the customer's pasted text before it reaches the model.

None of the three arrived at once — each was added after an incident. Mia reviews how often each check fires every quarter. A refund check that fired twice in a quarter isn't earning its place, and one firing on 30 percent of requests is probably drawn in the wrong spot.

The most common reading is that adding guardrails makes the model itself safe. The name evokes something that keeps a vehicle in its lane, which suggests the model's nature has changed. Nothing about the model changes; the checks read sentences passing by on the outside. Anything that crosses a line in a way no check describes goes through untouched. Teams holding this belief stop reading real outputs the day the guardrails ship, and the failures nobody listed get found by customers first.

The second is that tighter is better. It's a blocking mechanism, so more blocking looks like more safety. But checks judge with rules that are mostly right rather than certain, which means good answers get caught alongside bad ones. When three replies in ten turn into a fallback message, users conclude the feature is broken and stop using it. The line isn't drawn once — it moves as the firing counts come in.