Skip to content

The long-form spine

What to do when the answer is longer than the screen.

10 min

When the model produces a long answer — a memo, a plan, a multi-part breakdown — most products render it as a monolithic block of prose. The user scrolls. A lot. They lose the shape of the answer inside the scrolling. By the time they reach the end, they can't remember what was in the middle.

"The spine is how a long response stays navigable. Scroll as orientation, not as a dive."
The pattern

A pinned outline, a scrollable body.

Long answers get a sidebar with their own section list. The current section highlights as the user scrolls. Clicking jumps. Scroll sync is automatic. The answer becomes a small document, not a chat turn.

The spine is generated, not authored. The model emits section headers; the interface threads them into a navigable outline without any extra prompting.

Long answer with a live spine
Scroll inside the frame; watch the sidebar follow
Long response, scrollable body, pinned spine
Summary

I recommend sunsetting the legacy usage-based tier by Q3, migrating those accounts to a flat plan with an opt-in overage.

Why now

Usage-based billing drives 6% of revenue but 34% of support tickets. The ratio is getting worse every quarter, not better.

Risks

Two enterprise accounts sit on grandfathered terms. They need a white-glove migration path and a 90-day grace window.

Rollout

Internal comms week 1, customer comms week 2, migration tooling week 3, cutover week 6.

Appendix

Raw ticket breakdown, pricing calculator assumptions, and proposed email copy all sit in the linked working doc.

The spine is how a long response stays navigable. Scroll = navigate, not dive.

The why

Long outputs are documents, not messages.

The chat metaphor breaks down past a few hundred words. At that length, the user is reading something closer to a page than a reply. Treating it as a reply means losing the navigational affordances — contents, jump links, breadcrumbs — that make long documents readable.

Three moves

Details that earn the spine.

  • Auto-outline from headers. If the model emits sections, the spine builds itself. Don't ask the user to click "show outline."
  • Active section on scroll. Not just a TOC. Highlight the section the reader is currently inside. The spine is a live map.
  • Collapse for short answers. Anything under three sections shouldn't render the sidebar at all. The spine is opt-in by length.

The trap

The spine that isn't really a spine.

Some products ship a TOC that is just a static list of anchor links. It doesn't scroll-sync. It doesn't highlight the active section. It breaks when the model emits a section the schema didn't predict. The feature is the affordance, not the link.

Failure modes

What this pattern gets wrong when it gets wrong.

Silent truncate
The response ran out of room or tokens and the product didn't tell the user where it stopped.
Citation overload
So many citations that the user stops reading them, which defeats the purpose of having them at all.
Seen in the wild

Three shipping variants worth copying.

  • A thin rail with live-highlighted current section
  • A word count and estimated read time at the top
  • A collapse-all-but-one affordance for scanning