What the documents look like
Copy drafting for centralized livestream after-sales work draws on four recurring document types: livestream order lists, refund applications, reshipment orders, and script templates. Compared with ordinary platform after-sales handling, livestream after-sales requests tend to arrive in bursts after a single traffic event and are closely tied to what the host promised on air. Drafting therefore requires checking product information, the wording of commitments, and after-sales status against those documents. The stated data sources are the shop after-sales system, customer-service IM, warehouse WMS, and logistics tracking, with updates after each session and daily.
For this page the practical consequence is narrow. A promotional sentence in a draft must be traceable to a specific field in the order list, refund application, or script template. Host commitments and after-sales wording need to stay aligned. When requests arrive in a burst, copy review and handover requests rise at the same time, so the routing step has to separate information collection from business execution.
Constraints at the workflow routing step
Two interaction nodes are documented for this version. The Form Input node is a user-interaction node: when triggered, the conversation enters an interaction state, the workflow state is recorded, and execution continues after the user completes the interaction. Required information the user submits is collected and passed to later nodes. The User Selection node is also a user-interaction node: it enters the interaction state when triggered, and when the user makes a choice the node evaluates that choice and executes the "yes" branch. Both nodes can be added repeatedly and can trigger execution.
In routing terms, input collection for copy drafting, selection of commitment wording, and confirmation of handover requests each need to land on one of these two nodes. Form Input collects required fields and passes them downstream; User Selection branches on the user's choice. Order writes, document backfill, and external status synchronization require a separate business interface or a later process. The nodes themselves do not perform those business actions, and no documented error code or automatic business action should be asserted.
Hypothetical paper exercise sample. the source material reads "Row A-07 of this session's livestream order list, product is a certain insulated cup; the host stated during the livestream that it supports 'seven-day no-reason return'; refund application R-2024-0912 has been submitted, status pending review." Draft sentence to be judged: "This product supports seven-day no-reason return, and the refund has passed review." The subject is the same insulated cup, the object is the seven-day no-reason return commitment, and the source status is pending review. The draft sentence records the status as passed review, which does not match the source material.
Configuration and implementation checks
| Configuration item | Setting or check for this page | Explanation |
|---|---|---|
| Form Input node | Collect required fields for copy drafting | Enters interaction state when triggered; submitted information passes to later nodes |
| User Selection node | Choose commitment wording or handover request | Executes the "yes" branch after the user makes a choice |
| Output handoff | Pass collected information to later retrieval or judgment nodes | Compare output against input item by item |
| External action split | Order writes, document backfill, external sync | Requires a separate business interface or later process |
| Hypothetical starting point | Pending review as the comparison baseline for this exercise | Chosen because the sample source status is pending review, compared against "passed review" in the draft sentence |
| Retrieval check | Observe returned results and failure branches | No guarantee of first-hit or full recall |
Three common errors
- Treating information collected by the Form Input node as a completed business write. The node collects required fields and passes them to later nodes; order writes and external synchronization require a separate business interface or later process. Check: input is refund-application information collected by the form; compare the node output against whether a business interface is connected; observe whether the result stays at information passing.
- Treating the "yes" branch of the User Selection node as automatic judgment. The node executes the "yes" branch after the user makes a choice; the node does not judge on its own. Check: input is the pending-review status in the hypothetical sample; compare the draft sentence "the refund has passed review" against the source material; observe whether a status mismatch appears.
- Treating retrieval relevance as a permission or entity filter. A relevance score does not perform permission or entity isolation, and retrieval is not authorization. Check: input is a copy-verification request for the same insulated cup; compare whether the subject and object of returned results match the source material; observe whether records for other products or other statuses are mixed in.
How to verify the setup
- Use the source material and draft sentence from the hypothetical paper exercise. Input: "Row A-07 of this session's livestream order list, product is a certain insulated cup; the host stated 'seven-day no-reason return'; refund application R-2024-0912 status pending review." Compare against the draft sentence "This product supports seven-day no-reason return, and the refund has passed review." Expected observation: the draft sentence records pending review as passed review, does not match the source status, and is unsupported. This is a paper comparison, not a completed test.
- Use the handover request from the hypothetical sample. Input: "Please synchronize the review result of refund application R-2024-0912 to the reshipment order." Compare the Form Input node output against whether a business interface is connected. Expected observation: the node only passes information, external synchronization requires a separate business interface, and the request is not executed.
- Use the explicit paper input [] for empty-result handoff. Input is a stated empty list; compare whether the downstream design handles the empty-result branch. Expected observation: the downstream design must state an empty-result branch, and no claim can be made that a fictional rule retrieval necessarily returns []. Libraries built on different vector models cannot be associated together; verify identifiers first, exclude those that do not match, and record the actual observation.