What the documents look like
Fruit-store procurement for fresh produce runs on four document types: purchase orders, acceptance records, pesticide-residue test reports, and loss records. The underlying data comes from wholesale-market price movements, supplier quotations, store sales, and test reports. These materials update daily or per batch.
Compared with convenience-store fresh-food ordering, fruit procurement depends more on wholesale-market conditions and grade-based acceptance, and less on a headquarters standard meal with fixed specifications. For the task of drafting product and marketing copy, the drafting step has to extract checkable statements from those materials. If a material does not state a grade, origin, test status, or batch scope, that detail stays unknown. The model does not supply it.
A second practical point is that the four document types record different stages. A purchase order records what was ordered. An acceptance record records what arrived and how it was graded. A test report records a laboratory result for a batch. A loss record records shrinkage after receipt. Copy that merges these stages into one claim can assert more than any single document supports.
Constraints at the interactive forms step
The form input node is a user-interaction node. When it triggers, the conversation enters an interactive state, the workflow state is recorded, and execution waits until the user completes the interaction before continuing. The node collects the information the user fills in and passes it to later nodes. It does not provide a business database function of its own.
The user selection node is also a user-interaction node with the same interactive-state behavior. When the user makes a choice, the node evaluates that choice and executes the "yes" branch. It is not a staff directory and not a business-data selector.
Field validation, business approval, write-back, and bulk operations require an external system or later nodes. The interaction nodes do not perform those actions.
Hypothetical paper exercise: the source text consists of three sentences. "The purchase order for this batch of apples states grade one, quantity 200 boxes, supplier a wholesale-market stall, date 10 March 2025." "The corresponding acceptance record shows 180 boxes arrived for the same batch, acceptance grade one, acceptance date 10 March 2025." "The pesticide-residue test report states the batch result is qualified, report date 9 March 2025." The draft sentence to be judged is: "This store's grade-one apples from this batch have passed testing; welcome to purchase." The draft sentence involves a subject, an object, a status, and a date scope, and each item must be compared against the source text.
Configuration and implementation checks
| Configuration item | Type | Purpose and verification method on this page |
|---|---|---|
| Form input node | Official node | Triggers the interactive state, collects the draft sentence and source text, passes them to later nodes after submission |
| User selection node | Official node | Offers branch options for handling the draft sentence, executes the "yes" branch based on the choice |
| Required-field check | Implementation check | Lists subject, object, status, date scope, and quantity; records a gap when an item is absent |
| Draft-to-source comparison | Manual check action | Compares each field of the draft sentence with the source text, marking supported, unsupported, or pending verification |
| Downstream division of labour | Implementation check | Field validation, approval, and write-back are implemented by an external system or later nodes; the interaction nodes do not carry them |
The hypothetical starting point for this exercise: place the three source sentences and the draft sentence into the form input node and select "submit for comparison." This starting point is chosen to verify the collection and passing behaviour of the interaction node, and it is compared against the node's behaviour when a required field is left empty.
Three common errors
- Treating "have passed testing" in the draft sentence as a test conclusion for the whole apple batch. The source only states that the batch's test report is qualified, with a report date of 9 March 2025, while the acceptance date is 10 March 2025. These are evidence from different stages and cannot be merged into one complete conclusion at a single point in time.
- Treating the purchase-order quantity of 200 boxes and the acceptance-record quantity of 180 boxes as a contradiction. The two documents record different fields at different stages. The quantity difference is a matter pending verification and cannot be directly judged as a denial or a conflict.
- Treating the branch result of the user selection node as completed business approval. The node only executes a branch according to the choice. Approval, write-back, and database writes require an external system.
How to verify the setup
- Enter the three hypothetical source sentences and the draft sentence, and submit the form. Compare each field of the draft sentence with the corresponding field in the source text. If the subject, object, status, and date scope in the draft sentence each have a corresponding statement in the source text, the support condition is met. If a field is not stated in the source text, record it as unsupported or pending verification.
- Remove one required field in the form input node and submit. Compare whether the node stays in the interactive state and waits for the field to be completed. If the node remains in the interactive state and does not proceed, the required-field check condition is met. After completing the field and submitting, compare whether execution continues.
- Use the user selection node to offer two branch options for the draft sentence, and choose the "yes" branch. Compare whether the later node executes along that branch. If the execution path matches the chosen branch, the branch check condition is met. If it does not execute, record the observed result without inferring a cause.
For retrieval checks: if a knowledge base is used to retrieve the source text, verify whether the retrieval library and the query use the same vector model. Libraries using different vector models cannot be associated together. An empty-result handoff can be checked against downstream design using an explicit paper input of [], without claiming that a fictional-rule retrieval necessarily returns []. A relevance score does not perform permission or entity isolation, and retrieval by itself does not constitute authorization.