What this category's data looks like
In the research funding budget adjustment and reimbursement scenario, materials typically include three categories: budget adjustment applications, reimbursement forms, and contract invoices. Budget adjustment applications are initiated by the project team and list the subject, amount, and reason for adjustment; reimbursement forms record actual expenditures, quantities, and handling dates; contract invoices carry the supplier name, amount, invoice date, and signed receipt. Material sources are scattered across financial systems, project team ledgers, and scanned copies, and the update cadence advances with approval flows and reimbursement batches. Field characteristics manifest as inconsistent naming conventions, mixed quantity units, varied date formats, and non-fixed signature positions. After materials enter this feature, they are first parsed and chunked into the database as visible data rows and bound to a unique data identifier, then enter the three-state index flow for subsequent retrieval and verification use.
Configuration and implementation checks
This stage 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.
| Object | Check | Verification action |
|---|---|---|
| Budget adjustment application | Whether the name, quantity, date, and signature are consistent with the reimbursement form and contract invoice | Verify the subject name and amount, compare the application date with the signature field, and confirm version synchronization |
| Reimbursement form | Whether the same record fields are consistent with the budget adjustment application and contract invoice | Verify quantity units, handling date, and receipt, and flag fields inconsistent with the ledger |
| Contract invoice | Whether the name, quantity, date, and signature are consistent with the budget adjustment application and reimbursement form | Verify the supplier name, invoice date, and signature, and check for missing signatures or receipts |
| Data row | Is in one of the three states parsed, indexing, indexed and consistent with the interface display | Open the data row to verify the status, and use chunkSize and chunkSplitter to review the chunking results |
Three common errors
- Symptom: The name, quantity, and date of the same record do not match between the budget adjustment application and the reimbursement form. Cause: The two materials are entered at different stages, and the fields have not been uniformly mapped and compared.
- Symptom: The contract invoice version is not synchronized, and an old-version signature page is treated as a valid receipt. Cause: After the version update, the ledger was not written back, and retrieval still hits historical data rows.
- Symptom: Newly uploaded materials cannot be found. Cause: The data row is in the parsed or indexing state, and data pending indexing is naturally isolated at the retrieval layer and is not recalled.
How to verify the setup
This feature acceptance: Upload one material, observe the data row status flow and the coverage scope of the rebuild task, and confirm that parsing and chunking are immediately stored in the database as visible data rows and bound to a unique data identifier after parsing is complete, that the index flows through the three states parsed, indexing, and indexed, that changing the model only rebuilds data whose indexing is already complete, and that trainingType and chunkSize can be verified on the training dashboard.
Business test: Use one real record to find fields inconsistent with the ledger, hand them to the reviewer for confirmation, and write them back.
- Verify file records and data rows separately, confirm that the identifiers of files and data rows are distinguishable, and that the status display is consistent with the interface.
- Check the data rows covered by the rebuild task, and confirm that only data whose indexing is already complete is covered, and that data pending indexing does not participate in the rebuild chain.