Writing Pages a Model Can Quote Accurately

A retrieval system does not hand a model your page. It hands over two or three hundred words cut from the middle of it, with no title, no preceding paragraph and no way to look anything up. Prose that reads well top to bottom can be meaningless in that form, and the repairs are sentence-level and unglamorous.

The unit of retrieval is a passage

Retrieval pipelines split documents into chunks before they score anything, because scoring a whole document against a specific question buries the relevant sentence in ten thousand irrelevant ones. Typical chunk sizes are a few hundred tokens with a small overlap. The arithmetic is worth internalising:

chunk size        600 tokens
chars per token   ~4 for English prose
                  ------------------------
chunk in chars    ~2,400
chunk in words    ~380
                  ≈ three to four ordinary paragraphs

So a section that answers one question in under about four hundred words has a good chance of arriving whole. A section that takes twelve hundred words to get to the answer will be split, and the split does not respect your argument — the standard splitters cut on character counts, paragraph breaks or headings, in that order of crudeness. The reader of the middle chunk sees neither the setup nor the conclusion. More on the structural side of this in chunking strategies and what chunk boundaries do to meaning.

The rule that follows is simple and it is the whole page: every paragraph should be readable by somebody who has read no other paragraph. That is a stronger constraint than good writing normally imposes, and it costs a small amount of repetition.

Six ways a sentence loses its subject

• An unresolved pronoun at the start of a paragraph. “It also fails when the token budget is small.” What does?
• A back-reference to structure. “As mentioned above”, “the second approach”, “this method” — all of which point at text that is not in the chunk.
• A list item that only makes sense under its stem. “Faster, and cheaper per request” is not a sentence anywhere else.
• A number without its unit or its subject. “About 40% in our testing” is unquotable and, worse, quotable wrongly.
• A conditional whose antecedent is elsewhere. “In that case, use the batch endpoint.” Which case?
• A definition that never repeats the term. A section introducing an acronym once and then using only the acronym is a section whose later chunks are about an unexplained string.

None of these is a writing error under ordinary rules. All of them are fatal to a passage that travels alone.

Before and after

Eight rewrites. In each case the after is a few words longer and works without its neighbours.

1. Resolve the pronoun

BEFORE
  It only applies to requests that already carry an idempotency key.

AFTER
  Automatic retry only applies to requests that already carry an
  idempotency key.

2. Kill the structural back-reference

BEFORE
  The second option above is usually the right one for batch jobs.

AFTER
  Queueing the request and polling for the result is usually the right
  choice for batch jobs.

3. Give the list item a subject

BEFORE
  Advantages of the streaming endpoint:
  - Lower time to first token
  - No timeout at 60 seconds

AFTER
  Advantages of the streaming endpoint:
  - The streaming endpoint returns a first token in well under a second,
    against several seconds for the buffered endpoint.
  - Streaming responses are not subject to the 60-second gateway
    timeout, because bytes keep arriving.

4. Attach the number to its subject, unit and date

BEFORE
  This cut latency by about 40%.

AFTER
  Moving the embedding step out of the request path cut median
  end-to-end latency from about 900 ms to about 540 ms in this
  configuration, measured on the setup described in the previous
  section.

5. Restate the condition

BEFORE
  In that case, raise max_tokens.

AFTER
  If the response is being cut off mid-sentence with a finish reason of
  length, raise max_tokens.

6. Repeat the term, not the acronym

BEFORE
  TTFT is the number that decides whether the interface feels alive.

AFTER
  Time to first token — the delay before the first character of the
  answer appears — is the number that decides whether the interface
  feels alive.

7. Put the answer in the first sentence of the section

BEFORE
  There are several things to weigh here. Cost matters, and so does
  latency, and the answer depends on your traffic shape. Broadly,
  though, most teams end up caching the system prompt.

AFTER
  Cache the system prompt. It is the largest block of tokens that is
  identical across requests, which is exactly the condition prompt
  caching pays for. The rest of this section is when that is wrong.

8. Make the heading a claim, not a label

BEFORE
  ## Considerations

AFTER
  ## Why retries make duplicate charges more likely, not less

Answer first, qualify second

The ordering rule deserves its own section because it is the one that conflicts with how technically careful people naturally write. The instinct is to establish the caveats before stating the conclusion, so that nobody misreads it. In a chunked world that instinct produces passages whose first two hundred words are hedges and whose conclusion fell into the next chunk.

