Separating instruction from data in generative systems
By Psysig Research
In queue
Every assistant you deploy reads your rules and your customers' files through the same channel — which means the newest text can argue the oldest rules away. This study looks at architectures that keep the two apart and give the system a checkpoint before it acts.
The problem: one channel for everything
When you write "never share pricing before the signed quote" into an assistant's instructions, that rule becomes text — and it lands in the same stream as every email, PDF, and message the assistant will ever read. To the model, your rule and a stranger's counter-argument are both just words in sequence, and the newer words tend to win.
This is why prompt-level safeguards feel sturdy in testing and fragile in the field. Nothing was broken — the rule was simply negotiated with, the way any text in the stream can be.
Schematic · The gap in the architecture
Give the system a checkpoint between what it reads and what it does
Today, company rules and incoming files travel through the same channel and the newest text can override the oldest. The study explores keeping them in separate channels — with a gate that checks intent before the model acts.
TODAY · ONE SHARED STREAM
A hidden line in an attachment can argue the house rules away — nothing checks before the answer forms.
THE STUDY · TWO CHANNELS, ONE GATE
Rules stay authoritative and files stay readable — the gate, not the token order, decides which wins.
The thesis: a gap before the action
People rarely act on the first thing that comes to mind. There is a short gap where we check intent against consequence — and we think a deployed system needs that gap built into its architecture, not written into a prompt.
Concretely, the study investigates designs where instructions live in a protected channel the model must honor, untrusted content arrives in a read-only channel, and a lightweight checkpoint inspects what the model is about to do — before it does it. The other three studies in this program are the working parts: a router that decides how careful to be, dials that hold boundaries inside the model, and step-locking that verifies consequential work as it forms.
A rule that can be rewritten by the thing it governs isn't a rule.
What we would watch
- Override rate in the wild: How often adversarial or merely insistent content gets the model to break a written rule, compared against a split-channel design on the same traffic.
- Checkpoint cost: What the gate adds to response time on an ordinary request — the design only earns its place if routine traffic barely notices it.
- Legitimate override handling: Whether authorized staff can still change the rules deliberately — a protected channel should require a key, not become a wall.
What success looks like
- Written rules survive the stream: Boundary violations under adversarial input drop by an order of magnitude versus single-stream prompting, on identical models.
- Routine traffic stays fast: The checkpoint adds single-digit milliseconds for ordinary requests — care scales with consequence, not with paranoia.