What the documents look like
Retail checkout and loyalty materials centre on prices and member benefits. The main sources are the POS system, the member CRM, payment platforms and the price tag system. Day-to-day documents include promotion tags, loyalty points rules, checkout daily reports and exception refund slips. Updates run daily or per shift. In a cross-border setting, one promotion may exist at the same time as tags in several languages, points rules in several languages and refund records in different currencies.
Workflow routing has to build checkable input-and-output relationships between these materials. The results of retrieval and the values collected by forms are handed to later nodes, and those later nodes decide whether business processing begins. This page addresses one task only: cross-border materials and multilingual retrieval, at the workflow routing step. It does not treat retrieval or form submission as an authorization decision.
Constraints at the workflow routing step
The form input node is a user interaction node. When it is triggered, the conversation enters an interaction state and the workflow state is recorded. After the user fills in the required information 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 is triggered, the conversation likewise enters an interaction state and the workflow state is recorded. When the user makes a choice, the node evaluates that choice and executes the "yes" branch.
The interaction state and the state record are behaviours of the interaction nodes. No separate global state-recording switch is documented, and none should be asserted. Values collected by a form must be explicitly passed to a later retrieval, judgement or interface node. Order writing, document backfill and external state synchronisation require a separate business interface or a later process. Retrieval results and similarity scores do not perform permission or entity isolation, and retrieval by itself is not authorization.
Hypothetical paper exercise. A store checkout supervisor submits a cross-language promotion material check request. The source material reads: "Promotion tag (Chinese): Member Day 10% off all drinks, valid 2025-03-01 to 2025-03-03." "Promotion tag (EN): Member Day 10% off all drinks, valid 2025-03-01 to 2025-03-03." The proposed sentence is: "This promotion still runs at 10% off on 2025-03-04." The request to be judged is: submit the two tags and the proposed sentence to retrieval, confirm whether the proposed sentence agrees with the source text, and pass the check result through the form input node to a later judgement node. This is a paper exercise only. No test, deployment, approval or refund is claimed.
Configuration and implementation checks
| Configuration item | Use on this page | How it is set or checked |
|---|---|---|
| Form input node | Collect the required fields of the check request | On trigger, the conversation enters an interaction state; after submission the entered values are passed to later nodes |
| User selection node | Let the submitter choose whether to continue the check | After the user makes a choice, the "yes" branch executes; verify each branch connection |
| Interaction state check | Confirm the conversation enters an interaction state | Compare the interaction state and state-record behaviour after trigger against the documented description |
| Output handover check | Pass collected values to later nodes | Compare the form output item by item with the input of the later retrieval and judgement nodes |
| External action split | Separate node behaviour from business actions | Order writing, document backfill and external state synchronisation connect to a separate business interface |
| Retrieval scope check | Confirm the target material is within reach | Check the library identifier and the vector model identifier and exclude non-matching ones |
Three common errors
- Treating a retrieval hit as authorized execution. When retrieval returns promotion tag text, this shows only that the material can be retrieved. It does not mean the promotion has been approved or can be carried out externally. For the check, input the two tags above, compare the retrieval output with the proposed sentence, and observe whether the output presents only the source text with no authorization conclusion.
- Treating form submission as a business write. The form input node collects and passes entered values. Order writing and external synchronisation require a separate business interface. For the check, input the check request, compare the form output with the input of the later node, and observe whether any write is claimed without an interface.
- Treating a similarity score as an entity or permission filter. A score does not exclude unrelated business or unauthorized records. For the check, input the Chinese and English tags of the same promotion, compare the returned entries with the target scope, and observe whether records from other stores or other promotions appear.
How to verify the setup
- Input the two tag source texts above and the proposed sentence. Compare the proposed sentence date "2025-03-04" with the source validity period "2025-03-01 to 2025-03-03", and observe whether the proposed sentence agrees with the source text. If it does not agree, record it as pending verification and do not judge it approved or in effect.
- Input the check request. Compare the required fields of the form input node with the values passed after submission, and observe whether the later judgement node receives the same fields. If a field is missing or not passed, record the gap and do not supply an authorization clause.
- Input the Chinese and English tags of the same promotion. Compare the library identifier and vector model identifier of the returned entries, and observe whether they belong to the same model. If the identifiers differ, exclude the non-matching ones and record the actual observation. Do not run a cross-model retrieval to compare missed recall. For an empty-result handover, a clearly stated paper input of [] may be used to check the downstream design; do not claim that a fictional rule retrieval necessarily returns [].