What this category's data looks like
This page targets the scenario of credit management for primary and secondary school teacher training, and the materials come from three categories: training notices, credit recognition forms, and attendance rosters. Training notices provide the project name, training period, and credit cap, and are updated in sync with each training session's issuance; credit recognition forms carry the teacher's name, subject, recognized credits, and review signature, and are summarized and reported by semester; attendance rosters record attendance dates, sign-ins, and receipts, and are collected after the training ends. After these three categories of materials enter parsing and training tasks, notices are used to determine the basis criteria, recognition forms are used to verify credit amounts and signatures, and rosters are used to verify the correspondence between dates and personnel. Field characteristics center on name, ID number, project name, credit amount, start and end dates, and signature fields. Material versions roll forward with supplementary notices and correction statements; when old and new versions coexist, the current version must prevail, and records missing signatures or receipts cannot serve as basis entries.
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). Basis entries that can be traced back to the original text are then completed by retrieval and subsequent processing.
| Object | Check | Verification action |
|---|---|---|
| Training notice | The project name, training period, and credit cap must be consistent with the current issuance version, and the notice and recognition form must match the original text for the same project's name and dates | Check the notice version number and issuance date, compare the project name and start and end dates in the recognition form, and confirm there are no remnants of the old version |
| Credit recognition form | Teacher name, subject, recognized credits, and review signature are complete, and the same record's amounts and dates do not conflict between the roster and the recognition form | Check the signature field and receipt one by one, compare the roster attendance dates with the recognized credits, and flag records missing signatures or receipts |
| Attendance roster | Attendance dates, sign-ins, and receipts can be traced back to the original text, and the correspondence between roster personnel and recognition form personnel is clear | Check the sign-in dates and receipt completeness, compare the name and amount of the same teacher in both materials, and confirm version synchronization |
| Data rows and index status | Data rows are in one of the three states parsed, indexing, or indexed and are consistent with the interface display, and rebuilds only cover data that has already completed indexing | Open the data rows to check the status, separately check the file records and data row identifiers, view the coverage scope of the rebuild task, confirm that the chunkSize and chunkSplitter settings match the material structure, and that trainingType corresponds to the processing mode |
Three common errors
- Symptom: The same teacher's name or credit amount does not match between the recognition form and the roster. Cause: The two materials were entered at different times, the correction statement was not synchronized to all materials, and the old-version data row is still in the parsed state and has not been replaced.
- Symptom: The project name in the training notice is inconsistent with the recognition form, and the dates span periods. Cause: After the supplementary notice was issued, the old-version notice was not taken down, the retrieval layer recalls both versions at the same time, and there is no current-version marker.
- Symptom: The recognition form lacks a review signature or receipt, but the material is still cited as a basis. Cause: The data row with an empty signature field has already completed indexing, and retrieval did not filter by signature completeness, so the basis entry cannot be traced back to valid original text.
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 status transitions among parsed, indexing, and indexed, that rebuilds only cover data that has already completed indexing, and check chunkSize, chunkSplitter, and trainingType.
Business test: ask a cross-material basis question and see whether the answer provides a traceable source.
- Open the data rows to check whether the status is parsed, indexing, or indexed, and separately check whether the file records and data row identifiers are distinguishable.
- View the data rows covered by the rebuild task, confirm that it targets only data that has already completed indexing, and check that
chunkSize,chunkSplitter, andtrainingTypematch the material structure.