What the documents look like
Central chain procurement conversation logs sit around head-office purchasing and distribution work. The material sources named in the brief are ERP purchasing, WMS, store POS, and supplier delivery data. One after-sales question during order fulfilment can touch a centralized procurement contract, a replenishment plan, a delivery note, and a store requisition at the same time. The update rhythm given is daily and weekly. This page does not describe any batch synchronization mechanism, and the rhythm does not change how the conversation interface behaves.
The FastGPT v4.17.2 chat interface separates sessions by chatId and separates individual exchanges inside a session by dataId. A session list request can carry source=api, which returns sessions created through the API and does not return sessions created on the page. Run detail is available only when detail=true, and intermediate values are held in responseData. With detail=false the response carries the final answer and no responseData. Fields that the interface does not return cannot be treated as retained business records. Similarity and score affect recall ordering inside retrieval; they do not act as a permission filter or an entity separation mechanism.
A clearly labelled hypothetical paper exercise follows. It is a desk comparison, not a record of any executed call.
Material text for comparison: centralized procurement contract HT-2025-031 states that this batch of distribution is governed by the confirmation status of the delivery note. Replenishment plan BH-2025-0309 states that store B is scheduled to receive goods on 12 March 2025, pending delivery note confirmation. Object: the delivery note covering warehouse A to store B for 12 March 2025. Draft sentence under review: "The delivery note is confirmed and the store can receive goods on schedule." The two source sentences describe a pending state. The draft sentence states a confirmed state. The comparison is between the status wording in the source material and the status wording in the draft.
Constraints at the conversation logs step
Session identity is carried by chatId, and the brief's delivery note number is a business identifier that the operator maps to a chatId by hand. Nothing in the interface derives one from the other. The chatId must be unique and shorter than 250 characters. When chatId is a non-empty string, the system reads the session from the FastGPT database and uses the last element of the messages array as the user question; the remaining messages are ignored. When chatId is absent, no FastGPT context is used and the full context comes from the supplied messages. A conversation log review therefore has to confirm which of these two modes produced the record before treating the stored history as complete.
Run detail depends on detail=true. In non-stream mode the intermediate values sit in responseData; in stream mode they arrive through events, and flowResponses carries the full node responses. The event names documented include answer, fastAnswer, flowNodeStatus, flowResponses, updateVariables, interactive, and error. A log review that needs node-level evidence reads responseData or flowResponses; a review that only needs the final answer can work with detail=false, and in that case the node evidence is not present in the response.
Interactive nodes return a display configuration containing type and params. Internal runtime fields such as entryNodeIds, memoryEdges, nodeOutputs, and nodeResponseId are not returned to the external caller. A returned form or user-select configuration is a collection of values. It is not an approval, not a database write, and not an external synchronization. Any of those steps needs its own downstream implementation, and the conversation log alone does not show that they occurred.
Feedback state is written through updateUserFeedback with userGoodFeedback or userBadFeedback. A stored feedback value records that a rating was submitted. It does not establish that the underlying business question was resolved. Retrieval and similarity values remain ordering signals inside the retrieval step, and they do not exclude records belonging to other stores, other suppliers, or other business entities.
Configuration and implementation checks
| Item | Use on this page | How it is checked |
|---|---|---|
| appId | Locate the target application | Compare with body.appId in the request body |
| chatId | Locate the target session | Compare with the delivery note business number recorded for the exercise |
| dataId | Locate one exchange inside the session | Read from the conversation list result |
| detail | Obtain run detail | Set true and inspect responseData for the requested node |
| loadCustomFeedbacks | Read custom feedback | Passed when requesting the conversation list |
| source | Filter session origin | source=api returns API-created sessions only |
The exercise chatId is "peisong-20250310-01", chosen as a starting value for this paper case because it ties the session to the delivery note date and sequence. It is compared against the delivery note business number held in the exercise material. It is not a documented default and carries no meaning outside this exercise.
Three common errors
- Treating the replenishment plan wording "pending delivery note confirmation" as a confirmed delivery note. The check compares the status wording in the source material against the status wording in the draft sentence. The source states a pending state and the draft states a confirmed state, so the two do not agree.
- Using a similarity score to exclude conversations belonging to other stores or suppliers. The check compares the chatId in each returned record against the target business number. A score orders retrieval results; it does not remove records that belong to a different entity, and no permission conclusion follows from it.
- Treating a returned interactive form configuration as a completed business authorization. The check compares the returned type and params against the values actually submitted. A form collects values, and approval, database writes, and external synchronization require separate downstream implementation.
How to verify the setup
- Input the exercise chatId "peisong-20250310-01" and the message "Is the delivery note from warehouse A to store B for 12 March 2025 confirmed?" with detail=true. Compare the moduleName and moduleType entries in responseData against the nodes expected for this request. The condition is met when the expected node appears and its status can be read from the returned structure.
- Input the draft sentence "The delivery note is confirmed and the store can receive goods on schedule" together with the two source sentences from contract HT-2025-031 and plan BH-2025-0309. Compare the status field wording. The source states pending confirmation and the draft states confirmation, so the draft is judged inconsistent with the material and requires revision.
- Input the same chatId and message twice, once with detail=true and once with detail=false. Compare the two response structures for the presence of responseData. The condition is met when responseData is present in the detail=true response and absent from the detail=false response.
All three steps are paper comparisons. No call was executed, no record was written, and no approval, refund, or other business action took place. Where the interface does not return a field, the corresponding business fact remains unknown, and the gap is recorded as a gap rather than filled by assumption.