What the documents look like
Order fulfilment and after-sales question handling in retail checkout and loyalty promotion draws on four recurring document types: promotional price tags, membership points rules, the daily checkout report, and abnormal refund forms. The comparison target here is price and membership entitlement. Short-shelf-life inventory sits outside this page. Data sources named in the brief are the POS system, the membership CRM, the payment platform, and the price tag system. Update frequency is daily or per shift. A promotional price tag determines the amount due at the checkout moment. A membership points rule determines the calculation basis for entitlement. The daily checkout report records the transaction summary for a shift. An abnormal refund form carries the original evidence of an after-sales dispute. Workflow routing treats these materials as inputs, collects information through a form input node or a user selection node, and passes the collected values to later nodes.
Constraints at the workflow routing step
The form input node is a user interaction node. When it triggers, the conversation enters an interaction state, the workflow state is recorded, and after the user completes the required fields and submits, the node collects the submitted form information and passes it to later nodes. The user selection node is also a user interaction node. When it triggers, the conversation enters an interaction state and the workflow state is recorded. When the user makes a choice, the node evaluates that choice and executes the corresponding "yes" branch. Both nodes can be added repeatedly and trigger execution. The interaction state is behaviour of these nodes. No separate global state-recording switch is documented.
Collected information must be passed explicitly to later retrieval, decision, or interface nodes, and output must be compared against input item by item. Order writes, document backfill, and external status synchronisation require a separate business interface or a later process. Retrieval and form submission do not by themselves constitute authorised execution.
Hypothetical drill sample, clearly labelled as invented for this page: a store's daily checkout report for 12 March 2025 records a promotional price tag reading "member price 9.9 yuan", a membership points rule stating "members earn 1 point per 10 yuan spent", and an abnormal refund form stating "the customer claims settlement at 9.9 yuan but the receipt shows 12.9 yuan". The draft sentence to be assessed is: "This order was settled at the member price and the points were correctly credited." Checking requires comparing the receipt amount, the price tag text, and the points rule, and judging whether the draft sentence has material support.
Configuration and implementation checks
The table below covers the sample above and lists documented settings or implementation checks relevant to this feature and the primary task. The values are hypothetical starting points for this exercise, given to explain the reason for the choice and the comparison method. They are not official defaults.
| Configuration item | Hypothetical starting point for this exercise | Check note |
|---|---|---|
| Form input node | Enabled, collecting order number and disputed amount | Enters interaction state on trigger; passes information after submission |
| User selection node | Enabled, branches "agree to refund" and "escalate to human" | Executes the corresponding "yes" branch after the user chooses |
| Output handover | Pass form and selection results to a later decision node | Compare output against input item by item |
| Retrieval scope | Limited to promotional price tag and membership points rule documents | Retrieval does not carry permission or entity isolation |
| Empty-result handover | Check downstream design against a paper input of [] | No claim that a fictional rule search returns [] |
| External action | Order writes and status sync require a separate business interface | Forms and retrieval do not write to the database or synchronise |
Three common errors
- Treating a retrieval hit as an authorisation basis. A retrieved promotional price tag or points rule supplies text content only. It does not show that a refund was approved or that settlement was completed for this order. Input is the retrieved price tag text; the comparison object is "settlement completed" in the draft sentence; the observable result is that the draft sentence lacks a receipt amount and a points-crediting record.
- Treating the "yes" branch of the user selection node as completed execution. A user choosing "agree to refund" means only that this branch was selected. Refund execution requires a separate business interface. Input is the selection result; the comparison object is the refund form status field; the observable result is that the refund form still shows pending.
- Treating the interaction state record as a global switch. The interaction state is behaviour of the form input and user selection nodes. No separate global state-recording switch is documented. Input is the node trigger record; the comparison object is the configuration item list; the observable result is that no independent global state-recording switch exists in the configuration.
How to verify the setup
- Using the hypothetical sample above, input the four source texts: the daily checkout report, the promotional price tag, the membership points rule, and the abnormal refund form. The comparison object is the draft sentence "This order was settled at the member price and the points were correctly credited". The observable result is whether the draft sentence matches the amount and points fields in the materials. If the materials do not state a points-crediting record, that part remains unverified.
- Using the same hypothetical sample, input the "agree to refund" branch returned by the user selection node. The comparison object is the current status of the refund form. The observable result is whether the refund form still shows pending. If it still shows pending, the selection branch did not trigger an external write, and a separate business interface is required.
- Using the same hypothetical sample, input the order number and disputed amount collected by the form input node. The comparison object is the corresponding order record in the daily checkout report. The observable result is whether the two order numbers match. If the form fields are empty, the downstream decision node should record the gap and must not infer that settlement or refund was completed.