What the documents look like
Fresh-food supplier claims pursue quality responsibility for goods on arrival. They do not handle a store's natural shrinkage, and that boundary fixes which records belong in an operating report or an exception review. The document chain is a quality exception note, photographic evidence, a deduction notice, and a claim reconciliation statement. The supporting systems are the quality inspection system, WMS receiving, supplier contracts, and financial reconciliation. Updates occur per batch and per month, so a review has to keep single-batch evidence separate from the monthly roll-up. The tool-call step works across these structured and unstructured materials. Plugins bring external system capability into the flow, and nodes decide when each kind of material is drawn in.
Constraints at the tool calls step
A tool description tells the model what the tool is for. It needs to state the input conditions and the situations in which the tool should not be called. Tool parameters divide into fixed parameters for system modules and configurable parameters for plugins. A parameter description is not an execution guarantee. When a required parameter has no suitable value in context, the model may decline to call the tool, so the missing value has to be supplied through interaction and the actual request checked afterwards. In advanced orchestration, available tools are connected to the tool call module, and the documented advice is to tune a small number of tools before adding more. The tool call termination node ends the current tool call and also stops the AI from summarising the tool result. Retrieval itself carries no authorization duty; semantic recall and relevance scores do not perform permission or entity separation.
Hypothetical paper exercise. A batch of fresh produce arrives. The quality inspection system records that part of the batch fails the acceptance standard. The WMS receiving note states a rejected quantity. The supplier contract carries a quality responsibility clause. Financial reconciliation holds one deduction awaiting confirmation. The three source sentences to be checked are: the quality exception note states "Batch A-2401, category leafy vegetables, acceptance conclusion partly non-conforming"; the WMS receiving note states "Batch A-2401, rejected quantity a number of crates"; the deduction notice states "For Batch A-2401, proposed deduction amount pending supplier confirmation". The draft sentence under review is "The claim for Batch A-2401 has been paid out." That draft touches subject, batch, and status. The source sentences show the deduction notice still awaiting confirmation. A completed payout is not recorded in the source text.
Configuration and implementation checks
The table below uses the same exercise and lists settings or implementation checks that the official text describes.
| Configuration item | Setting or check | Relation to this exercise |
|---|---|---|
| Tool description | State the purpose and the situations where the tool should not be called | The claim lookup tool should say it returns material records only and does not determine payout status |
| Tool parameters | Check fixed system-module parameters and configurable plugin parameters separately | Batch number, category, and date range serve as query parameters; a parameter description is not an execution guarantee |
| Required parameters | With no suitable required parameter, the model may not call the tool | Without a batch number the model may not call the lookup, so the value is supplied through interaction |
| Tool connection | In advanced orchestration, connect available tools to the tool call module | Tune a small number of tools first rather than adding many at once |
| Tool call termination | The termination node ends the current tool call and stops AI summarisation | Attach it after material checking so an unconfirmed status is not summarised |
| Custom tool variables | Add variable descriptions for nodes not treated as tool parameters | Connect the deduction notice node so the lookup covers that material |
Three common errors
- Treating a parameter description as an execution guarantee. The input is the plugin parameter description text; the comparison is whether that parameter value actually appears in the request; the observable result is whether the request carries the corresponding value. A description present while the request lacks the value shows the description does not guarantee execution.
- Treating a pending status as a completed payout. The input is the deduction notice wording "proposed deduction amount pending supplier confirmation"; the comparison is the draft sentence "The claim for Batch A-2401 has been paid out"; the observable result is whether the status fields agree. The source does not record a completed payout, so the draft sentence is unsupported.
- Treating retrieval output as an authorization basis. The input is a material list returned by one tool call; the comparison is whether the current operator holds permission to reach that batch's financial reconciliation; the observable result is whether the returned records fall inside the authorized scope. A returned record does not show the operator may execute a deduction or a synchronization.
How to verify the setup
- For the draft sentence "The claim for Batch A-2401 has been paid out", the input is the three source sentences from the quality exception note, the WMS receiving note, and the deduction notice. The comparison is the status description in the draft against the status field in the source text. The expected observation is that no completed payout record exists in the source, so the draft sentence is marked as awaiting verification. Only if a completed payout record appears with matching subject, batch, and field does the support condition hold.
- For the missing required parameter, the input is one query request without a batch number. The comparison is whether a tool call is actually issued. The expected observation is that the model may not call the tool, and the batch number is supplied through interaction before the actual request is checked again. Only if the batch number appears in the request and a result returns does the call condition hold.
- For the retrieval scope check, the input is one query that returns an empty result. The comparison is whether the downstream design handles an empty result as empty. The expected observation is that the downstream does not read an empty result as the absence of claim records. Only if the downstream design distinguishes an empty result from a query not run does the check condition hold. Libraries built on different vector models cannot be associated together; verify the identifier first, exclude non-matching libraries, and record the actual observation without inferring missed recall or redundant results.
This page covers one combination only: fresh-food supplier claims, operating reports and exception reviews, and tool calls with plugins. At handover, the state of materials, actions, and requests, and whether any authorization exists, cannot be read from retrieval output or from a form.