How to Get Perfect Result from AI Every Time: Structured Output Prompts That Never Break [Lesson 4]

Learn how to get clean JSON and perfect tables from AI every time. Master schemas, validation rules, and bulletproof formatting with copy-paste templates.

Picture this: you ask an AI to extract product information from a description and return it as JSON. The first time, it works perfectly. The second time, it adds extra commentary before the JSON. The third time, it misspells a field name. The fourth time, it returns a table instead of JSON. You copy the output into your code, and everything breaks.

This is the nightmare of unstructured outputs. When you need clean data that flows directly into your systems, spreadsheets, or databases, “pretty close” isn’t good enough. One extra word, one missing bracket, one inconsistent field name, and your entire workflow stops.

But it doesn’t have to be this way. When you know how to request structured outputs properly, AI models can give you perfect JSON, flawless tables, and consistent formats that work the first time, every time. No manual cleanup, no parsing errors, no frustration.

In this lesson, you’ll learn how to write prompts that produce bulletproof structured outputs. You’ll discover schema lines, strict field rules, validation techniques, and retry strategies that make your AI workflows reliable enough to automate completely.

Big Idea

Structured outputs are fragile by default but become bulletproof when you combine clear schemas, strict rules, helpful examples, and validation checkpoints. The secret is telling the model exactly what breaks and how to avoid it.

Think About The Recipe Card

Imagine you’re creating a recipe database. You need every recipe formatted exactly the same way so your app can read it:

recipe name, prep time in minutes, ingredient list, and step-by-step instructions.

You hire three assistants to help.

Assistant A gets vague instructions: “Write down recipes in an organized way.” They return recipes with different formats every time. One has prep time as “about half an hour,” another says “30 mins,” another just says “quick.” Your app can’t parse any of it.

Assistant B gets better instructions: “Use this format: Name, PrepTime, Ingredients, Steps.” They’re more consistent, but sometimes they add extra notes, sometimes they forget a field, and sometimes they spell “PrepTime” as “Prep Time” with a space. Still breaks your app.

Assistant C gets a complete template with an example recipe, strict rules (”PrepTime must be a number in minutes, no text”), and a validation checklist (”Check: all four fields present, PrepTime is numeric”). They return perfect recipe cards every single time. Your app processes them automatically with zero errors.

The same principle applies to AI outputs. Generic requests produce messy data. Clear templates with examples help. But templates and examples plus strict rules plus validation create bulletproof structured outputs.

How It Works: The Four Layers of Structure

Layer 1: Schema Lines (The Foundation)

A schema line is a clear definition of exactly what fields you want and what type of data each field should contain.

Weak schema: “Return the information as JSON.”

Strong schema: “Return a JSON object with these exact fields: name (string), age (integer), email (string), active (boolean).”

The strong schema names each field, specifies the data type, and makes it impossible for the model to guess what you want.

Example of schema line in a prompt:

Extract customer information and return ONLY a JSON object with these fields:
- firstName: string (customer’s first name)
- lastName: string (customer’s last name)  
- email: string (valid email address)
- phone: string (10 digits, format: XXX-XXX-XXXX)
- orderTotal: number (dollar amount without $ symbol)
- isPremium: boolean (true if premium customer, false otherwise)

This schema tells the model the field names (exact spelling), the data types, and even the format for specific fields like phone numbers.

Layer 2: Strict Field Rules (The Guardrails)

Schema lines tell the model what to include. Field rules tell it how to format each piece of data and what to avoid.

Common field rules:

For strings:

• “Use title case for names”

• “No quotation marks around the string value inside JSON”

• “Maximum 50 characters”

• “Use empty string “” if value not found, never use null or N/A”

For numbers:

• “Return as integer with no commas or decimals”

• “Use 0 if value not found, never use null or empty string”

• “Currency values should be numbers only, no $ symbol”

For booleans:

• “Use true or false only, never yes/no or 1/0”

• “Use false as default if uncertain”

For arrays:

• “Return empty array [] if no items found”

• “Each item should be a string in quotes”

• “Maximum 10 items”

Example of strict rules in a prompt:

Field formatting rules:
- All field names must match schema exactly (case-sensitive)
- Use empty string “” for missing text fields, never null or “N/A”
- Use 0 for missing numeric fields, never null or empty string
- Phone numbers must be 10 digits with format XXX-XXX-XXXX
- Boolean fields must be true or false, never 1/0 or yes/no
- Do NOT add any fields not in the schema
- Do NOT include any text before or after the JSON object

These rules prevent the most common errors that break parsers: inconsistent null handling, wrong data types, extra fields, and surrounding text.

Layer 3: Example First, Then Rules (The Pattern)

Showing one perfect example before stating rules dramatically improves consistency. The model sees the target, then reads the rules that create that target.

Structure:

1. Schema definition

2. One perfect example output

3. Strict rules

