Requested Style Conflicts With Requested Output Format

You asked for output that is “warm, conversational, and personable” — and also “strict JSON with these exact keys.” JSON has fixed structure. Warmth lives in prose. Asking for both is asking the model to satisfy two contradictory specifications, and what comes back depends on which constraint wins that run: either flat, lifeless JSON that satisfies the schema, or warm prose with JSON-ish tags around it that breaks your parser. The model is not failing to find the middle ground. There is no middle ground between strict structure and unconstrained prose.

Fastest fix: decide who reads the output first. If a parser reads it first, drop “warm” from the prompt and turn on real schema enforcement at the API level (response_format: json_schema with strict: true on OpenAI, output_format/output_config.format with type: "json_schema" on Claude, responseSchema on Gemini). If a human reads it first, drop the strict JSON and ask for a markdown table plus a short comment. If both must read it, run two passes: prose first, then extract that prose into the schema.

Common causes

1. Warmth requested inside a fixed-key schema

JSON keys are not warm. Enum values are not warm. The only slot for warmth is inside a string-valued prose field, and even there it is bounded by length and surrounding structure.

How to spot it: you asked for JSON and a warm tone in the same instruction.

2. Creative voice plus machine-readable goal

Marketing copy wants creative voice. An ETL pipeline wants machine-readable structure. Serving both in one output sacrifices the strong constraint of each.

How to spot it: the output will be consumed by both humans and a script.

3. No declared winner when they conflict

If you do not say “format wins” or “style wins,” the model averages them. Both consumers end up disappointed.

How to spot it: there is no priority ranking between style and format in the prompt.

4. Strict JSON for tasks where the value is nuance

Asking for “JSON with sentiment as positive/negative/neutral” throws away “frustrated but understanding.” The schema is the bottleneck, not the model.

How to spot it: the JSON shape cannot express what you actually need.

5. Conflicting cues in one prompt

The same prompt says “be conversational” (warmth) and “return only valid JSON” (structure). The model has no way to reconcile them, so it picks one at random per run, which is why the output flips between runs.

How to spot it: both directives are present with no resolution between them.

Which bucket are you in

Symptom you see	Most likely cause	Go to
JSON parses but reads cold and robotic	Warmth requested but schema has no prose field for it	Step 2
Parser throws on a prose preamble like Here is the JSON: or trailing commentary	No API-level enforcement; warmth leaked outside the braces	Step 4, Step 6
Output shape changes every run (sometimes JSON, sometimes prose)	Conflicting cues, no declared winner	Step 1
JSON is valid but loses the meaning you needed	Enum/schema too coarse for the nuance	Step 3 (go human) or widen the field
Extra invented fields appear in the JSON	Model “improving” your schema	Step 4, Step 6

Before you change anything

• Identify your real consumer: a parser, a human, or both.
• If both, decide which is primary (which one breaks if the output is wrong).
• Identify the one value you cannot lose: warmth or structure.
• Decide whether one pass can satisfy both, or whether you need a pipeline.
• Be ready to drop the weaker constraint entirely if necessary.

Information to collect

• The current prompt, with both the style and format requests visible.
• A sample output that fails one constraint or both.
• The downstream consumer (the specific parser, the specific reader).
• Which constraint is non-negotiable.
• The model and any system prompt in play.

Shortest path to fix

Step 1: Decide the primary consumer

Consumer = parser (JSON downstream):
  Format wins. Drop "warm" from the prompt entirely.

Consumer = human reader:
  Style wins. Use markdown (table + commentary) instead of strict JSON.

Consumer = both (display in UI + pipe to analytics):
  Two passes. See Step 5.

Step 2: For a schema with prose fields, scope warmth to those

{
  "category": "billing",
  "priority": "high",
  "summary": "<prose, warm tone, max 50 words>",
  "escalation_needed": true
}

category and priority are strict enums with no warmth, escalation_needed is a boolean, and summary is the one prose field where warmth is allowed. Mark explicitly which fields can be prose and which are mechanical so the model does not spread tone into the structured fields.

Step 3: For human-only output, choose a hybrid format

Markdown table for the structured part:
| Category | Priority | Status |
|---|---|---|
| Billing | High | Needs escalation |

Commentary below the table (where warmth lives):
"The customer is frustrated but understanding — they have been a
loyal user for 3 years. Worth a personal callback rather than a
canned response."

The model produces both halves naturally, and you keep the structure you can scan plus the tone a human wants.

Step 4: Forbid schema bloat in the prompt

Constraints on the JSON:
- Do not add fields not listed in the schema.
- Do not include explanatory comments inside the JSON.
- Do not wrap the JSON in a prose preamble ("Here is the JSON:").
- Return only the JSON object, nothing before or after it.

Models like to “improve” your schema with explanatory fields and to prepend a friendly sentence. Both break a strict parser. Forbid them in the prompt, and enforce them for real in Step 6.

Step 5: Two-pass workflow for both-consumer cases

Pass 1 (content): Generate warm, nuanced analysis as prose.
Pass 2 (structure): Given the prose from Pass 1, extract it into this JSON schema.

