Opir reminded me that a lot of guardrail work is really classification.
The conversation around safety often drifts toward judge models and verbose explanations. That can help, but it is a strange default for every decision. Is the prompt safe? Is this a jailbreak attempt? Does the response violate policy? Which category is involved? Those are classifier-shaped questions.
The useful part of Opir is that it makes that shape easy to see again.
prompt or response
-> safety classifier
-> label scores
-> policy decision
-> allow, block, route, redact, or review
The labels matter because “unsafe” is too blunt for most products. Harassment is not the same thing as malware. Prompt injection is not the same thing as self-harm. A benign explanation of a risky topic is not the same thing as an instruction to do harm. The taxonomy is what turns a safety score into something the product can act on.
That also means false positives matter. A classifier that blocks ordinary security education, research content, or benign mentions of dangerous terms creates product damage even when the system is catching bad actors correctly. The hard negatives are what keep the boundary sane.
I like the edge variants because they make the guardrail cheap enough to sit in front of the expensive model or next to a local tool path. That gives the app options: block, route, redact, or send to review. It does not remove judgment. It just makes the judgment inspectable.
The framing I trust is simple. Safety is not magic text. It is labels, thresholds, policies, and a place in the request path where those things can actually do work.
Related posts

About Jeremy London
Engineering leader and builder in Denver. I write about AI platforms, agents, security, reliability, homelab infrastructure, and the parts of engineering work that have to survive production.