What this category's data looks like
This category's data covers three types of materials: laboratory grading and classification tables, hazard source lists, and safety responsibility statements. The grading and classification table is organized by fields such as room, hazard source category, risk level, and responsible unit, and is updated as campuses are renovated, equipment is added or removed, and personnel change; the hazard source list records name, quantity, storage location, and control measures, and version differences often arise from procurement, scrapping, and transfers; the safety responsibility statement contains the responsible person, signature, date, and receipt, and is re-signed when positions change. After these materials enter parsing and training tasks, the grading and classification table and the hazard source list serve as data rows to be retrieved, and the responsibility statement serves as a traceable attachment; each is bound to a unique data identifier and stored according to the parsing, indexing, and training pipeline, for use in subsequent retrieval and ledger generation.
Configuration and implementation checks
This step is executed by parsing and training tasks (server-side tasks), outputting data rows and index status (parsed, indexing, indexed). The version ledger and change records are then completed by retrieval and subsequent processing.
| Object | Check | Verification action |
|---|---|---|
| Laboratory grading and classification table | Fields include room number, hazard source category, risk level, responsible unit, and effective date, and correspond item by item with the hazard source list | Check whether the name, level, and date of the same room in the two materials are consistent, and check whether the version number is synchronized |
| Hazard source list | Name, quantity, storage location, and control measures are consistent with the references in the grading and classification table, and quantity and date are traceable | Check the file records and data rows separately, and confirm that quantity, date, and signature fields have no missing items |
| Safety responsibility statement | Responsible person, signature, date, and receipt are complete and correspond to the current version | Check whether signatures and receipts are missing, whether the old version is traceable, and whether references point to the current version |
| Data row index status | Is in one of the three states parsed / indexing / indexed and is consistent with the interface display | Open the data row to check the status, confirm that data pending indexing does not participate in recall, and that rebuilding only covers data whose indexing is completed |
Three common errors
- Symptom: the name, quantity, and date of the same record do not match between the grading and classification table and the hazard source list. Cause: the two materials are updated separately, without field-level comparison and version synchronization.
- Symptom: the responsibility statement lacks a signature or receipt, and the old version is still referenced. Cause: the signing process is not closed-loop, the version is not synchronized, and references do not point to the current version.
- Symptom: newly uploaded materials cannot be found, and failed training leaves empty data rows. Cause: successful parsing does not equal a retrieval hit, the index status has not reached completed, and data pending indexing does not participate in recall.
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, check the parsing chunking and training mode corresponding to chunkSize, chunkSplitter, and trainingType, and confirm that the three states parsed, indexing, and indexed are consistent with the interface display.
Business test: change one piece of content, and see whether the version number and references are updated synchronously
- Open the data row to check the status, and confirm that the file record and the data row each have distinguishable identities, that the old version is traceable, and that the current version is unique
- Check the data rows covered by the rebuild task, and confirm that it only covers data whose indexing is completed, and that data pending indexing does not participate in the rebuild chain