Guardrails
Overview
Section titled “Overview”Domain Authority tells you where the limits should be. This topic is about enforcing them — and about the moment a system stops answering questions and starts doing things.
What a guardrail is
Section titled “What a guardrail is”A guardrail is a check that constrains what goes into a model or what comes out of it.
On the way in: Is this request safe to send? Does it contain personal data that shouldn’t leave the region? Is someone trying to override the system’s instructions?
On the way out: Is this answer safe to return? Does it leak another customer’s data? Is it a confident answer to something the system doesn’t actually know?
These are not settings you switch on at the end. They sit in the request path, they add latency, they cost money, and they need somewhere to live. That makes them structure.
The line that matters most
Section titled “The line that matters most”An assistant that answers wrongly wastes someone’s time. An assistant that acts wrongly loses money — and does it at machine speed, thousands of times before anyone notices.
The moment a system can act rather than just answer, one question becomes central:
What is this allowed to do without a human?
That’s a business question with a monetary value attached, not a technical one. It is exactly the kind of decision that belongs to you as solution architect — cross-team, expensive to change, and tied directly to a business driver.
Drawing the line by blast radius
Section titled “Drawing the line by blast radius”The useful organising principle is blast radius: how much damage one wrong action does, and how reversible it is.
graph LR A["<b>Act alone</b><br/>small, reversible<br/><i>answer a question<br/>look something up</i>"] --> B["<b>Act, then notify</b><br/>reversible, visible<br/><i>reschedule work</i>"] B --> C["<b>Ask first</b><br/>costs money<br/><i>issue a refund</i>"] C --> D["<b>Never</b><br/>irreversible or<br/>outside the remit<br/><i>cancel a contract<br/>change permissions</i>"]
Four tiers by blast radius. Every action the system can take belongs in exactly one, and the decision is written down.
The exact boundaries are arguable. Having drawn them explicitly is not optional — an unclassified action defaults to whatever the implementer assumed.
Guardrails aren’t free
Section titled “Guardrails aren’t free”Three costs, and pretending otherwise is how they get cut later under deadline pressure.
Latency. Every check sits in the path. Input screening plus output screening can add meaningfully to a response the user is watching stream in.
Money. Checks that use a model cost per call, on top of the call they’re protecting.
False positives. A guardrail tuned to catch personal data will block legitimate requests containing a customer’s name — which, in a support tool, is most of them. Too strict and people route around the system entirely; then you have no guardrails and no adoption.
That last one is the real design problem. Guardrails that are too aggressive don’t fail loudly; they fail by making the tool annoying enough to abandon.
Who owns the line
Section titled “Who owns the line”Not you alone.
Compliance owns what may leave the building. Finance owns the exposure from automated actions that cost money. The team who will use the thing owns whether the false-positive rate is liveable.
Your job is to make the boundary explicit, written down, and agreed — not to decide it privately. This is the interests-versus-positions work applied to a concrete decision: a compliance lead’s position will be “no personal data to third parties”; their interest is not being responsible for a breach. Those two admit very different designs.
Feeds the workbook
Section titled “Feeds the workbook”Your business-value brief and charter should reflect where this decision sits. Setting the escalation model is plausibly yours; deciding the organisation’s risk appetite for automated spending is not.
→ You’ve been designing with pieces that didn’t exist five years ago. Next, what they’re called and what they’re for. — New primitives