What the documents look like
This page covers the conversation logs and audit step inside the order fulfilment and after-sales question task for franchisee training and opening coaching. The category differs from franchise filing management: opening coaching transfers operating capability, so the working materials are training sign-in sheets, opening checklists, SOP manuals and assessment results. These materials come from training systems, supervisor apps, store photos and the head office SOP library. When they are mishandled, the consequences are failed openings, inconsistent customer experience and franchisee complaints.
Training sign-in sheets and assessment results are per-store, per-month records. Opening checklists and SOP manuals are referenced repeatedly during the coaching period. A conversation log becomes useful for this task only when a question-and-answer turn can be tied to a specific store and a specific coaching stage. The log has to carry the store identity and the stage identity, otherwise fulfilment and after-sales reconciliation cannot attach a reply to the right obligation.
A conversation identity is defined by chatId, and dataId points to one conversation turn inside that conversation. When checking an opening coaching question for one store, first confirm that the chatId belongs to that store and that stage, and avoid merging turns from different entry points into one total. When run detail is needed, set detail according to the official contract and inspect the module responses in responseData. A business field that does not appear in the response cannot be assumed to have been retained in full.
An existing log does not by itself complete a compliance audit. Reconciliation, retention and compliance requirements are carried out by a complete business plan elsewhere. The similarity and relevance values of a retrieval library do not perform permission or entity isolation, and a retrieval result does not constitute authorization.
Hypothetical drill sample. The source text available for checking consists of three statements. First, the sign-in sheet states: "On 5 March 2025, the A-store franchisee completed the cashier module training, and the sign-in is valid." Second, the opening checklist states: "On 20 March 2025, the A-store opening materials check, status is pending review." Third, the SOP manual states: "Cashier exception handling actions follow the current head office version." One draft sentence to be judged is: "The A-store cashier training and opening materials have both been confirmed as passed, and the store may enter formal operation." That sentence merges a valid sign-in and a pending review into a passed state, and it does not give the SOP version correspondence.
Constraints at the conversation logs step
The primary task is order fulfilment and after-sales question answering. The audit constraint is that a log entry proves only that a turn occurred; it does not prove that a business check, an approval or a handover was completed. A pending review is not an approval. An offered option is not an execution. An unsigned termination is not a completed termination.
The chatId defines the session. When chatId is a non-empty string, FastGPT uses it to fetch the session from its database and treats the last item in the messages array as the user question; the remaining messages are ignored. The caller has to keep chatId unique and shorter than 250 characters. A responseChatItemId, when supplied, becomes the response message ID and has to be unique under that chatId.
The detail parameter controls whether intermediate values are returned. Under stream mode these arrive through distinct events; under non-stream mode the intermediate values are held in responseData. The model and temperature fields passed in the request do not take effect, because those fields are decided by the orchestration. Actual token consumption is not returned; if it is needed, set detail=true and calculate the tokens values inside responseData manually.
Retrieval is not authorization. A relevance score is not a category, entity or permission filter, and a similarity setting does not exclude unrelated businesses or unauthorized records. Forms collect values; business verification, approval, database writes and external synchronization each need their stated downstream implementation. Without a documented error code or an actual observation, record what to compare and leave the outcome unknown rather than naming a deterministic failure cause.
Configuration and implementation checks
The table below lists official documented settings or implementation checks relevant to this function and the primary task, around the sample above. The values are hypothetical starting points for this drill, chosen to make the comparison method explicit; they are not official default values.
| Configuration item | Hypothetical drill starting value | Check method and reason |
|---|---|---|
| appId | appId of the sample application | Check together with chatId to confirm the session belongs to this application |
| chatId | Identifier of the A-store coaching session | Keep it unique and shorter than 250 characters; used to fetch that session context |
| detail | Set to true | Enable when run detail is needed, then inspect responseData |
| stream | Set to false | Makes choices and responseData directly readable in one response |
| messages | One user question | Works with chatId; the last item is taken as the user question |
| loadCustomFeedbacks | Set to true | Reads custom feedback together with the conversation list |
Three common errors
- Treating "pending review" as "passed". In the sample, the opening checklist status is pending review, while the draft sentence says both items have been confirmed as passed. To check this, take the checklist source text and the draft sentence as input, compare the status field value, and require an explicit passed status. A pending review is not supported by the evidence.
- Merging question-and-answer turns from different sessions. Different chatId values belong to different sessions, and merging them misplaces the store and the stage. To check this, take two chatId values and their respective turns as input, compare the dataId ownership, and only records under the same chatId may be grouped into the same coaching stage.
- Using a similarity score to infer permission or entity ownership. A relevance value is not a permission or entity filter. To check this, take the returned score and the target store identifier as input, compare the business identifier on the returned record, and note that a high or low score does not change whether that record belongs to the target store. Ownership has to be checked separately.
How to verify the setup
- Verification one. For the sample draft sentence, take the sign-in sheet source text, the opening checklist source text and the draft sentence as input, and compare whether the draft sentence matches the status in both source statements. The opening checklist is pending review, while the draft sentence says it has been confirmed as passed. The sentence does not meet the condition and is recorded as unsupported.
- Verification two. For the sample session, take the chatId and a request with detail=true as input, and compare whether the module responses in responseData contain the required fields. If a business field does not appear in the returned data, record it as unknown and do not assume it was retained.
- Verification three. For empty-result handling, take a paper retrieval result of [] as input and compare how the downstream design behaves when no reference is present. This input only checks the handling logic; it does not assert that a retrieval with fictional rules will return an empty array.
These verifications are paper checks. They were not executed and do not constitute a test, a deployment or an approval conclusion.