Stop Writing Prompts Like Prose: Use the Four-Part Contract to Kill LLM Drift

Most so-called "prompt engineering" advice obsesses over word choice, but the real problem is this: people write prompts like they're drafting an email, then act surprised when the model drifts between runs.

Production prompts aren't prose — they're contracts. A contract must explicitly define four things, or the model fills in the blanks with whatever is statistically most likely. That's where drift comes from.

The Four Parts of a Contract

Any prompt that needs to perform consistently should answer these four questions:

1. Role — Who is speaking, and what are they optimizing for?
2. Task — What is the single deliverable? (Not a list — one thing.)
3. Constraints — What must never happen?
4. Output contract — The exact shape of a valid response, and what to do when the input can't be satisfied.

Leave any one of these out, and the model guesses. Guessing is the enemy. The value of this framework isn't cleverness — it's locking down every decision that should be yours before the model makes it differently on each run.

Before: The Prose-Style Prompt

Here's a typical prose-style prompt:

You are a helpful assistant. Summarize the following customer review and tell me
if it's positive or negative and maybe what the main complaint is. Be concise.

Depending on the input, this prompt can fail in at least five different directions — and you can't predict which one. Vague phrases like "be concise" and "maybe" hand all judgment over to the model.

After: The Contract-Style Prompt

ROLE
You extract structured feedback from customer reviews. You optimize for accuracy,
not for making the review sound better.

TASK
Given one review, produce a single JSON object classifying sentiment and listing
complaints.

CONSTRAINTS
- Never invent a complaint that is not present in the text.
- Never output anything except the JSON object. No preamble, no markdown fence.
- If the review is not about a product, set "relevant": false.

OUTPUT CONTRACT (strict)
{
  "relevant": boolean,
  "sentiment": "positive" | "neutral" | "negative",
  "complaints": string[],
  "confidence": number
}
If you cannot comply, output {"error": "<short reason>"}.

The second prompt is longer — and that's exactly the point. Every extra line is a decision you made once, rather than letting the model make a different decision every run. The length buys you determinism.

The Output Contract: The Part Everyone Skips

A schema without an escape hatch causes a very specific failure mode: when the input doesn't fit, the model fabricates content to satisfy the schema. It would rather return a correctly shaped but factually wrong object than admit failure.

The fix is to explicitly define a failure shape (e.g., {"error": ...}) and enforce it in code:

import json

REQUIRED = {"relevant", "sentiment", "complaints", "confidence"}

def validate(raw: str) -> dict:
    obj = json.loads(raw)
    if "error" in obj:
        raise ValueError(obj["error"])
    missing = REQUIRED - obj.keys()
    if missing:
        raise ValueError(f"missing keys: {missing}")
    if obj["sentiment"] not in {"positive", "neutral", "negative"}:
        raise ValueError("bad sentiment")
    return obj

With this in place, "drift" stops being a quietly wrong answer that surfaces three systems downstream, and becomes a loud, catchable exception. This is the fundamental shift from hoping it's right to verifying it's right.

Constraints That Actually Change Behavior

The constraints section is where you win the battle. Weak constraints like "be accurate" do nothing; strong constraints surgically remove specific failure modes:

• "Never invent a complaint not present in the text" → blocks hallucinated details.
• "No preamble, no markdown fence" → stops the model from wrapping JSON in a code block.
• "One deliverable only" → stops the model from answering three questions you didn't ask.
• "If X, do Y" → gives the model a legitimate exit, which reduces fabrication.

Key observation: these constraints are either negations or conditionals. "Be helpful" is unfalsifiable; "never invent" is testable. Testability is what determines whether a constraint actually works.

Common Pitfalls

Test the contract, not your gut feeling. Keep 20–50 input/expected-output pairs and run them every time you change the prompt. A change that "feels better" can silently break 10% of your cases.

Don't over-constrain the reasoning process. If the task requires thinking, give the model room — just don't let that thinking leak into the output. Use a two-call pattern: one call for reasoning, one for formatting.

Version your prompts like code. A prompt is a dependency. If it's not in git with a changelog, you can't roll back regressions.

One contract, all providers. If you're failing over between models, the output contract is exactly what ensures their responses are interchangeable.

Why This Matters

The gap between a demo-quality prompt and a production-quality prompt isn't cleverness — it's explicitness. A contract you can validate is a prompt you can actually ship, monitor, and debug. Everything else is just hoping for the best.

The core insight of this methodology: treat prompts as a software engineering artifact — with a defined interface, validation, version control, and a test suite. Once you start thinking in contracts rather than prose, the stability of your LLM outputs changes fundamentally.