What the documents look like
Near-expiry markdown handling follows the shelf-life state of store inventory. It does not weigh and sort individual order lines. The main data sources named in the brief are POS stock age, store inspection, ERP inventory and quality inspection records. The daily documents are near-expiry lists, markdown approvals, damage write-off forms and promotional price tags. The brief records update frequency as daily and per shift. For the operating review and exception review task, the practical consequence is that workflow routing has to carry batch state across several documents. The most time-consuming steps are identifying near-expiry batches, approving markdowns and isolating unsellable goods. Routing nodes collect and pass values. They do not approve markdowns, write inventory or synchronize external state.
Constraints at the workflow routing step
In the supplied FastGPT v4.17.2 documents, the Form Input node is a user interaction node. When it triggers, the conversation enters an interaction state, the workflow state is recorded, and execution continues after the user completes the interaction. After the user fills required information 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. When it triggers, the conversation enters an interaction state and the workflow state is recorded. When the user makes a selection, the node judges that selection and executes the "yes" branch. Both nodes can be added repeatedly and trigger execution.
The constraints follow from those documented behaviors. The interaction state is a node behavior. No separate global state-recording switch is documented. Collected values must be explicitly passed to later retrieval, judgment or interface nodes. Order writes, document backfill and external state synchronization need a separate business interface or a later process. Retrieval and form collection do not constitute authorization. Whether a markdown approval passes or a damage write-off executes depends on downstream business implementation and the human authorization boundary.
Hypothetical drill sample: a store fresh-goods area near-expiry list states that the object is chilled yogurt batch A, that stock age has entered the near-expiry interval, that the status is pending markdown approval, and that the effective scope is the current shift. A draft sentence reads: "This batch has completed markdown approval and can be sold directly at the markdown price tag." The material needed for judgment is the near-expiry list text and the markdown approval record. In this sample the approval record is not provided.
Configuration and implementation checks
| Configuration item | Hypothetical starting point for this drill | Reason and comparison method |
|---|---|---|
| Form Input node | Enabled, collecting the near-expiry list identifier and batch status | Compare each submitted value against the fields in the sample list text |
| User Selection node | Enabled, with "yes" and "no" branches | After a user selection, verify each branch connection against the configured connection |
| Interaction state check | Conversation enters interaction state on trigger | Confirm the recorded state as node behavior; no separate global switch is documented |
| Output handoff | Form information passed to a later judgment node | Compare output fields with input fields item by item |
| External action split | Markdown approval and damage write-off connect to a separate business interface | Check whether the interface exists; record a gap when it is not connected |
The values in this table are hypothetical starting points for this drill. They are not official defaults. The same-vector-model requirement for retrieval libraries applies only to the documented shared-association scenario and does not extend to other external systems.
Three common errors
- Treating a form submission as a completed markdown approval. In the sample, the approval record is not provided, so the draft sentence "has completed markdown approval" lacks support and must be recorded as pending verification.
- Treating the "yes" branch of the User Selection node as automatic execution authorization. The node judges the selection and executes the branch. Approval and writes require a separate business interface.
- Treating retrieval results as a permission or entity isolation mechanism. A relevance score does not perform permission filtering. Libraries on different vector models cannot be associated together; verify identifiers first and exclude non-matching records.
How to verify the setup
- Input the sample near-expiry list text and the draft sentence. Compare the list status "pending markdown approval" with the draft sentence "has completed markdown approval." If the approval record is missing, judge the sentence as unsupported. Do not judge it as a contradiction or a denial.
- Input the User Selection node's selection result. Compare the branch taken with the configured connection. Observe whether the "yes" branch executes according to the connection. Do not infer automatic approval or inventory writes.
- Input a paper empty result [] to check the downstream design. Observe whether the empty result is explicitly handled. Do not claim that a fictional rule retrieval necessarily returns []. In a cross-model scenario, verify identifiers first and exclude non-matching records, then record the actual observation.