Pass 1 captures nuance, Pass 2 enforces structure, and each pass has exactly one job. This is more reliable than one prompt trying to do both, and Pass 2 can run on a cheaper model with structured output mode turned on.

Step 6: Turn on structured output mode at the API level

Prompt instructions ask politely. API-level enforcement makes invalid structure literally impossible, because constrained decoding compiles your JSON Schema into a grammar and blocks any token that would violate it. As of June 2026 all three major providers support real schema enforcement, so prefer this over “please return only JSON” in a prompt:

• OpenAI (GPT-5.5): set response_format to { "type": "json_schema", "json_schema": { "name": "...", "schema": {...}, "strict": true } }. With strict: true, every object in the schema must set "additionalProperties": false and list every property in required. The older {"type": "json_object"} JSON mode only guarantees valid syntax, not your schema, so treat it as legacy. Check the response refusal field, since a refusal returns there instead of schema-shaped content.
• Anthropic (Claude Opus 4.7 / Sonnet 4.6): Structured Outputs went to public beta in November 2025. Send the beta header anthropic-beta: structured-outputs-2025-11-13 and pass output_format (or output_config.format) with type: "json_schema"; every object needs "additionalProperties": false. Claude Code runs Anthropic models only, so this is the path inside that ecosystem.
• Google (Gemini 3.1 Pro): set responseMimeType: "application/json" and pass a schema in responseSchema (an OpenAPI subset) or responseJsonSchema (full JSON Schema). Use one or the other, not both.

With enforcement on, warmth is safely confined to prose fields and cannot break the parser. If you are calling a model from a chat UI rather than the API and have no schema control, fall back to Step 4 plus the two-pass workflow.

How to confirm the fix

• The output parses cleanly downstream with no manual cleanup.
• Prose fields, if any, have the warmth you wanted.
• No schema bloat and no invented fields.
• Running the same prompt 3 times produces 3 outputs of identical shape.
• For OpenAI strict mode, the refusal field is null on a normal run.
• A human reader, if applicable, finds the output acceptable.

If it still fails

1. The two constraints may be fundamentally incompatible. Drop one.
2. Use the two-pass pipeline (Step 5) for any case where both must hold.
3. Switch to API-level structured output (Step 6) if you have not already; prompt-only “return JSON” is unreliable at any temperature.
4. Lower the temperature. Format stability and field-name adherence improve at lower temperatures even when strict mode is off.
5. If strict mode rejects your schema, check that every object sets additionalProperties: false and that every property is in required (OpenAI strict mode treats optional fields as a type union with null).

Prevention

• Treat style and format as separate concerns and rank them before writing the prompt.
• Default: machine consumers get a clean schema with no style ask; human consumers get markdown.
• For mixed-consumer pipelines, split into two passes.
• Reserve “warm JSON” for explicit prose fields, never for keys or enums.
• Enforce schema at the API level rather than asking for JSON in prose, whenever you control the call.
• Audit production prompts for the style-plus-format conflict; most are resolved by removing one of the two.
• When in doubt about the consumer, ask: “what receives this output first?”

Related reading

• Mixed tone instructions
• No output format specified
• AI output style drift
• Conflicting instructions weaken output
• Output polished not actionable

Tags: #Troubleshooting #Prompt #Prompt quality #Style drift

Related Articles

Troubleshooting

Few-Shot Examples Have Uneven Quality and Drag Output Down

You gave the model 5 examples; 2 are great, 3 are mediocre, and it averages toward the mediocre ones. Why example variance hurts and how to curate down to 3-5 consistent ones.

May 24, 2026 #Prompt engineering #Troubleshooting

Troubleshooting

Model Returns Invalid JSON Because Schema Was Described, Not Enforced

You asked for JSON matching a schema. Most calls return valid JSON, some return prose with JSON inside, some omit fields. Description vs enforcement, and how to fix at the API layer.

May 24, 2026 #Prompt engineering #Troubleshooting

Troubleshooting

Model Invented Fake Citations and URLs

The model produced a citation like Smith et al. 2019 and the paper does not exist, or a URL that 404s. Why citation hallucination happens and how to stop it for good.

May 24, 2026 #Prompt engineering #Troubleshooting

Troubleshooting

Model Replies in the Wrong Language (How to Lock It)

You prompted in English and the model answered in Chinese, or it switched mid-output. The exact cause of language drift and the system-prompt + retry pattern that locks the output language, verified June 2026.

May 24, 2026 #Prompt engineering #Troubleshooting

Troubleshooting

LLM Response Cut Off Mid-Sentence: max_tokens Too Low (2026 Fix)

The model's reply ends mid-sentence, mid-JSON, or with an unclosed code block. It is almost always the token cap. How to size it, detect truncation per SDK, and recover.

May 24, 2026 #Prompt engineering #Troubleshooting

Troubleshooting

Prompt Asks for 10 Items, Model Returns 3 and Stops

You asked for 10 ideas and got 3, or 10 slots padded with filler. Why list-length prompts under-deliver, and the prompt + schema fixes that actually get you N distinct items.

May 24, 2026 #Prompt engineering #Troubleshooting