What Is a Prompt Template?
A prompt template is a parameterised prompt: fixed text with named slots that are filled at request time. The template is the artefact — versioned, reviewed, tested — and the string that reaches the request is one rendering of it for one set of values. Nearly everything that makes templates worth having, and everything that makes them dangerous, follows from the fact that rendering is textual substitution.
Rendering, and why the artefact is the template rather than the string
A template holds three kinds of material. Fixed text is the part that is identical on every request. Slots are named positions filled from a binding of names to values. Structural directives — a conditional block, a loop over a list — decide which fixed text appears at all. Rendering resolves all three into a single string, and that string is what the request carries: nothing downstream of the render knows a template was ever involved.
That is exactly why the template is the thing kept under version control and given an identifier. An output is attributable to an input only if the input can be named, and the rendered string is per-request and frequently not retained, a good deal of it being somebody else's data. Recording the template identifier and its version alongside a result keeps the pair recoverable: the fixed half sits in the repository and the variable half is whatever the request already logs. A template edited in place with no version change severs that link for every result recorded on either side of the edit.
Templates are also the rare component in a system built on generation that is testable in the ordinary way, because rendering is a pure function: one binding produces exactly one string, and that string can be asserted character for character in a unit test with no network call in sight. The tests worth writing are about the edges rather than the happy path — what renders when an optional value is absent, when a list is empty, when a value contains the delimiter the template uses to mark its sections. Each of those has a silent wrong answer: the literal word undefined embedded in an instruction, a heading standing over nothing, a section marker appearing where the template did not put one. None of them raises an error.
| Element | The quiet failure |
|---|---|
| Fixed instruction text | Edited without a version change, after which earlier results can no longer be attributed to the text that produced them. |
| Named slot | Bound to a missing value and rendered as an empty string or a literal placeholder, both of which read as ordinary text. |
| Conditional block | Two renderings that differ near the start, which is where a reused opening span stops being reusable. |
| List expansion | An empty list rendering as a heading with nothing beneath it, or a long one consuming the budget the rest of the prompt needed. |
| Delimiter marking a section | A bound value that contains the delimiter, closing a section the template intended to keep open. |
| Whitespace and line breaks | Part of the string, and therefore part of what is tokenized. An indentation change is a change to the input. |
Not one of the six raises an exception. A rendering is a string, and a string that is wrong has the same type as a string that is right — which is the whole reason the version identifier and the edge-case tests are the discipline here, and why a template never rendered against an empty list is a template with an untested branch in it.
The slot is not a boundary
Substitution concatenates. Once a value has been rendered into the template, the resulting string carries no mark separating the author's instructions from the material interpolated between them: both are text, in one channel, arriving together. This is the mechanism behind prompt injection, and putting it as a property of concatenation rather than as a failure to follow instructions is the part that matters, because it explains why the ordinary defences are partial. Delimiters around a slot, an instruction to treat the enclosed material as data, placing untrusted content after the instructions and restating the constraint below it — each narrows the opening, and none of them closes it.
The comparison usually reached for is a parameterised database query, and it is instructive in the opposite direction to the one intended. A parameterised query is safe because the value never enters the statement: the statement is parsed as a statement, the parameter is carried separately and bound as a value, and no content of the value can alter the parse. A prompt has one channel and no parse, so there is nothing for a slot to be separated into. Every mechanism offered as an equivalent — escaping, tagging, provenance markers — operates inside the same channel it is trying to partition.
The practical consequence is that slots should be classified by where their values come from, and that classification should drive what the surrounding system permits rather than what the prompt requests. A slot filled from a configuration file, a slot filled by an authenticated user, and a slot filled with the body of a fetched web page are three different exposures rendered by identical syntax. Whatever protection the third one gets has to live outside the string — in what the tools reached afterwards are allowed to touch, and in what a person is asked to approve — because the string itself has no room in which to say where its parts came from.
How the Registry classifies a prompt template authoring task
Defining a parameterised prompt with named variables and rendering it for each row of an input batch is filed as a code modification task in this registry's classification. The classification follows the deliverable and not its subject matter: what is produced is a template file, a binding step and a set of tests, committed and reviewed exactly as any other source is, whatever the rendered instructions happen to be about.
The Registry's canonical brief for this entry is filed as:
Define a parameterised prompt with named variables and render it for each row of an input batch.
Submitted for assessment it is
classified as Code modification, and its wording is hashed once — to
1b143cfd7a4e5c1c…, the first sixteen of sixty-four hexadecimal
characters — with the wording itself never stored. The hash is what the derivation
reads.
That class's own page is /tasks/code.
Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.
What this page does not claim about prompt template
Which templating syntax renders the slots, how a missing binding behaves in it, and whether the rendered string is retained anywhere at all are decisions belonging to a particular codebase, and the canonical brief above fixes none of the three. This registry renders no operator's template, stores no rendered prompt, and has measured nothing about one wording against another. A task description submitted here is hashed and discarded, which is the same treatment its own inputs receive.
The Registry does not run this task, does not inspect any system's output for it, and validates no assessment it issues against what afterwards happens. What it does is compute — from a published method, for one submitted task and one submitted configuration — a verdict and a recommended execution window. It computes neither on this page.
Questions about prompt template
- What is a prompt template?
- A prompt template is a prompt with named slots filled in at request time. The fixed text and the structure are the versioned artefact; the string that reaches the request is one rendering of that artefact for one set of values.
- Why version a prompt template?
- Because a result is attributable only if its input can be named. The rendered string is per-request and often not retained, so recording the template identifier and version next to a result is what makes the pair recoverable afterwards.
- How is a prompt template different from a system prompt?
- A system prompt is a standing instruction block occupying a position in the request. A template is a mechanism for producing text, and it may well produce the system prompt as well as the user turn. One names where text sits; the other names how the text is assembled.
- Do delimiters around a slot make interpolated input safe?
- They narrow the opening rather than close it. Rendering concatenates, so the interpolated value and the surrounding instructions arrive as one undifferentiated string. A delimiter is a convention inside that string, and a value containing the delimiter is inside it too.
- Why do templates interact with prompt caching?
- Reuse of a cached prefix depends on requests sharing an identical opening span. A slot or a conditional block near the top of a template makes that opening vary from request to request, so the shared span ends where the first variable part begins.
Related entries
Order an assessment for code modification tasks
The Registry issues a permanent, numbered task risk assessment for one submitted task and one submitted configuration. EUR 1.90 Standard, EUR 4.90 Extended, EUR 14.90 Full Chart, which adds the permanent chart. Assessments from EUR 1.90; machine-readable at /pricing.json.