What the documents look like
Permit handling for import and export occurs before customs declaration and determines whether a shipment may lawfully cross the border. The working materials for one shipment include an automatic import licence, a dual-use item licence, the contract, and the product description. Data comes from the commerce authority system, customs commodity codes, supplier materials, and the customer's statement of use. These materials are updated per shipment, and the content differs from one shipment to the next. Progress and approval status are followed shipment by shipment.
In a multi-turn conversation, a customer often asks several connected questions about the same shipment: which licence type applies, how the statement of use should be worded, and what the current approval status is. Whether earlier turns are carried into the reply affects how coherent the answer is. The prompt must state the material scope, the answering task, and how to behave when evidence is missing. The model must not supply business facts on its own. The history setting determines how much earlier conversation is available for a follow-up question, and a new session differs from a continued session in what is sent. For knowledge-base continuous dialogue, reference resolution and question expansion need checking, and short questions do not all qualify. The context length and reply ceiling supported by the model need to be checked together with long documents and follow-up combinations. The reply format is chosen according to what comes next; when json_schema is selected, the corresponding format requirement must be filled in and the returned structure checked.
Hypothetical paper exercise: a trade compliance staff member asks connected questions about one shipment. The material text supplied for checking reads: "The goods in this shipment are ball screws for CNC machine tools; the supplier's product description states they are used in metal-cutting machine tool assembly." "Contract number HT-2024-0317, signing date 17 March 2024; the goods amount and delivery terms are governed by the contract body." The draft sentence to be judged reads: "This shipment has obtained a dual-use item licence and shipment can be arranged." That draft sentence carries no licence number, issue date, or validity scope, so it is an unsupported statement.
Constraints at the multi-turn prompts step
The prompt defines what the model may treat as source material. For this category, the material scope is the automatic import licence, the dual-use item licence, the contract, and the product description, together with the supplier materials and the customer's statement of use. The answering task is order fulfilment and after-sales explanation, not licence application and not customs declaration. When a required field is absent from the supplied material, the reply states that the field is unknown rather than filling it in.
History handling is a separate condition. A request that carries a chatId continues an existing conversation, and the system takes the session from its database and uses the last message as the user question; other messages are ignored. A request without chatId builds context entirely from the supplied messages. The two cases produce different available context, so a follow-up answer must be checked against what was actually carried in.
Model and length settings interact with long documents and follow-up questions. The maximum context shown for a model is the length of content a single request may reference, and a larger value suits long documents and long conversations. The reply ceiling limits how long one answer may be; set too low, a reply may be cut off early. The temperature setting controls stability, and a lower value suits customer service and knowledge-base question answering. Top_p also controls randomness and overlaps with temperature; adjusting both at once is not usually recommended. A stop sequence ends output when the specified content appears, and ordinary chat does not need one.
Reply format follows the downstream consumer. Ordinary customer service and knowledge-base answers keep the default. When a later step needs to read fixed-format content, json_schema is selected and the corresponding format requirement is filled in. Multimodal recognition depends on the model's own capability; the selectable types follow the model, and unsupported types are filtered again before the request is sent. A media link inside a user question is parsed only after link extraction is enabled, and that extraction is attempted only when the user question is under 500 characters and processes at most 4 media links per request. Ordinary document files are not sent directly to the model as multimodal input; their content still needs file parsing into text.
Configuration and implementation checks
The table below lists settings or implementation checks relevant to this page's feature and primary task. The hypothetical starting values are for this paper comparison only and are not official defaults.
| Configuration item | Hypothetical starting value for this exercise | Reason and comparison method |
|---|---|---|
| Memory turns | Keep a small number of history turns | Customer service and knowledge-base applications usually keep a small number of history turns; compare with the length of the connected licence-type questions in the sample |
| Reply ceiling | Opened, set to a medium length | The sample needs a complete explanation; compare with truncation, observing whether the reply stops early |
| Temperature | Low | Customer service and knowledge-base question answering call for a low value; compare with stable answers in rule-clear scenarios |
| Reply format | Default | Ordinary customer service keeps the default; switch to json_schema only when a later step needs to read fixed-format content |
| Multimodal recognition | Image recognition enabled according to model capability | The sample includes a product description screenshot; compare with the supported types shown in the model dialog |
| Hide AI output | Off | The final reply must be shown to the customer; compare with temporarily enabling it during debugging to observe intermediate thinking |
Three common errors
- The prompt does not state the material scope or how to handle missing evidence, so the model writes a licence-obtained conclusion directly onto the sample draft sentence. Check: input the sample material text and the draft sentence, compare whether the draft sentence contains a licence number, issue date, or validity scope that the material text does not carry; if any appears, the condition is not met.
- When continuing a session, the history actually carried in is not checked, and a new-session input is treated as continued context. Check: compare the messages of two requests under the same chatId with the session retrieved from the database, and observe whether the follow-up answer cites information that did not appear in the earlier turn.
- After selecting json_schema, the corresponding format requirement is not filled in, and the returned structure is assumed to be fixed. Check: input the format requirement text, compare whether the returned content contains the expected fields; a missing field remains to be verified.
How to verify the setup
- Input the sample material text and the draft sentence, compare whether the reply relies only on the material text, and observe whether the draft sentence is adopted as a licence-obtained conclusion. If licence information not carried in the material text appears, the condition is not met.
- Input two connected follow-up questions under the same chatId, compare whether the second reply cites the goods information confirmed in the first turn, and observe whether a licence status not mentioned earlier appears. Citing information that did not appear earlier remains to be verified.
- Input the explicit paper input [] to check the empty-result handling design, compare whether the downstream reply treats it as no retrieval result, and observe whether a licence conclusion is generated from nothing. If a conclusion is generated, the condition is not met. The retrieval check records only actual observations and does not guarantee a first hit or that an unrelated query returns empty.
This page addresses only import and export permit handling, order fulfilment and after-sales explanation, and multi-turn prompts. At operational handover, which materials, operations, and requests sit at which authorisation state cannot be treated as authorisation execution by retrieval or by a form. Retrieval is not authorisation, and a relevance score is not a category, entity, or permission filter. Forms collect values; business verification, approval, database writes, and external synchronisation require their stated downstream implementation. A pending request is not approval, an offered option is not execution, and an unsigned termination is not a completed termination. Where a document field is not provided, it remains unknown.