What this category's data looks like
This category's data covers three core types of materials: student status records, transfer applications, and suspension/resumption materials. Sources are school academic affairs, district/county student status management, and parent submissions. The update cadence varies with student status establishment at the start of the semester, changes during the semester, and archiving at the end of the semester. Field characteristics center on student name, ID number, student status number, class, date, signature, and receipt. When materials enter parsing and training tasks, student status records serve as the primary record and carry the identity anchor, while transfer applications and suspension/resumption materials serve as the basis for changes and carry event evidence. The three must corroborate each other on fields, dates, and signatures. Data versions and change maintenance require that the current version be unique, old versions be traceable, and references be synchronized, avoiding mismatches in names, quantities, or dates for the same record across two materials, or unsynchronized versions, missing signatures, and missing receipts.
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 chunks are immediately persisted as visible data rows and bound to a unique data identifier. Indexing flows through three states, and data pending indexing does not participate in recall.
| Object | Check | Verification action |
|---|---|---|
| Data row | Is in one of the three states and consistent with the interface display | Open the data row to check the status, and confirm that the transitions of parsed, indexing, and indexed are consistent with the interface |
| File record and data row | The identities of the file record and the data row are kept separate | Check the file record and the data row separately, and confirm that the unique data identifier is not mixed up |
| Student status record | Fields, dates, and signatures are complete and consistent with the transfer application and suspension/resumption materials | Compare name, student status number, date, and signature, and check whether the same record matches |
| Transfer application and suspension/resumption materials | The basis for change is synchronized with the primary record version and no receipt is missing | Check whether the version number and references are synchronized, and check whether signatures and receipts are complete |
Three common errors
- Symptom: The name or date of the same student does not match between the student status record and the transfer application. Cause: The data version is not synchronized; the old version is traceable but the reference has not been updated.
- Symptom: Suspension/resumption materials lack a signature or receipt but still enter subsequent processes. Cause: Parsing only persists data rows; signature and receipt verification is completed by retrieval and subsequent processing.
- Symptom: Newly uploaded materials cannot be found. Cause: The data row is in a pending-indexing state and does not participate in recall; you must wait for indexing to complete.
How to verify the setup
Check whether the data row status is parsed, indexing, or indexed, and confirm it is consistent with the interface display.
View the data rows covered by the rebuild task, and confirm that it targets only data that has completed indexing; data pending indexing does not participate in the rebuild.
- This feature's acceptance: upload one material, observe the data row status transitions and the coverage scope of the rebuild task, and check the parsing and training output corresponding to
chunkSize,chunkSplitter, andtrainingType. - Business test: change one piece of content, and see whether the version number and references are updated synchronously.