Long spoken answers need structure, not a linear dump

What it is

Ask “what’s tomorrow,” and the system reads from the 8 a.m. standup through the 9 p.m. dinner, twelve events in a sentence with no rank of pause. What arrives is a stream, not a report that can later be retrieved by chunk. A structured spoken answer collapses long output into a graspable skeleton first — “two meetings in the morning, afternoon clear, dinner at night” — and expands a branch on demand. A linear dump is not “complete information.” It flattens hierarchy so working memory cannot build a table of contents for the utterance.

Why it happens

Listening to a long stretch is not storing every word. People extract themes and grow chunks as they go. If prosody and syntax mark no boundaries, extraction fails and the stretch degrades into a tape that must be replayed from the head to locate one item. A skeleton that arrives first gives later details a node to hang on (“the afternoon block is empty” becomes an addressable drawer). Details first, skeleton never, and later words pile into a buffer with no compartments. This is not the same as the option-count cap: an answer can be long if the hierarchy is shallow and the nodes are few; it can be short and still unsearchable if twelve equal-weight events are read in a row.

A linear dump also forces a bad listening policy: to avoid missing what comes next, people stop integrating what just passed, and keep only the closing clause. Structure’s job is to allow “hear the shape, then decide whether to hear a leaf,” not to line the leaves up as sentence subjects.

Studying it

Take one calendar and speak it two ways: a hierarchical summary (blocks then items) versus an equal-weight linear readout (each event in time order). After hearing, two retrievals: gist (busy morning? any social in the evening?) and a probed detail (“what was the 14:00 item”). Independents: event count, number of blocks, whether a named block can be expanded after the summary. Dependents that split gist-right/detail-wrong from detail-right/no-block point to different encoding failures.

Do not make “felt memorable” the main score. The structure tree people produce — how many blocks they state, how many items per block — shows whether a table of contents was built. If the lab prints the outline and then lets people listen, the measure is reading structure, not heard structure.

Where it stops holding

An atomic fact (“the door is open,” “the timer is set”) has no foldable hierarchy; structure is empty. If the user already has the same calendar on screen and speech only reports what changed, the structural load sits on vision. An emergency alert wants one proposition on the shortest path; gist-then-expand delays a critical leaf (dose, exit). Experts who already own a slot template for a daily briefing will hear a linear order as structure when it matches that template; the same order is still a dump for a listener with no template.

Applying it

• Answers longer than two or three sentences start with a countable skeleton (how many blocks, a label for each). Default stop there; expand a block when the user names it, rather than automatically reading every leaf.
• Nodes in the skeleton must be speakable (“the afternoon block,” “the evening item”). Otherwise the structure exists only for the system; for the listener it is still a tape.
• Do not fake structure by chaining twelve events with “and then… and then….” No anaphoric node, still linear.
• How to check: after the readout, only two questions — “how many parts is tomorrow” and “anything in the afternoon.” Blocks without leaves: structure landed. Both answers guessed from the last clause heard: it was a dump.

Related

• Same group: M1.02.1 Heard options vanish; there is nothing to glance back at · M1.02.2 How many options you can speak is capped by working memory
• Nearby: M3.02 Speech Rate and Prosody · M3.07 Rate, Pauses and Prosody · M3.11 Trimming Speech Output
• Search terms: structured spoken answers · hierarchical spoken summary · discourse scaffolding