What data belongs to this category
Data for this category is generated across the full user acceptance testing workflow. Sources include requirement specification documents, test environment interaction records, client business sample data, and defect tracking systems. Data updates once per test phase or version iteration. Associated daily documents include UAT test cases, acceptance issue tickets, acceptance reports, and signed confirmation forms. Data fields include conversation identifiers, associated case numbers, operator identities, interaction timestamps, token consumption, and operation types. No custom extended fields are included. This page is compatible with FastGPT v4.17.0.
What constraints these characteristics impose on conversation logs and auditing
This category’s data has dispersed sources and links to multiple types of business documents. It requires the conversation logs and auditing workflow to forcibly bind chatId with the corresponding UAT case number, to ensure logs can be traced back to specific test scenarios. The phase-based update rhythm of data requires audit storage to divide archive units by test phase, to avoid mixing data across phases. The fixed daily document field characteristics require log fields to align with case numbers and timestamps from UAT test cases and acceptance issue tickets, to facilitate associated calls during subsequent acceptance report generation. Multi-role participation scenarios require audit permissions to distinguish operation scopes for implementation consultants, test managers, and client business representatives, to prevent unauthorized modification or deletion of audit data. For time-consuming links such as case preparation and issue reproduction classification, logs must fully record interaction details to enable quick backtracking of verification basis.
How to set configurations
| Configuration Item | Recommended Setting | Rationale |
|---|---|---|
| Mandatory case identifier binding | Bind chatId with UAT case number | Ensure every log can be traced back to a specific test scenario, matching the association requirements of this category’s data |
| Log content storage | Fully store interaction content in the detail field | Cover conversation details across the full UAT testing workflow, meeting complete record requirements for compliance auditing |
| Token consumption statistics | Enable responseChatItemId associated statistics | Match the token consumption statistics field in this category’s data, enabling resource usage statistics per case |
| Log retention period | Retain until 30 days after the acceptance phase ends | Align with the archiving cycle of the acceptance workflow, preventing audit gaps caused by early deletion |
| Historical context scope | Limit to only calling the first 5 conversations of the current case | Control context length, avoiding excessive token consumption |
Three common configuration errors
- Symptom: After deleting a single conversation, the overall
chatIdassociated log disappears. Cause: The mandatory retention policy forchatIdbinding is not enabled, and the session deletion logic is mistakenly applied to case-bound associated logs. - Symptom: Token consumption statistics calculated per application do not match results calculated per case. Cause:
responseChatItemIdis not used to associate with specific cases, leading to statistics covering conversations outside the test scenario. - Symptom: Workflows set to retain only 1 chat record still link to very old historical conversations, or using the API to start a new conversation unexpectedly adds an extra historical record. Cause: The case scope of the conversation is not limited, and the call logic pulls global historical conversations instead of binding to current case conversation data.
How to confirm configuration is complete
- View the associated fields of a single conversation, confirm that
chatIdis bound to the corresponding UAT case number. - Perform a test conversation deletion operation, verify that logs for the corresponding
chatIdare not deleted entirely. - Initiate a token consumption statistics request, confirm that the statistics scope only covers conversations for the current test case.
- Trigger a workflow or API call to pull historical context, verify that only conversation records within the current case scope are retrieved.
The values provided are common starting points and should be evaluated against samples from the target deployment.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-10-19.