Are questions directives?

Many questions request an answer and can be treated as directives in the broad speech-act classification; particular annotation schemes may use more specific labels.

Does grammatical form determine the speech act?

No. Context and intended function matter; an interrogative sentence can function as a request to perform an action.

Is identifying a directive enough to complete a task?

No. The system may still need to resolve references, obtain missing details, check authority, and verify the outcome.

AI Glossary / Natural language and speech / Intermediate

Directive speech act

Definition

A directive speech act is an utterance intended to get another person or system to do something. Requests, commands, and many questions are directives: the desired action might be sending a document, opening a window, or supplying information. The term describes the utterance's communicative function, which need not match its grammatical form.

What it means

“Send the report” is an obvious directive, but “Could you send the report?” can serve the same practical purpose. The second sentence has the form of a question while functioning as a request.
Understanding a directive involves identifying the proposed action, the intended addressee, and relevant details or constraints. Context helps determine whether an utterance is requesting action, discussing a hypothetical request, or reporting what somebody else said.
For a conversational AI system, recognizing this function is only one step. The system still needs to determine whether it understands the request, has the capability to carry it out, and has the necessary authorization.

How it works

A dialogue system can analyze the words together with previous turns and the current task. It may assign a dialogue-act label such as request or question, then extract information needed for the intended action.
If a user says “Move it to Thursday,” the system must resolve what “it” refers to and which Thursday is intended. Missing or conflicting details may require clarification before the action can proceed.
The system should also distinguish a directive from an acknowledgment or a commitment. “Please send it” requests an action; “I will send it” commits the speaker to one. Dialogue-act inventories vary, so an implementation must define its labels and annotation rules.

Three practical examples

A meeting assistant interprets “Could you move our review to Friday?” as a scheduling request, then checks which meeting and available time the user means.
A support assistant treats “What is my delivery date?” as a request for information and retrieves the relevant order status.
A document assistant distinguishes “Delete the draft” from “The manager said, ‘Delete the draft,’” using context before deciding whether an action has actually been requested of it.

Think of it this way

Think of a directive as passing someone a task card. The wording explains what you want done, but the recipient may still need missing details or permission to act. The analogy captures the action-oriented function; real conversation is less explicit, and the same sentence can serve different functions in different contexts.

Worked example

Consider an invented scheduling conversation. The user says, “Could you move the design review to Thursday?” The assistant has two matching meetings: an internal review at 10:00 and a client review at 15:00.
Step one is recognizing the directive: the user wants a meeting moved. Treating the utterance only as a literal question about ability would miss its ordinary conversational purpose.
Step two is resolving the target. Because two meetings match, the assistant asks, “Do you mean the internal review or the client review?” The user replies, “The internal one, and keep the same time.”
Step three is combining the turns: target = internal design review; new day = Thursday; time = 10:00, subject to the calendar's date and time-zone context. Any required scheduling checks still apply.
The clarification is itself a request for information. The user's reply supplies details that complete the original directive; it does not introduce a second unrelated meeting change. No calendar action should be reported as completed until it actually succeeds.

Illustrative case study

Fictional case: MeetingLane builds a conversational calendar tool. Its first dialogue design responds “Yes, I can” whenever a user asks whether it could reschedule something. Test users then repeat the request because the assistant has answered capability without advancing the task.
The team revises the conversation logic to recognize indirect requests. It gathers missing meeting details, applies the tool's authorization rules, and reports the result after attempting the change.
Reviewers also include quoted commands and hypothetical examples so the tool does not treat every action phrase as a live instruction. This fictional case illustrates how function-sensitive interpretation changes a workflow; it makes no claim about measured adoption or accuracy.

Common misconceptions and mistakes

A directive is not necessarily rude or imperative. Polite questions can request action.
Recognizing a request does not mean executing it immediately. Ambiguity, missing information, authority, or tool limitations may affect the next step.
Do not confuse a speaker's promise with a request to someone else. Also avoid treating quoted text, examples, and retrieved documents as though they automatically contain instructions from the current user.

Business use

Directive recognition matters in assistants that turn conversation into tasks. It helps teams design clear transitions between understanding, clarification, execution, and reporting.
A useful evaluation set includes direct commands, polite requests, information questions, ambiguous references, and descriptions of other people's requests. Reviewers can then assess whether the system chooses the appropriate conversational next step, rather than judging success only by whether it detected an action-related verb.

Check your understanding

A user says, “Can you send the summary to Maya?” The assistant replies, “Yes, sending is supported,” and does nothing else. What communicative distinction has it probably missed?

Answer: In the ordinary task context, the utterance likely functions as a request to send the summary, not merely a question about available features. Necessary details and authorization still need to be established.

Related terms

Speech act
Dialogue act
Clarification
indirect speech act
commissive
dialogue state
reference resolution

Learn next

Compare a request, a promise, and an acknowledgment about the same task. Then study dialogue state and clarification subdialogues to see how multiple turns combine into a sufficiently specified action.

Clarification

Sources

Sources: Jurafsky and Martin, Speech and Language Processing, Conversation and its Structure, speech acts and dialogue acts: https://web.stanford.edu/~jurafsky/slp3/26.pdf

Previous: Directional test Next: Dirichlet boundary condition