What this category's data looks like
At the signing stage of research project task statements, the materials are mainly project task statements, subject task breakdown tables, and budget books, sourced from application system exports, offline signed scans, and ledger registration forms. The update rhythm is concentrated in the signing window period, and it is common for the name, quantity, and date of the same record to mismatch across two materials, versions not being synchronized, and signatures or receipts missing. The field characteristics are project name, subject number, funding category, start and end dates, signature field, and seal position. When entering this feature, the project task statement serves as the main object carrying the overall indicators and responsibility agreements; the subject task breakdown table serves as the subordinate object splitting out subject names, undertaking units, and assessment milestones; the budget book serves as the amount object listing categories, quantities, and calculation bases. The three are stored separately as file records and data rows for subsequent retrieval and comparison.
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 discrepancy list is then completed by retrieval and subsequent processing. After parsing is completed, parsing chunks are immediately stored as visible data rows and bound to a unique data identifier; the index transitions through three states, data pending indexing does not participate in recall, and changing the model only rebuilds data whose indexing has been completed.
| Object | Check | Verification action |
|---|---|---|
| Project task statement | Name, quantity, date, and signature field must correspond item by item with the ledger | Check the file record and data row identifier, confirm the status is parsed or indexing or indexed, and record the chunkSize chunk boundaries |
| Subject task breakdown table | Subject name, undertaking unit, and assessment milestones are consistent with the budget book and task statement | Compare the name and date of the same subject in the two materials, mark discrepant fields, and check the chunkSplitter splitting result |
| Budget book | Funding categories, quantities, and calculation bases are consistent with the task statement's standards | Check amount categories and quantities, check whether signatures or receipts are missing, and confirm the processing mode corresponding to trainingType |
| Data row status | Is in one of the three states and consistent with the interface display | Open the data row to check the status, and confirm that data pending indexing is not recalled |
Three common errors
- Symptom: newly uploaded materials cannot be found. Cause: the data row is in parsed or indexing, and data pending indexing is naturally isolated at the retrieval layer and not recalled.
- Symptom: empty data rows remain after training fails. Cause: training interruption leaves data with incomplete indexing, which must be directly edited or deleted before retrying.
- Symptom: the name, quantity, and date of the same record mismatch across two materials. Cause: versions are not synchronized or signatures/receipts are missing, and the ledger and task statement standards are not aligned.
How to verify the setup
Feature acceptance: upload one material, observe the data row status transitions and the coverage scope of the rebuild task, confirm that rebuild is triggered only for data whose indexing has been completed, and that the initial training covers data pending indexing and data being indexed.
Business test: use one real record to find fields inconsistent with the ledger, submit them to the reviewer for confirmation, and write back the discrepancy list.
- Check file records and data rows separately, confirm that the identities of file records and data rows are distinguishable, and that the status display is consistent with the three states.
- Look at the data rows covered by the rebuild task, confirm that only data whose indexing has been completed is covered, and that data pending indexing does not participate in the rebuild chain.