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 updated weekly or monthly, with fields including inspection item, location, date, and inspector signature; hazard rectification ledgers are updated on a rolling basis by rectification milestone, with fields including hazard name, quantity, responsible person, rectification deadline, and acceptance signature; emergency incident reports are submitted immediately when an incident occurs, with fields including incident name, number of people involved, date of occurrence, reporter, and receipt. When these three types of materials enter the parsing and chunking function, the safety inspection checklists and hazard rectification ledgers play the role of cross-verification, while the emergency incident reports play the role of timeliness tracing. The name, quantity, and date of the same hazard in the two materials must remain consistent, and signatures and receipts must not be missing.
Configuration and implementation checks
This step is executed by the parsing and training task (server-side task), which outputs data rows and index status (parsed, indexing, indexed). "Version ledger and change records" is then completed by retrieval and subsequent processing.
| Object | Check | Verification action |
|---|---|---|
| Safety inspection checklist | Inspection item, location, date, and inspector signature must be aligned item by item with the hazard rectification ledger | Check the file records and data rows, confirm that the chunks split out by chunkSize and chunkSplitter cover all inspection items, and that the status is parsed |
| Hazard rectification ledger | Hazard name, quantity, responsible person, rectification deadline, and acceptance signature must be consistent with the safety inspection checklist | Check whether the data row status transitions from indexing to indexed, and verify trainingType and the coverage scope of the rebuild task |
| Emergency incident report | Incident name, number of people involved, date of occurrence, reporter, and receipt must be consistent with the reporting records | Check the file records and data rows separately, confirm that the old version is traceable and references are synchronized, and that the status is indexed |
| Version ledger and change records | The current version is unique, old versions are traceable, and references are updated synchronously | After changing one piece of content, check whether the version number and references are synchronized, and confirm that the rebuild only covers data that has already completed indexing |
Three common errors
- Symptom: a newly uploaded safety inspection checklist cannot be found. Cause: the data row is in parsed or indexing status; data pending indexing does not participate in recall, and successful parsing does not equal a retrieval hit.
- Symptom: the name, quantity, and date of the same hazard do not match between the ledger and the report. Cause: the two materials were not synchronized to the same version, and references were not updated with the change.
- Symptom: after a training failure, empty data rows remain or signatures/receipts are missing. Cause: the initial training covered data pending indexing, and the failed data was not edited or deleted in time.
How to verify the setup
This feature's acceptance: upload one material, observe the data row status transitions and the coverage scope of the rebuild task, confirm that the three states parsed / indexing / indexed are consistent with the interface display, and that the rebuild targets only data that has already completed indexing.
Business test: change one piece of content, and check whether the version number and references are updated synchronously
- Open the data rows to check the status, confirm it is one of the three states and consistent with the interface display, and check the file records and data rows separately
- Check the data rows covered by the rebuild task, confirm that only data that has already completed indexing is covered, and that unchanged vectors are not recalculated after switching models