What this category's data looks like
This category's data covers three types of materials: self-assessment reports, issue lists, and rectification plans. Sources are kindergarten submissions, responsible inspector feedback, and rectification receipts. The update cadence follows the self-assessment cycle and rectification milestones. Field characteristics center on kindergarten name, number of classes, number of children, issue items, rectification deadline, responsible person's signature, and receipt date. When materials enter the document parsing and chunking stage, the self-assessment report carries the overall conclusions and indicator scores, the issue list carries item-by-item issues and corresponding evidence, and the rectification plan carries measures, deadlines, and signature fields. The three types of materials often have the same record appearing repeatedly across different documents, and names, quantities, dates, and signature statuses can easily diverge. A version ledger and change records are needed to pin down the current version, old-version traceability, and reference synchronization, avoiding retrieval hits on outdated content.
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. After parsing is complete, parsing and chunking immediately persist to the database as visible data rows and bind a unique data identifier; the index transitions through the three states parsed, indexing, and indexed.
| Object | Check | Verification action |
|---|---|---|
| Self-assessment report | Name, number of classes, number of children, date, and signature must be consistent with the issue list and rectification plan | Open the data row to check whether the status is parsed, indexing, or indexed, and compare the kindergarten name and quantity fields in the report |
| Issue list | Issue items, responsible person, and rectification deadline must correspond item by item with the rectification plan | Check the file records and data rows separately to confirm that the name, quantity, and date of the same issue in the two materials have not diverged |
| Rectification plan | Rectification measures, completion date, and signature receipt must form a closed loop with the issue list | Check whether the data rows covered by the rebuild task fall only on data that has completed indexing, and inspect the signature and receipt fields |
| Parsing and training tasks | Initial training covers data pending indexing and data being indexed; rebuild targets only data that has completed indexing | On the training dashboard, view progress by processing mode, and check the chunking results corresponding to trainingType and the chunkSize and chunkSplitter configurations |
Three common errors
- Symptom: newly uploaded materials 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 same record's name, quantity, and date do not match between the self-assessment report and the issue list. Cause: versions are not synchronized, the old version is still hit by retrieval, and references are not updated with the current version.
- Symptom: the rectification plan lacks a signature or receipt. Cause: change records are not bound to the signature field and receipt date, the version ledger does not mark the current version as unique, and the old version is traceable but has not been replaced.
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, and confirm that the status transitions among parsed, indexing, and indexed and that rebuild covers only data that has completed indexing.
Business test: change one piece of content, see whether the version number and references are updated synchronously, and check whether the identifiers of file records and data rows can be distinguished.
- Open the data row to check that the status matches the interface display, confirm that data pending indexing is not recalled, and that failed training data can be directly edited or deleted.
- Check the file records and data rows separately, inspect the chunking and training modes corresponding to
chunkSize,chunkSplitter, andtrainingType, and review the scope of data rows covered by the rebuild task.