What the documents look like
Franchise supervision records sit across a supervisor app, POS sales, the franchise system and store photographs, with weekly and monthly update rhythms. The working documents for this task are store visit forms, franchise contracts, rectification notices and display standards. A multi-turn conversation can only organize the context that these documents provide; the model does not receive live store execution status from the dialogue itself. Whether a rectification notice was delivered, whether a contract clause remains effective, and what a franchisee actually replied all require manual verification or a separate system connection.
Consider a paper-check sample, not a real record. The store visit form reads: "Week 2 of March 2024, Category A store, refrigerated cabinet temperature logged twice daily; one entry missing on 14 March; store manager note: equipment maintenance." The rectification notice reads: "Regarding the missing temperature entry on 14 March, supplement the record and reply before 20 March." A drafted sentence reads: "The store's refrigerated cabinet temperature records are complete, and rectification is finished." The source texts state one missing entry and one supplement request. Whether the supplement was submitted and whether rectification was accepted are not recorded, so the drafted sentence exceeds the available evidence.
Constraints at the multi-turn prompts step
The prompt must state the document scope, the answering task and how to handle missing evidence, and must not let the model supply business facts. History handling differs by session type. When chatId is a non-empty string, the system retrieves the session from the database and uses the last item of the messages array as the user question, ignoring the remaining messages. When chatId is absent, FastGPT does not use its own context feature and builds context entirely from the supplied messages. These two paths bring different context into a turn and should be checked separately.
Question optimization applies to continuous knowledge-base dialogue, where pronoun resolution and question expansion can be reviewed. Short questions in other settings are not covered by that assumption. Model and length settings need to match the model's supported context and reply configuration. Reply format follows the downstream consumer: plain text suits ordinary supervision dialogue, while json_schema requires the corresponding format requirements to be filled in and the returned structure verified.
Retrieval is not authorization. A relevance score is not a category, entity or permission filter, and a session lookup provides no basis for deciding contract validity or store permissions. Interactive forms collect values; business verification, approval, database writes and external synchronization remain downstream implementation concerns.
Configuration and implementation checks
| Configuration item | Value or check for this page | Explanation |
|---|---|---|
| Memory turns | Hypothetical trial starting point: 6 turns, compared against the two follow-up turns in the sample | Larger values carry more prior content; compare whether follow-ups still cite the correct document |
| Reply limit | Hypothetical trial starting point: set around the drafted sentence length, compare truncation position | A low setting may cut the reply short |
| Temperature | Hypothetical trial starting point: a lower value, compared with knowledge-base question answering | Rule-bound supervision dialogue needs stable answers |
| Reply format | Sample drafted sentence checked as plain text; choose json_schema only when a downstream step reads a fixed structure, then fill in the format requirements | Format depends on whether the downstream flow reads structured output |
| Multimodal recognition | When the sample includes store photographs, check whether the model supports image recognition | The option does not appear when the model lacks the capability |
| Hidden AI output | Check when an internal result in the sample must pass to a later node | Content is not shown directly but can still be handed to the next node |
Three common errors
- Treating "records are complete" in the drafted sentence as a confirmed fact from the store visit form. The form states one missing entry and a maintenance note. Input: the store visit form text. Comparison: the completeness wording in the drafted sentence. Observable result: whether the drafted sentence goes beyond what the source records.
- Treating the supplement request in the rectification notice as completed rectification. The notice states a supplement and reply requirement before 20 March. Input: the rectification notice text. Comparison: the phrase "rectification is finished" in the drafted sentence. Observable result: whether the source records a supplement reply or an acceptance record.
- Treating session retrieval under a non-empty
chatIdas verification of franchise contract or store permissions. Input: thechatIdin the request. Comparison: the authorization state of the contract or store. Observable result: whether the session lookup supplies any authorization basis.
How to verify the setup
- Input the sample store visit form text and the drafted sentence. Compare "records are complete" against the missing entry recorded in the source. Observe whether the model identifies insufficient evidence. The expectation is that the model does not confirm completeness; the actual result depends on the run.
- Input the sample rectification notice text and the drafted sentence. Compare "rectification is finished" against the supplement requirement in the notice. Observe whether the model separates a requirement from completion. The expectation is that the model notes the supplement reply status is not recorded.
- Input a continuing-session request containing only a
chatIdand a store name. Compare the returned content against the franchise contract authorization fields. Observe whether an authorization conclusion appears. The expectation is that the model gives no authorization judgment, and authorization status remains subject to manual verification.
Across all three checks, missing evidence stays missing. A pending request is not approval, an offered option is not execution, and an unsigned termination is not a completed termination.