What the documents look like
Repair and reship work aims to restore a product to use, and it closes differently from a refund-only dispute. Four source systems hold the records that a multi-turn conversation must treat as checkable facts: the after-sales system holds repair applications, the order system holds order data, repair sites hold inspection reports, and the parts warehouse WMS holds parts outbound records. Records update per order and daily. A repair application states what the customer reported and the receiving date. An inspection report states the diagnosed fault and whether repair is possible. A parts outbound record states which part left the warehouse, in what quantity, on what date, and for what purpose.
A multi-turn prompt can only cite wording that was actually carried into the conversation. When a field is absent from the supplied text, the answer keeps that gap open. This matters because the three stages differ: a part leaving the warehouse, a repair being completed, and a customer confirming normal use are separate facts. Treating one as another produces repeated complaints, overrun repairs, and uncontrolled parts cost. The update cadence does not change the prompt step, so it stays out of the checks below.
Constraints at the multi-turn prompts step
The prompt states the document scope, the answering task, and how to handle missing evidence. It does not let the model write business facts that the records do not contain. History handling requires checking which context was actually carried in, and separating a new session from a continued session. Where a knowledge base supports continuous dialogue, check that references are resolved and the question is expanded, without assuming every short question needs it. Model and length settings need checking against the context the model supports and the reply settings in use. Reply format follows the downstream consumer; when json_schema is selected, the format requirement is filled in and the returned structure is verified.
Hypothetical drill sample. Text supplied for checking: repair application WX-0417 states "customer reported the unit does not heat; received 2025-04-17; inspection at the site in progress." Inspection report JC-0417 states "heating element open circuit; judged repairable; part required HE-220." Parts outbound record CK-0417 states "HE-220 outbound 1 piece, 2025-04-18, purpose repair." Draft sentence to be judged: "The part has been shipped from the warehouse, the repair is complete, and the customer can use the product normally." This sentence turns an outbound status into a completed repair. The supplied text states no repair completion and no customer confirmation, so the sentence is not supported.
Configuration and implementation checks
| Configuration item | Value or check on this page | Basis and note |
|---|---|---|
| AI model | Choose a model whose tool-calling capability is shown as supported | Model capability determines which configuration items appear |
| Memory turns | Hypothetical starting point 3 turns, compared with 1 turn and 6 turns for whether WX-0417 remains in context | Customer service keeps a small number of history turns |
| Temperature | Hypothetical starting point on the low side | Customer service and rule-bound scenarios suit lower values |
| Reply format | Default for ordinary question answering; select json_schema and fill the format requirement when a fixed structure is read downstream | Chosen by the downstream consumer |
| Multimodal recognition | Enable only when the model supports it and the input contains images | Requests are filtered against model capability before sending |
| Thinking configuration | Simple question answering may use "no thinking"; a complex judgment may use a higher level | Strength aligns with reasoning_effort |
Three common errors
- Treating a parts outbound record as a completed repair. The input is the draft sentence and the CK-0417 text; the comparison is between the "outbound" field and the "repair complete" field; the outbound record states no repair completion, so the sentence is unsupported.
- Treating a retrieval hit as authorized execution. Retrieval returns text fragments only. Business verification and database writes need their own downstream implementation, and a hit does not mean a reship can be executed.
- Treating a similarity value as an entity filter.
similarityis a relevance number and does not carry permission or entity isolation, so it cannot be used to exclude unrelated business records.
How to verify the setup
- Input the supplied source text and the draft sentence, then compare whether the draft states a status the source text does not contain. If "repair complete" appears while the source text only records an outbound part, the sentence is unsupported. The expected observation is that the draft is flagged; whether the model actually flags it remains unverified until run.
- Input two requests, one for a new session and one continuing a session, then compare the context carried in each. The continued session is expected to include WX-0417; the new session is expected not to. What the platform actually carries in each case stays unknown until observed.
- Input an empty result
[]together with the downstream design, then compare how the downstream handles a no-reference output. The check confirms the downstream treats it as a no-reference case; it does not assume that a fictional rule always returns[].