What this category's data looks like
This category's materials include appointment contracts, work permit materials, and course scheduling tables. Appointment contracts lock the appointment relationship with signatures and dates, work permit materials support compliance with credential fields and receipts, and course scheduling tables map teaching tasks with classes, class hours, and teacher names. After the three types of materials enter parsing and training tasks, each is stored as an independent data row and bound to a unique data identifier: contracts and permit materials serve as the basis source, and course scheduling tables serve as the scheduling fact. The update rhythm changes with semesters and appointment cycles, and field characteristics are concentrated in names, credential numbers, course names, class hour quantities, effective dates, and signature fields. The names, quantities, and dates of the same record in contracts and permit materials are prone to mismatch; when versions are not synchronized or signature receipts are missing, basis entries cannot be traced back to the original text.
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 completed next by retrieval and subsequent processing. Parsed chunks are stored as visible data rows immediately after parsing is completed, the index flows through three states, and data pending indexing does not participate in recall.
| Object | Check | Verification action |
|---|---|---|
| Appointment contract | The signature, date, and appointment term fields match the original text | Open the data row to check the signature field and effective date, and confirm the status is indexed |
| Work permit materials | Credential fields, receipts, and contract names are consistent | Check the file record and the data row separately, and confirm the identifiers are distinguishable |
| Course scheduling table | Course names, class hour quantities, and teacher names can be traced back | Check the data rows covered by the rebuild task, and confirm entries are complete after splitting by chunkSize and chunkSplitter |
| Data row status | It is in one of the three states and consistent with the interface display | View the status flow: parsed, indexing, indexed, and confirm trainingType corresponds to the processing mode |
Three common errors
- Symptom: materials just uploaded cannot be found. Cause: the data row is in a pending-indexing state, and the retrieval layer naturally isolates it from recall, so you must wait for indexing to complete.
- Symptom: the names, quantities, and dates of the same record in two materials do not match. Cause: versions are not synchronized, and contracts and permit materials are stored separately without cross-checking.
- Symptom: empty data rows remain after training fails. Cause: missing signatures or receipts interrupt parsing, and failed data is not edited or deleted in time, forming residue.
How to verify the setup
This feature's acceptance: upload one material, observe the data row status flow and the coverage scope of the rebuild task, confirm parsed to indexing to indexed, and when changing models only rebuild data that has completed indexing.
Business test: ask a cross-material basis question and see whether the answer provides a traceable source.
- Open the data row to check whether the status is consistent with the interface display, and confirm the file record and the data row each have distinguishable identities.
- Check the data rows covered by the rebuild task, and confirm it only covers data that has completed indexing; data pending indexing does not participate in the rebuild chain.