What the documents look like
After-sales repairs and reships aim to restore a product to working condition. The case does not close through a direct refund. That objective shapes which materials enter contract and transaction comparison: repair applications, reship orders, inspection reports and accessory outbound notes. Data sources include the after-sales system, the order system, repair sites and the accessory warehouse WMS. Typical operating parties are brand after-sales teams, e-commerce customer service and accessory warehouses. Materials keep appearing within a single case lifecycle, so workflow routing needs a place to record state for per-case interaction.
The comparison object is a set of documents, not a single record. A repair application carries a case number, a responsible party, an object, a fault description and a status. An inspection report carries a conclusion and an effective scope. An accessory outbound note carries an item and an outbound status. Each field has its own meaning, and the same case number across documents does not merge those meanings.
Constraints at the workflow routing step
The Form Input node and the User Selection node are user interaction nodes. When either node triggers, the conversation enters an interaction state, the workflow state is recorded, and execution continues after the user finishes the interaction. Form Input collects required information and passes the submitted values to later nodes. User Selection evaluates the user's choice and executes the corresponding "yes" branch. State recording is behavior of the interaction node itself. No separate global state-recording switch is documented.
Retrieval and authorization stay separate. A form collects values. Order writes, document backfill and external status synchronization require a separate business interface or a later process. Retrieval results do not constitute authorization. A similarity setting does not perform entity isolation or permission filtering. Libraries built on different vector models cannot be associated together; identifiers must be checked first, non-matching libraries excluded, and actual observations recorded.
Hypothetical paper exercise. The source text supplied for comparison reads: "Repair application WX-2041, party: a brand after-sales site, object: Model A rice cooker, fault description: abnormal heating; status is awaiting inspection. Inspection report JC-2041 conclusion: heating plate damaged, accessory replacement recommended; effective scope: this case. Accessory outbound note CK-2041 states: one heating plate, outbound status: dispatched." A draft sentence to be judged reads: "WX-2041 has completed repair and has been shipped back to the customer, and the accessory cost has been settled." Compared with the source, the source shows only awaiting inspection and dispatched; completed repair, shipment back and settled cost are not stated in the source.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this exercise | Reason and comparison method |
|---|---|---|
| Form Input fields | Repair case number, party, object, fault description, status | Compare field by field against the source; record missing items as unsupported |
| User Selection branches | Two options: repair, reship | After a choice, the "yes" branch executes; verify each branch connection |
| Interaction state recording | Node's own state recording in use | Check interaction wait, dialog hiding and state recording behavior |
| Output handoff | Pass form values to a later retrieval or decision node | Compare each output item against the input item |
| Retrieval scope identifier | Check library identifier and vector model identifier first | Exclude non-matching libraries; do not run cross-model retrieval to compare missed recall |
| Empty-result handoff | Use a paper input of [] to check downstream design | Observe how downstream handles an empty reference; no claim that [] is always returned |
Three common errors
- Treating the draft sentence's "completed repair and shipped back to the customer, accessory cost settled" as source fact. The source status is awaiting inspection and dispatched. All three statements are unsupported, not contradicted and not negated.
- Treating values collected by the form as authorized execution. The form only collects values. Order writes and external synchronization require a separate business interface. A pending review does not demonstrate that an operation permission is absent.
- Treating retrieval or a similarity setting as a means of entity isolation. Retrieval does not carry authorization. Libraries on different vector models cannot be associated together; identifiers must be checked first and non-matching libraries excluded.
How to verify the setup
- Input the hypothetical source text and the draft sentence, then compare the three statements in the draft against the source status fields. When the source shows only awaiting inspection and dispatched, the three statements must be marked unsupported. They must not be marked contradictory or negative.
- Input the two branches of the User Selection node and compare the choice result against the branch connections. Choosing "repair" should execute the corresponding "yes" branch; choosing "reship" should execute the other branch. An unconnected or wrongly connected branch is recorded as pending verification.
- Input a paper empty reference of [] and compare the downstream node output. Downstream should show empty-result handoff behavior. If downstream has no corresponding handling, record the gap. Do not claim that a fictional rule retrieval always returns [].
This page addresses only after-sales repairs and reships, contract and transaction material comparison, and workflow routing. During operations handover, the authorization state of materials, actions and requests must remain explicit. Retrieval and forms are not authorization execution.