What the documents look like
Store cold-chain receiving for fresh produce revolves around four document families: cold-chain vehicle temperature records, arrival acceptance sheets, rejection sheets, and supplier delivery notes. Supporting data comes from the vehicle temperature control system, the WMS, the store receiving system, and quality-inspection photographs. Compared with fruit procurement, this category tracks transport temperature and arrival batches, and does not handle origin price inquiries.
Updates occur per batch and per day. Errors carry consequences in spoiled ingredients, supplier disputes, and regulatory penalties. Operating reports and exception reviews therefore depend on aligning what a conversation log records about a request and its return against the business documents the same batch generated. A log entry is not the same as a completed compliance audit. Reconciliation, retention, and compliance obligations belong to a fuller business process that sits outside the conversation interface.
The conversation interface organizes sessions and records through appId, chatId, and dataId. When chatId is a non-empty string, FastGPT reads the session from its database and uses only the last element of the messages array as the user question; the remaining messages are ignored. When chatId is not passed, the context feature is not used and context is built entirely from the supplied messages. A responseChatItemId, when passed, becomes the ID of the response message for that turn and is stored in the database; it must be unique within the current chatId. Setting detail=true returns intermediate values and complete results. In non-stream mode those sit in responseData; in stream mode they arrive through event values.
The conversation CRUD surface covers session lists, record lists, single-record run details, feedback, and deletion. A session list request with source=api returns only sessions created through the API. Clearing application sessions clears only sessions created through an API key. Fields such as moduleName, moduleType, runningTime, tokens, and quoteList in a run detail reflect node execution. Business data that was not returned cannot be assumed to have been retained in full.
Hypothetical paper exercise
Material text one (excerpt from an arrival acceptance sheet): On 12 March, Store A received cold-chain vehicle batch L-0312. The arrival acceptance sheet records a temperature of 2 degrees Celsius, and the quality inspector signed to confirm that sampling passed.
Material text two (excerpt from a rejection sheet): On the same day, a separate batch L-0313 had missing temperature records. Store A issued a rejection sheet, and its status is pending supplier confirmation.
Draft sentence to assess: "Both batches received by Store A on 12 March passed acceptance."
Constraints at the conversation logs step
The chatId choice determines what the log can later support. A request that omits chatId builds context only from messages and does not draw on stored session history. A request that passes chatId draws on the database session and treats the final message as the user question. Mixing the two in one operating report produces session statistics that do not share a basis.
The responseChatItemId must be unique within the current chatId. Reusing one value across two different chatIds is not covered by the documented uniqueness condition, and the resulting storage behavior is not stated in the supplied text. Two requests with the same responseChatItemId and different chatIds should be compared against the returned storage result, and any outcome beyond what the document states remains unknown.
The detail flag controls whether intermediate values and complete results are returned. Without detail=true, the intermediate node fields are absent from the response. An operating review that needs node-level fields must request them; their absence in a detail=false response is not evidence that the nodes did not run.
quoteList entries carry a score. A relevance score is a similarity value for a retrieval result. It is not a category filter, an entity filter, or a permission filter, and it does not establish that unrelated businesses or unauthorized records were excluded from retrieval. Retrieval is not authorization. Form inputs collect values; business verification, approval, database writes, and external synchronization require their stated downstream implementation.
Configuration and implementation checks
| Configuration item | Value or check method | Explanation |
|---|---|---|
| appId | Passed in the request body, or associated with the API key | Locates the application and, together with chatId, identifies the target conversation |
| chatId | Non-empty string, length under 250 | Uses the database session and treats the last message as the user question |
| responseChatItemId | Unique within the current chatId | Stored as the response message ID for that turn |
| detail | true or false | true returns intermediate values; in non-stream mode these sit in responseData |
| source | api | Session list returns only sessions created through the API |
| dataId | Obtained from the record list | Used to query a single record's run detail |
The starting value for this hypothetical exercise sets detail to true, because the check needs the node fields inside responseData. The comparison object is the intermediate values absent when detail=false. This starting value is not an official default.
Three common errors
- Combining requests with an empty chatId and requests with a non-empty chatId into one session tally. Check: submit two requests, one without chatId and one with chatId, compare the returned session attribution and history content, and observe whether the two are recorded separately.
- Reusing one responseChatItemId across two different chatIds. Check: submit the same responseChatItemId with two different chatIds, compare the returned storage result, and observe whether overwriting or an anomaly appears.
- Treating the score in quoteList as proof that retrieval excluded unrelated business records. Check: submit one query, compare the returned quoteList against the business document subjects, and observe whether score level corresponds to record ownership.
How to verify the setup
- Enter the arrival acceptance sheet and rejection sheet text from the hypothetical exercise, compare the draft sentence "Both batches received by Store A on 12 March passed acceptance" against the two materials, and observe that the rejection sheet places L-0313 in a pending supplier confirmation status, so the draft sentence is unsupported.
- Submit one request with detail=true and one with detail=false, compare the returned structures for the presence of responseData, and observe that node response fields appear with detail=true and are absent with detail=false. For an empty-result handoff, a paper input of [] can be used to check the downstream display design; this does not claim that retrieval returns an empty array.
- Submit one request with an empty chatId and one with a non-empty chatId, compare the returned history content, and observe that a non-empty chatId uses the database session while an empty chatId does not use the context feature.