Invert it. State the answer, then narrow it. “Use a 300-token chunk for FAQ content. That figure comes from the length of a complete question-and-answer pair; for reference documentation, where a single concept can run to a page, it is too small.” The claim and its scope are now in the same two sentences, which is the smallest unit that can be quoted without distortion.

This is also the format that survives the failure mode described in why models produce confident wrong answers: a hedge that arrives after the claim is a hedge that can be dropped. A scope that is inside the same sentence as the claim cannot be.

Numbers need their units and their date

A number is the most quotable thing on a page and therefore the most dangerous. Any figure you want quoted correctly needs four things in the same sentence: what it measures, its unit, its condition, and when it was true.

WEAK     Throughput roughly doubled.

STRONG   Throughput rose from about 40 to about 85 requests per second
         on a single 8-core instance after connection pooling was
         enabled, measured in March 2026 against the same synthetic
         workload.

The long version is not padding — it is the difference between a sentence that can be quoted and a sentence that cannot be quoted responsibly. It also protects you: a figure that carries its conditions cannot be repeated as a general claim about your product, which is exactly how numbers get away from their authors.

Tables, lists and code extract badly

Everything above is about sentences. The parts of a page that are not sentences have their own failure mode, and it is easy to see: run an HTML-to-text converter over your page and read what happened to your table.

A two-column table usually survives as alternating lines and is readable. A wide table generally does not: the column headers appear once at the top and the cells appear as a stream of values, so by row four nothing indicates which column a number belongs to. If a fact only exists at the intersection of row seven and column five, it is gone.

WHAT YOU WROTE
  Model       Context   Input $/M   Output $/M   Tools
  alpha-1     200,000   3.00        15.00        yes
  beta-2      128,000   0.50         1.50        no

WHAT A NAIVE EXTRACTOR PRODUCES
  Model Context Input $/M Output $/M Tools
  alpha-1 200,000 3.00 15.00 yes
  beta-2 128,000 0.50 1.50 no

WHAT SURVIVES FOR CERTAIN
  alpha-1 has a 200,000-token context window, costs $3.00 per million
  input tokens and $15.00 per million output tokens, and supports tool
  calling.

The remedy is not to stop using tables — they are better for a human scanning, and that matters more. It is to make sure that any fact you would mind being lost also exists as a sentence somewhere on the page. A table plus a paragraph summarising the two rows that matter costs forty words and is immune to the whole problem.

Three related cases:

• Nested lists flatten. Two levels of indentation become one, and a sub-item that qualified its parent now reads as a sibling that contradicts it.
• Code blocks usually survive intact but arrive with no indication of what they are for. A sentence immediately before each block saying what it does is what makes it quotable, and it is the sentence most often omitted.
• Text in images does not survive at all. A diagram whose labels carry the argument is a diagram whose argument is not on the page. Describe it in prose beneath it, which also happens to be what a screen reader needs.

Headings a chunker can use

Structure-aware splitters cut at headings, which means your headings are chunk boundaries whether or not you intended them to be. Three consequences:

• A descriptive heading becomes the chunk’s title. Many splitters prepend the heading trail to each chunk, so “Notes” adds nothing and “Why the retry loop double-charges” adds the subject back.
• A section with no heading merges into its neighbour. If two topics share one heading, they will be scored as one thing.
• Skipping levels confuses the trail. An h2 followed by an h4 produces a nesting that is wrong in whatever the splitter reconstructs.

The corollary for page planning is in retrieval-friendly site architecture: one question per section, one canonical section per question, and the section short enough to survive intact.

Where this becomes bad writing

Applied without judgement, every one of these rules produces prose that is exhausting to read. A page that names its subject in full in every sentence reads like a legal notice, and a human abandoning your page in the first paragraph is a worse outcome than a chunk that needed one more noun.

The workable compromise: apply the rules hard at the start of each section and at the start of each paragraph, and relax inside them. Those are the positions a splitter is most likely to cut at, and they are also the positions a human scanning the page lands on. The two audiences want the same thing there, which is why this particular optimisation is safe and most of the ones sold alongside it are not.

And the honest caveat: everything on this page is a claim about extractability — whether a passage can be read alone — which you can verify yourself by copying any four hundred words out of your page and reading them. Whether it changes how often an assistant cites you is a different claim, unverifiable at your scale, and this page does not make it.