liveBook · Manning

Closed-world instruction set

As explained in Prompt Engineering in Practice

A closed-world instruction set explicitly defines permitted behavior, rules out unspecified alternatives, and supplies a predetermined response for disallowed or unsupported requests.

A closed-world instruction set defines an assistant’s permitted task and output, explicitly rules out other behavior, and gives a fixed response when the request or input falls outside that scope. It is more precise than telling an assistant to “be helpful” while asking it to “decline inappropriate requests”: those vague directions leave the boundary open to interpretation. section 10.3.1

Write the instruction set as an operational boundary:

  • State the only authorized job and what input the assistant accepts. section 10.3.1
  • Specify the permitted output and prohibit competing tasks, persona changes, and instructions embedded in input data. section 10.3.1 section 10.4.1
  • Provide an exact fallback for unsupported requests or inputs that lack the data needed for the job. section 10.3.1 section 10.4.1

Code review assistant

A code review assistant accepts code and returns feedback on clarity, correctness, and engineering practices. A request to adopt an unrestricted persona and explain an unrelated attack is outside that job. Instead of debating the request, the assistant replies: “I can only review code for clarity and correctness. Please share the code you'd like me to review.” section 10.3.1

Deployment notification prompt

A deployment notification assistant produces only a message describing a deployment event. Mark external event data with [PAYLOAD START] and [PAYLOAD END], and instruct the assistant to treat text inside as data, not directions. If no recognizable deployment event data is present, return exactly: “No valid deployment data was found in this payload.” section 10.4.1

A closed-world instruction set works alongside delimiters, explicit trust framing, and a strict output format. For ticket triage, restricting the answer to “Priority: [level]” and “Category: [category]” leaves no permitted space for an injected request to disclose routing rules or add commentary. These controls reinforce one another; the instruction set alone should not be treated as a guarantee against injection. section 10.4 section 10.4.2

How Prompt Engineering in Practice covers it

How deep it goes
Develops the technique through explicit task boundaries, prohibited behavior, output restrictions, and exact fallbacks, without describing model internals.
Examples
Uses a code review assistant, a deployment notification bot, and two-line support-ticket triage to demonstrate scope control.
What it assumes
Assumes familiarity with assistant prompts and variable inputs; illustrates trust boundaries and precise constraints through complete prompt examples.
What you can do after
Build it from scratch as a scoped prompt with explicit exclusions and a fallback, then combine it with controls for untrusted input.
How it connects
Combines with prompt injection defenses, delimiter-based separation, explicit trust framing, strict output formats, and minimal context exposure.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Prompt Engineering in Practice. The section links point to the parts of the book it draws on.