What this category's data looks like
This category's data involves three types of core materials: program setup application forms, talent cultivation plans, and expert review opinions. The application form contains the program name, code, program length, enrollment number, application date, and responsible person's signature; the cultivation plan contains the curriculum system, credits and class hours, cultivation objectives, and revision date; the review opinions contain the expert list, review conclusion, signatures, and receipt date. Materials enter intensively according to the annual application window, and versions iterate multiple times with internal school review and higher-level feedback. After entering this function, the application form and cultivation plan serve as parsing and chunking objects and are split into retrievable data rows; the review opinions serve as an independent material row, and their signature and receipt fields are compared at the field level with the ledger after parsing. In discrepancy localization, the three types of materials respectively play the roles of baseline, comparison, and supporting evidence.
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 "discrepancy list" is then completed by retrieval and subsequent processing. After parsing is completed, parsing chunks are immediately persisted as visible data rows and bound to a unique data identifier. The index transitions through the three states parsed / indexing / indexed. Data pending indexing does not participate in recall. Changing the model only rebuilds data that has already completed indexing.
| Object | Check | Verification action |
|---|---|---|
| Program setup application form | The program name, program code, enrollment number, application date, and responsible person's signature must match the ledger field by field | Check the file record and the data row separately, inspect the chunking result corresponding to chunkSize and chunkSplitter, and confirm that the name and quantity fields have not been truncated |
| Talent cultivation plan | The course names, credits and class hours, revision date, and approval signature must be consistent with the application form and the ledger | Check whether the data row status is indexed, compare whether the plan version number is synchronized with the ledger version, and inspect the processing mode corresponding to trainingType |
| Expert review opinions | The expert list, review conclusion, signatures, and receipt date must be consistent with the ledger, with no missing items | Check the signature column and receipt date fields, confirm that the review opinion data row has been parsed and is in one of the three states, and separately mark items missing signatures |
| Ledger record | The name, quantity, and date of the same program in the two materials should correspond exactly | Using the ledger as the baseline, compare the material data rows one by one, and output a list of fields with inconsistent names, quantities, or dates |
Three common errors
- Symptom: The enrollment number for the same program does not match between the application form and the cultivation plan. Cause: The versions of the two materials are not synchronized, and old-version data rows are still in indexed state and are recalled.
- Symptom: The review opinions are missing signatures or the receipt date. Cause: After parsing the scanned material, the signature column is empty, but the data row is still persisted as a visible data row.
- Symptom: Newly uploaded materials cannot be found. Cause: The data row is in parsed or indexing state, and data pending indexing is naturally isolated at the retrieval layer and is not recalled.
How to verify the setup
This function's acceptance check: 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 changing the model rebuild covers only data that has already completed indexing.
Business test: use one real record to find fields inconsistent with the ledger, compare names, quantities, dates, and signature receipts, output a discrepancy list for the reviewer to confirm and write back.
- Open the data row verification status, confirm that it is in one of the three states and consistent with the interface display, and check the file record and the data row separately
- Inspect the data rows covered by the rebuild task, confirm that it covers only data that has already completed indexing, and that the initial training covers data pending indexing and data in indexing