What the documents look like
Brand livestream operations place script, inventory and after-sales responsibility on the brand team, with creator commissions not forming the main cost structure. This division shapes how conversation records for order fulfilment and after-sales questions are kept inside the brand's own application and data scope. The main data sources listed for this category are the Douyin store compass, Juliang Qianchuan, livestream comments and transaction details. Transaction details and after-sales work orders act as external references for checking order status, while conversation logs reflect the interaction process. Error consequences concentrate on false-advertising complaints, oversold inventory and falling conversion, so the audit focus for conversation logs is whether the input, run detail and feedback of a given answer can be traced, not whether the log replaces the order system in deciding fulfilment outcomes.
Conversation identity uses chatId as the session identifier and dataId as the identifier of one dialogue under a session. The supplied documents describe no automatic link between these identifiers and business order records, so comparison by subject, time and content remains manual. When run detail is needed, the official contract sets detail in the request; non-streaming results are held in responseData, and streaming results are distinguished through event. Without detail, intermediate values are not returned, and complete retention of business data cannot be inferred from that absence. Test-mode and production-call identity fields may differ, so input, history and returned content are checked separately. The existence of a log does not mean a compliance audit is complete; reconciliation, retention and compliance requirements belong to a full business plan.
Constraints at the conversation logs step
A hypothetical paper exercise sample is used below. A brand livestream team, after a livestream on 12 March 2025, exports order details from the Douyin store compass. One order carries the remark "placed, awaiting shipment, buyer has applied to change address". The team plans to send this draft reply to the buyer: "The order is confirmed, the address change has been synced to the warehouse, and it ships today." The material supplied for comparison states: order details show "awaiting shipment"; the after-sales work order shows "address change application under review"; the livestream script contains no clause promising address modification. The handover request to be judged is: confirm whether this draft sentence can be sent directly.
Several constraints follow. The draft asserts a synced address change and same-day shipment, while the supplied material records only an application under review and an awaiting-shipment status. The draft is therefore unsupported and remains pending verification. A form interaction collects values; business verification, approval, database writes and external synchronisation need their stated downstream implementation, and an application under review is not an approval. A similarity score returned by retrieval expresses degree of similarity; it does not exclude unrelated businesses or unauthorised records. Retrieval is not authorisation. When a chatId is non-empty, the system takes the session from the FastGPT database and uses the last item in the messages array as the user question, ignoring the rest; the chatId must be unique and shorter than 250 characters. When chatId is not passed, no FastGPT context is used and the context is built entirely from the messages supplied. The responseChatItemId, when passed, becomes the response message ID stored in the database and must be unique under the current chatId. The model and temperature fields passed in a request have no effect; orchestration decides them. Actual token consumption is not returned, and detail=true allows manual calculation from tokens in responseData.
Configuration and implementation checks
| Configuration or check item | Relation to this page's documents | Handling in the hypothetical exercise |
|---|---|---|
| appId and chatId | The chat interface locates the application by appId and the session by chatId | Take the application and session identifiers used for this after-sales answer and compare them with the buyer session in the order details |
| detail setting | Run detail is requested by setting detail under the official contract | The hypothetical starting value is true, chosen because responseData is needed to check node output; compare with the case where false returns no intermediate values |
| responseChatItemId | When passed, it is stored as the response message ID and must be unique under the same chatId | The hypothetical starting value is generated from the order number; check for duplication against existing values |
| Session list with source=api | When fetching the session list, source=api returns only sessions created through the API | Check whether this answer session appears in that list; page sessions are not included |
| loadCustomFeedbacks | Optionally read custom feedback when fetching the dialogue list | The hypothetical starting value is true, used to check whether like and dislike records return with the dialogue |
| Interactive node return fields | Interactive nodes return only type and params; internal runtime fields are not returned | Check whether form input is passed as an object serialised into a string as the messages value |
Three common errors
- Treating a detail=false response as a complete run record. The input is one detail=false response, the comparison object is the required node output, and the observable result is that responseData is absent; complete retention of business data cannot be claimed from this.
- Treating retrieval or form submission as authorised execution. The input is one form-input interaction, the comparison object is the after-sales status in the order details, and the observable result is that the form collects values only, while business verification, approval and database writes need downstream implementation; an application under review is not an approval.
- Treating a similarity score as a permission or entity filter. The input is one retrieval return carrying score, the comparison object is buyer identity and order ownership, and the observable result is that score expresses similarity only and does not exclude unrelated businesses or unauthorised records.
How to verify the setup
- Input the order details showing "awaiting shipment" and the work order showing "address change application under review" from the hypothetical sample, and compare the draft sentence "the address change has been synced to the warehouse, and it ships today" against the supplied material. The observable result is that the material records neither completed synchronisation nor same-day shipment, so the sentence is unsupported and is recorded as pending verification.
- Input one chat request with detail=true and compare the module output in the returned responseData against the request parameters. The observable result is that node status and complete results appear; when the same comparison is made with detail=false, responseData is absent, which distinguishes the two settings.
- Input two requests sharing the same chatId and compare whether responseChatItemId repeats. The observable result is that a repeated value violates the uniqueness requirement; with different chatId values, the same value does not conflict and each session is checked separately.