What this category's data looks like
This page addresses the enterprise new employee onboarding training scenario, with material sources covering onboarding training plans, course sign-in sheets, job descriptions, and accompanying acknowledgements. The update cadence follows position adjustments, course revisions, and batch class starts, and it is common for the same record to have mismatched names, quantities, or dates across two materials, unsynchronized versions, and missing signatures or acknowledgements. When materials enter this feature, their roles differ: the onboarding training plan serves as the primary basis, the course sign-in sheet provides process traceability, the job description supplies field and date benchmarks, and the acknowledgement is used for confirmation. Parsing and chunking determine how each material is split into retrievable data rows, while the version ledger and change records rely on data row status and reference synchronization to ensure the current version is unique and old versions are traceable.
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. Successful parsing does not mean retrieval will definitely hit; the index status must also be considered.
| Object | Check | Verification action |
|---|---|---|
| Onboarding training plan | Fields, dates, and signatures are complete, and consistent with the corresponding record in the job description | Check whether the data row status is parsed / indexing / indexed, and compare the course names, dates, and signature fields in the plan |
| Course sign-in sheet | The same record's names, quantities, and dates match between the plan and the sign-in sheet, and no acknowledgement is missing | Check the file record and the data row separately, confirm the sign-in sheet data row is bound to a unique data identifier, and check whether the signature and date fields are retained after splitting by chunkSize and chunkSplitter |
| Job description | The current version is unique, old versions are traceable, and references are synchronized | Inspect the data rows covered by the rebuild task, confirm that only data with completed indexing is covered, and whether old version references are updated in sync with the version number |
| Version ledger and change records | Data row status is consistent with the interface display, and the rebuild scope is clear | Open the data rows to check the status, and confirm that the processing mode corresponding to trainingType is consistent with the three-state index flow |
Three common errors
- Symptom: newly uploaded materials cannot be found. Cause: although parsing and chunking have been persisted as visible data rows, the index is still in parsed or indexing, and data pending indexing does not participate in recall.
- Symptom: the same record's names, quantities, and dates do not match between the training plan and the sign-in sheet. Cause: the two materials are not bound to the same data identifier, versions are not synchronized, and references still point to the old version.
- Symptom: after a training failure, empty data rows remain, or signatures and acknowledgements are missing. Cause: residual data from the interrupted training is not cleaned up, and acknowledgements are not updated with the version, causing the ledger and materials to be inconsistent.
How to verify the setup
This feature's acceptance: upload one material, observe the data row status transitions and the coverage scope of the rebuild task, and confirm that only parsed / indexing / indexed statuses appear, and that the rebuild only covers data with completed indexing.
Business test: change one piece of content and see whether the version number and references are updated in sync; if a reference upper limit is involved, check the tokens of the reference text, record the array count separately, and quoteMaxToken serves only as the reference content budget.
- Open the data rows to check the status, confirm it is consistent with the interface display, and check the identity identifiers of the file record and the data row separately.
- Inspect the data rows covered by the rebuild task, and confirm that changing the model only rebuilds data with completed indexing, and that data pending indexing does not participate in the rebuild chain.