What this category's data looks like
Grade entry and credit recognition involves three types of materials: transcripts, deferred examination applications, and make-up examination arrangements. Sources are mostly academic affairs system exports, college submissions, and teacher submissions, and the update cadence rolls with semesters, make-up examinations, and deferred examination milestones. Transcripts carry course names, credits, grades, and signatures; deferred examination applications carry the application reason, date, and approval signature; make-up examination arrangements carry the make-up examination course, time, location, and receipt. After these three types of materials enter this feature, parsing and chunking first form visible data rows, which then enter index flow for retrieval and subsequent processing to reference. Field characteristics center on course names, credit counts, dates, and signature receipts. The same record often has mismatched names, counts, and dates across different materials, versions are not synchronized, and signatures or receipts are missing.
Configuration and implementation checks
Parsing and training tasks (server-side tasks) only output data rows and index status (parsed, indexing, indexed). The version ledger and change records must be handled next 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 flows through three states, and data pending indexing does not participate in recall.
| Object | Check | Verification action |
|---|---|---|
| Transcript | Whether the course name, credit count, date, and signature are consistent with the current version | Open the data row to check whether the status is parsed / indexing / indexed, and check the chunk boundaries corresponding to chunkSize and chunkSplitter |
| Deferred examination application | Whether the application reason, date, and approval signature are complete, and whether they match the transcript record | Check the file record and the data row separately, confirm that the identifiers of the file and the data row are distinguishable, and check the processing mode corresponding to trainingType |
| Make-up examination arrangement | Whether the make-up examination course, time, location, and receipt are consistent with the deferred examination application and the transcript | Look at the data rows covered by the rebuild task, and confirm that it only covers data whose indexing is completed; data pending indexing does not participate in the rebuild |
| Version ledger and change records | The current version is unique, old versions are traceable, and references are synchronized | After changing one piece of content, check whether the version number and references are updated synchronously, and record the number of references and the tokens of the reference text |
Three common errors
- Symptom: materials just uploaded cannot be found. Cause: the data row is still in parsed or indexing, and data pending indexing is naturally isolated at the retrieval layer and is not recalled.
- Symptom: empty data rows remain after training fails. Cause: training interruption leaves orphan data, failed data is not edited or deleted in time, and the status is inconsistent with the interface display.
- Symptom: the name, count, and date of the same record do not match across two materials. Cause: versions are not synchronized, signatures or receipts are missing, and old-version references are not updated with the current version.
How to verify the setup
Feature acceptance: upload one material, observe the data row status transitions and the coverage scope of the rebuild task, confirm that only parsed / indexing / indexed appear as statuses, that the rebuild only covers data whose indexing is completed, and check the behavior corresponding to the three identifiers chunkSize, chunkSplitter, and trainingType.
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, confirm that it is one of the three states and is consistent with the interface display, and check the file record and the data row separately.
- View the data rows covered by the rebuild task, and confirm that it only covers data whose indexing is completed; data pending indexing does not participate in the rebuild.