Partial success has to be reported item by item
Aliases: mixed outcome · per-item status · partial completion
What it is
The result of a compound command is a vector, not an “okay.” Lights off, music service down, alarm set — a lone “okay” hides the miss, and the user finds out at night. A lone “couldn't do that” recodes the two successes as failures. Speech has no row of status icons. Speaking each outcome is the audible per-row status. The claim is how to report after execution, not how to sequence before it.
Why it happens
A single speech act flattens a vector into a scalar and throws away which item failed. People cannot repair the miss because they do not know which to repair; they may also believe everything worked and stop checking. Auditory working memory will not hold eight statuses read in a row, so itemizing is not reading the list: failures first, and actionable; successes can be packed (“lights and alarm are done”). In public there is also exposure: itemizing may speak “the payment didn't go through,” and that line has to be able to shrink.
“Okay” is enough for a single intent because the vector length is one. Compound commands lengthen it, and the same courtesy no longer carries the information. Partial success also needs the report to be isomorphic with the detected set: three jobs heard, two reported, and the fate of the third is still invisible.
Studying it
Build partial-failure scenes: three jobs, the middle one fails. Compare a one-line summary with a per-item report. Dependents: whether people can name the failed item, whether they try to repair it, whether they falsely believe the other two failed too. Vary list length to see at which item spoken status collapses. Do not use satisfaction: people can find the answer “crisp” and still believe all three worked.
In logs, search immediate follow-ups after compounds (“what about the music”). A high rate means the previous scalar did not unpack the vector. Sessions where the system said “okay” and a backend item was not OK are field evidence of scalar reports.
Where it stops holding
All three succeeded and the list is short: “all done” can pass, if people can map “all” onto their original sentence. Reading eight successes is too long — report failures first, successes as a count: “six worked; the blinds are offline.” When the whole compound is refused as a unit (policy blocks one item, so nothing runs) there is no partial success; say the order was cancelled as a whole. In public, or when a failure names someone else, shrink to “one of those didn't go through — which should I tell you,” rather than speaking the object aloud.
Applying it
- Return a status per intent. Never collapse mixed outcomes to one polarity. Speak failures first, with one sayable repair; pack successes.
- Align the report set with the detected set: three jobs heard means three fates spoken, including “not done yet, waiting on your nod.”
- Keep “okay” / “done” for all-success of at most three items; beyond that, switch to a count plus the exception.
- How to check: fail the middle item. If after the report people cannot name which failed, or think the other two failed too, the report failed. Switch to itemized and measure again; follow-ups of the form “what about X” should drop.