What the documents look like
Cross-border independent-site payment risk control turns on card-network disputes and receiving accounts. Order fulfilment that follows parcel status handles a different object, so the two document sets overlap only partly. The working materials named in the brief are payment chargeback notices, fraudulent-order lists, invoices, and proof of delivery signed by the carrier. These come from a Stripe or PayPal console, Shopify orders, carrier signature records, and customer-service email. The brief gives the update frequency as daily or per order; that frequency does not change how the interactive form step behaves, so it is noted only as stated.
For store service and internal training, staff must turn fields from those materials into form entries, then hand the collected values to later nodes. In FastGPT v4.17.2 the form input node collects the information a user fills in and passes it to subsequent nodes after submission. The user selection node judges the user's choice and executes the "yes" branch. Both are user-interaction nodes: when triggered, the conversation enters an interaction state, the workflow state is recorded, and execution continues after the user finishes interacting. The documented behaviour of these two nodes stops there. Field validation, business approval, database writes, and bulk operations are not part of what the node itself performs; they need an external system or a later node.
Constraints at the interactive forms step
A form collects values. It does not verify a dispute, approve a refund, write to a database, or synchronise with an external platform. The interaction state means the workflow is waiting for a user action; it does not mean any authorisation has been obtained. A pending request is not an approval, an offered option is not an execution, and an unsigned termination is not a completed termination. A retrieval similarity score is not a category, entity, or permission filter, and retrieval is not authorisation.
The following is a hypothetical paper exercise sample, clearly labelled, used only to show a checking method. It does not correspond to any real customer or real document.
Hypothetical paper exercise sample. A payment chargeback notice reads: "Dispute number A-001, 5 March 2024, cardholder raised a chargeback, amount 200 US dollars, status pending evidence submission." A proof of delivery reads: "Waybill T-100, signed 1 March 2024, signed by Zhang." A draft sentence under review reads: "A-001 has completed evidence submission and obtained a full refund."
The draft sentence asserts two facts. The notice states a status of pending evidence submission, so the claim of completed submission is not supported by the notice. The notice says nothing about a refund, so the refund claim has no source in either document. Both remain unverified rather than disproved.
Configuration and implementation checks
The table below lists documented settings or implementation checks relevant to this page's documents. The values are hypothetical starting points for this exercise, chosen so the sample text can be compared field by field. They are not official defaults.
| Configuration or check | Hypothetical value or action | Reason and comparison target |
|---|---|---|
| Form input node | Add three fields: dispute number, amount, status | The sample notice contains these three items; without them no field-by-field comparison is possible |
| User selection node | Set two branches for "evidence submitted" | The draft sentence concerns submission status, so a user choice routes the branch |
| Interaction state check | Confirm the conversation enters the interaction state after triggering | Compared with the documented waiting-for-interaction behaviour |
| Required-field check | Test separately with the dispute number missing and then supplied | Compared with the fact that the sample notice contains a dispute number |
| Status field value | Enter "pending evidence submission" as written in the sample | Compared with the draft sentence's "completed evidence submission" |
| Downstream division of work | Mark the submission action as pending external implementation | The form does not perform database writes; compared with the node's own capability |
Three common errors
- Treating the interaction state as completed authorisation. In the sample the status is pending evidence submission; collecting that value means only that it was entered. The submission action still requires external implementation. Check: input the sample notice text and the draft sentence, compare the status field value, and if the draft sentence is treated as completed after form submission, the condition is not met.
- Treating a user selection branch as business approval. In the sample, "evidence submitted" is chosen by the user, and the choice only determines which branch runs. Check: input that selection item, compare the branch execution result with the sample notice status, and if the branch path is recorded as approval granted, the condition is not met.
- Treating a retrieval or form result as permission isolation. Dispute number A-001 and waybill T-100 belong to different materials. Check: input both numbers, compare the subject and number of the returned records, and if similarity alone merges the two records into one business matter, the condition is not met.
How to verify the setup
- Input the hypothetical sample notice text and the draft sentence. Compare "completed evidence submission" in the draft with "status pending evidence submission" in the notice. If the two disagree, the draft sentence is not supported by the source and is recorded as pending verification.
- Input the dispute number, amount, and status from the sample. Compare the form's required fields against the notice item by item. If submission still succeeds with the dispute number missing, the required-field check does not pass.
- Input the two branches of the user selection for "evidence submitted". Compare the branch execution result with the sample notice status. If choosing "submitted" directly produces a refund record, that exceeds the capability of the form and selection nodes and should be recorded as requiring external system implementation.
All three checks are paper comparisons. No deployment, execution, approval, refund, or other business action has occurred. Where the sample documents are silent, the corresponding fact remains missing and is recorded as a gap rather than resolved.