What this category's data looks like
This page addresses student disciplinary and appeal handling scenarios. Materials come from three types of documents: disciplinary fact materials, disciplinary decision letters, and appeal statements, updated in batches by semester or event node. The three types of materials play different roles in the function: disciplinary fact materials provide original behavior descriptions and evidence lists, disciplinary decision letters carry the final determination conclusions and effective dates, and appeal statements reflect objections and supplementary explanations. Field characteristics center on names, quantities, dates, signatures, and receipts. The same object appears repeatedly across multiple materials and needs item-by-item comparison. After materials enter parsing and chunking, they are stored as visible data rows, flowing through three index states, for subsequent retrieval and discrepancy location.
Configuration and implementation checks
This step is executed by parsing and training tasks (server-side tasks), outputting data rows and index states (parsed, indexing, indexed). The "discrepancy list" is completed next by retrieval and subsequent processing. After parsing is complete, parsing and chunking immediately store data as visible data rows and bind a unique data identifier. The index flows through three states: parsed, indexing, indexed. Data pending indexing does not participate in recall. Changing models only rebuilds data that has completed indexing.
| Object | Check | Verification action |
|---|---|---|
| Disciplinary fact materials | Names, quantities, and dates are item-by-item consistent with the disciplinary decision letter; signatures and receipts are complete | Check whether the parsed data row status is parsed, indexing, or indexed, and compare whether the chunkSize chunk boundaries cut off date and quantity fields |
| Disciplinary decision letter | The same record's names, quantities, and dates match the appeal statement; version number and effective date are synchronized | Open the data row to check whether the status matches the interface display, and confirm that key fields are not split apart after chunkSplitter splitting |
| Appeal statement | Signatures and receipts are consistent with the disciplinary decision letter version; the objected object's names and quantities have no discrepancies | Separately verify the file record and data row identifiers, and confirm that the trainingType corresponds to the processing mode and matches the index status |
| File and data row identifiers | File records and data rows each have distinguishable identities; the rebuild scope only covers data that has completed indexing | Look at the data rows covered by the rebuild task, and confirm that the initial training covers data pending indexing and indexing, while rebuild only targets indexed data |
Three common errors
- Symptom: Newly uploaded materials cannot be found. Cause: The data row is in parsed or indexing status. Data pending indexing is naturally isolated at the retrieval layer and is not recalled, so you must wait for indexing to complete.
- Symptom: The same record's names, quantities, and dates do not match across two materials. Cause: The version is not synchronized or chunk boundaries cut off fields, causing missing or misaligned fields during comparison.
- Symptom: Empty data rows remain after training fails. Cause: Training interruption leaves orphan data. Materials missing signatures or receipts are not edited or deleted in time, affecting subsequent review.
How to verify the setup
This function's acceptance: Upload one material, observe the data row status transitions and the coverage scope of the rebuild task, and confirm that the three states parsed, indexing, and indexed are consistent with the interface display, and that rebuild only covers data that has completed indexing.
Business test: Use one real record to find fields inconsistent with the ledger, verify names, quantities, dates, signatures, and receipts item by item, and submit discrepancies to the reviewer for confirmation and write-back.
- Open the data row to check the status, confirm it is one of parsed, indexing, or indexed, and separately verify the file record and data row identifiers.
- View the data rows covered by the rebuild task, and confirm that changing models only rebuilds data that has completed indexing, while initial training covers data pending indexing and indexing.