In ordinary prompting, you ask and the model answers — which means you carry the burden of knowing everything the model needs and cramming it into one message. On a well-scoped question that's fine. On something open-ended like "plan me a trip" or "design a schema," it's a trap: you can't enumerate every detail up front, and every detail you forget, the model silently guesses. A fluent answer built on an unspoken wrong assumption is worse than no answer, because it looks right.
Flipped Interaction inverts the roles. You instruct the model to ask you questions, one at a time, until it has gathered enough to act — and only then to produce the result. It's a pattern from White et al.'s Prompt Pattern Catalog, and the elicitation that used to be your job becomes the model's.
The three (P) contextual statements
The catalog describes each pattern as a set of fundamental contextual statements. Flipped Interaction needs exactly three:
- (P1) role + goal — "You are gathering requirements to plan a trip."
- (P2) cadence — "Ask me questions one at a time and wait for my answer."
- (P3) stop condition — "Keep asking until you have enough, then produce the output."
Get those three explicit and the behaviour is reliable. Leave one implicit and it drifts: it batches eight questions at once, or never stops, or answers for you.
Under the hood it's slot-filling
"Until it has enough" is really slot-filling. There's a set of facts the goal requires, and you keep a running checklist of which are still missing. Each turn, ask the next unfilled slot; record the answer. Name the slots in the prompt so the model knows what "enough" means — and track them in your own code so the flow is deterministic and never depends on the model to remember:
const SLOTS = ["destination", "duration", "budget", "company", "pace"];
function nextSlot(filled) { // first slot not yet answered
for (const s of SLOTS) if (!(s in filled)) return s;
return null; // null → all filled
}
function isComplete(filled) { return nextSlot(filled) === null; }
The stop condition does double duty: it stops the interview from running forever and stops the model from finishing early on a half-empty checklist. You literally cannot reach the synthesis branch while nextSlot(filled) is non-null — so there's no confidently-wrong output built on missing facts:
if (nextSlot(filled)) askNext(); // still gathering
else synthesize(filled); // enough → produce the result
The copy-paste template
Drop this straight into your system field and fill the brackets — the three (P) statements are labelled so you can see the skeleton, and the slot list is what makes "enough" unambiguous:
From now on, I would like you to ask me questions to
[GOAL — e.g. plan a trip / spec a database schema / debug an error].
(P1 · role & goal) You are gathering requirements to [GOAL].
(P2 · cadence) Ask me the questions ONE AT A TIME and wait for my
answer before asking the next. Do not make assumptions or answer
for me; if something is unclear, ask.
(P3 · stop condition) Keep asking until you have enough to [GOAL].
You have enough once you know: [SLOT 1], [SLOT 2], [SLOT 3],
[SLOT 4], [SLOT 5]. Ask about the first thing you are still missing.
When — and only when — every item above is known, stop asking and
produce [OUTPUT], clearly prefixed with "RESULT:".
Ask me your first question now.
One more thing worth pinning: models love to batch questions and skip ahead. Enforce the cadence twice — say it in the prompt and only render one question at a time — and drive the order from nextSlot() in your own code so a chatty model can't slip a batch past your UI. Because filled is plain data, you can persist it and resume a dropped session mid-interview.
Reach for this pattern whenever the human is the source of truth but doesn't know up front what's relevant: requirement gathering, onboarding wizards, intake forms, debugging interviews. Try the live, deterministic demo — it interviews you toward a trip, a schema, or a bug diagnosis — here: https://dev48v.infy.uk/prompt/day55-flipped-interaction.html
Top comments (0)