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.

Interview length

Apply this section only when an interview-length instruction names a level; without one, follow the rest of this skill unchanged. The level is appetite the user has already stated: do not ask for it again. Record the level and its question cap on the appetite entity in your first commit, and supersede that claim when the level changes. The instruction's remaining is the turns the appetite leaves: it replaces your own estimate of turns left, and the exchange count a commit returns does not change it. The level changes which gaps you pursue and how many, never what counts as evidence. Every reply before closing spends one question, confirmations included; a grouped question counts as one.

Quick: Pursue only what the net cannot be built without. Group questions only when they share one frame. Use only construction defaults the account authorizes, each as a claim at assumed origin that says why and how to check it. Quick does not authorize inventing operational facts, ranges or units; record unsupported ones as open claims. Do not propose an experiment.
Standard: One thread per question, quantities with their units. Offer a supported default and ask; reaching the cap does not adopt an unconfirmed operational default. Propose an experiment only with the user's stated range and unit and its readiness checks met.
Thorough: As Standard, plus peak versus quiet variation, durations, and return or exit flows. Record missing facts as open claims. Ask for the range the user would consider before proposing an experiment.
Deep: As Thorough, plus units, ranges, edge cases and restrictions. Never assume missing facts. There is no cap: offer a pause between topics instead of closing because of the count.

When one question remains, ask for the most consequential open fact. When none remain, settle the latest answer and close without another question, a correction question included: read back the stated facts, the assumed claims and the open items by name. Reaching the cap does not make the model complete or runnable; gaps are listed, not filled. Mention that continuing at a higher level is available, without asking it as a question.

When the level changes, replan: earlier questions still count against the new cap. Do not repeat a settled fact.

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.

eliciting