What the documents look like
Retail checkout and loyalty work turns on price and membership benefit, and it does not manage short-shelf-life inventory. The comparison task draws on four recurring document types: promotional price tags, membership point rules, checkout daily reports, and abnormal refund slips. These materials arrive from the POS system, the membership CRM, the payment platform, and the price tag system, and they refresh daily or once per shift. A mismatch between a stated price or benefit rule and an actual transaction record can produce price complaints, cash shortfalls or overages, and membership benefit disputes. The comparison therefore has to place the paper rule and the transaction record inside one workflow so that the same subject, the same period, and the same field can be examined together.
Constraints at the workflow routing step
Workflow routing here handles material collection, state waiting, and branch decisions. 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 submits the required information that information is passed to later nodes. The user selection node is also a user interaction node: when the user makes a choice, the node evaluates that choice and executes the corresponding branch. Both nodes can be added repeatedly and trigger execution.
Routing must separate several kinds of action. Existing node behavior covers entering the interaction state, recording state, collecting required fields, passing submitted information onward, and executing a branch from a selection. The configurable surface is limited to the required form fields and the selection branches. Human comparison work covers matching the promotional price tag against the price in the checkout daily report, and matching the membership point rule against the benefit movement in the abnormal refund slip. Order writes, document backfill, and external state synchronization require a separate business interface or a downstream process; retrieval and forms do not constitute authorized execution.
Hypothetical paper exercise sample
Promotional price tag text for comparison: "Store A runs a promotional price of 9.9 yuan for product X from 1 March 2025 to 7 March 2025, and membership points accrue at 1x the amount actually paid." Checkout daily report text: "On 3 March 2025, product X recorded 12 transactions at a unit price of 9.9 yuan, with 118.8 membership points accrued." Draft handover request: "Confirm that the points accrued for product X on 3 March match the promotional price tag rule, and approve backfilling the difference into the membership account."
The sample carries a subject (Store A), an object (product X), a state (promotional period and points rule), and an effective scope (1 March to 7 March). The backfill request is pending review; it is not an approval and it is not an executed action.
Configuration and implementation checks
| Configuration item | Hypothetical trial starting point | Reason for the choice and comparison method |
|---|---|---|
| Required form input fields | Store number, product number, transaction date, field to compare | These map to the sample subject and object; a missing entry leaves the comparison scope unlocatable |
| User selection branches | Match, mismatch, insufficient evidence | Three branches cover the judgment states the sample can reach, each wired to a downstream node |
| Interaction state recording | Use the node's built-in state recording | The documentation states that interaction nodes record workflow state; no separate global switch is set |
| Output receiving node | Pass form values and selection result into the comparison node | Compare each output field against the corresponding input field |
| Backfill action split | Marked as requiring a separate business interface | The documentation does not describe automatic writes; backfill must be implemented by a downstream process |
| Retrieval scope | Target retrieval scope with access rights | Material needed for the comparison must sit inside an accessible scope; record a gap when it is missing |
The numeric starting point serves this hypothetical exercise only and does not represent an official default.
Three common errors
- Treating a pending backfill request as approved and executed. In the sample, the draft sentence says "approve backfilling the difference," and that request sits in pending review, neither approved nor executed. The check inputs that request text, compares its status field, and only treats the action as executed when an explicit approval record exists and the downstream interface returns a write result.
- Treating retrieval or a form as authorization. The form input node collects information and passes it on; it does not grant operating authority over a membership account. The check inputs the submitted form values and the backfill interface call record, then compares whether a separate authorization credential exists. A form submission alone cannot establish that the backfill was authorized.
- Treating different fields or different periods as directly contradictory. In the sample, the promotional price tag sets points at 1x the amount actually paid, and the checkout daily report shows 118.8 points across 12 transactions. The check inputs both passages and compares the same subject, the same period, and the same field. A contradiction exists only when the points rule and the daily report points field take mutually exclusive values; otherwise the result is unsupported or pending verification.
How to verify the setup
- Input the promotional price tag text and the checkout daily report text from the hypothetical sample, and compare the product number, transaction date, unit price, and points fields. When the same subject, same period, and same field take mutually exclusive values, record a mismatch. When a field is missing or the periods differ, record unsupported or pending verification. The expected observable result is that the comparison node emits the corresponding judgment; first-hit success and full recall are not guaranteed.
- Input the draft handover request text, and compare its status field against approval records. When the request status is pending review and no approval record exists, record unauthorized execution. When an explicit approval record exists and the downstream interface returns a write result, record executed. The expected observable result is that the selection branch follows the corresponding path and does not automatically trigger backfill.
- Input an empty result [] as the retrieval output, and examine the downstream node design. Compare whether the downstream node defines an explicit receiving branch for the empty result. When the downstream node still runs the comparison on an empty result, record a design gap. The expected observable result is that the downstream node handles the empty result as designed; a fabricated rule retrieval is not claimed to always return [].
Libraries built on different vector models cannot be associated together; check identifiers first and exclude those that do not conform. Image retrieval requires a corresponding image input and model capability, and reranking requires a model enabled according to its settings. The optional paths shown in an overall document flowchart do not mean every request executes all of them.