When the answer is a procedure

“How do I request a hardware replacement?” is not a question about a fact. It is a request for a sequence that somebody is about to carry out, in order, possibly with money or access or an irreversible action involved.

Procedural answers need different generation handling from factual ones, because the ways they go wrong are different and the cost of getting them wrong lands after the user has already started.

What makes a procedure different

Order is a claim. In a factual answer, rearranging clauses is harmless paraphrase. In a procedure it changes the instruction.

Omission is an error, not brevity. A summarised fact is still true. A summarised procedure with the approval step removed is false.

Prerequisites and warnings are load-bearing. “Back up the volume before you detach it” is not colour; it is the difference between a routine task and data loss.

A partial procedure is worse than no procedure. Someone follows four of six steps, stops, and is now in a half-configured state. A refusal would have sent them to the document.

The failure modes, roughly by cost

Merged variants. Two chunks describe two versions of the same process — the contractor path and the employee path, or last year’s and this year’s — and the model fuses them into a single coherent procedure that exists in no document. This is the expensive one. Every individual step is real and cited, and the sequence is fiction.

Dropped step. Usually the least interesting one: a waiting period, a notification, a form that has to be filed before the interesting action. Paraphrase eats it because it doesn’t look like content.

Lost conditional. “If you are a contractor, use the vendor portal instead” becomes an unconditional instruction, or disappears. The answer is then correct for most readers and wrong for the ones who most needed the qualifier.

Truncation at a chunk boundary. The procedure spanned two chunks and only one was retrieved. The symptom is an answer that ends at step four with no terminal action — no confirmation, no submission, no “you’re done.”

Reordering. Less common than the others, and mostly a consequence of paraphrasing prose steps that had no numbers.

Instruct for fidelity, not fluency

When the answer is a procedure:
- Preserve the source's order and numbering exactly.
- Do not combine steps from different sources into one
  procedure. If the sources describe different variants, present
  them separately and say who each applies to.
- Keep every conditional attached to the step it modifies.
- Reproduce warnings and prerequisites close to verbatim.
- State any prerequisite before step one.
- If the steps appear to be cut off or do not reach a completed
  state, say so and cite where they stop.

The no-merging rule is the one that earns its place. Left unstated, synthesis is the default behaviour, and synthesis is exactly wrong here.

This is the case for quoting

Quoting versus paraphrasing is usually a judgement call. For procedures it isn’t: near-verbatim reproduction is the right default. Paraphrase buys readability you don’t need and costs precision you do.

The specific things paraphrase damages are exact identifiers — a menu path, a command, a form number, a field name, a button label. A user following the answer is looking for that string on a screen. An approximation of it is useless in a way an approximate fact is not.

Detecting incompleteness cheaply

If the source numbered its steps, you have a free check. Does the retrieved text start at step one? Does it end at something terminal? A retrieved fragment running from step three to step seven is detectable without a model call, and the right response is either another retrieval pass or an honest note in the answer.

Where the source uses prose rather than numbers, the instruction above has to carry it — ask the model to say when the steps look truncated. It is not fully reliable, but it converts some silent truncations into visible ones, and the alternative is nothing.

Either way, log it. Procedures that regularly retrieve incomplete are usually a chunking or ingestion problem in one specific document, and that is a fixable thing rather than a permanent tax.

Shape it for execution

The general guidance in the shape of a good answer applies, with procedure-specific additions:

Number the steps, matching the source’s numbering. If the source’s step five is your step three because you dropped the ones that didn’t apply, a user comparing the answer with the document is confused for no reason.

Prerequisites go above step one, not inline where they’ll be read too late.

Branches get their own labelled block. A conditional buried in a parenthetical inside step four is a conditional that gets skipped.

Cite per step or per block, not once at the end. A single trailing citation on a ten-step answer tells the reader nothing about which step came from where — citations that point somewhere real covers why the granularity matters.

Sometimes the answer is the document

For long, high-consequence or frequently-revised procedures, reproducing the whole thing is the wrong ambition. The runbook will change; your answer won’t.

An answer that names the right document and section, gives the first couple of steps so the user can confirm they’re in the right place, and links them onward is often more useful and always more durable than a full reproduction that quietly goes stale. Getting someone to the authoritative source is a legitimate outcome, not a failure to answer.