Specification, not incantation

High-quality prompting · 7 min read

Lesson 40 of 60
In this module

Prompting is widely taught as a collection of tricks. Say "you are an expert". Offer a tip. Threaten a consequence. Most of this is folklore: it circulates because someone once got a better answer after doing it, which is not evidence when the same input produces different output on different runs.

The useful frame is duller and works. A prompt is a specification. You are writing down what you want, what the system needs to know in order to produce it, what it must not do, and what shape the answer should take. Everything that improves prompts improves them by making the specification more complete or more precise.

The four things worth stating

Task. One sentence, in the imperative, naming the actual operation. "Summarise" and "extract" and "classify into these five categories" are operations. "Help me with this document" is not.

Context. The material the answer depends on, supplied rather than assumed. This is where most weak prompts fail, and it is also where most data protection incidents start, which makes it the item requiring the most thought rather than the most text.

Constraints. What the answer must respect. Length. Vocabulary. Jurisdiction. What to do with missing information, which is the single highest-value constraint you can add, because the default behaviour of a fluent system given insufficient input is to produce a fluent answer anyway.

Output format. The shape you will actually consume. If the answer feeds a spreadsheet, say so and name the columns. Format instructions do more work than tone instructions, because a wrongly shaped answer has to be redone and a wrongly toned one can be edited.

Why longer is not better

Long prompts fail in two specific ways that have nothing to do with any model's limits.

First, they accumulate contradictions. A prompt grown over six weeks by four people contains "be concise" in paragraph two and "cover every relevant consideration" in paragraph nine. Whichever the system follows, someone is unhappy, and nobody can say which instruction is responsible.

Second, they hide the useful part. When a prompt works, the team wants to know why, so it can be reused. If the prompt is eight hundred words of accumulated ritual, nobody can isolate the part that mattered, so the whole thing gets copied, contradictions included, into the next use case.

The practical test is subtractive: remove a sentence and see whether the output gets worse. Teams almost never do this, and it is the only way to find out what is load-bearing.

Context is where the risk is

What you paste is what leaves. Under the revised Swiss Federal Act on Data Protection, the Article 6 principles apply to that processing: lawfulness, good faith, proportionality, purpose limitation and accuracy. Proportionality is the one prompting habits fail. Pasting a whole case file because it was easier than extracting the relevant paragraph is a proportionality problem even if the answer is good. Article 19 requires people to be told on collection about the purposes and recipients, and where data goes abroad, the state and the safeguard relied on.

There is a second risk, and it is not a privacy one. Text you supply as context is text the system will treat as input, including instructions hidden inside it. Prompt injection is catalogued in the OWASP Top 10 for Large Language Model Applications 2026, and in agentic settings the related failure modes appear in the OWASP Top 10 for Agentic Applications 2026, published 9 December 2025, which lists among others ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation and ASI06 Memory and Context Poisoning. If your prompt pipeline pastes in a document a third party controls, the third party is writing part of your prompt.

What good practice looks like at an individual level

  • State the task as an operation, not a wish.
  • Supply the minimum context that makes the task answerable, and no more.
  • Say explicitly what to do when the input does not support an answer.
  • Name the output shape.
  • Delete anything you cannot justify when you re-read it next week.

None of this is a compliance requirement. It is what makes the output checkable, and checkability is the precondition for everything in the next lesson.

As of 24 September 2026.

Sign in to save your progress

You can read every lesson without an account. Signing in keeps your place and unlocks the assessment.