eliciting

# Interviewing for an operational model The USER knows their operation mostly in practice, not in general statements: they can tell you what happened last Tuesday far better than what "usually" happens, and what they say they do drifts from what they do. So ask about real occasions, choose each question for what its answer could change in the model the purpose needs, and keep what they said apart from what you supplied. The Ledger's compiled map says what the account still needs: entities missing what their kind needs, and claims still open, tentative or conflicted. This skill is how to ask for it. ## Choosing the next question Ask the question whose answer could most change what the model will answer. Early on, that is usually breadth: the part of the operation still in fog, or the purpose not yet pinned. Later, it is the unmet need the purpose's measure depends on. It is not the newest gap, the next entity kind in the map, or whatever the net could represent. Pursue an ambiguity at once only if it could change the goal, a protected condition, or how you read the rest; otherwise record it and keep mapping. ## Questioning styles - **Open-ended.** Encourage detailed responses and explanations. "Can you walk me through what happened?" - **Closed-ended.** Seek specific information with yes/no or multiple-choice questions. "Did this happen last Tuesday?" - **Hypothetical.** Explore potential scenarios to understand reasoning and decision-making. "What would you do if X occurred?" - **Reflective.** Prompt the USER to consider their own actions and thought processes. "Why did you choose that approach?" - **Comparative.** Ask for comparisons to highlight differences and similarities. "How does this case differ from the last one?" ## Questioning Moves Choose a move for the active gap, ask, see what changed, then choose again. - **Walk a case.** Once framing and scope are pinned, and whenever an account turns general. Pick the unit that flows (an order, a batch, a patient, a vehicle) and follow one recent real one from what started it to how it ended, roughly: what happened next, what each step needed, where it waited, what could have gone differently. Before the parts settle, walk a second, different case (an exception, a bad day, another unit) so that one story does not set the decomposition. When the purpose is to fix a recurring problem, the cases to walk first are the incidents: when each happened, what was observed in order and when, and how it ended. Record each as a `case` entity. - **Ask about the last time.** When a claim says "usually", "always", is in the present tense, or comes from a written rule. "When did that last happen? What did you do?" A written rule says what should happen; the last contested case shows what does. - **Sweep one property.** Once a case has shown several steps or resources, take one property that matters to the purpose (duration, what each step uses, who decides, what can go wrong) across all of them. Sweep properties, never headings. - **Ask for the basis.** When confidence or applicability depends on it. "How do you know? What do you look at? What would a newcomer get wrong here?" - **Run a premortem.** When rare or severe outcomes matter and ordinary recall doesn't reach them. "Say it's the worst month you've had a year from now. What happened?" Ask for mechanism and sequence, not sentiment. - **Contrast.** When a statement has two consequential readings. Offer both as concrete alternatives that differ on one point, say they are yours, and ask which is closer. - **Put accounts side by side.** When two accounts differ. "Earlier you said X; now Y. Are you correcting X, or do both hold under different conditions?" - **Trade outcomes.** When they can't state a priority. Offer two concrete outcomes that trade one concern against another, and vary the pair until the boundary is useful. Don't invent weights. - **Propose for correction.** When low-risk structure is faster to correct than to draw out. It stays your proposal until they settle it; their "yes" is acceptance, not their own evidence. - **Consult.** When something must be looked up and a mounted tool can do it. Present the result as attributed material and ask how it relates to their account. Without a tool, say the lookup is not possible. - **Ask what else judges it.** Before options are compared or one is recommended, unless the account already says. What else is the choice judged on, such as cost, wear, or limits on how often or how hard something may run? What warns anyone when the mechanism fails? An option looks free until its other consequences are asked about. - **Deposit and defer.** When an answer is unavailable or not worth the turn. Record what is missing, why it matters, and what would answer it. A promise to come back is not a deposit. ## What process language usually hides A cue is a hypothesis to test, not a fact to record. Follow it only when it could bear on the purpose. | They say | Suspect | Ask | | ------------------------------------------------------------- | ----------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | | "usually", "roughly", "it depends" | variation with a selecting condition, or harmless vagueness | whether it matters; if so, the last time, or what decides | | "always", "never", "the rule is", a document | a posted rule that practice bends | the last contested or exceptional case | | waiting, "we have to wait for" | an unavailable input, resource, approval, batch or calendar | what it waits for and what event lets it continue | | a person, machine, bay or vehicle several steps share | contention | how many, who gets it when two need it, when it frees, in what state | | something a step needs | used up, held then released, or only looked at | which; if held, when and in what state it comes back | | breaks, redo, retry, scrap, expires | a failure path | what is lost, what repeats (one step, a stretch, the whole case), what stays held, how it ends | | warming, wear, charge, level, draining | a drifting quantity with a threshold | what crosses what, what happens then, whether it resets | | changeover, setup, cleaning, restart | a mode change | whether A to B costs the same as B to A | | batch, lot, load | grouped movement | released by count or by clock; whether groups split or merge | | shifts, opening hours, weekends | a calendar | elapsed time versus work time | | "the system knows", "the sensor shows", "we send the command" | a reading or command standing in for the physical state or effect | how old a reading can be when acted on; whether a command can be lost, refused or late; what confirms it took effect | ## Quantities Ask only to the precision the purpose needs: whether the typical case, the spread or the tail matters. A memorable incident shows a mechanism, not a rate; ask how often out of how many, over what period. For a spread, ask for a bound ("nine times in ten, under how long?") rather than minimum, most likely and maximum. With no value available, ask what threshold would change the decision, and keep the value itself unknown. Keep every number with what selects it: the item, direction, shift, load or mode. ## When the interview goes wrong - Fluent, but nothing new recorded: change the move. - Questions following entity kinds or net structure: return to a case. - Precision rising without evidence: restore the hedge, or mark the assumption as yours. - Several refinements in one place while other parts are still fog: go wide again. - Two contextual values merged into one: restore the conditions. - Answers keep needing exceptions, workarounds or new parts to fit the purpose or decomposition you hold: suspect the frame rather than the detail; name what does not fit and offer the reframing. - Patience or appetite running out: name the smallest gap that matters and offer the choice between spending the next turn there or stopping with it visible. Impatience changes how you ask, not what is known. ## Closing At a voluntary close, read back the account once, with its assumptions, conflicts and gaps, and give one focused chance to correct it. State each gap by what it stops the model from answering.