Structure for Reading, Prose for Writing: markup helps a model read a document, but it wrecks the writing

If you're giving a model a document so it can find data in it — format it as structure (XML tags, tables, nested lists). If you're giving a model notes, a brief, or instructions that it needs to write a text from — leave them as plain prose. Mix the two modes, and the model starts writing worse.

The reason is that structure changes what the model treats as the grammatical subject of the sentence. When a brief was wrapped in <requester>...</requester> tags, the requester named in the tag literally became the subject of the sentence — and almost every model response started sounding like "The requester demands..." instead of just answering the point. The share of responses that actually addressed the substance, rather than restating the question, dropped by nearly a third to a half once the exact same instructions were converted from text into tags.

The fix is simple: split the roles of your markup. Source material meant for reading goes into structure. Instructions meant for writing stay in prose. And if you need to kill a specific bad habit the model has (like opening every answer by restating the question) — don't ban it with a blunt instruction. Give the model a self-check instead: write the sentence, cross out anything copied from the question, and if nothing is left, rewrite it from scratch.

Method Blueprint

PART 1 (material meant for reading — document, requirements, table):
→ Format it as markup (tags, nested lists, a table)
→ The model reliably finds the right items and doesn't mix up neighboring fields

PART 2 (material meant for writing — brief, positioning, tone):
→ Leave it as prose, no tags
→ The model writes naturally, instead of dragging the source's structure into its own style

SELF-CHECK STEP (for every written response):
1. Write the first sentence of the answer
2. Strip out anything that just echoes the wording of the question
3. If nothing concrete is left → rewrite it from scratch

It all happens in a single prompt: the structure is set by the format of the input data, and the self-check is a separate instruction inside that same request.

Applied Example

Task: A digital agency is drafting a response to a major brand's brief — say, a pitch to run social media for a coffee chain. There's a brief with the client's requirements (a 15-point list: tone of voice, KPIs, budget constraints) and the agency's internal notes on positioning and past case studies.

Prompt:

You have two types of material.

1. CLIENT REQUIREMENTS (a document to read — use markup so you can find each point precisely):
<requirements>
  <item id="1">Describe how you'll handle the brand's TikTok communication</item>
  <item id="2">State the expected engagement KPI for the quarter</item>
  <item id="3">Describe your experience with coffee chains or similar formats</item>
</requirements>

2. OUR NOTES (for the style and content of the answer — plain text, no tags):
We've worked with three coffee chains over the past two years, averaging 40% growth
in engagement. Our style is friendly, no corporate jargon. We lean on UGC content
and local influencers rather than paid ads.

Task: write a response to each requirement, using the facts and tone from the notes.

After writing a response to a point, check yourself:
- write the first sentence
- cross out anything that just echoes the client's wording from the requirement
- if nothing concrete is left after that, rewrite the sentence so it
  answers the point directly

Result: The model produces three responses tied precisely to each requirement (no mixing up KPIs with experience), written in the agency's own voice instead of corporate boilerplate like "The client requires a description of TikTok communication." The opening sentences answer the substance right away instead of restating the question.

Why It Works

Models are bad at separating "what I need to find" from "what I need to repeat." When writing instructions are wrapped in tags, the model treats the tag (say, "requester") as the most salient word in the text and naturally makes it the subject of every sentence. That's where the same stiff, boilerplate phrasing comes from instead of a direct answer.

But for lookup tasks, the model uses structural boundaries beautifully — a tag or a table cell clearly marks "one chunk of meaning starts and ends here," so the model doesn't confuse neighboring fields.

The method keeps these two modes in separate parts of the prompt: structure where the model needs to find something; and an explicit instruction that style and content should come from the prose, not from the tags.

Levers you can pull: - Source format (structured vs. plain) → only structure the material the model needs to look things up in, not the material it needs to write from. - How you ban a phrase → don't write "don't start like this" — give the model a self-check instead ("write it, strike the copied part, rewrite"). A blunt ban just shifts the problem to a neighboring phrasing. - Naming specific banned phrases → this works, but only as a second layer, after the self-check, and only with an example attached — otherwise the leftover errors cluster exactly around the named forms. - Framing your examples ("this is a form to emulate, not text to copy") — nearly eliminates word-for-word copying of the example.

Prompt Template

You have two types of material.

1. MATERIAL TO READ ({document with requirements/questions}) — use markup
so you can find each point precisely:
<items>
  <item id="1">{requirement 1}</item>
  <item id="2">{requirement 2}</item>
</items>

2. MATERIAL TO WRITE FROM ({brief, style notes, facts}) — plain text, no markup:
{prose notes}

Task: write a response to each item in the material to read,
using the facts and style from the material to write from.

A past example ({sample text}) is a form to emulate, not text to copy.

After each response, check yourself:
- write the first sentence
- strike out anything that echoes the wording of the original item
- if nothing concrete is left, rewrite the sentence so it
  answers the point directly

Fill in: {document with requirements} — what needs to be found precisely and covered; {prose notes} — facts, tone, positioning; {sample text} — a style reference, if you have one.

🚀 Quick start — paste into the chat:

Here's a template for the "structure for reading, prose for writing" technique. Adapt it to my task: {your task}.
Ask me questions to fill in the fields.

[paste the template above]

The LLM will ask what your document with requirements is (what needs to be found) and what your style notes are (what to write from) — because the method only works if these two materials aren't tangled together into one structure.

Limitations

⚠️ Not a top-tier model: the experiment was run on an open mid-sized model (up to 200 billion parameters). The authors flag directly that on a top-tier model, rigid structure and multi-step checks might actually backfire — what "keeps a weak model on the rails" can "put handcuffs" on a strong one. This wasn't tested in the paper, but it's named as the weakest point of the findings.

⚠️ A blunt ban doesn't remove the problem, it concentrates it: if you just tell the model "don't write it that way," the leftover errors will cluster almost entirely around the exact forms you named. You need a behavioral self-check first, and naming specific phrasings should only be a second, targeted layer.

⚠️ The method hits different tasks differently: for short, simple one-line instructions the effect may barely register — the asymmetry is strongest when instructions are long and involve multiple entities (like the 150,000+ character brief used in the study).

How It Was Studied

The team took a real, working system that writes tender proposals for an organization in Australia/New Zealand, and compared its answers against proposals the same organization had submitted by hand. Another LLM served as the quality judge, scoring not for text overlap but for substance. On one tender, the system wrote blind — with zero ready-made examples to draw on — and its answers were rated as good as or better than the human-written ones in 73% of sections, with nearly every gap explained not by writing quality but simply by the system lacking information the human author had access to.

They separately tested three reading tasks (routing comments to questions, extracting cells from a table, parsing an old proposal) — markup improved all three. Then they applied that exact same markup to writing instructions — and answer quality dropped by nearly a third. That's the study's central contrast: the very same technique (wrapping text in tags) helps in one direction for reading and hurts in the opposite direction for writing.

The design is honest: the authors separately classified every gap versus the human answer as either "the model lacked data" or "the model wrote worse," instead of lumping everything under generation quality. That's a rare methodological detail that makes the findings more trustworthy than the usual "the model scored X%."

Resources

Structure for Reading, Prose for Writing: Asymmetric Structural Conditioning in Multi-Agent Document Authoring — Cheng Yu, Nikhil Mathew, Zhengjie Wang, ML Research Labs, Canberra, Australia (supported by Trellis Data).