What the documents look like
Near-expiry markdown handling works on shelf-stock batches, not on item-by-item weighed orders. The main data comes from POS stock age, store inspections, ERP inventory, and quality-check records. The working documents are near-expiry lists, markdown approvals, damage or write-off forms, and promotional price tags. Data updates by day or by shift.
Three consequences matter for this page. A markdown approval needs to name the batch, the store, and the effective time window. Damage write-off and markdown are two different states, and a handover must not merge them. A promotional price tag depends on an approved markdown record; the form only collects what the user fills in and passes it to later nodes. It does not carry a business database of its own.
Constraints at the interactive forms step
When the Form Input node is triggered, the conversation enters an interactive state, the workflow state is recorded, and execution continues after the user finishes the interaction. The User Selection node judges the user's choice and runs the "yes" branch. Neither node is a staff directory or a business-data selector. Field validation, business approval, write-back, and batch operations need an external system or a later node. Retrieval and similarity scores do not perform permission filtering; retrieval is not authorization.
Hypothetical drill sample. A store inspection record dated 10 March 2026 reads: "Store A, batch B-0310, category chilled yogurt, shelf life to 12 March 2026, current status pending markdown, inspector has signed." A damage form from the same day reads: "Store A, batch B-0310, status pending write-off, damage reporter has signed." The handover request to be judged is: "Put batch B-0310 on the shelf at a 30 percent discount and complete the write-off." That request merges two mutually exclusive states and supplies no markdown approval record. A form can collect fields such as batch number, store, discount rate, and requested time window, but whether an approval passed and whether a write-off was executed are actions for a later node or an external system. Submitting the form is not itself an authorization.
Configuration and implementation checks
The table below stays with the sample above and lists only documented settings or implementation checks.
| Configuration item | Role | How to check it against this page's sample |
|---|---|---|
| Form Input node | Enters the interactive state on trigger, collects filled information, passes it to later nodes | Check whether batch number, store, and discount rate are required fields in the sample |
| Required-field check | Lists the information this task cannot omit, tests the missing case and the completed case | Submit with the discount rate missing and observe whether the conversation stays in the interactive state |
| User Selection node | Runs the "yes" branch according to the user's choice | Check whether the option "markdown approval obtained" triggers the corresponding branch |
| Interactive-state record | Records the workflow state after the node triggers and waits for interaction | Check whether the conversation is in the interactive state before submission and continues after it |
| Downstream division of labour | Field validation, approval, and write-back are implemented in an external system or a later node as needed | Check whether the damage form status is updated by an external system; the form does not rewrite it |
Hypothetical trial starting value for this page: the discount rate field is set to 30 percent. The reason for choosing it is that the sample text gives no specific rate, so it must be compared with the rate in the approval record. If the approval record states 30 percent, the two agree; if it states 50 percent, they disagree and the item stays pending verification. This is a starting value for the drill, not an official default.
Three common errors
- Treating form submission as a completed markdown approval. The input is the "pending markdown" status in the sample plus the handover request; the comparison point is whether an approval record exists; the observable result is that "on the shelf at a 30 percent discount" in the request lacks an approval basis and should be recorded as unsupported.
- Merging "pending write-off" and "pending markdown" into one handling action. The input is the two source texts; the comparison point is the status value of the same field for the same batch; the observable result is that two mutually exclusive values appear in one request and should be split into two separate flows.
- Using a similarity score or retrieval hit in place of a permission judgment. The input is the batch record returned by retrieval; the comparison point is whether that record falls within the current store and the current operator's authorization scope; the observable result is that a retrieval hit does not equal an executable markdown and the authorization boundary must be checked separately.
How to verify the setup
- Enter the sample source text and the handover request, compare "on the shelf at a 30 percent discount" in the request against the approval record field, and observe whether a missing-approval-record indication appears. If it is missing, the condition is not met and the item is recorded as pending verification.
- Enter the two status source texts, compare the value of the same field for the same batch, and observe whether "pending markdown" and "pending write-off" are identified as mutually exclusive. If only one is identified, the condition is not met.
- Enter the empty result [] and compare whether the downstream design handles it as "no record", then observe whether a fabricated batch or an automatic release appears. If either appears, the condition is not met. The retrieval check records only what is observed and does not guarantee a first hit or full recall. Libraries using different vector models cannot be associated together; check the identifier first and exclude those that do not match.
This page covers only near-expiry markdown handling, operations permission and handover management, and interactive forms. It does not treat retrieval or a form as an authorization to execute.