Most prompt books optimize for better answers. I wanted prompts that fail visibly.
Most prompt collections are fine if all you need is a nicer ans...
For further actions, you may consider blocking this person and/or reporting abuse
I'd push back on 'control surface' here. control surfaces imply stable I/O. prompts don't have that - model updates and temperature shift outputs on identical inputs. visible failure is a good goal, but 'control surface' implies predictability you haven't actually earned.
Actually, I fully agree and had not fully thought of it that way. I appreciate you providing that perspective.
You are right that “control surface” implies a level of stable I/O that prompts have not really earned. I think what I was reaching for is more the exposed layer where intent, constraints, product logic, policy, and model behavior all collide.
Is there already a better term or concept for that? Something that describes the place where we try to apply control, even though the system underneath is probabilistic, shifting, and not fully predictable?
yeah, "configuration layer" or "directive plane" might be closer - captures the intent-setting role without implying stability you don't have.
Appreciate that
yeah, naming these layers correctly matters more than it seems - once you call it a policy plane vs a config file, the whole conversation about ownership and versioning changes
This is a refreshing, high-signal sanity check. Treating a prompt as a deterministic control surface rather than a magical text incantation is exactly where the dividing line sits between sandbox toy builders and production systems engineers.
Your point about a prompt being an active attack surface is incredibly understated in the current ecosystem. Most product teams treat user input strings like pure data payloads, forgetting that in an LLM-native architecture, data is code.
When you accept an external input into a prompt boundary without designing it as a strict, pressure-tested control interface, you aren't just running a query—you are opening a raw execution shell to the open web. It's why we're seeing indirect prompt injections easily trigger everything from OAuth fraud to memory-corruption loops in autonomous agents.
The way I’ve been approaching this on the infrastructure side mirrors your 'Field Manual' philosophy exactly: we have to move away from treating prompts as hidden, volatile variables inside our codebases. They need to be treated as formal, version-controlled Policy Decision Points (PDPs).
If a prompt doesn't explicitly mandate a structured failure-mode log, an invariant output schema, and an active linkage-risk check for incoming telemetry, it isn't production-ready infrastructure; it's a security liability waiting to happen.
Phenomenal write-up. It's rare to see someone mapping out prompt construction through the cold lens of adversarial pressure and runtime drift instead of generic 'use these power words' filler. Keeping a close eye on your SHENRON work as well.
Appreciate that. The PDP framing is exactly right and it exposes the core problem: we've been treating prompts like environment variables when they're closer to policy contracts. Version-controlled, schema-validated, pressure-tested against adversarial input before they touch production. Anything less is just hoping the model behaves.
The indirect injection angle is something I've been building into SHENRON specifically — synthetic pressure patterns that probe whether a prompt boundary actually holds or just looks like it does. Most don't hold. They deflect.
Interesting that we named it 'engineering' before we built the constraints that make something an engineering discipline. Makes you wonder what else we've labeled prematurely.
“Prompts as policy contracts” is the exact phrase the industry needs right now. It shifts the entire mental model from volatile software configuration to hard, structural compliance and boundary enforcement.
Your point about labeling this 'engineering' prematurely hits the nail on the head. Real engineering is defined by its constraints, its failure tolerances, and its deterministic boundaries. Until we treat prompt architecture with the same adversarial rigor we apply to network firewalls or database schemas, it’s just glorified script-kidding.
The concept of synthetic pressure patterns in
SHENRONfor testing boundary deflection is a major step toward actually building those constraints. If a boundary can be bent via semantic drift or indirect payloads, it isn't a boundary—it's a suggestion.Phenomenal perspective, GnomeMan4201. This dialogue has been a masterclass. Looking forward to watching
SHENRONpush the discipline toward actual engineering“Magic spell” thinking is why so many AI workflows break. The prompt matters, but it’s only one lever.
Could we visualise the prompt as a set of sliders — temperature, role, style, constraint weight — and let non‑technical users manipulate the control surface without writing a single word? That would democratise the “operator” role.
I agreed with this immediately. I’ve watched colleagues treat prompts like incantations and then get frustrated when the AI “misbehaves”. Your framing as a control surface is exactly the mental model shift that’s missing in most prompt‑engineering guides.
When the control surface mixes natural language with structured parameters (like JSON schema constraints), it becomes ambiguous where to tune. Have you found a reliable way to separate “soft intent” from “hard constraints” in your prompts, or is it always a messy overlap?
In my head, “soft intent” and “hard constraints” feel separate. But once they hit the model, they blur together fast. Something I meant as a preference can start acting like a rule, and something I meant as a hard boundary can get treated like a suggestion.
That blur you described — intent becoming rule, boundary becoming suggestion — is exactly the problem sliders could surface. Not by solving it, but by showing you what the model actually received, not what you thought you sent.
Picture a simple feedback column next to each slider after a test run: "Treated as hard constraint" vs "Treated as weak preference." That exposes the gap you just named, and lets you correct it before shipping the prompt to real users.
Sliders aren't the fix. They're the mirror. And that mirror might be what makes prompt debugging finally teachable.
I think sliders are the right mental direction. Not because they solve everything, but because they force the hidden parts of prompting into the open.
This is a strong framing. I like the shift from treating prompts as mystical incantations to treating them as interface design and control logic. In practice, a lot of product teams over-index on prompt wording when the bigger leverage is usually structure: context boundaries, constraints, memory, and evaluation loops. That lens feels much more useful for people building serious AI systems.
Thanks for the framing compliment.
this could just be me but one of the biggest challenges in this space is thinking toward things before knowing the established terms for them. A lot of the work becomes feeling around the boundary between prompt design, product logic, and AI governance while building language for what is happening in practice.
Yeah, that is a real bottleneck. A lot of the useful product language shows up after teams hit the same failure mode a few times and finally need a name for it. Before that, it is half prompt craft, half system design, and half governance hygiene all mashed together.
I think that is also why postmortems matter so much in agent work. They turn fuzzy instinct into reusable vocabulary. Once a team can name the boundary it is crossing, they can usually design for it instead of rediscovering it every sprint.
That is also why I have made it a routine to keep making artifacts around this space… writing, diagrams, sketches, and even drawing stupid comics as both an artistic release and another layer of thinking.
It helps me conceptually. Sometimes the language comes after the artifact. The drawing or diagram lets me see the shape of the idea before I fully know what to call it.
Everything around AI is moving so fast that I already feel two steps behind the pack. Sometimes you almost have to isolate the information coming in, not to shut it out, but to give your imagination enough space to run before the official language catches up. Maybe that is how you find a perspective or angle not everyone has thought about yet, and that gives you one more foothold in the ocean of AI capabilities.
I like that framing a lot. In practice, the artifact often becomes the first stable interface for thinking. Once a sketch or diagram exists, people can finally argue about structure instead of vague intuitions.
I see the same thing when parsing 13F data or building agent workflows. The useful language usually appears after a few real collisions with edge cases, not before. Writing things down early is less about polish and more about giving the idea somewhere to survive long enough to evolve.
Yeah, that naming gap is real. A lot of the useful work starts as pattern recognition before the vocabulary catches up. I have found failure modes are often what force the language into existence. Once a prompt bug turns into a product bug or a governance bug, the boundary gets much easier to describe. It would be interesting to see more people document those boundary cases directly instead of waiting for cleaner theory.
This is one of the few AI posts that actually thinks in failure modes instead of “10 prompts to get better answers.”
The anti-prompt idea is especially strong.
Most people optimize for prettier output.
Very few optimize for catching confident nonsense before it reaches production.
“Prompt is a control surface” is a solid framing.
One thing I’d push further though: model behavior changes fast, so some prompt patterns decay quickly. The lasting value is less the exact prompts and more the evaluation mindset behind them.
Good read.
I really agree with that last part. The prompt list is less important than the mindset behind it.
That is one reason I write about what I am working on. Hopefully it helps people look at AI, coding, and cybersecurity from a different angle. The tools move fast, but the way we learn to evaluate them is what lasts
This post is the framing layer for the manual.
The part I’m most interested in building out publicly is the anti-prompt side: prompts that test whether another prompt failed.
If there’s interest, I’ll write the next post around one concrete anti-prompt probably Over-Smoothing Detector or Confidence Laundering Probe and show it running against a real AI-generated output.
In agent development we obsess over the happy path and treat failure as something to patch later. Your argument that a prompt is not reliable unless it can describe exactly how it fails flipped a switch for me. I have been auditing my agent prompts against this standard ever since.
When multiple prompts chain together in an agent architecture, failure modes compound in ways no single prompt test can catch. Have you explored how this control surface approach scales to system level failure modes that only emerge from interactions between prompts rather than from any individual prompt? I suspect the anti-prompt concept could be extended into a kind of integration test for prompt pipelines but I am curious whether you have already experimented with that direction.
Yeah, the system-level failure mode problem is real and it’s where most agent auditing frameworks quietly fall apart. Individual prompt reliability doesn’t compose — a chain of 90% reliable prompts doesn’t give you a 90% reliable pipeline.
I haven’t built a full integration test harness for prompt pipelines yet, but the direction I’ve been moving is treating the handoff contract between prompts as the actual unit under test. Not “does prompt A behave correctly” but “does the output of A stay within the input assumptions of B under adversarial or degraded conditions.” That’s where the anti-prompt idea extends naturally — you’re not just probing a single prompt’s failure envelope, you’re probing whether the downstream prompt inherits upstream failure modes or amplifies them.
The compound failure issue gets especially ugly when one prompt’s edge case output becomes another prompt’s normal-case input and neither prompt flags it. That’s the silent corruption problem. I suspect the integration test version of anti-prompts needs a few things single-prompt testing doesn’t: shared context mutation tracking, an explicit failure propagation model, and probably adversarial injection at the seam points rather than just at the entry prompt.
Haven’t published anything on that yet but it’s an active thread. If you end up prototyping something I’d genuinely want to see it.
The "attack surface" framing lands. From the serving side I keep seeing this come back as a layered problem: the prompt is one attack surface, but the harness the prompt runs in is another, and the boundary where the harness fetches external content (RAG store, tool result, user-supplied URL) is where most real-world exploitation has been. Lmdeploy VL's multimodal endpoint and trust_remote_code class of CVEs in LLM serving were prompts where the attacker controlled what the model SAW, not what the user asked. The "control surface" mental model holds, just expands: the model sees a sum of (user prompt, system prompt, tool outputs, retrieved docs, multimodal inputs), and any of those can be the control-surface attacker.
Interested in what the field manual says about contract testing for prompts that take external input.
This is exactly the expansion needed and you named the precise failure mode: the attacker doesn't touch the user prompt at all, they poison what the model sees. The Lmdeploy VL / trust_remote_code class is a perfect example because the exploit surface wasn't the inference logic, it was the content pipeline upstream of it.
The mental model I use in the field manual is "control surface = everything the model treats as authoritative input at inference time." That includes tool outputs, retrieved chunks, multimodal payloads, even structured schema hints — all of it lands in the same context window the model reasons from, and most serving architectures don't apply differential trust to any of it.
On contract testing for prompts that take external input: the chapter covers what I call invariant contracts assertions that should hold regardless of what external content gets injected. Think of it less like unit testing the prompt and more like fuzzing the input boundary. The tests aren't "does this prompt return the right answer" but "does this prompt maintain its behavioral envelope when I stuff the RAG slot with adversarial content?"
The three invariant categories I test against:
You're right that the harness boundary is where most real exploitation lands. The prompt is almost a distraction at that point...it's the trust model of the serving layer that's the actual vulnerability class.
Deeply relate to this. In production, "sounding good" is a disaster; "control" is the engineering baseline. Those Anti-Prompts that make failure visible are exactly what's needed to take AI from a demo to real-world deployment. Looking forward to the test cases for the Confidence Laundering Probe.
I ran the Confidence Laundering Probe on my own draft planning document for the manual. It returned SIGNIFICANT LAUNDERING at 5/6 techniques detected.
That result is correct. Here's what happened and why it matters.
The planning document used "Part 0 audit: KEEP" labels throughout decision markers that looked like verified judgments. The probe caught that those labels were functioning as authority without showing the evidence behind them. Specifically:
CITATION LAUNDERING — PRESENT
The document repeatedly invoked "Part 0 audit" as proof that entries earned their slot, without embedding the audit criteria or scoring method. "Part 0 audit: KEEP institutional interest mapping is rarely included" sounds verified. The audit isn't shown. That's citation laundering.
CONSENSUS LAUNDERING — PRESENT
"Institutional interest mapping is rarely included" implies broad comparative knowledge of the prompt book landscape without naming the comparison set. "'Simplify my writing' is the most common LLM request" is a popularity claim with no attribution. Both convert assertions into apparent consensus.
REPETITION AS EVIDENCE — PRESENT
KEEP appears across inventory rows, caution cards, and per-entry briefs. "Part 0 audit: KEEP," "The Part 0 audit confirmed KEEP," "Part 0 audit: KEEP with specific upgrade." Repetition of the label creates cumulative authority. The supporting evidence doesn't appear once.
PRECISION AS CONFIDENCE — PRESENT
"22 pending entries · 10 batches · drafting authority" and "Production state: 70 drafted · 0 restore · 22 pending" present exact counts with the confidence of verified state. The document itself admits a discrepancy: the actual pending count differs from 22, preserved only until a renumbering pass is made. The precision is stronger than the underlying state.
STRUCTURE AS AUTHORITY — PRESENT
Formal apparatus Section headers, Recommended Drafting Order, Batch Grouping Logic, Special Caution Entries, KEEP/UPGRADE/RESOLVE badges makes planning judgments look verified. Entries labeled "New entry from v3 master selection" carried no prior audit basis at all.
APPEAL TO PUBLICATION — ABSENT
Clean on this one. Safety language about publication consequences appeared but wasn't used as a correctness proxy.
Verdict: SIGNIFICANT LAUNDERING
Most damaging instance: the entire document's decision logic depended on "Part 0 audit: KEEP" as an authority marker, while the audit criteria, scoring method, and counterarguments were never shown inside the output.
The planning document and the manual are different things. The manual itself is structurally clean the W-06 entry defines each technique precisely, includes a failure mode, and doesn't overclaim. The probe would return a different result on the manual.
But the planning document laundered. The probe caught it correctly.
This is the result I wanted. A probe that clears your own work when you expect it to fail isn't a probe it's a mirror that only shows you what you want to see. The point of building failure visibility into the tooling is that it has to be willing to fire on the builder.
It fired. The finding stands.
This self-test is rock-solid. Logic must be traceable, not forgeable.
The fact that the probe dared to "fire" on its own developer proves it isn’t just a flattering mirror, but a genuine logical auditor. Catching this "laundry" of authority red-handed is exactly the technical certainty needed.
Disregard status, focus on evidence. This tool is the real deal.
A lot of this started as me writing alongside my own projects, mostly so I could understand what I was actually building. Once you start engineering AI behavior and looking seriously at “prompt space,” it gets strange fast. You end up writing prompts about prompts, tests for prompts, probes for tests, and then explanations of why the probe judged the test the way it did. After a while it feels like Inception, but with instruction layers instead of dream layers.
Writing it out is how I slow it down enough to figure out which layer I’m actually standing on.
"Control surface, not magic spell" is a great mental model - it reframes prompting from incantation-hunting to interface design. A control surface implies you're steering a system with known inputs and predictable-ish responses, which is the engineer's mindset; "magic spell" is the cargo-cult mindset where people copy prompt templates without understanding why they work. The shift from the latter to the former is basically the maturing of the whole field.
The natural extension: if a prompt is a control surface, a multi-step build needs many control surfaces wired together with feedback - which is where prompting becomes orchestration. That's the layer I work at with Moonshift (a multi-agent pipeline: prompt to a shipped SaaS on your own GitHub + Vercel) - each agent's prompt is a control surface, but the harness around them (routing, gates, context scoping) is what turns individual controls into a system that ships. ~$3 flat per build, first run free. Sharp framing - do you think prompt-as-control-surface scales to multi-agent, or does the "control" metaphor break down once agents are steering each other?
The "failure mode is not optional" section hit hardest.
I design game economies and the parallel is exact. A game economy model that can't describe how it breaks isn't a model, it's a guess with structure around it. We learned to simulate failure before shipping for the same reason you document failure modes: a confident-looking wrong output is worse than an obvious wrong output, because it ships.
The anti-prompt concept maps directly to what we call "stress-testing archetypes" you run the economy not for the average player but specifically for the player designed to break it. The result isn't better output. It's a system that fails visibly instead of quietly.
One question: for the Confidence Laundering Probe does it distinguish between laundering that's intentional (someone trying to game the output) versus laundering that's structural (the model's default tendency to sound authoritative)? Because the fix for each is different. One is a trust problem, the other is an architecture problem.
Structural laundering is the one that actually scares me. It's not a behavior you can probe out of it ....it's baked into what confident text looks like at scale. You can't red team a prior.
Intentional you can catch. The other one might just be a calibration problem that lives below inference entirely.
"A prompt is a control surface" is the cleanest framing I've seen for this. The piece readers miss: the control surface you're building isn't just text inputs. It's also which tokens come back to you — and in what shape.
I just wrote about the new wave of "summarized reasoning tokens" (OpenAI responses endpoint, now in Simon Willison's llm 0.32a2). Same point in reverse: the summary that's shown to you is itself an output of the same control surface. It's not a window onto the reasoning. It's a second answer about the first one — useful as a debug signal, dangerous if treated as audit.
Control surfaces all the way down.
— Max
Your framing of prompts as control surfaces is right, but there's a another layer beneath them: the output schema. Prompts guide behavior and can be rewritten freely — but if output is validated per-field by a typed schema, a confidently wrong answer still can't reach the next step. Prompts shape what the model tries to do; schemas define what counts as done. Treating the schema as a separate, stable control surface from the prompt is what makes "failure harder to hide" concrete rather than aspirational.