What this category's data looks like
School safety hazard inspections and campus incident reporting involve three types of materials: safety inspection checklists, hazard rectification ledgers, and emergency incident reports. Safety inspection checklists are filled out weekly or monthly by the inspector, recording the hazard name, location, quantity, inspection date, and signature; hazard rectification ledgers are updated by the safety officer according to the rectification cycle, containing the hazard number, rectification responsible person, rectification deadline, completion date, and receipt; emergency incident reports are submitted within a time limit after the incident occurs, containing the incident name, number of people involved, date of occurrence, reporter's signature, and receipt of acceptance. After the three types of materials enter parsing and chunking, each becomes a searchable data row, used for subsequent material verification and discrepancy localization.
Configuration and implementation checks
This step is executed by the parsing and training task (server-side task), outputting data rows and index status (parsed, indexing, indexed). The "discrepancy list" is then completed by retrieval and subsequent processing.
| Object | Check | Verification action |
|---|---|---|
| Safety inspection checklist | The name, quantity, and date of the same hazard are consistent across the two materials, and signatures are complete | Verify the data row status and index status, and confirm that fields are complete after splitting by chunkSize and chunkSplitter |
| Hazard rectification ledger | The name, quantity, completion date, and receipt of the rectification record are consistent, and versions are synchronized | Verify the file record and data row identity separately, and check whether trainingType and the index are consistent |
| Emergency incident report | The incident name, number of people involved, date of occurrence, reporting signature, and receipt of acceptance are consistent | Open the data row to verify the status, and confirm that the parsed / indexing / indexed transitions are consistent with the interface display |
Three common errors
- Symptom: The name and quantity of the same hazard do not match between the safety inspection checklist and the rectification ledger. Cause: The versions of the two materials are not synchronized, or field attribution is misaligned after parsing and chunking.
- Symptom: The emergency incident report lacks a signature or receipt, making it impossible to confirm that the reporting loop is closed. Cause: The scanned material does not include the signature page, or the signature area is cut into an adjacent data row during chunking.
- Symptom: A newly uploaded material cannot be found. Cause: The data row is in a pending-indexing state, and the retrieval layer is naturally isolated, so it only participates in recall after indexing is complete.
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.
Business test: use one real record to find a field that is inconsistent with the ledger.
- Open the data row to verify the status, and confirm that parsed / indexing / indexed are consistent with the interface display
- Verify the file record and data row identity separately, and check the data row scope covered by the rebuild task