What the documents look like
Near-expiry markdown handling works on the remaining sellable time of shelf inventory. This differs from weighing and sorting, which measures each order item by item. Store staff produce four document types: near-expiry lists, markdown approvals, damage reports and promotional price tags. These draw on POS stock age, store inspections, ERP inventory and quality inspection records. The update rhythm is daily or per shift, and the store service and internal training step uses these materials to judge which batches have entered a pending state and which markdown requests remain under review.
Document status itself forms a handover condition. A near-expiry list records batch and remaining days. A markdown approval records the request and the approval opinion. A damage report records the disposal outcome for unsellable goods. A promotional price tag corresponds to the actual shelf price. These four document types sit at different positions in the authorization chain. A retrieval hit on a list only shows that the text exists; it does not show that a markdown was approved or that goods were isolated.
Constraints at the workflow routing step
When a form input node triggers, the conversation enters an interaction state and the workflow state is recorded. After the user completes required fields and submits, the node collects the form information and passes it to later nodes. A user selection node also enters an interaction state; after the user makes a choice, the node judges that choice and executes the corresponding branch. Both node types are user interaction nodes, can be added repeatedly, and trigger execution. The interaction state and state recording are behaviors of the node itself and do not constitute a global state-recording switch.
Collected information must be explicitly passed to later retrieval, judgment or interface nodes, and outputs must be compared item by item against inputs. Order writes, document backfill and external status synchronization require a separate business interface or later flow. Form submission does not produce an authorization effect. Retrieval results and similarity scores do not carry permission or entity-isolation duties; a matched text does not mean an operation has been approved.
Hypothetical drill sample: a store submits a near-expiry list. The source text reads: "Object: low-temperature yogurt batch A, remaining sellable days 2, status is pending determination; the markdown approval form states 'request 10% discount, approval opinion field blank'; no damage report has been generated." A separate draft handover sentence reads: "This batch's markdown has been approved, isolation may be executed and external inventory synchronized." The subject, object, status and effective scope needed for the judgment all appear in the source text. A blank approval opinion field means approval is incomplete, and the claim of approval in the draft sentence is unsupported.
Configuration and implementation checks
| Configuration item | Relevant setting or check on this page | Check method |
|---|---|---|
| Form input node | Enters interaction state on trigger and collects required information; passes it to later nodes after submission | Compare submitted values with values actually received by later nodes |
| User selection node | Executes the corresponding branch after the user makes a choice | Verify branch connections against choice results one by one |
| Interaction state check | State recording is a behavior of interaction nodes | Observe actual entry into and exit from the interaction state |
| Output handover check | Collected information is explicitly passed to retrieval, judgment or interface nodes | Compare node inputs with downstream outputs item by item |
| External operation division | Order writes, document backfill and external synchronization require a separate interface or later flow | Confirm whether a corresponding handover node exists in the flow |
| Hypothetical trial starting point | This drill treats the blank approval opinion field as a pending-verification state; this starting point is chosen because the source text states no approval conclusion, and it is compared with a sample that has a filled approval opinion | Record differences between the two samples in downstream branches |
Three common errors
- Treating form submission as completed markdown approval. If the submission action in the sample above is taken as approval, downstream branches run on the approved path, while the source text leaves the approval opinion field blank; that conclusion is unsupported.
- Treating a retrieval hit on a near-expiry list as operation authorization. The existence of list text only shows the material is readable; it does not show the store has been permitted to mark down or isolate, and these are different facts.
- Treating execution of a user-selected branch as external inventory already synchronized. Branch execution is an internal workflow path; external status synchronization requires a separate business interface, and the node itself does not complete that action.
How to verify the setup
- Input the hypothetical source text and draft handover sentence above, compare the draft sentence's claim of approval with the blank approval opinion field in the source text, and observe whether the system misjudges the pending-verification state as approved. If the output matches the source status, this check meets the condition.
- Input the same batch list text, compare the retrieval hit result with the authorization status field, and observe whether a judgment substitutes a hit for authorization. If the hit and the authorization are presented separately, this check meets the condition.
- Input an explicit paper empty result [], compare whether downstream nodes accept it as designed for empty input, and observe whether fabricated rules are returned. If downstream handles it as empty input and does not supply invented content, this check meets the condition.