What this category's data looks like
Common materials for school safety hazard inspections and campus incident reporting include safety checklists, hazard rectification ledgers, emergency incident reports, parent notification receipts, and emergency plan version pages. Sources are mostly internal self-inspection records, feedback from higher-level inspections, class daily reports, and gatekeeper logs, with an update cadence of daily patrols, weekly summaries, monthly archiving, and immediate supplementary reporting after an incident occurs. Field characteristics center on inspection items, hazard descriptions, rectification responsible persons, rectification deadlines, re-inspection conclusions, incident course, reporting time, signatures, and receipts. When materials enter parsing and training tasks, safety checklists and rectification ledgers play the role of field comparison, emergency incident reports play the role of timeline and signature verification, plan version pages play the role of determining current validity, and receipts play the role of delivery confirmation.
Configuration and implementation checks
This part is executed by parsing and training tasks (server-side tasks), outputting data rows and index status (parsed, indexing, indexed). "Basis entries that can be traced back to the original text" are then completed by retrieval and subsequent processing. After parsing is completed, parsed chunks are immediately persisted as visible data rows and bound to a unique data identifier, and indexing flows through the three states parsed, indexing, and indexed.
| Object | Check | Verification action |
|---|---|---|
| Safety checklist | Inspection items, dates, and signatures must match the rectification ledger; missing signatures or receipts are regarded as incomplete basis | Separately check the file records and data rows, and confirm that the inspection date, inspector signature, and re-inspection conclusion are consistent |
| Hazard rectification ledger | The name, quantity, and date of the same hazard in the two materials must not mismatch, and the version must be current | Open the data row to check whether the status is parsed or indexed, and compare the rectification deadline with the re-inspection date |
| Emergency incident report | The incident course, reporting time, and receipt must be traceable back to the original text; a missing receipt is regarded as delivery not closed-loop | Check the signature fields of the report and receipt, and confirm that the reporting time and parent notification time are consistent |
| Data rows and index status | It is in one of the three states and consistent with the interface display; data pending indexing does not participate in recall | Check whether the data rows covered by the rebuild task contain only data with completed indexing, and verify trainingType and chunkSize |
Three common errors
- Phenomenon: the name, quantity, and date of the same hazard in the checklist and rectification ledger do not match. Cause: the two materials were entered separately, without cross-material field comparison and traceback-to-original-text verification.
- Phenomenon: the plan version was not synchronized, and old-version clauses were cited when replying to parents. Cause: the version page was not updated with the current document, and retrieval still recalled historical chunks.
- Phenomenon: the emergency incident report lacks signatures or receipts, and the basis entries cannot be closed-loop. Cause: receipts were not fully collected during the reporting and notification stages, and fields were incomplete when the materials entered parsing.
How to verify the setup
Acceptance of this feature: upload one material and observe the data row status transitions and the coverage scope of the rebuild task. Data rows should move from parsed to indexing and then to indexed; data pending indexing does not participate in recall; changing the model only rebuilds data with completed indexing, and verify the persisted results of trainingType, chunkSplitter, and chunkSize.
Business test: ask a cross-material basis question and see whether the answer gives a traceable source. For example, ask whether a certain hazard rectification was re-inspected within the specified deadline; the answer must trace back to the original text of the safety checklist and rectification ledger, and indicate the date and signature.
- Separately check the file records and data rows, and confirm that the identities of the file records and data rows are distinguishable, and that the status is consistent with the interface display.
- Check whether the data rows covered by the rebuild task contain only data with completed indexing, and verify the persisted results of
trainingType,chunkSplitter, andchunkSize.