Interactive Flow Control

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A user requests user-data export without fields/destination. The teaching interface supports id,email,phone; available columns do not imply all are wanted. Inspect capability before resolving intent gaps that change export behavior.

Mechanism

Read the interface and existing requirements first. Ask a concise group of still-needed fields, record scope and destination questions, waiting for required answers while continuing independent inspection. Update the understood task after the response and reuse answers already given rather than asking again.

Bad example

The interface supports id/email/phone, so export all user fields to users.json despite missing destination/scope.

Good example

Inspect the supplied interface and existing request. If fields/destination remain missing, ask which fields, records and location to use and await these data-scope decisions. Meanwhile inspect format/error behavior without exporting. Reuse explicit existing answers; prepare only the chosen scope, not every supported field by default.

Why the change matters

Interface evidence establishes capability; user answers establish intent. Necessary questions govern next actions without treating more supported data as permission or repeatedly reopening settled choices.

Observable expectation

With a teaching answer ‘IDs only, current filtered records, specified local directory’, use those conditions only. Without an answer, scope remains unresolved while interface inspection proceeds.

Reject guessed targets, unselected email/phone and elapsed time treated as consent. No real user data is read/exported.

Limits

Do not force fixed question counts; complete requests can proceed. Clarification supplies missing information rather than reauthorizing settled work. Material data-scope gaps cannot disappear into convenient defaults.