What the documents look like
Closure settlement moves in the opposite direction from head-office site selection: it handles exit and asset recovery. Order fulfilment and after-sales question answering for this category works from four document families: closure approval, inventory clearance forms, lease termination agreements, and asset count sheets. These records are organised per store and updated irregularly. Within one batch, a closure approval may sit at submitted but not yet approved, an inventory clearance form may be approved but not executed, and a lease termination agreement may be signed but not yet effective.
Those states decide what a multi-turn conversation may state. When an approval record is still at the submitted stage, the only supported fact is that the process was initiated. When a lease termination agreement is at draft or awaiting signature, deposit return and lease end have no determined outcome. The multi-turn prompt task is to name the document scope, the answering task, and the treatment of missing evidence so the model keeps gaps open instead of writing business facts.
Constraints at the multi-turn prompts step
Multi-turn conversation carries history forward. A new session and a continued session take different inputs. When chatId is not passed, the system does not use its stored context and the supplied messages build the context entirely. When a non-empty chatId is passed, the conversation is read from the database, the last item in the messages array is taken as the user question, and the remaining messages are ignored. The prompt must state which documents the current turn may reference, so a conclusion from another store or another period is not carried into this turn.
Question optimisation is checked for pronoun resolution and question expansion only in knowledge-base continuous-conversation settings; it is not assumed to apply to every short question. For model and length, compare the model's supported context and reply ceiling against a long document plus follow-up combination. Reply format follows downstream consumption; when json_schema is selected, the corresponding format requirement must be filled in and the returned structure verified. Retrieval and similarity affect recall ordering only; they do not perform permission or entity isolation, and retrieval itself is not authorisation.
Hypothetical paper exercise: a chain brand operations staff member submits a draft inventory clearance form and a draft lease termination agreement. The source text reads: "Inventory clearance form status is submitted, awaiting regional operations approval; store counted: Store A; count date: 10 March 2025; quantity scope: 12 shelving units, 3 refrigerated cabinets." "Lease termination agreement status is awaiting landlord signature; deposit return clause: no return date stated." The draft sentence to be judged is: "Store A inventory clearance is complete and the deposit will be returned after lease termination." This exercise is for paper review only and does not represent any real store or completed business action.
Configuration and implementation checks
The table below lists documented settings or implementation checks relevant to this feature and primary task, tied to the exercise above. The values are starting points for this hypothetical trial, used for comparison against another set of settings, and are not official defaults.
| Configuration item | Hypothetical trial starting point | Check method and reason |
|---|---|---|
| AI model | Choose a model that supports the required context length | Compare the model's maximum context and tool-calling capability against the combined length of the sample documents plus follow-up |
| Memory turns | Retain a small number of history turns first | Compare two consecutive turns under the same chatId against a new session without chatId, confirming the difference in carried context |
| Reply ceiling | Set a value that can hold a complete explanation first | Trigger a longer answer with the sample documents plus follow-up and observe whether it is truncated early |
| Temperature | Take a lower value first | Repeat the same question and compare answer stability; lower values suit customer service and rule-based settings |
| Reply format | Keep the default first | Switch to json_schema only when a downstream node needs to read a fixed structure, then fill in the format requirement and verify the returned structure |
| Hide AI output | Keep it off first | Turn it off during debugging to observe intermediate content and confirm whether downstream nodes can continue through the AI reply output |
Three common errors
- Reading "submitted, awaiting regional operations approval" as approval granted, then writing that inventory clearance is complete. The input is the status field in the sample source text; the comparison is between "submitted, awaiting regional operations approval" and "approved", which are mutually exclusive values of the same field, and only the latter satisfies the condition.
- Treating a lease termination agreement at "awaiting landlord signature" as effective and answering a deposit return date on that basis. The input is the agreement status and the deposit return clause; the comparison is against the actual record "no return date stated", and when the document does not state it, only the gap can be recorded.
- Treating a retrieval hit or similarity score as a permission basis and returning records beyond the questioner's accessible range. The input is the questioner's identity and the target retrieval scope; the comparison is whether that scope contains the required documents, and retrieval does not constitute authorisation.
How to verify the setup
- Input the sample source text and the draft sentence "Store A inventory clearance is complete and the deposit will be returned after lease termination", then compare the draft sentence against the three records: "submitted, awaiting regional operations approval", "awaiting landlord signature", and "no return date stated". The expected observation is that the answer states neither the clearance nor the deposit conclusion is supported by the documents and keeps the status as pending verification.
- Input two consecutive follow-up turns under the same chatId, and the same question without chatId. Compare the history content each answer references. The expected observation is that the continued session can reference the previous turn's documents while the new session relies only on the current messages, and the difference in input scope is observable.
- Input an explicit paper empty result
[]as the upstream retrieval output and compare the downstream node's answer design when no reference is present. The expected observation is that the answer states no relevant documents were obtained and does not write business facts; this result is for checking the downstream design only and does not represent any actual retrieval rule return.
All of the above are paper review designs that have not been executed and do not constitute a test, deployment, or business approval conclusion.