What the documents look like
Near-expiry markdown work tracks the remaining shelf life of stock already on display, which is a different operating shape from weighing and sorting goods one order at a time. Store inspections, ERP inventory, POS stock-age records and quality-inspection records together form the evidence base for markdown decisions, refreshed daily or by shift. Drafting product and marketing copy lands on four document types: the near-expiry list, the markdown approval, the damage report and the promotional price tag. Copy that touches markdown range, sellable status or consumption deadline can turn a spoilage-management issue into a food-safety complaint when a sentence is not supported by the underlying material.
Constraints at the multi-turn prompts step
The value of multi-turn dialogue here is converting one near-expiry list item by item into checkable copy while keeping the context of each follow-up question. The prompt needs to state the material scope, the answering task, and how to behave when evidence is insufficient; the model does not fill in batch numbers, dates or approval conclusions on its own. A continued session and a new session carry different context, so verification distinguishes what each actually sends. Short questions inside a running conversation may need reference resolution; whether question optimisation is enabled depends on the actual needs of continuous knowledge-base conversation, and not every short question qualifies by default. The model's maximum context and reply ceiling determine whether a long list and repeated follow-ups fit, and the reply format follows whether a downstream node reads a fixed structure; choosing json_schema requires filling in the corresponding format requirement and checking the returned structure.
Hypothetical paper exercise: the three source sentences supplied for checking are "Store inspection record: the object is one batch of leafy vegetables, status is near-expiry, the suggested markdown range is to be set by the store manager after approval. Markdown approval form: the markdown range for this batch is pending approval, approval status is pending review. Damage report: the same batch has not yet been reported as damage." One draft sentence to be judged is "This batch of leafy vegetables has passed markdown approval and can be purchased with confidence." The judging point is that the material shows pending review only, while the draft sentence writes pending review as passed, which is a same-field value mismatch and must be returned for revision.
Configuration and implementation checks
| Configuration item | Relevant value or check on this page | Basis and explanation |
|---|---|---|
| AI model | Select a model that supports the required context length | Maximum context determines whether a long list and repeated follow-ups fit |
| Memory turns | Hypothetical trial starting point of a small number of turns, compared against output with history disabled | This value is a hypothetical starting point for this exercise, not an official default; too few turns cannot use earlier text |
| Reply ceiling | Adjust to the copy length needed, compared against truncation symptoms | Set too low, replies are cut early; set higher, consumption rises |
| Temperature | Use a lower value for drafting, compared against more stable output | Markdown copy touches sellable status, so stability comes first |
| Reply format | Choose json_schema when a downstream node reads a fixed structure, and fill in the format requirement | Ordinary question answering keeps the default |
| Multimodal recognition | Enable only when the model supports it and image input is genuinely present | The dialog shows available options according to model capability |
Three common errors
- Writing "pending review" as "approval passed". The input is the markdown approval form text above; the comparison is the value of the approval-status field; the observable error result is that the draft sentence and the material hold mismatched values in the same field.
- Letting the model fill in a batch date or consumption deadline. The input is an inspection record that contains only near-expiry status and no specific date; the comparison is whether the draft sentence contains a date the material does not carry; the observable error result is that the copy adds time information with no source.
- Treating retrieval similarity as a sellable-range or permission filter. The input is a similarity value returned by one knowledge-base retrieval; the comparison is that value against the approval-status field; the observable error result is treating relevance as a basis for authorisation.
How to verify the setup
- Input the three source sentences of the hypothetical exercise above together with the draft sentence "This batch of leafy vegetables has passed markdown approval and can be purchased with confidence." Compare the draft sentence against the approval-status field of the markdown approval form. If the two values are mutually exclusive, judge it as inconsistent and return it. The expectation is that this inconsistency is identified; no actual test is claimed.
- Input an inspection record that contains only near-expiry status and no date, together with a draft sentence that requires a consumption deadline. Compare whether the draft sentence contains a date the material does not carry; if it does, judge it as unsourced addition. The expectation is that the sentence is flagged for verification.
- Input one retrieval that returns an empty result, written as []. Compare the downstream node's output design under empty references and observe whether it handles the case as missing evidence. The expectation is that the downstream does not fill in business facts and that missing evidence stays missing.
Retrieval similarity carries no permission or entity-isolation duty. Libraries across different vector models cannot be associated together; check the identifiers first, exclude those that do not match, and record only what is actually observed. A node's existing behaviour, a configurable field, a manual checking action and a business action that needs a separate system implementation are treated separately. Interactive waiting and record status follow the documentation, and no control switch or automatic judgement that the documentation does not describe is assumed to exist.