What the documents look like
Brand after-sales repair work turns on warranty responsibility and physical repair outlets, so the materials in scope go beyond platform refund handling. The documents handled per repair case are warranty cards, repair work orders, inspection reports and replacement approvals. Each records a different part of the same event: the purchasing party, the repaired object, the fault state and the scope of an approval. The same field can carry mutually exclusive values across two documents. Materials update per order and daily, but that update rhythm does not change the conditions under which a tool call runs; the tool call step reads the text carried by the current request.
For this page the primary task is contract and transaction material comparison. A comparison request supplies source document text together with a drafted judgment sentence or handover request, and the tool step is expected to check whether the drafted wording is supported by the supplied text.
Hypothetical drill sample, created for this page only and not drawn from any real record: the warranty card states the purchaser is Party A, the product serial number is A-001, and the warranty period runs to 31 March 2026. The repair work order states the report date is 10 April 2026 and the fault description is a cracked screen. The replacement approval form states the approval status is pending review. The drafted judgment sentence to be checked reads: "The product is within the warranty period and the replacement has been approved." This sentence merges two separate facts, and pending review is not approval.
Constraints at the tool calls step
A tool introduction tells the model what the tool is for, so it needs to state the input conditions and the situations in which the tool should not be called. For system modules the tool parameters are already fixed; for plugins the tool parameters are configurable. Each parameter carries a parameter description and a required flag. Where a required parameter has no suitable value in context, the model may decline to call the tool, and interaction can be used to prompt the user to supply the value, after which the actual request is checked. In advanced orchestration, available tools are connected to the tool call module by joining the diamond connectors, and the introduction of a connected tool can be edited so the call timing is more precise. The documentation recommends adding few tools at a time and tuning before expanding.
The tool call termination node ends the current call. When the workflow reaches it, no further tools are called and the AI is not asked to summarize the tool results. Retrieval and similarity scores do not perform permission or entity isolation, and retrieval on its own is not authorization. Whether a document, operation or request is authorized at handover depends on the surrounding business process, not on a search hit or a form entry.
Configuration and implementation checks
| Configuration item | Setting or check relevant to this page | Relation to the sample |
|---|---|---|
| Tool introduction | State input conditions and situations where the tool should not be called | The drafted sentence spans warranty period and approval status |
| Tool parameters | Check plugin configurable parameters and required flags | The material text and drafted sentence are passed in |
| Required parameters | Where no suitable value exists, the model may not call the tool | The sample carries complete values, so the call can proceed |
| Tool connection | Connect available tools in advanced orchestration | Connect one comparison tool first |
| Tool call termination | Ends the current call and stops AI summarization | Attach after comparison when no summary is wanted |
| Hypothetical trial starting value | Similarity threshold set to 0.7 as a paper-trial starting point, chosen to make hits and misses easy to observe, compared against returned item counts for the same query at other thresholds | Used for this hypothetical trial only, not an official default |
Three common errors
- Treating pending review as approved. In the sample the replacement approval form carries the status pending review, while the drafted sentence states the replacement has been approved. The input is the approval form text, the compared field is the approval status, and the observable result is that the status value does not match the drafted claim.
- Merging warranty period and approval status into one finding. In the sample the warranty period ends 31 March 2026 and the report date is 10 April 2026, while the drafted sentence states the product is within the warranty period. The input is the warranty card and the work order, the compared fields are the two dates, and the observable result is that the report date falls after the warranty end date.
- Treating a retrieval hit as authorization. In the sample the replacement approval form is retrieved, and the drafted sentence relies on that retrieval to state approval. The input is the retrieval result, the comparison is between the retrieval result and the approval status field, and the observable result is that the retrieval hit does not change the pending review status.
How to verify the setup
- Input the sample material text and the drafted sentence, then compare the phrase "within the warranty period" against the warranty card end date and the work order report date. If the report date falls after the end date, that part of the drafted sentence is not supported. The expected observation is a date mismatch; the comparison is not a claim that any test was run.
- Input the replacement approval form text and compare "has been approved" against the approval status field. If the status is pending review, that part of the drafted sentence is not supported, because pending review does not constitute approval. The expected observation is a status mismatch.
- Input an empty result list
[]and check how the downstream design handles it; this is an empty-result handling check and does not assert that a retrieval over invented rules will return an empty list. Libraries built on different vector models cannot be associated together, so identifiers are checked first and non-matching libraries are excluded, with the actual observation recorded. What remains unknown is any downstream behaviour that the documentation does not describe.