What this category's data looks like
In the foreign teacher appointment and course scheduling scenario, appointment contracts, work permit materials, and course scheduling tables are the three core types of materials. Their sources are scattered across the school's human resources, academic affairs, and foreign affairs departments, and their update cadence is driven by contract renewals, permit changes, and semester scheduling. Appointment contracts focus on position, compensation, and signatures/seals; work permit materials focus on certificates, dates, and receipts; course scheduling tables focus on course names, class counts, and teaching times. After these three types of materials enter parsing and training tasks, each forms an independent data row, respectively taking on the roles of identity verification, permit traceability, and scheduling reference. Fields, dates, and signatures need to remain synchronized in the version ledger.
Configuration and implementation checks
This step is executed by parsing and training tasks (server-side tasks), outputting data rows and index statuses (parsed, indexing, indexed). The "version ledger and change records" are then completed by retrieval and subsequent processing.
| Object | Check | Verification action |
|---|---|---|
| Appointment contract | Contract fields, dates, and signatures must be consistent with the work permit materials, and names and quantities must match | Check whether the appointment contract data row status is indexed, and compare the signature and receipt fields |
| Work permit materials | Permit dates and receipts must be synchronized with the appointment contract; old versions must be traceable and the current version must be unique | Check whether the file record and the data row identifier are separate, and see whether the rebuild scope covers only data that has completed indexing |
| Course scheduling table | Course names, class counts, and teaching times must be consistent with the contract position | Check the course scheduling table data row status, and confirm that data pending indexing does not participate in recall |
| Data row | Is in one of the three states parsed / indexing / indexed and is consistent with the interface display | Open the data row to check the status, and inspect the processing modes corresponding to chunkSize, chunkSplitter, and trainingType |
Three common errors
- Symptom: a newly uploaded appointment contract 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: the same teacher's name and quantity do not match between the contract and the course scheduling table. Cause: the two materials are parsed independently, versions are not synchronized, and references are not updated with changes.
- Symptom: after a training failure, an empty data row is left behind, or rebuilding after switching models takes abnormally long. Cause: failed data is not edited or deleted in time, and the rebuild scope mistakenly covers data pending indexing.
How to verify the setup
Acceptance for this feature: upload one material and observe the data row status transitions and the coverage scope of the rebuild task.
Business test: change one piece of content and see whether the version number and references are updated synchronously.
- Check the file record and the data row separately, confirm that the identifiers of the file and the data row are separate, and that the data row status is consistent with the interface display.
- Inspect the data rows covered by the rebuild task, confirm that only data that has completed indexing is covered, and that data pending indexing does not participate in the rebuild chain.