What the documents look like
Fresh-food supplier claims pursue responsibility for quality at arrival. They do not handle natural in-store shrinkage, and that boundary shapes the whole document set: quality exception forms, photo evidence, deduction notices and claim reconciliation statements. Quality inspection systems and WMS receiving records supply the batch acceptance conclusion, supplier contracts supply the responsibility and compensation terms, and financial reconciliation supplies the amount basis. Materials update on two rhythms, per batch and monthly, so a monthly settlement document and a batch-level document may cover different time ranges. A multi-turn conversation has to carry both the batch-level evidence and the monthly reconciliation basis at the same time. The prompt therefore needs to state the document scope, the answering task, and how to describe a point that the supplied evidence does not support.
Constraints at the multi-turn prompts step
Multi-turn conversation depends on the context that history records bring in. When a chatId is used to continue a session, the system automatically reads the session from the database and uses the last item of the messages array as the user question, while the remaining messages are ignored. When no chatId is passed, the context is built entirely from the submitted messages. A prompt has to distinguish the input shape of a new session from that of a continued session. The memory turn count controls how many earlier chat turns the AI may reference at most, and customer service and knowledge-base question-answering applications typically keep a small number of history turns. Reply format follows what the downstream step consumes; choosing json_schema requires filling in the corresponding format requirement. Retrieval output does not constitute authorization, and a similarity score does not act as an entity or permission filter.
Hypothetical paper exercise sample: the material text to be checked reads, "Quality exception form Q-0715 states: batch 20260710-03, arrival date 10 July 2026, acceptance conclusion partly non-conforming, quantity involved 40 boxes." and "Deduction notice D-0715 states: corresponding batch 20260710-03, deduction amount calculated per the contract annex, status pending supplier confirmation." The draft sentence to be judged reads, "The supplier has confirmed the deduction, so the claim reconciliation statement can be booked on this basis." The subject, object, status and validity range needed for the judgment all appear in the source text, and the draft turns a pending status into a confirmed one, which goes beyond the source wording.
Configuration and implementation checks
The table below covers the hypothetical exercise above and lists officially described settings or implementation check items relevant to this feature and primary task. The values are starting points for this hypothetical exercise only, with the reason for choosing them and the comparison object stated; they are not official default values.
| Configuration item | Hypothetical exercise starting point | Reason and comparison object |
|---|---|---|
| AI model | Choose a model that supports tool calling and the required context | Compared with the need to read batch number, date and status fields in the sample |
| Memory turns | Keep a small number of history turns | Compared with the documented note that customer service and knowledge-base applications typically keep a small number of history turns |
| Reply cap | Lower as needed to keep answers short | Compared with longer-reply scenarios such as plan generation |
| Temperature | On the low side | Compared with scenarios that are rule-bound and need stable answers |
| Reply format | Keep default; when a downstream step reads a fixed structure, choose json_schema and fill in the format requirement | Compared with whether a downstream node reads a fixed format |
| Multimodal recognition | Decide whether to enable image recognition per model capability | Compared with whether photo evidence enters as an image and whether the model supports images |
Three common errors
- Treating a pending status as a completed status. In the sample the deduction notice status is pending supplier confirmation, while the draft sentence writes it as confirmed, so the input and the source status field do not match.
- Treating retrieval output as an authorization basis. A similarity score reflects matching degree only and does not act as an entity or permission filter, so it cannot be used to conclude that the claim reconciliation statement can be booked.
- Writing a field that the source does not state as a definite fact. The source does not state the supplier reply content or the effective terms, and the draft sentence must not add confirmation or effectiveness wording.
Corresponding checks:
- Input the sample source text and the draft sentence, compare the status field values, and treat the condition as unmet when the draft contains "confirmed" while the source says "pending supplier confirmation."
- Input the quoteList returned by retrieval, compare whether it contains subject and permission identifiers, and treat the condition as unmet when booking is judged from score alone.
- Input the list of fields not stated in the source, compare whether the draft sentence contains a definite statement of such a field, and treat the condition as unmet when it does.
How to verify the setup
- Verification one: input the sample source text and the draft sentence, compare the deduction notice status field, and the condition is met when the draft keeps "pending supplier confirmation" and does not write it as confirmed; if wording such as "confirmed" or "booked" appears, the condition is not met.
- Verification two: input one continued-session request where chatId is non-empty and messages contains only the last user question, compare whether the returned historyPreview matches the expected number of history turns, and the condition is met when it matches; if content beyond the memory turn range is carried in, the condition is not met.
- Verification three: input a clearly stated paper-based empty-result downstream scenario, set the knowledge-base retrieval return to [], compare whether the downstream node handles it through the empty-result branch, and the condition is met when it does; if the downstream node writes the empty result as a hit, the condition is not met. All of the above are paper checks and were not actually deployed or executed.