Headings and Sections — Make Your Model Think Like a Table of Contents (But Cooler)

Headings are not just pretty banners; they are navigational beacons, parsing anchors, and secret instructions your model can follow when you tell it to. Use them like a boss.

---

Hook: Why you should care (and fast)

Imagine you asked a model for a long report and it spat out one giant paragraph that reads like a philosophy professor on a coffee bender. Horrible. Now imagine it gives you a crisp, semantically meaningful hierarchy: Title, Summary, Methods, Results, Next Steps. Beautiful. Headings turn chaos into structure.

This lesson builds on your work with bullets, lists, and outlines, and on the zero/one/few-shot tradeoffs you learned earlier. We already know that examples can steer formatting; here we make formatting the steering wheel.

---

Big idea: Heads up — headings are instructions

• A heading is a command: telling the model to produce a specific type of content.
• A section is a contract: it promises a scope and style for the following text.
• Headings help parsing: for humans and downstream tools (parsers, extractors, UI components).

When to use headings

1. Long outputs (> 200–300 words)
2. Multi-step content (how-to, reports, case analyses)
3. Outputs that will be post-processed (converted to HTML/JSON, used in apps)
4. When you want predictable substructures for few-shot examples to latch onto

---

Patterns and templates: How to ask for headings

Here are pragmatic prompt patterns. Replace placeholders with your task specifics.

1. Explicit sections list (most reliable)

Produce a markdown document with these sections in this order:
- Title
- Summary (2–3 sentences)
- Key Findings (bullet list)
- Recommendations (numbered list)
- Sources (bullet list)

2. Section-by-section generation (good for very long tasks)

Step 1: Generate the Title and Summary only.
Step 2: Wait for approval, then write the Methods and Results.

3. Semantic heading labels (constrain tone)

Use these headings: 'TL;DR', 'Why it matters', 'Evidence', 'How to use it'. Keep 'TL;DR' ≤ 30 words.

Tip: use explicit constraints next to headings (e.g., maximum bullets, sentence count) so the model knows the shape of each section.

---

Formatting styles: pick the right dialect for your downstream consumer

Output style	Example heading	Best use case
Markdown	# Summary \n ## Methods	Human-readable docs, GitHub, notebooks
HTML	Results	Web content pipelines
JSON object	{section: 'Summary', content: '...'}	Programmatic consumption, APIs

When you need machine-readability, prefer JSON or explicit delimiters. When you need human readability, use Markdown or HTML.

---

Few-shot + headings: how examples change heading behavior

You already know from the zero/one/few-shot lesson that examples steer behavior. Here are direct consequences for headings:

• Example order matters: early examples set the "voice" and heading naming convention. If your first example uses 'Key Findings', the model prefers that over 'Conclusions'.
• Example quality matters: clean, consistent headings in examples = consistent headings in output.
• Fewer examples? Be explicit. If you skip examples, you must describe the heading structure clearly.

Practical rule: if you want highly consistent heading names/levels, provide 2–3 high-quality examples that match your exact naming and constraints.

---

Advanced tricks — make headings work for complex flows

1) Use enumerated headings for guaranteed presence

Ask for numbered sections so you can reference them reliably later:

1. Introduction
2. Methods
3. Results
4. Discussion

You can later prompt: 'Expand section 3 with charts' and the model knows where to go.

2) Section markers for easy parsing

Use delimiter tokens that are unlikely to appear naturally, e.g., '<<<SECTION: Methods>>>'. This is gold when you must parse content with regex.

3) Scoped constraints per section

## Methods (max 4 bullet points)
- bullet 1
- bullet 2

Constrain tone and length per section to avoid runaway verbosity.

4) Generative chaining — scaffold complexity

Produce an outline first, then expand each heading in subsequent turns. This reduces hallucination and keeps structure intact.

5) Templates for mixed outputs

If you want both machine and human consumption:

Output both:
1) JSON with keys 'title','summary','sections' (array of {heading,content})
2) A Markdown rendering of the same content

This dual-output pattern keeps developers and reviewers happy.

---

Small but deadly mistakes to avoid

• Inconsistent capitalization between examples and prompt. 'Key findings' vs 'Key Findings' = different behavior.
• Vague headings like 'Notes' — ambiguous scopes invite rambling.
• Overly long heading names — keep them scannable.
• Forgetting to lock order if downstream parsing expects it.

---

Mini demo: prompt → output

Prompt (explicit, no examples):

Create a markdown document with these sections in order:
- Title (one line)
- TL;DR (one sentence)
- Background (2 bullets)
- Analysis (3 bullets)
- Action items (numbered list, 3 items)

Expected model output (abbreviated):

Title: Rapid A/B Test Insights

TL;DR

One-sentence summary.

Background

• Bullet one
• Bullet two

Analysis

• Point A
• Point B
• Point C

Action items

1. Do X
2. Do Y
3. Do Z

This is intentionally rigid — perfect for dashboards and reports.

---

Closing — TL;DR of the TL;DR

• Headings are instructions: use them to constrain content, style, and scope.
• Make them machine-friendly when you need parsing; make them human-friendly when readability matters.
• Combine with few-shot: consistent examples = consistent headings. Skip examples? Be explicit in the prompt.
• Chain and scaffold: outline first, expand later to control hallucinations and keep structure.

Final thought: a good heading is like a good joke — it tells you what to expect, sets the tone, and lands the point. Give your model good cues, and it will give you good structure.