4. Input to process

Example of this pattern:

Extract contact information from the text below and return as JSON.

Schema:
{
  “name”: “string”,
  “email”: “string”, 
  “phone”: “string”,
  “company”: “string”
}

Perfect example output:
{
  “name”: “Sarah Johnson”,
  “email”: “sarah.j@techcorp.com”,
  “phone”: “415-555-0123”,
  “company”: “TechCorp”
}

Strict rules:
- Output ONLY the JSON object, no other text
- Use empty string “” if any field is missing
- Phone format must be XXX-XXX-XXXX
- Match field names exactly as shown in schema

Now process this text:
[input text here]

The model sees the perfect example first, understands the desired structure, then reads the rules that explain why it’s formatted that way.

Layer 4: Validation and Retries (The Safety Net)

Even with perfect prompts, occasional errors happen. Building validation into your workflow or application catches errors before they cause problems.

Validation approaches:

1. JSON validation (basic) Check if output is valid JSON that can be parsed.

python

import json

try:
    data = json.loads(model_output)
    # Valid JSON, proceed
except json.JSONDecodeError:
    # Invalid JSON, retry with stricter prompt

2. Schema validation (better) Check if JSON has all required fields with correct types.

python

required_fields = [”name”, “email”, “phone”, “company”]
for field in required_fields:
    if field not in data:
        # Missing field, retry

3. Business logic validation (best) Check if values make sense for your use case.

python

if len(data[”phone”]) != 12:  # Should be XXX-XXX-XXXX
    # Invalid phone format, retry
if “@” not in data[”email”]:
    # Invalid email, retry

Retry strategy:

When validation fails, don’t just run the same prompt again. Add a repair instruction:

The previous output had this error: [specific error]
Please fix it and return ONLY the corrected JSON object.
Remember: [state the specific rule that was broken]

This targeted retry works much better than simply rerunning the original prompt.

JSON That Never Breaks: The Complete Template

Here’s a bulletproof template for JSON extraction:

You are a data extraction specialist. Extract information from the text below and return ONLY a valid JSON object.

Schema (required fields with types):
{
  “fieldName1”: “string”,
  “fieldName2”: “number”,
  “fieldName3”: “boolean”,
  “fieldName4”: [”array”, “of”, “strings”]
}

Perfect example output:
{
  “fieldName1”: “example text”,
  “fieldName2”: 42,
  “fieldName3”: true,
  “fieldName4”: [”item1”, “item2”]
}

Strict formatting rules:
- Output ONLY the JSON object, no preamble or explanation
- Match field names exactly (case-sensitive)
- Use empty string “” for missing text fields
- Use 0 for missing numeric fields
- Use false for missing boolean fields
- Use empty array [] for missing array fields
- Do NOT add any fields not in the schema
- Do NOT include markdown code fences or backticks
- Do NOT include the word “json” before the output
- Ensure all strings are in double quotes
- Ensure proper comma placement between fields

Text to process:
[input text here]

This template combines all four layers: clear schema, strict rules, perfect example, and explicit instructions about what NOT to do.

Tables That Never Break: The Complete Template

Tables are simpler than JSON but still need strict rules. Here’s the pattern:

You are a data organizer. Create a table from the information below.

Table structure:
| Column1 | Column2 | Column3 |
|---------|---------|---------|
| value1  | value2  | value3  |

Example output:
| Name | Age | City |
|------|-----|------|
| Sarah | 28 | Seattle |
| Mike | 34 | Boston |

Strict formatting rules:
- Use markdown table format exactly as shown
- Include header row with column names
- Include separator row with dashes
- Align columns with pipe characters |
- One row per entry
- Use “N/A” for missing values (not empty cells)
- Do NOT add any text before or after the table
- Do NOT add explanations inside table cells
- Do NOT skip the separator row

Data to organize:
[input data here]

Advanced Technique: Refusal on Low Confidence

Sometimes the input doesn’t contain the data you need. Teaching the AI model when NOT to try prevents garbage outputs.

Add a refusal rule:

Refusal rule:
If any required field cannot be determined from the text with high confidence, return this exact error object instead:
{
  “error”: “insufficient_data”,
  “message”: “Cannot extract required fields from input text”,
  “missing_fields”: [”list”, “of”, “fields”, “that”, “are”, “missing”]
}

This prevents the model from guessing or hallucinating data when it should admit uncertainty.

Real-World Examples

Example 1: Product Information Extraction

Task: Extract product details from descriptions for e-commerce database.

You are a product data extractor. Extract product information and return ONLY valid JSON.

Schema:
{
  “productName”: “string”,
  “price”: “number”,
  “category”: “string”,
  “inStock”: “boolean”,
  “features”: [”array of strings”]
}

Example output:
{
  “productName”: “Wireless Bluetooth Speaker”,
  “price”: 79.99,
  “category”: “Electronics”,
  “inStock”: true,
  “features”: [”Waterproof”, “20-hour battery”, “360-degree sound”]
}

