What this category's data looks like
Materials for the school safety hazard inspection and campus incident reporting category include three types: safety inspection checklists, hazard rectification ledgers, and emergency incident reports. Safety inspection checklists are updated according to the inspection cycle, and their fields cover inspection date, inspector signature, hazard description, and rectification requirements; hazard rectification ledgers are updated on a rolling basis with rectification progress, and their fields include hazard name, rectification responsible person, completion date, and acceptance signature; emergency incident reports are submitted immediately when an incident occurs, and their fields include incident name, occurrence time, number of people involved, reporter signature, and receipt number. When these three types of materials enter the Q&A intake and missing-item follow-up function, the safety inspection checklist serves as the inspection basis and provides hazard entries, the hazard rectification ledger serves as the handling basis and provides rectification status, and the emergency incident report serves as the reporting basis and provides incident elements. For the same record, the hazard name, quantity, and date in the safety inspection checklist and the hazard rectification ledger may not match, and when an emergency incident report lacks a signature or receipt, acceptance cannot be confirmed. In multi-turn dialogue, the model needs to refer to the preceding text according to the number of memory turns, identify missing items, and ask follow-up questions before answering.
Configuration and implementation checks
This part is executed by the number of memory turns and the prompt configuration in the application settings, and outputs the range of historical messages referenced and the answer constraints. The intake record and the completed follow-up questions are then completed by the model. The number of memory turns controls how many previous dialogue turns can be referenced at most when answering; if the value is too small, the preceding text cannot be used, and if the value is too large, irrelevant content is brought in and consumption increases.
| Object | Check | Verification action |
|---|---|---|
| Safety inspection checklist | Whether the inspection date, inspector signature, and hazard description are consistent with the hazard rectification ledger | Check the name, quantity, and date of the same hazard in the two materials, check whether the signature fields are complete, and confirm whether the preceding turns in messages cover this record |
| Hazard rectification ledger | Whether the rectification responsible person, completion date, and acceptance signature correspond to the safety inspection checklist | Compare the hazard entries in the ledger and the checklist, check whether the versions are synchronized, and confirm whether the historical message range corresponding to chatId includes the rectification record |
| Emergency incident report | Whether the incident name, occurrence time, number of people involved, reporter signature, and receipt number are complete | Check whether the report signature and receipt are missing, verify the incident element fields in variables, and confirm whether the preceding turns reference this report |
| Number of memory turns | Matches the range of preceding text required by the question | Check the current value in the application settings, run a trial with two consecutive question turns, and compare the usage records of the two runs |
Three common errors
- Phenomenon: The name, quantity, and date of the same hazard in the safety inspection checklist and the hazard rectification ledger do not match. Cause: The two materials are entered separately and no cross-validation is performed, resulting in contradictions between the intake record and the completed follow-up questions.
- Phenomenon: The emergency incident report lacks the reporter signature or receipt number. Cause: The reporting step does not enforce validation of the signature and receipt fields, so the model cannot confirm the acceptance status when answering based on it.
- Phenomenon: When the second question uses a reference, the answer does not address the question. Cause: The number of memory turns is too small, so the preceding text is not referenced, or the opening message is treated as preceding text and brings in irrelevant content.
How to verify the setup
Acceptance of this function: with two consecutive follow-up questions, see whether the second question inherits the reference from the first question, check whether the preceding turns in messages are correctly referenced, and whether chatId and variables correspond to the same session.
Business test: ask a question that lacks key information and see whether it asks a follow-up question before answering.
- Check the current value of the number of memory turns in the application settings, run a trial with two consecutive question turns, and confirm that the second question can correctly inherit the reference from the first question.
- Compare the usage records of the two runs, check the consumption change after adjusting the number of turns, and confirm that the range of preceding text matches what the question requires.