What this category's data looks like
In the foreign teacher appointment and course scheduling scenario, materials usually come from three sources: appointment contracts, work permit materials, and course scheduling tables, with update cadence rolling along with approval nodes and scheduling cycles. Appointment contracts focus on position, term, compensation, and signature page; work permit materials focus on name, ID number, permit number, validity period, and receipt; course scheduling tables focus on course name, class, number of class hours, teaching date, and signature of the teaching supervisor. When these three types of materials enter the document parsing and chunking function, each plays a different role: contracts and permit materials provide appointment facts and compliance fields, while course scheduling tables provide scheduling facts and quantity fields. After parsing and chunking, they are stored as data rows for subsequent retrieval and review comparison, with field characteristics concentrated in four categories: name, quantity, date, and signature.
Configuration and implementation checks
This step is executed by the parsing and training task (server-side task), outputting data rows and index status (parsed, indexing, indexed). The discrepancy list is then completed by retrieval and subsequent processing; parsing and chunking itself does not produce a discrepancy list or business documents.
| Object | Check | Verification action |
|---|---|---|
| Appointment contract | Name, term, position, and signature page must be consistent with the work permit materials | Verify the contract name, permit number, start and end dates, and signature, record inconsistent fields, and mark the chunkSize chunk boundary |
| Work permit materials | Name, ID number, permit number, validity period, and receipt must be consistent with the contract | Verify the permit receipt date against the contract term, check for missing signatures or receipts, and confirm that fields do not cross chunks after chunkSplitter splitting |
| Course scheduling table | Course name, class, number of class hours, and teaching date must be consistent with the ledger | Verify the number of class hours and teaching date, check the signature of the teaching supervisor, and confirm the processing mode corresponding to trainingType and the data row status |
| Data row status | Is in one of the three states parsed, indexing, indexed and is consistent with the interface display | Open the data row to verify the status, and confirm that data pending indexing does not participate in recall |
Three common errors
- Symptom: The name, permit number, or date of the same record does not match between the contract and the permit materials. Cause: The versions of the two materials are not synchronized, and fields stored after parsing and chunking are not cross-compared.
- Symptom: The number of class hours in the course scheduling table is inconsistent with the ledger, and the scheduling date deviates. Cause: The materials were not re-parsed after updating, and old data rows are still in indexed status and are hit by retrieval.
- Symptom: The permit materials lack a signature or receipt, but the data row still shows parsed or indexing. Cause: Successful parsing does not equal a retrieval hit; before the index status transitions to indexed, it does not participate in recall.
How to verify the setup
This feature acceptance: Upload one material, observe the data row status transitions and the coverage scope of the rebuild task, confirm that the three states parsed, indexing, and indexed are consistent with the interface display, and that the rebuild only covers data that has completed indexing.
Business test: Use one real record to find fields inconsistent with the ledger, and verify the name, quantity, date, and signature in the contract, permit materials, and course scheduling table.
- Verify the file records and data rows separately, confirm that the identifiers of files and data rows are distinguishable, and that data rows are bound to a unique data identifier.
- Check the data rows covered by the rebuild task, and confirm that changing the model only rebuilds data that has completed indexing, and that data pending indexing does not participate in the rebuild chain.