What the documents look like
Copy drafting for brand concession counters draws on four recurring document types: the joint-operation concession contract, the mall activity letter, sales receipts, and the monthly reconciliation statement. Because the mall collects payment centrally and settles on a concession-fee basis, any price, activity condition, or gift description that appears in drafted copy needs to correspond to the activity letter and the concession contract terms. When those texts diverge, the difference surfaces later in the monthly reconciliation.
The main data sources are the mall POS, the brand ERP, mall member activities, and the finance system, with daily and monthly update cycles. A drafting step therefore often waits until an activity letter or a reconciliation statement exists as a definite text. This page addresses only workflow routing for copy drafting. Identity certification, report analysis, and settlement itself sit outside this page.
Constraints at the workflow routing step
The form input node is a user-interaction node. When it triggers, the conversation enters an interaction state and the workflow state is recorded. After the user completes the required fields 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: it enters the interaction state, records the workflow state, and after the user makes a choice it evaluates that choice and executes the corresponding "yes" branch. A drafting workflow needs to pass collected values such as activity name, concession-counter entity, activity period, and product object explicitly to later retrieval or evaluation nodes, then check item by item whether the output corresponds to the input. Order writing, document backfill, and external status synchronization require a separate business interface or a downstream flow; the interaction nodes themselves do not perform those actions. Retrieval results do not carry permission or entity-isolation functions, and libraries built on different vector models cannot be associated together.
Hypothetical paper exercise: the source text reads, "A mall activity letter states that counter A participates in the spring promotion from 1 March 2025 to 31 March 2025; the activity product is the designated skincare set; the activity price is subject to mall POS settlement." The proposed draft sentence reads, "During counter A's spring promotion, all skincare sets are sold at the activity price." The comparison object is the product scope recorded in the activity letter against the product scope in the proposed sentence. The effective scope field needed for the judgment is "designated skincare set." This exercise is a paper review and corresponds to no real customer or real activity.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this exercise | Reason and comparison method |
|---|---|---|
| Form input node | Enabled, collecting activity name, concession-counter entity, activity period, product object | Compare field by field against downstream retrieval input for completeness |
| User selection node | Enabled, used to confirm the applicable branch for the proposed sentence | Check whether the selection result and the "yes" branch connection agree |
| Interaction state check | Workflow state is recorded and the flow waits for submission | Observe state change before and after submission; no separate global switch is set |
| Output handoff check | Form information is passed into retrieval or evaluation nodes | Compare node input against downstream received fields item by item |
| External action division | Order writing, document backfill, external synchronization connect to separate interfaces | Confirm the interaction nodes do not carry business write actions |
| Retrieval scope check | Only retrieval scopes with access rights are used | Observe whether returned results correspond to the input identifier |
Three common errors
- Expanding "designated skincare set" from the activity letter into "all skincare sets." The input is the activity letter text and the proposed sentence; the comparison object is the product scope field; when the two disagree, the proposed sentence is not supported.
- Treating the "yes" branch of the user selection node as a completed business action. The input is the selection result and the branch connection; the comparison object is whether the downstream node actually receives the form information; when the downstream node does not receive it, the business action remains unimplemented.
- Using retrieval results in place of a permission judgment. The input is the returned records and the access scope; the comparison object is whether the record identifiers fall inside the authorized scope; when this cannot be verified, record the gap and do not infer a permission conclusion.
How to verify the setup
- Enter the activity letter text and the proposed sentence, compare the product scope field, and if the proposed sentence covers a broader scope than the activity letter records, mark it unsupported and return the sentence for revision.
- Enter the user selection result and the branch connection, compare whether the downstream node of the "yes" branch receives the form information, and if it does not, record a handoff gap rather than treating the action as executed.
- Enter an explicit paper empty result
[], compare whether the downstream node is designed for an empty-result branch, and if the downstream still demands a concrete drafted sentence, record a design gap without claiming that a fictional rule retrieval necessarily returns empty.
All of the above are paper checks. No deployment, approval, or settlement operation was carried out.