What this category's data looks like
Enterprise sales product training involves three types of materials: product manuals, pitch materials, and channel training schedules. Sources are the product department, sales operations, and channel management, and the update cadence changes with product iterations, pitch adjustments, and schedule planning. Product manuals carry functional specifications and operating steps, pitch materials carry objection handling and closing paths, and channel training schedules carry sessions, instructors, and participants. When the three types of materials enter the parsing and chunking stage, each is recorded and stored as an independent file; after parsing is complete, a visible data row is generated and bound to a unique data identifier, with fields including material name, version number, effective date, author, and signature receipt status. If the name, quantity, or date of the same record does not match across two materials, the version is not synchronized, or the signature or receipt is missing, the training messaging will deviate.
Configuration and implementation checks
This step is executed by the parsing and training task (server-side task), which outputs data rows and index status (parsed, indexing, indexed). The version ledger and change records are then completed by retrieval and subsequent processing.
| Object | Check | Verification action |
|---|---|---|
| Product manual | Name, version number, effective date, and signature status align item by item with the pitch materials | Check the file record and data row, confirm the chunkSize and chunkSplitter settings, then check whether the status is parsed, indexing, or indexed |
| Pitch materials | Quantity, date, and author are consistent with the channel training schedule records | Check the file record and data row separately, and inspect the training mode and index status corresponding to trainingType |
| Channel training schedule | Sessions, instructors, and participants are synchronized with the product manual version | Open the data row to check the status, and confirm that the rebuild task only covers data that has already been indexed |
| Version ledger and change records | The current version is unique, old versions are traceable, and references are synchronized | After changing one piece of content, check whether the version number and references are updated in sync, and record the three-state index transitions |
Three common errors
- Symptom: a newly uploaded material cannot be found. Cause: the data row is in a pending-index state, and the retrieval layer naturally isolates it so it is not recalled; successful parsing does not equal a retrieval hit.
- Symptom: the name, quantity, or date of the same record does not match across two materials. Cause: the manual and the pitch materials are maintained separately, versions are not synchronized, and references are not updated with changes.
- Symptom: after a training failure, an empty data row is left behind, or the signature and receipt are missing. Cause: the old pipeline leaves orphan data behind, and the signature receipt field is not verified together with the version ledger.
How to verify the setup
Acceptance for this feature: 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 already been indexed.
Business test: change one piece of content, and check whether the version number and references are updated in sync.
- Open the data row to check the status, confirm that it is in one of the three states and consistent with the interface display, and check the file record and data row identifier separately.
- View the data rows covered by the rebuild task, and confirm that it only covers data that has already been indexed; pending-index data does not participate in the rebuild chain.