What the documents look like
JD POP third-party store operations centre on open-platform dispute rules and warranty-period service documents. The material handled day to day includes product information sheets, dispatch-time commitments, dispute handling forms and warranty-period service records. These materials update daily or per order. In the store-service and internal-training setting, workflow routing has to move the fields carried in a handover record into the later nodes in a stable way, while keeping human judgement inside its authorisation boundary.
Two interaction nodes matter here. The Form Input node is a user-interaction node: when it is triggered, the conversation enters an interaction state, the workflow state is recorded, and after the user fills in the required information and submits, the node collects what was entered and passes it to later nodes. The User Selection node is also a user-interaction node: when triggered, the conversation enters the 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 are trigger-executed.
Retrieval results and similarity scores do not carry permission or entity-isolation duties, and retrieval itself does not constitute authorisation. Order writes, document back-filling and external status synchronisation require a separately connected business interface or a later process.
Constraints at the workflow routing step
The routing step has to keep three things separate: what an interaction node actually does, what a person is asked to check, and what a downstream system must implement. The Form Input node collects required values and forwards them; it does not verify the business meaning of those values. The User Selection node branches on the user's choice; the branch taken is a routing decision, not evidence that the chosen business action was carried out. The interaction state and the recorded workflow state are behaviours of the interaction nodes themselves; no separate global state-recording switch is documented.
Hypothetical paper exercise sample. The source material reads: "Dispute handling form JD-2024-0517, subject the POP store operations group, object the warranty-period service record for order number 800123456789, status pending after-sales supervisor review, submission date 17 May 2024." The draft sentence to be judged reads: "This dispute handling form has been approved by the after-sales supervisor and the refund has been completed." The draft turns a pending review into a completed approval and refund. The source material does not state an approval fact or a refund fact.
Configuration and implementation checks
| Configuration item | Setting on this page | How to check |
|---|---|---|
| Form Input node | Collect dispute handling form number, order number, current status, submission date | After submission, compare the field values passed to later nodes |
| User Selection node | Set the "yes" branch to carry the after-sales supervisor review conclusion | Verify each branch connection against the selection result |
| Interaction state | Triggered by the interaction node, which records the workflow state | Observe whether the conversation enters the interaction state |
| Output handover | Pass the form fields to a judgement or interface node | Compare each output field against the input field |
| Business action split | Approval, refund and external synchronisation marked as requiring separate implementation | Check whether the action has a corresponding downstream implementation |
| Hypothetical trial starting point | Use "pending review" as the paper input status for this exercise | Compare against the status field in the source material |
The hypothetical trial starting point is "pending review" because the status field in the sample source material is exactly pending review. The comparison object is the status value in the source material.
Three common errors
- Treating the "pending review" status collected by the form as an approval result. Input: the status field in the sample source material. Comparison object: the phrase "has been approved" in the draft sentence. Observable result: the two values differ.
- Treating a retrieval similarity score as a permission filter. Input: the returned retrieval result. Comparison object: the authorisation scope identifier. Observable result: the score carries no subject or permission field.
- Treating the "yes" branch of the User Selection node as a completed refund. Input: the branch selection record. Comparison object: a refund completion receipt. Observable result: the branch selection does not produce a refund receipt.
How to verify the setup
- Input the sample source material and the draft sentence. Compare the source status "pending review" with the draft's "approved and refund completed." If the two do not agree, the draft sentence is not supported by the source material.
- Input the sample order number and the warranty-period service record. Compare whether the form fields are passed through completely to later nodes. If a field is missing, the output handover is incomplete.
- Input an empty result
[]and check the downstream design. Observe whether the downstream handles it as empty input. If the downstream depends on a non-empty field, a manual input has to be added. Whether retrieval returns an empty result remains unknown.