Rules:
- price must be a number without $ symbol
- category must be one word title case
- features array must contain 3-5 items
- Use false for inStock if not mentioned
- Output ONLY the JSON, no other text

Product description:
[paste description here]

Example 2: Meeting Notes to Action Items Table

Task: Convert meeting transcript to action items table.

You are a meeting assistant. Extract action items and create a table.

Table format:
| Action | Owner | Due Date | Priority |
|--------|-------|----------|----------|

Example:
| Action | Owner | Due Date | Priority |
|--------|-------|----------|----------|
| Review Q2 budget | Sarah | 2025-06-15 | High |
| Update website copy | Mike | 2025-06-20 | Medium |

Rules:
- Include header and separator rows
- Due Date format: YYYY-MM-DD
- Priority must be: High, Medium, or Low
- Use “Unassigned” if no owner mentioned
- Use “TBD” if no due date mentioned
- Sort by priority (High first)
- Maximum 10 rows

Meeting transcript:
[paste transcript here]

Example 3: Email Parsing with Validation

Task: Parse customer emails for support ticket system.

You are an email parser. Extract key information and return valid JSON.

Schema:
{
  “senderName”: “string”,
  “senderEmail”: “string”,
  “subject”: “string”,
  “category”: “string”,
  “priority”: “string”,
  “summary”: “string”
}

Example:
{
  “senderName”: “John Smith”,
  “senderEmail”: “john@email.com”,
  “subject”: “Refund request for order #12345”,
  “category”: “Billing”,
  “priority”: “High”,
  “summary”: “Customer requests refund for damaged item in order 12345”
}

Rules:
- category must be one of: Billing, Technical, Shipping, General
- priority must be: Low, Medium, High, Urgent
- summary must be under 100 characters
- Use “General” for category if unclear
- Use “Medium” for priority if unclear
- Output ONLY JSON

Refusal rule:
If email doesn’t contain enough information to determine category and priority, return:
{
  “error”: “insufficient_data”,
  “message”: “Cannot classify email with confidence”
}

Email to process:
[paste email here]

Why It Matters

Structured outputs are the bridge between AI conversations and real automation. When you can reliably get clean JSON or perfect tables, you can:

• Feed AI outputs directly into databases without manual cleanup

• Build automated workflows that run 24/7 without breaking

• Process hundreds or thousands of items consistently

• Trust the data enough to make business decisions

• Save hours of manual data entry and reformatting

The difference between a prompt that “kind of works” and one that “always works” is often just these four layers: clear schema, strict rules, good examples, and validation. Master this once, and you unlock true automation potential.

Key Takeaways

• Structured outputs need four layers: schema, rules, examples, and validation

• Schema lines define exactly what fields and data types you want

• Strict field rules prevent common formatting errors and inconsistencies

• Showing one perfect example before rules dramatically improves consistency

• Always specify how to handle missing data (empty string, 0, false, etc.)

• Tell the model what NOT to do (no extra text, no markdown fences, no null values)

• Validation catches errors before they break your systems

• Retry with targeted repair instructions when validation fails

• Refusal rules teach the model when to admit uncertainty instead of guessing

• The order matters: schema, example, rules, then input

Mini Exercises

Exercise 1: Write a JSON extraction prompt

Create a prompt to extract book information (title, author, year, genre, rating) from book descriptions. Include schema, example, and rules.

Exercise 2: Add refusal rules

Take your prompt from Exercise 1 and add a refusal rule for when the description doesn’t contain a rating. What should the error output look like?

Exercise 3: Build a table prompt

Write a prompt to convert a list of employees (name, department, hire date, remote status) into a markdown table. Include example output and formatting rules.

Exercise 4: Test and validate

Run your JSON prompt from Exercise 1 on 3 different book descriptions. Check if the outputs parse correctly. If any fail, identify which rule was broken and strengthen your prompt.

Exercise 5: Create a repair prompt

Imagine your JSON output has this error: phone number includes letters instead of just digits. Write a repair prompt that fixes this specific error without rerunning the entire extraction.

Success check: Your prompts should produce outputs that parse correctly 100% of the time on the first try. If they don’t, add more specific rules or better examples.

Next Lesson

You now know how to get perfect structured outputs that flow directly into your systems. In the next lesson, we’ll explore reasoning prompts that improve factual accuracy and step-by-step problem solving.

You’ll learn how to make AI models think before they answer, break down complex tasks into steps, and verify their own work for fewer errors and more reliable results.

For now, practice writing structured output prompts for your real work tasks. Create templates you can reuse. Build validation into your workflows. And remember: the extra five minutes you spend writing strict rules saves hours of manual cleanup later.

---

The difference between prompts that work once and prompts that work every time? Strict rules, clear examples, and zero ambiguity.