What the documents look like
Site selection and store opening happen before a store begins trading, and the work centres on lease negotiation and construction handover. The working materials are a site evaluation form, a lease letter of intent, a renovation budget and an opening schedule. Data comes from trade-area footfall, map POI, POS history by store type and landlord records. These materials are updated per store on an irregular basis, and the consequences of error are opening losses, delayed handover or deposit loss.
The conversation logs and audit step handles the session records produced by headquarters expansion staff, regional development staff and engineering managers during order fulfilment and after-sales question handling, and whether those records can be located, checked and retained. Materials sit across several entry points. When session identity is not aligned with the business record, later reconciliation lacks a reliable anchor.
Constraints at the conversation logs step
Session identity is anchored on chatId. When chatId is a non-empty string, FastGPT reads the session from its database and uses the last item of the messages array as the user question, ignoring the remaining messages. When chatId is not passed, the context feature is not used and context is built entirely from the passed messages. A passed responseChatItemId becomes the response message ID for that turn and is stored in the database; it must be unique under the current chatId. The model, temperature and similar parameter fields on the chat endpoint are invalid and are determined by the orchestration. The detail field controls whether intermediate values are returned: in non-stream mode the result sits in responseData, and in stream mode it is distinguished by event. Session management endpoints can list sessions, change title and top status, delete a single session, or clear sessions created by an API key. Conversation management endpoints retrieve run detail by dataId, delete a conversation, and update like or dislike feedback. These are record location and reading capabilities. Business reconciliation, retention and compliance audit need a complete business solution implemented separately.
Hypothetical drill sample, provided for checking only. A site evaluation form states: "Object: a street-front unit in a named trade area; Stage: intent discussion; Valid until 31 March 2025; Authorization scope: regional development may initiate drafting of a lease letter of intent." A lease letter of intent in the same batch states: "Status is awaiting landlord signature; Deposit clause: subject to the final contract." A proposed handover request reads: "The lease for this unit is confirmed; renovation scheduling can proceed." Point to determine: whether "lease confirmed" in the proposed handover request is supported by the materials.
Configuration and implementation checks
| Configuration item | Value or check method | Relation to the sample |
|---|---|---|
| chatId | Non-empty string, length under 250, kept consistent for one session | Locates the session for this unit |
| responseChatItemId | Unique under the current chatId | Marks the response message for this turn |
| detail | When true, non-stream results sit in responseData | Used to check run detail fields |
| source | Session list read with source set to api | Separates API-created sessions |
| dataId | Retrieves run detail for a conversation under a session | Locates a single conversation |
| loadCustomFeedbacks | Optional; reads custom feedback | Used to check feedback fields |
Three common errors
- Treating the no-context behaviour of an omitted chatId as continuation of the same session. Input a request that omits chatId, compare how its messages build context against the database session read when chatId is passed, and observe whether the two context sources are mixed.
- Treating a display configuration returned by an interactive node as an authorization result. In the sample the lease letter of intent is awaiting landlord signature while the proposed handover request says the lease is confirmed; compare the two status fields and observe whether a pending signature is read as confirmed.
- Treating responseData fields under detail=true as complete retention of business data. Input one detail=true request, compare the returned fields against the fields needed for business reconciliation, and observe whether unreturned fields are assumed to be retained.
How to verify the setup
- Input the site evaluation form text and the proposed handover request from the sample. Compare "intent discussion" and "valid until 31 March 2025" against "lease confirmed". If the handover request falls outside the validity period or restates intent discussion as confirmed, record the claim as unsupported.
- Input the lease letter of intent text from the sample. Compare "awaiting landlord signature" against "lease confirmed". If the two statuses disagree, record an evidence gap and do not treat the lease as effective.
- Input a paper empty result [] together with the downstream design. Compare whether the downstream handles the empty result as empty, and observe whether any business action is taken without a basis. The retrieval check records only what is observed; it does not guarantee a first hit or full recall.