What the documents look like
Near-expiry markdown handling follows the shelf-stock lifecycle. It does not follow the order-by-order weighing and sorting pattern. The main data sources are POS stock age, store inspections, ERP inventory, and quality inspection records. Daily documents include the near-expiry list, markdown approval, damage report, and promotional price tag. The update frequency is daily or per shift. The three most time-consuming steps are identifying near-expiry batches, approving markdowns, and isolating unsellable goods. A tool description needs to state the input conditions and the situations in which the tool should not be called, so the model can decide whether to initiate a call.
A near-expiry list carries a batch identity, an expiry date, and a status value. A markdown approval carries a pending or approved state. A damage report and a promotional price tag each carry their own scope. Tool calls depend on these materials because the model reads the tool description and the parameter descriptions together to decide whether a call is appropriate.
Constraints at the tool calls step
A tool consists of an introduction and parameters. System module parameters are fixed. Plugin parameters are configurable. Two key parameter values are the parameter description and whether the parameter is required. When no parameter is required, the tool may still be called even if no suitable parameter appears in the context, and the model sometimes fabricates a parameter. When a required parameter is missing, the model may not call the tool, and prompt wording can guide the user to supply it. In advanced orchestration, available tools are connected to the tool call module, and the guidance is to start with a small number of tools before tuning further. The tool call termination node ends the current call, stops further tool calls, and stops the AI from summarizing the tool result. Custom variables extend the inputs so that nodes not treated as tool parameters can enter the call chain.
Hypothetical paper exercise sample: at one store, on the shift of 10 March 2026, an inspector submits a paper near-expiry list. The source text reads: "Chilled yogurt, 6 boxes, shelf life until 12 March 2026, current status pending markdown approval." A draft handover sentence reads: "This batch has completed markdown approval and can be executed against the promotional price tag." The comparison material shows only pending markdown approval and contains no approval record. The request remains undetermined and cannot be treated as authorized for execution.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this exercise | Comparison method and reason |
|---|---|---|
| Tool introduction | State that inputs are the near-expiry list, markdown approval, damage report, and promotional price tag | Check whether the introduction covers input conditions and the situations in which the tool should not be called |
| Required parameter | Set batch identity and status as required | Observe whether the model does not call when these are missing, then check the actual request |
| Tool connection | Connect only the near-expiry list check and the approval status query | A small number of tools supports tuning and avoids adding too many at once |
| Tool call termination | Place after the approval status query | Check whether the current call ends and whether AI summarization is no longer invoked |
| Custom variable | Write a parameter description for the inspection record node | Check whether the call chain includes that node and its downstream workflow |
These values are starting points for this hypothetical exercise. The reason for choosing them is that they cover the material range in the sample, and the comparison object is the fields present in the sample source text.
Three common errors
- Treating pending markdown approval as completed markdown approval. The sample source text states only pending markdown approval, while the draft sentence states completion. Compare the status fields in the two texts and observe whether the same field carries mutually exclusive values.
- Treating a tool parameter description as an execution assurance. A parameter description explains purpose. It does not make the model call the tool or return an expected result. Check the actual request and the actual return.
- Treating a retrieval result as authorization to execute. Retrieving a near-expiry list does not mean approval was granted. Business verification, approval, and database writes need downstream system implementation.
How to verify the setup
- Enter the sample source text "Chilled yogurt, 6 boxes, shelf life until 12 March 2026, current status pending markdown approval." Compare the draft sentence "This batch has completed markdown approval" against the status field in the source text. The execution condition is met only when the source text contains an approval record.
- Enter the sample handover request. Compare whether the tool call is not initiated because a required parameter is missing. Observe whether the batch identity and status appear in the actual request. When they are missing, record the result as unsupported.
- Enter the sample material range. Compare whether the tool call termination node ends the current call after the approval status query. Observe whether AI summarization of the tool result is no longer invoked. When no termination behavior is observed, record the result as pending verification.
These checks describe what to compare and what to observe. They do not report an actual test, deployment, approval, refund, or other business action.