A system prompt is the runtime instruction set a model reads before every single response — it defines who the assistant is, what it will do, and what it will refuse, in the moment it matters. Your PRD describes intent on paper, reviewed once in a meeting. The system prompt is the only artifact the model actually consults, which makes it the real specification and the most under-owned document in your stack.
Quick answer: The system prompt is where PRD requirements about behavior — refusals, tone, scope, escalation — get executed at runtime. If a PM doesn't write or review it, someone else has quietly made those product decisions, usually an engineer optimizing for "it works" rather than "it's right."
The System Prompt Is Where Your PRD Actually Runs
A PRD is a proposal. It sits in Confluence, gets a few comments, and informs a build. The system prompt is different: it is loaded into every inference call, and the model's behavior is a direct function of what's in it, not what your PRD intended. When the two disagree, the system prompt wins every time, because it's the one thing actually present at the moment of generation.
This is a bigger shift than it sounds. In traditional software, a requirements doc gets compiled into code, tests, and UI — there are several translation layers and several places to catch a gap between intent and behavior. With an LLM feature, the system prompt often is the translation layer. Skip reviewing it and you've skipped reviewing the feature.
Consider what typically lives only in the system prompt today, decided by whoever wrote the last version before a demo:
- The assistant's persona and register (formal, casual, clinical)
- Topics it will and won't engage with
- How it formats answers (paragraphs, bullets, tables, code)
- What it does when it doesn't know something
- Whether and how it hands off to a human
None of that is a small detail. It's the product. OpenAI's public Model Spec exists precisely because this gap kept causing incidents — it formalizes a chain of command (platform rules outrank developer instructions, which outrank user requests) so that behavior decisions are traceable to an owner rather than buried in a prompt file nobody remembers writing. If you're new to how prompts are structured mechanically, our complete guide to prompt design covers the fundamentals this article assumes; here we're focused strictly on the ownership question.
PRD vs. System Prompt, as Artifacts
The two documents look similar — both describe what the product should do — but they behave completely differently in production.
| Attribute | PRD | System Prompt |
|---|---|---|
| Primary audience | Engineering, design, stakeholders | The model, at inference time |
| Enforcement point | None — it's descriptive | Every single response — it's executive |
| Update cadence | Sprint or release cycle | Can change same-day, often without review |
| Typical author | PM | Whoever last touched the prompt file |
| Failure visibility | Caught in QA or user testing | Caught in production, sometimes publicly |
That last row is the one that should worry you. When a PRD is wrong, a reviewer catches it before ship. When a system prompt is wrong, a user finds it — and increasingly, so does a journalist or a tribunal.
PRD Requirement vs. System Prompt Encoding: A Side-by-Side
A PRD line like "the assistant must never give medical advice" reads as a clear requirement, but it is not directly usable by a model — it has to be translated into concrete, testable instructions that define the boundary, the refusal language, and what happens after the refusal. That translation work is a product decision, not an engineering one.
Here's the same requirement type, shown as a PRD line and then as a plausible system-prompt encoding a PM should be reviewing, not discovering after launch:
| PRD Requirement | System Prompt Encoding | Why the Translation Isn't Trivial |
|---|---|---|
| "Must never give medical advice" | "You are not a licensed medical professional. If asked to diagnose, recommend treatment, or interpret symptoms or lab results, decline the specific request and suggest the user consult a clinician. Do not soften this into a disclaimer-then-answer pattern." | "Medical advice" is ambiguous — does it include general nutrition info, OTC dosage, or mental-health resources? The PM has to draw that line, not leave it to the model's judgment. |
| "Keep responses concise" | "Default to 3–5 sentences. Use a bulleted list only when covering 3+ discrete items. Never restate the user's question before answering." | "Concise" is subjective until it's operationalized into a rule the model can actually follow consistently. |
| "Escalate sensitive requests to a human" | "If the user expresses self-harm ideation, disputes a legal or financial decision, or requests account cancellation, stop the current task, output the designated handoff message, and tag the conversation for human review." | Escalation needs a defined trigger list and a downstream system to receive the handoff — a cross-functional dependency, not a prompt tweak. |
| "Maintain a warm, expert, never condescending brand voice" | A short list of forbidden phrases ("as I mentioned," "obviously," "simply") plus two or three worked examples of the target voice in both easy and frustrated-user scenarios. | Voice guidelines described in adjectives don't transfer to a model; they need concrete positive and negative examples. |
Notice the pattern: every row on the right requires a decision that is squarely product judgment — where the line is, how firm the refusal should be, what happens next. Engineers can implement any of these once decided. Very few of them should be deciding it by default.
The Five Things a PM Must Own in the System Prompt
If you take nothing else from this article, take this list. These are the five dimensions of behavior that determine whether an AI feature feels like a considered product or a demo that escaped into production, and each one maps to a decision only a PM (or a PM working with legal, support, and design) should be making.
- Scope — what the assistant is for, and, just as importantly, what it is explicitly not for.
- Refusals — the exact boundaries, and the tone in which the model declines.
- Tone — the voice, register, and personality, consistent across contexts.
- Output contract — the structure the response must take, every time.
- Escalation — when the model stops and hands off, to a human or another system.
1. Scope
Scope is the boundary of what the assistant will attempt. A support assistant scoped to "billing and account questions" behaves very differently from one scoped to "anything the user asks." The PM decision here is which data sources and actions are in bounds — a question our guide to AI data strategy goes into in more depth, since scope is really a statement about what data the model is allowed to touch.
Write scope as a positive list ("answers questions about X, Y, Z") and a negative list ("does not discuss competitor pricing, does not process refunds directly"). Both lists belong in the prompt, not just in your head.
2. Refusals
A refusal is not just "no" — it's a decision about firmness, phrasing, and what (if anything) is offered instead. Should the assistant explain why it's declining? Redirect to a resource? Refuse silently and change the subject? Each choice has different UX and trust implications, and each is a product call.
Get this wrong and you get one of two failure modes: an assistant so cautious it refuses reasonable requests, or one so permissive it becomes a jailbreak magnet. Our AI safety guide covers refusal design and adversarial testing in more depth — worth a read before you finalize refusal language for anything regulated or reputationally sensitive.
3. Tone
Tone drifts fastest when nobody owns it, especially once a feature expands beyond one channel. The tone that reads as "confident and warm" in text can read as clipped or robotic once it's the same assistant answering by voice, where pacing and phrasing carry more weight than punctuation. If your roadmap includes speech interfaces, our guide to multimodal and voice AI is worth reviewing before you assume your text-tuned system prompt will transfer cleanly.
4. Output contract
The output contract is the structural promise: does the assistant always return a short answer plus bullets? A fixed JSON shape a downstream system parses? Markdown a UI renders? This is the most engineering-adjacent of the five, but it's still a product decision, because the shape of the output is the feature for anything that isn't pure chat.
When the output feeds another system — a ticket, a CRM field, a workflow trigger — the contract has to be as precise as an API spec. Our guide to structured outputs and shippable JSON walks through how to define that contract so it survives contact with a real model rather than breaking on the fifth edge case.
5. Escalation
Escalation is the exit ramp: the point where the assistant stops trying to answer and routes to a person, a form, or another tool. Every regulated or high-stakes feature needs an explicit escalation list, because "the model will figure out when it's out of its depth" is not a policy — it's a hope.
A useful test: if you can't name the exact phrase or signal that triggers escalation, you haven't finished the spec. You've finished a wish.
Why Most System Prompts Are Written by No One in Particular
Most system prompts in production today were written once, under deadline, by whoever was closest to the code — and then never formally revisited. That's not a criticism of engineers; it's a description of what happens when a governance gap exists and someone has to ship anyway. The result is behavior that reflects engineering convenience more often than product intent.
This gap has a real cost, and it's no longer hypothetical. In 2024, a Canadian tribunal held Air Canada liable after its support chatbot invented a bereavement-fare refund policy that didn't exist — a case (Moffatt v. Air Canada, BCCRT) that turned entirely on nobody having defined and enforced what the assistant was and wasn't authorized to promise. The failure wasn't a model bug; it was an unowned scope and refusal boundary.
The governance frameworks now catching up to this problem say the same thing from different angles:
NIST's AI Risk Management Framework includes aGovernfunction explicitly requiring organizations to assign accountability for AI system behavior — not just its accuracy, but its conduct.Anthropic's work onConstitutional AItreats the rules a model follows as a first-class, reviewable artifact rather than an implementation detail buried in code — and the company has published versions of Claude's own system prompts, effectively making the practice auditable.- Independent researcher
Simon Willison, who has documented dozens of real prompt-injection and jailbreak incidents, has argued consistently that a system prompt's boundaries are a security surface, not just a style guide — treat it as unreviewed infrastructure and it will eventually leak or be bypassed. Gartnerhas predicted that a substantial share of agentic AI projects — directionally on the order of 4 in 10 — will be abandoned or scaled back by 2027, citing unclear ROI and inadequate behavioral controls as leading causes, not model capability.
That last figure is worth sitting with. Projects don't usually get killed because the model was too weak; they get killed because nobody could confidently say what the system would or wouldn't do, and the cost of finding out in production was too high. That's a spend problem as much as a trust problem — our guide to AI economics breaks down where those costs actually accumulate when behavior isn't specified up front.
The pattern across all four sources is the same: behavior needs an owner, a review process, and a paper trail — the exact things a PRD is supposed to provide, applied to an artifact most PRDs never mention.
Treating the System Prompt Like a Living Spec, Not a Config File
A system prompt that changes without review is a product changing without review — the fix isn't a one-time audit, it's a standing process: version it, review it cross-functionally, and gate changes behind the same readiness bar you'd apply to any other shipped requirement.
In practice, that means:
- Version control it like code, with a diff visible in review — not a string buried in a backend file that only one engineer touches.
- Review it cross-functionally — legal for refusals, support for escalation triggers, brand for tone, PM for scope — before any meaningful change ships.
- Test it against the PRD line by line, the way you'd test acceptance criteria: does this prompt actually produce a refusal on the medical-advice case, every time, in five different phrasings of the same request?
- Gate releases the same way you'd gate a feature: no shipping a scope or refusal change without the same sign-off a pricing change would require.
This is the same discipline a living PRD is supposed to enforce, just pointed at a different artifact. It's why Prodinja's Spec Studio is built around drafting behavior as a living PRD — with sections, PR-style diffs, and readiness gates before anything ships — so a scope change or a new refusal rule goes through the same review trail as any other requirement, instead of living quietly in a prompt file nobody diffs. The tool doesn't replace the judgment calls above; it's designed to give them a place to happen before launch instead of after an incident.
Key Takeaways
- The system prompt, not the PRD, is what actually runs at inference time — if you haven't reviewed it, you haven't reviewed the feature.
- Every behavioral PRD line (refusals, tone, escalation) needs a concrete, testable translation into prompt language; that translation is a product decision.
- Own five things specifically: scope, refusals, tone, output contract, and escalation — each maps to a real product judgment call.
- Unowned system prompts have already caused real, documented incidents, including a tribunal ruling against Air Canada over an invented chatbot policy.
- Governance frameworks like
NIST's AI RMF and practices likeOpenAI'sModel Specexist because "the engineer who shipped it owns it" doesn't scale as accountability. - Treat the system prompt as a living, versioned spec with cross-functional review and readiness gates — not a config value set once and forgotten.
Frequently Asked Questions
Is the system prompt part of the PRD, or a separate document?
It should be treated as the executable companion to your PRD, not a replacement — the PRD states intent and rationale for stakeholders, while the system prompt is the technical encoding a PM reviews line by line before it ships. Keep both, but stop assuming the PRD alone determines behavior.
Who should own the system prompt — the PM or engineering?
The PM should own the decisions encoded in it (scope, refusals, tone, escalation, output contract); engineering should own the implementation and technical constraints (token limits, model quirks, latency trade-offs). Ownership without review rights on either side is where incidents come from.
How do you test whether a system prompt actually enforces a PRD requirement?
Test it the way you'd test acceptance criteria: write five to ten adversarial phrasings of the request the requirement is meant to block, run them against the live prompt, and check that the refusal (or behavior) holds every time, not just on the obvious phrasing. If it only holds for the exact wording you tested during the demo, it isn't enforced.
Can end users see the system prompt?
Not by default, but it can often be extracted through prompt-injection or persistent questioning, which is why researchers like Simon Willison treat it as a security surface rather than a private implementation detail. Write it assuming it may eventually be read by a curious or adversarial user.
What's the difference between a system prompt and a guardrail?
A system prompt is the model's own instructions for how to behave; a guardrail is typically an external check — a classifier, filter, or rule engine — that inspects input or output independently of what the model was told. Mature systems use both, because a system prompt alone is an instruction, not an enforcement mechanism.