What the documents look like
Wholesale stall trading is fragmented. Bargaining happens on site, and shipment often relies on consignment. The records that circulate day to day are purchase sheets, handwritten sales slips, stall lease contracts and payment receipts. Their update rhythm is daily or per order. These materials are mostly paper or chat records, and their fields are not standardized. The same product can appear under different names, specifications or quantities across documents. Product information and selection questions require turning the product details on these records into a comparable form before any selection answer is produced. Workflow routing therefore has to separate what the user fills in, what document retrieval supplies, and what still requires separate verification.
Constraints at the workflow routing 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 the dialogue box is hidden. The user fills the required information and submits it, after which the node collects the submitted values and passes them to later nodes. The user selection node also enters the interaction state and records workflow state. When the user makes a choice, the node evaluates that choice and executes the corresponding yes branch. In product information and selection questions, selection conditions such as category, specification, quantity and pickup method can be collected through form input. Whether a substitute is acceptable can be handled through a user selection branch. The collected values must be explicitly passed to later retrieval or judgment nodes. Order writing, document backfill and external state synchronization require a separate business interface or a later process. Retrieval does not carry authorization responsibility, and a similarity score does not exclude unrelated business records or unauthorized records.
Hypothetical drill sample: the source text for verification reads, "Stall A issued a handwritten sales slip on 10 March 2025, product name 'rebar HRB400', specification diameter 12 mm, quantity 30 tonnes, unit price subject to on-site bargaining that day, pickup method consignment, payment receipt number A-0310, balance status unpaid." The draft sentence to be judged reads, "This batch of rebar has been paid in full and can be recommended for same-specification stock in the selection answer." The subject required for judgment is Stall A, the object is rebar HRB400 diameter 12 mm, 30 tonnes, the status is unpaid balance, and the effective scope is the 10 March 2025 sales slip and receipt number A-0310. The draft sentence and the source text share the same subject, the same period and the same field, and their values are mutually exclusive. The draft sentence is unsupported.
Configuration and implementation checks
The table below lists only officially described settings or implementation check items relevant to this page's main task. The values in the retrieval checks are starting points for this hypothetical trial, used to compare observed results. They are not official defaults.
| Configuration item | Hypothetical trial starting point and reason | Comparison method and observation |
|---|---|---|
| Required form input fields | Category, specification, quantity and pickup method are set as required, because a selection question cannot be compared when one is missing | After submission, check whether later nodes receive all field values |
| User selection branches | Two options are set: "accept substitute" and "do not accept substitute" | After a choice is made, check whether only the corresponding yes branch executes |
| Retrieval input handoff | The category and specification collected by the form are joined as retrieval input | Observe whether the retrieval input matches the form output |
| Empty result handoff | Use the paper input [] to check the downstream design | Check whether the downstream handles the empty result branch, without claiming that a fictional rule must return [] |
| Retrieval library identifier check | First check the vector model identifier of each library and exclude those whose identifiers do not match | Record the actual observation, and do not perform cross-model retrieval comparison |
| External operation division | Order writing and document backfill are marked as requiring a separate business interface | Check whether the workflow contains any unexplained automatic write |
Three common errors
- Treating selection conditions collected by form input as already authorized execution. The input is "rebar HRB400, diameter 12 mm, 30 tonnes" from the hypothetical sample. The comparison object is whether payment has been settled. The observed result is that the source text records an unpaid balance, while the draft sentence states payment in full. This is unsupported.
- Treating the yes branch of a user selection as business approval. The input is the "accept substitute" option. The comparison object is whether an approval record exists. The observed result is that the materials contain no approval field. This is an evidence gap.
- Treating a retrieval similarity score as an entity or permission filter. The input is a selection question query. The comparison object is whether the returned records belong to Stall A. The observed result is that the score does not carry that filter, and the identifier must be checked separately.
How to verify the setup
- Use the hypothetical source text and draft sentence. The input is Stall A, 10 March 2025, unpaid balance. The comparison object is the draft sentence "paid in full." The observed result is that the same subject, same period and same field hold mutually exclusive values, so the draft sentence is judged unsupported. The condition is met when the draft sentence is marked for verification.
- Use the form fields from the hypothetical sample. The input is category, specification, quantity and pickup method. The comparison object is the values actually received by the later retrieval node. The observed result is complete field transfer. The condition is met when no field is lost.
- Use the paper input [] to check the empty result handoff. The input is an empty array. The comparison object is the downstream branch design. The observed result is that the downstream handles the empty result path. The condition is met when no claim is made that a fictional rule must return [], and the actual observation is recorded.