Structured Prompting

Move from prose-only prompts to reliable, machine-readable outputs and safely bounded tool requests.

Intermediate20 minute guide + labReviewed July 25, 2026

What You Will Be Able to Do

Define an output contract with fields, types, constraints, and failure behavior.
Separate model-generated arguments from application-controlled execution.
Validate JSON before using it in code, databases, messages, or tools.
Recover safely from malformed, incomplete, or unsupported output.

The Contract-First Pattern

Natural language is useful for exploring ideas. Software integrations need a contract. Define what valid output means before asking a model to generate it.

State the task

Describe the decision or transformation, supplied evidence, and what the model must not infer.

Define the schema

Name required fields, data types, allowed values, length or range constraints, and whether extra fields are forbidden.

Define uncertainty

Allow values such as null, an evidence list, or a status field. Never force the model to invent missing facts merely to satisfy a schema.

Validate outside the model

Parse and validate in deterministic code. Reject or repair invalid output before it crosses a trust boundary.

Fragile

Read this request and tell my system what to do.

Contract-first

Extract only facts present in REQUEST. Return JSON with request_type (one of refund, exchange, question), order_id (string or null), and needs_human_review (boolean). Use null for missing facts. Do not include other keys.

Prefer provider-enforced schemas when available. “Return JSON” is an instruction; schema-constrained output can provide stronger formatting guarantees. Neither guarantees that values are true.

Tool Calls Are Proposals, Not Permission

Function calling lets a model propose a tool name and structured arguments. Your application—not the prompt—must decide whether the action is authorized.

Layer	Responsibility	Example control
Model	Select a permitted tool and draft arguments	`lookup_order({"order_id":"A104"})`
Validator	Check name, types, ranges, and unexpected fields	Reject an unknown tool or malformed ID
Authorization	Confirm the user may perform this action	User can read only their own order
Execution	Apply timeout, limits, idempotency, and logging	A retry cannot create two refunds
Approval	Pause before consequential writes	A person confirms a payment or deletion

Never execute generated SQL, shell commands, HTML, URLs, or tool arguments without controls appropriate to that sink. Structured output reduces ambiguity; it does not make output trusted.

Design for Failure and Recovery

Invalid syntax

Parsing fails. Retry once with the validation error or use schema-constrained generation; then route to a fallback.

Valid shape, false value

A schema cannot verify reality. Check IDs, calculations, citations, and business rules against authoritative systems.

Missing evidence

Accept explicit uncertainty. Route high-impact or incomplete cases to a person instead of filling gaps.

Version change

Version prompts and schemas together. Run a representative evaluation set before changing models or production prompts.

Interactive JSON Contract Lab

This lab runs entirely in your browser. Define required fields, load sample output, edit it, and validate syntax and top-level keys. It teaches the boundary between “valid JSON” and “valid for this task.”

Required fields (comma separated)

Candidate model output

Validation checklist

Output parses as one JSON object.
Every required top-level field exists.
No unexpected top-level fields appear.
Values still need type, range, evidence, and policy checks in production.

Select “Validate output” to inspect the candidate.

Not yet validated.

Practice: Build a Safe Extraction Contract

Choose a low-risk document such as a fictional support request.
Define 3–6 fields, types, allowed values, and how missing information is represented.
Create five examples: normal, missing field, conflicting values, irrelevant text, and malicious instructions inside the document.
Run the prompt, validate output, and record each failure.
Revise the contract—not just the wording—then retest all five cases.