What this category's data looks like
This page addresses business basis queries for research funding budget adjustments and reimbursements. The materials include three categories: budget adjustment applications, reimbursement forms, and contract invoices. Budget adjustment applications record the adjustment reason, account, and date; reimbursement forms record expense details, quantity, amount, and signature; contract invoices record the contract number, invoice number, invoice date, and receipt. The materials come from original files submitted at each business stage in the research management system, and the update cadence advances with business processing progress. There are situations where the same record has inconsistent names, quantities, or dates across multiple materials, versions are not synchronized, and signatures or receipts are missing. After the materials enter the parsing and training task, each is parsed and chunked into visible data rows and bound to a unique data identifier, becoming the underlying data for subsequent retrieval and basis citation.
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 basis entries that can cite the original text are then completed by retrieval and subsequent processing. Successful parsing does not equal a retrieval hit; the index status also matters.
| Object | Check | Verification action |
|---|---|---|
| Budget adjustment application | Whether the application reason, adjustment account, date, and signature are consistent with the current version | Open the data row to check the status, confirm it is in one of parsed / indexing / indexed, and verify the application date and signature |
| Reimbursement form | Whether the expense details, quantity, amount, date, and signature match the contract invoice | Verify the file record and the data row separately, and confirm that the name, quantity, and date of the same record are consistent in both materials |
| Contract invoice | Whether the contract number, invoice number, invoice date, and receipt are complete and the versions are synchronized | View the data rows covered by the rebuild task, confirm that only data with completed indexing is covered, and verify the receipt and version |
| Data row and file record | Whether the identities of the file record and the data row are distinguishable, and whether the status is consistent with the interface display | In the parsing and training task, verify the data rows corresponding to chunkSize, chunkSplitter, and trainingType |
Three common errors
- Symptom: newly uploaded materials cannot be found. Cause: the data row is in a pending-indexing state, and the retrieval layer is naturally isolated and does not recall it; you must wait for the index status to transition to completed.
- Symptom: the name, quantity, and date of the same record do not match across two materials. Cause: each material is parsed and chunked independently, and cross-material field alignment and version synchronization are not performed.
- Symptom: empty data rows remain after training fails. Cause: interrupted training leaves orphan data behind, and materials missing signatures or receipts are not edited or deleted in time.
How to verify the setup
This feature acceptance: upload one material, observe the data row status transition and the coverage scope of the rebuild task, confirm that after parsing and chunking it is immediately persisted and bound to a unique data identifier, that the index transitions through the three states parsed / indexing / indexed, that changing the model only rebuilds data with completed indexing, and verify the data rows corresponding to chunkSize, chunkSplitter, and trainingType.
Business test: ask a cross-material basis question and see whether the answer provides a citable source.
- Open the data row to check the status, confirm it is consistent with the interface display, and verify the file record and the data row separately.
- View the data rows covered by the rebuild task, confirm that only data with completed indexing is covered, and that the initial training covers data that is pending indexing and indexing.