Near-expiry markdowns: tool calls for document comparison

Review tool calls for document comparison in Near-expiry markdowns. Check document scope, failure paths and source evidence through controlled tests.

What the documents look like

Near-expiry markdown handling tracks the remaining shelf life of stock rather than weighing and sorting individual order lines. Store staff produce a near-expiry list by shift or by day through shelf inspection, and that list moves through markdown approval, damage or loss reports, and promotional price tags. Document comparison for this category checks whether the subject, item, batch, period, and status agree across those materials. POS stock age, ERP inventory, quality inspection records, and store inspection each arise independently, so one batch can sit at different stages in a markdown approval, a damage report, and a promotional price tag. The tool call and plugin layer treats these materials as callable inputs, retrieves them on demand, and hands them to the model for comparison. Because the materials update daily and by shift, a comparison run reflects the state of the retrieved documents at the time of retrieval, and later store actions are not part of that state.

Constraints at the tool calls step

The tool call node decides whether to invoke a tool from three pieces of information: the tool introduction, the parameter introduction, and whether each parameter is required. System module parameters are fixed; plugin parameters are configurable. When a required parameter has no suitable value in context, the model may decline to call the tool, and a prompt can guide the user to supply the value. When no parameter is required, the model may still call the tool and may fabricate a parameter value. In advanced orchestration, available tools must be connected to the tool call module, and the documented guidance is to start with a small number of tools and tune before adding more. The tool call termination node ends the current call, stops further tool calls, and stops the AI from summarizing tool results. A custom tool variable can extend the variable inputs of a tool so that a node not treated as a tool parameter can still be invoked with a description attached.

Hypothetical paper exercise, labelled as such and involving no real party. Material one (markdown approval, hypothetical reference SP-001): subject is a fresh produce store, object is a batch of leafy vegetables, markdown effective date is 10 March 2025, approval status is "pending review." Material two (promotional price tag, hypothetical reference JQ-001): same store and same batch, tag print date is 10 March 2025, tag status is "printed." Draft sentence to be assessed: "The markdown for this batch took effect on 10 March 2025." The fields needed for the judgment are approval status and effective date. Material two records only that the tag was printed and states no approval outcome.

Configuration and implementation checks

The table below is a hypothetical starting point for this page, not an official default. Reason for the selection: the exercise holds two materials and one draft sentence, so the parameter scope needs to cover that input while leaving room for manual review.

Configuration itemHypothetical starting point on this pageWhat it is compared with
Tool introductionState that the tool compares subject, batch, date, and status across markdown approval and promotional price tagField-by-field against the exercise materials
Tool parameters (plugin)Input material reference, field name, field valueContent actually stated in the material text
Required parametersMaterial reference and field name to be judged set as requiredWhether a completion interaction occurs when they are absent
Tool connectionConnect only the comparison tool and the retrieval toolWhether an unconnected tool is invoked
Tool call terminationPlaced after the comparison toolWhether AI summarization still runs after termination
Custom tool variableAdd a "field value source" descriptionThe source annotation in the exercise fields

Three common errors

  1. Treating "pending review" as already effective. In the exercise, material one carries approval status "pending review." If the draft sentence states "took effect," the input is the status field of material one, the comparison object is the requirement of effectiveness, and the observable result is that the draft sentence does not agree with the status recorded in material one.
  2. Inferring completed approval from a printed price tag. Material two states only the tag print date and tag status, and records no approval outcome. The input is all fields of material two, the comparison object is the approval status field, and the observable result is that material two does not supply that field, so the point remains unsupported.
  3. Treating tool call termination as completing the comparison. The termination node ends the call and blocks AI summarization; it produces no comparison conclusion. The input is the position of the termination node, the comparison object is whether a comparison result is output, and the observable result is no conclusion output, which requires manual review.

How to verify the setup

  1. Take material one and the draft sentence. Input the approval status field and the effective date field, compare the draft wording "took effect" against the "pending review" status in material one, and observe that the two do not agree, so the draft sentence does not hold.
  2. Take material two. Input the tag print date and tag status, compare whether an approval outcome is stated, and observe that the field is absent. The result is recorded as pending verification, not as a denial or a conflict.
  3. Take the hypothetical empty input [] and check whether the downstream design distinguishes an empty result from "no material." Observe that the downstream treats it as an empty input, and do not infer that a retrieval over invented rules necessarily returns [].

A pending approval request is not an approval, a printed tag is not an executed markdown, and an unsigned termination is not a completed termination. Retrieval and form entry collect or return values; business verification, approval, database writes, and external synchronization require their own downstream implementation. Where a document field is not provided, its value remains unknown.