What the documents look like
Complaints and official replies are addressed to a platform or a regulatory authority, so the material has to carry formal evidence and rectification wording. The main sources are the 12315 platform, platform complaint centres, customer service chat, and the order system. Day-to-day work covers complaint tickets, regulatory enquiry letters, order evidence, and rectification reports. In the store service and internal training step, facts scattered across tickets, chat logs, and orders are assembled into material that store staff can check and hand over, and a decision is then made about which content enters a form and which content is left to later nodes. Updates are irregular and occur once per case; this page does not derive batch synchronisation or automatic triggers from that pattern.
A hypothetical paper exercise sample is used throughout this page. The source material reads: "Complaint ticket A-07 records that on 12 March 2025 the consumer raised a refund request for order D-221, and the store replied on 14 March with 'registered, pending verification'; regulatory enquiry letter Q-09 requires the store to provide a written explanation of the handling process by 20 March." The draft sentence to be assessed is: "The store has completed the refund and submitted the rectification reply." Assessment requires the same subject, the same period, and the same field. The source material contains only "registered, pending verification" and a deadline for a written explanation. It does not record completion of the refund or submission of the rectification reply, so the draft sentence is unsupported.
Constraints at the interactive forms step
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 execution continues downward after the user completes the interaction. After submission, the node collects the information the user filled in and passes it to later nodes. The user selection node is also a user interaction node, and it executes a branch according to the user's choice. Neither node carries business database functions of its own. Field validation, business approval, write-back, and batch operations need to be implemented in an external system or in later nodes. Interaction waiting, state recording, and hiding of the dialogue box follow the documented description; no submission count limit, automatic judgement, or snapshot guarantee is assumed to exist.
For this category, the constraint that matters most is the separation between collecting values and completing a business action. A form can gather a ticket number, an order number, a request type, and a reply status. It does not verify the facts in those values, does not approve anything, and does not write to an order system or a regulatory platform. The same applies to the selection node: it routes the workflow according to the choice made, and the choice itself is not a permission, an approval, or an authorisation.
Configuration and implementation checks
The table below lists documented settings or implementation checks relevant to this feature and this task. Where a number appears, it is a hypothetical starting point for this exercise, with the reason for choosing it and the value it is compared against.
| Configuration item | Setting or check for this exercise | Reason and comparison object |
|---|---|---|
| Form input node | After triggering, enter the interaction state and wait for submission before continuing | Documented node behaviour; compare whether the workflow continues before and after interaction |
| Required information list | Ticket number, order number, request type, reply status | Fields needed for the assessment in this sample; compare submission behaviour with missing items and with all items present |
| User selection node | Execute the "yes" branch according to the choice | Documented branch behaviour; compare the choice made with the branch taken |
| Interaction state recording | Record the workflow state after triggering | Documented behaviour; compare state continuity during interaction and after completion |
| Downstream division of work | Field validation, approval, and write-back are implemented in an external system or later nodes | Documented statement that the node does not carry a business database; compare this page's scope with downstream responsibilities |
| Hypothetical starting point | Four required fields | Chosen because the sample assessment needs those four fields; compare whether submission can continue before and after the fields are completed |
Three common errors
- Treating form submission as business completion. In the sample, the store replied only "registered, pending verification". If a draft sentence states "the refund has been completed", the input is the original text of ticket A-07, the comparison object is the refund completion field, and the observable result is that the source text does not record that field, so the statement is unsupported.
- Treating the user selection node as a staff directory or a business data selector. The input is the choice presented after the node is triggered, the comparison object is the documented "yes" branch, and the observable result is that the branch follows the choice. Describing the choice as an authorisation or an approval goes beyond the documented scope.
- Treating retrieval or a form as authorised execution. The input is the ticket information collected by the form, the comparison object is business actions such as refund completion or rectification submission, and the observable result is that those actions need an external system or later nodes. The form itself does not produce an authorisation effect.
How to verify the setup
- Input the sample source text "Complaint ticket A-07 ... pending verification" together with the draft sentence "The store has completed the refund and submitted the rectification reply". Compare the two fields of refund completion and rectification submission. The observable result is that the source text does not record either field, so the draft sentence is unsupported and the evidence gap is retained.
- Input two situations: required fields missing, and required fields completed. Compare whether the workflow continues downward after submission. The observable result is that with the fields completed the node collects the information and passes it on, while with fields missing the interaction is not complete. No automatic judgement is claimed to exist.
- Input the choice made at the user selection node. Compare it with execution of the "yes" branch. The observable result is that the workflow follows the branch matching the choice. If the choice is used for an authorisation decision, record that as beyond the documented description and pending verification.
These checks test the named primary task: assessing proposed copy against the supplied source wording and its limitations. They do not test identity certification, report analysis, or any other task. Where the source material does not record a field, that gap remains a gap. A pending request is not an approval, an offered option is not execution, and an unsigned termination is not a completed termination.