📄 GRICE INCORPORATED: Cooperativity in Spoken Dialogue

Summary

The authors built the dialogue component of a Danish-research prototype spoken language dialogue system (SLDS) for flight ticket reservation. The system leads the conversation, and users can only take the initiative through the keywords "repeat" and "change". To keep users from doing things the system cannot handle, the designers needed it to behave as cooperatively as possible. They derived principles of cooperative human-machine dialogue from user-system interaction problems found in a Wizard of Oz (WOZ) corpus. They then compared these principles with Grice's Cooperative Principle and maxims, which led them to reformulate some of them. Finally, they checked the principles against a user-test corpus from the implemented system. The comparison shows that Grice's maxims form a subset of the resulting set. Three further aspects of dialogue are not covered by Grice:

• asymmetry between the dialogue partners,
• background knowledge,
• repair and clarification meta-communication.

Nearly all problems found in the user test could be explained as violations of the principles. This suggests the principles could become practical design guidelines for SLDS dialogue.

Key points

• The WOZ phase ran seven iterations and produced 125 transcribed dialogues, about seven hours of speech. Of these, 94 dialogues came from external subjects in the last two rounds, and 24 subjects took part overall.
• From 120 interaction-problem examples, the authors first identified 14 principles. The final Table 1 contains 13 generic principles (GP1–GP13) and 11 specific principles (SP1–SP11), grouped into seven dialogue aspects. Grice's maxims are the starred generic principles.
• The maxims of truth and evidence never came up as design problems during WOZ. The authors explain that an SLDS designer cares about these constantly anyway, so they were simply added to the set.
• In the user test, speech recognition was simulated and all other components were the implemented ones. Twelve external users produced 57 scenario-based dialogues.
• The user test revealed 86 dialogue problems, and almost all of them fit existing principles. Only two new specific meta-communication principles had to be added (SP10, SP11). This was expected, because meta-communication had not been simulated during WOZ.

Interesting ideas

• I1. The dialogue model was drawn as a graph, with system phrases at the nodes and expected user answer contents on the edges. Both planned scenarios and recorded dialogues were traced through it, and every deviation was flagged as a likely design flaw. This gives a cheap, systematic way to find gaps without a working system.
• I2. Each failure was recorded as symptom, diagnosis and cure, and tied to the specific principle it violated. This turns raw error lists into actionable, categorised fixes.
• I3. The principles form a hierarchy in which broad generic ones subsume narrow, domain-bound specific ones. This keeps the theory compact and still lets an application add concrete checks.
• I4. One failure from the user test: the system answered "no departure at 7:20", although a non-discount departure at that time existed. The cure was to state the nearby alternative explicitly. A literally true answer can still be uncooperative.
• I5. When user constraints conflicted (discount vs. exact time), the authors' fix was to ask the user which one has priority, not to silently drop one.

For Mova

How these ideas could serve Mova, our small open language model — its files, stages and tests:

• I1 (learn): trace evaluation items through the expected frame/world path. Points where the actual analysis leaves that path become ranked candidates for self-induced repair rules.
• I2 (learn): log parser and reader errors in this three-part format, keyed to a named rule. Repairs then stay explainable, and recurring violation types become visible.
• I3 (frames): organise implicature and cooperativity checks in crate prag the same way. Grice-level maxims would sit at the top, with specific detectors such as "missing feedback" or "unflagged ambiguity" hanging under them.
• I4 (answer): when a reader answers "no" or "none", it could check the world of the text for the closest matching alternative and mention it. This would make answers informative enough, not merely correct.
• I5 (world): if constraints or facts in a text's world contradict each other, record the conflict and the competing readings explicitly. This avoids picking one without justification and keeps the decision traceable.