Outlining and Structuring Long Pieces

Ask a model for an outline and you get the average article on that topic, because that is what a most-probable continuation of the title is. Write the claims yourself and use the model to attack them, and you get something the average article does not have.

Why generated outlines are all the same

Give three different models the same title and the outlines will share most of their headings, usually in the same order: a definition, a history, a list of benefits, a list of challenges, some best practices, a look at the future. This is not a failure. It is a correct answer to the question that was asked, which was effectively “what structure usually follows this title?”

The consequence is specific. If you generate the outline and then write against it, you have adopted the structure of every piece you are competing with before writing a word, and the only remaining variable is prose quality — which is the variable machine assistance flattens. The structural decision is where the differentiation was, and it was spent first.

An outline is claims, not topics

A topic outline lists what will be discussed. A claim outline lists what will be asserted. Only the second can be wrong, which is the only reason to have one.

TOPIC OUTLINE (useless)
1. Introduction to prompt caching
2. How prompt caching works
3. Benefits of prompt caching
4. Challenges and considerations
5. Conclusion

CLAIM OUTLINE (an argument)
1. Prompt caching is a prefill optimisation, so it moves time to first
   token and leaves tokens per second unchanged.
2. It therefore does nothing for the latency of long answers, which is
   what most people are actually complaining about.
3. The break-even is about four calls per cached prefix, because a
   cache write typically costs more than an ordinary input token.
4. Which means it pays for shared system prompts and loses for
   personalised ones, and most teams have it the wrong way round.

Write these yourself, one line per claim, in whatever order they occur to you. Fifteen minutes. Do not write prose. The point of the exercise is that the argument is small enough to see all at once, which is the only condition under which you can tell that claim two does not follow from claim one.

Prompt one: the adversary pass

Now the model is useful, because the material is in the context and the job is critique rather than invention.

Below is the skeleton of an argument, one claim per line. You are a
sceptical expert reader who is inclined to disagree.

For each claim, return:
- entailment: does it follow from the claims above it? yes / no /
  "needs a step that is missing"
- objection: the single strongest objection a knowledgeable reader
  would raise, in one sentence. If you cannot think of a real one, say
  "none" rather than inventing a weak one.
- evidence_required: what specific thing would have to be shown for
  this claim to stand — a number, a citation, a worked example, or
  "assertion is sufficient".

Then answer three questions about the argument as a whole:
- What is the strongest claim here that the author has not made?
- Which claim, if false, breaks the most of the rest?
- What would a reader who already believes all of this learn?

Do not rewrite the claims and do not add new ones.

CLAIMS
1. ...

The last of the three questions is the one that earns its keep. If the honest answer is “nothing”, the piece is a summary of the consensus and no amount of drafting will change that. Theevidence_required field is the second most useful, because it produces your research list — and it tends to surface the claim you were planning to assert confidently and cannot actually support.

Expect roughly half of what comes back to be generic. Read all of it and act on the specific half. Instructing the model to return “none” rather than a weak objection cuts the generic share noticeably, for the same reason an explicit abstention option helps anywhere else: without one, the most probable output is always some objection.

Prompt two: the load order

Ordering is a genuine constraint-satisfaction problem and models are reasonable at it. Every claim has prerequisites; the reader must be able to accept each claim when they reach it.

Here are the claims of an article. For each, list the ids of the
claims a reader must already accept before this one can land — its
prerequisites. Then propose an order that satisfies every prerequisite,
and name any cycles you find.

If two orders both satisfy the constraints, prefer the one that states
the most surprising claim earliest.

Return JSON: {"prereqs": {"3": ["1"], ...}, "order": [1,3,2,...],
"cycles": [[2,5]]}

Cycles are the valuable output. A cycle means two claims each depend on the other, which in a draft shows up as a section that keeps forward-referencing another one. The fix is usually to split a claim in two, and finding that by hand takes an afternoon of confused rewriting.

Overriding the proposed order is normal. The tie-break instruction — surprising claim earliest — is there because generated orders default to gentle build-up, and gentle build-up is how you lose a reader who is scanning.

The one-sentence test

Before any prose exists, write one sentence per section stating what that section establishes. Then read the sentences in sequence, ignoring everything else.

• If it reads as an argument, the outline is done and drafting is now a transcription job.
• If a sentence describes a subject rather than an assertion (“this section covers the history of”), that section has no claim and is a candidate for deletion.
• If two sentences say the same thing differently, you have found the sections to merge — before writing two thousand words of them.
• If the sequence has a gap, you have found the missing section, which is much cheaper to notice now.

For a long piece this list also becomes the table of contents and, with light editing, the summary.

Pieces that have no argument

Some pieces genuinely do not assert anything: a reference page, a procedure, a comparison of options where the reader’s circumstances decide. Forcing a claim outline onto one of those produces a manufactured thesis, which is worse than no thesis. The structure of a reference piece is not an argument — it is a decision tree, and it has a different completeness test.

Outline these by reader state rather than by claim. Write down every situation the reader could be in when they arrive, and the piece must have a path for each.

ARGUMENT OUTLINE            REFERENCE OUTLINE
one line per claim          one line per reader state

test: does it read as       test: is every state the reader could
an argument?                arrive in covered, and does each path
                            end somewhere?

Example, "restoring a backup":
  state A  you have a backup and the database is running
  state B  you have a backup and the database will not start
  state C  you have a backup from a different major version
  state D  you think you have a backup and have not checked
  state E  you have no backup

State D is the one nobody writes and the one most readers are in.
State E is a real path: it ends with what to do instead, not with
a sentence telling them they should have had one.

A model is useful here in exactly the way it was useful for prerequisites: ask it to enumerate the states a reader could be in and which ones your draft covers. Enumeration over supplied material is a strength. It will produce some states that do not exist, which cost you a moment each, and it will occasionally produce the one you had not thought of, which is worth the whole exercise.

The two outline types combine in one piece more often than not: an argument about which approach to take, followed by a reference section for each. Outline the two halves separately and by different tests, because a completeness test applied to an argument produces padding and an argument test applied to a reference produces false confidence.

Turning the skeleton into prose

1. Draft section by section, never the whole piece in one call. A whole-piece generation regresses to the average structure regardless of the outline you supplied, because the outline is one instruction competing with a very strong prior about what articles look like.
2. Give each call the claim, the evidence you gathered, the sentences of the sections either side, and a length budget. Withhold the rest of the piece: more context here buys nothing and increases the pull toward summarising itself.
3. Write the opening and the closing yourself. They are the two places where voice is most visible and where generated text is most formulaic — every tell on the editing page lives disproportionately in the first and last two paragraphs.
4. Edit in the order given on that page: cut sections, fix structure, add specifics, then repair sentences.

Where this goes wrong

• Letting the model write the claims after all. The usual slide is asking it to “expand” a claim list, which returns eleven claims where you had four, most of them true and uninteresting. Adding claims is the one thing to keep for yourself.
• Treating the objections as edits. An objection is information about your reader, not an instruction. Half of them should be answered in the piece; the other half are worth ignoring deliberately, and a piece that answers every objection has no shape.
• Outlining something you have not researched. The adversary pass will happily critique an argument built on facts you have not checked, and it will not tell you that is what it is doing. Sources first — the source-first workflow comes before this page, not after.
• Outlining a short piece. Under about 800 words the overhead exceeds the benefit. Write it.