Content Boundaries & Schema Design

Content Boundaries

Across every interface, keep trusted instructions separate from untrusted data -- user input, retrieved documents, tool output. Untrusted content must be delimited clearly (for example, with XML-style tags) so that injected text inside the data cannot be read as an instruction to the model. This is the application-design half of a concern that also shows up as a security requirement: a prompt-injection payload hiding inside a retrieved document or tool result is only dangerous if the application fails to mark it as data rather than instruction.

Schema Design

When an application needs machine-readable output, define a JSON schema and use Structured Output or tool-forcing to get responses that conform to it. The design goal is a schema that is strict but not brittle:

• Strict enough that downstream code can parse the output reliably without defensive guesswork
• Not so brittle that a minor, harmless variation in phrasing or an edge case the schema didn't anticipate causes a hard failure

Getting this balance right is itself a design skill -- an overly rigid schema fails on inputs it should have handled; an overly loose one pushes parsing ambiguity back onto the caller.

Common exam traps

• Assuming any user-supplied or retrieved text is automatically safe to place directly in the prompt without delimiting it -- unsanitized untrusted content is a prompt-injection vector.
• Treating schema strictness as a pure good with no downside -- a schema so rigid it can't tolerate reasonable variation becomes brittle and fails on legitimate edge cases.