What this category's data looks like
This category's data looks like this: Material verification and discrepancy localization for primary and secondary school enrollment organizations revolves around three types of materials: enrollment plans, application material checklists, and admission lists. Enrollment plans are published by academic year or batch, and contain enrollment scope, time nodes, and admission rules; application material checklists are updated in sync with the plans, and list proof items such as household registration, property, and student status, as well as signature fields; admission lists are generated by the review step, and contain student name, ID number, admission batch, and receipt status. The three types of materials come from different sources and have different update rhythms, and their field characteristics center on names, quantities, dates, and signatures. When entering this feature, the enrollment plan serves as the rule source document, the application material checklist serves as the comparison baseline, and the admission list serves as the object to be verified; after being parsed and chunked separately, they are stored as data rows for subsequent retrieval and discrepancy localization.
Configuration and implementation checks
Configuration and implementation checks: This step is executed by parsing and training tasks (server-side tasks), and outputs data rows and index status (parsed, indexing, indexed). The discrepancy list is then completed by retrieval and subsequent processing. After parsing is completed, parsed chunks are immediately stored as visible data rows and bound to a unique data identifier; the index transitions through three states, and data pending indexing does not participate in recall.
| Object | Check | Verification action |
|---|---|---|
| Enrollment plan | Check whether the application start and end dates, batch name, and signature field in the plan are consistent with the application material checklist | Open the data rows of the two materials separately, compare the date fields and signature fields, and record inconsistent items |
| Application material checklist | Check whether the material item names and copy counts in the checklist are consistent with the corresponding fields in the admission list | Locate records in the retrieval layer by student name or ID number, and compare names and quantities field by field |
| Admission list | Check whether the admission batch, receipt status, and signature in the list are consistent with the ledger | Open the data rows to view the index status, confirm it is in parsed / indexing / indexed, and then compare |
| Data row | Check whether the data row status is consistent with the interface display, and whether the file record and the data row identifier are distinguishable | Check the file record and the data row separately, and view the range of data rows covered by the rebuild task |
Three common errors
- Symptom: The name or ID number of the same student does not match between the application material checklist and the admission list. Cause: The two materials are entered separately, and no field-level comparison is performed for the same object.
- Symptom: After the enrollment plan is updated, the application material checklist still uses the old dates and batch. Cause: Versions are not synchronized, the materials are maintained independently, and there is no unified version identifier.
- Symptom: The admission list lacks a signature or the receipt field is empty. Cause: The review step did not write back, the signature field is missing when the material enters parsing, and it cannot be located in the data rows.
How to verify the setup
How to verify the setup: Acceptance for this feature: upload one material and observe the data row status transitions and the coverage of the rebuild task. Check whether data rows transition through the three states parsed, indexing, and indexed, whether rebuilding when switching models covers only data whose indexing has been completed, and confirm the parsing and training parameters corresponding to chunkSize, chunkSplitter, and trainingType.
Business test: Use one real record to find a field that is inconsistent with the ledger, and hand it to the reviewer for confirmation and write-back.
- Open the data rows to check the status, confirm it is in one of the three states and consistent with the interface display; check the file record and the data row separately, and confirm that the two identifiers are distinguishable.
- View the data rows covered by the rebuild task, confirm that only data whose indexing has been completed is covered; perform read-only viewing of data pending indexing, which does not participate in recall.