What this category's data looks like
At the signing stage of a scientific research project task book, the materials are mainly three documents: the project task book, the subject task breakdown table, and the budget book. The project task book comes from the project approval reply and the compiling unit, and is finalized along with the task book signing process; the subject task breakdown table is split by the subject leader according to the task book and is updated on a rolling basis as the subject progresses; the budget book is jointly compiled by finance and the project team and is synchronized with budget review and approval. The three materials have a high degree of field overlap: project name, subject name, person in charge, start and end dates, funding amount, signature and receipt. When entering this function, the project task book plays the role of the main record, the subject task breakdown table plays the role of split verification, and the budget book plays the role of amount and account verification. The material update rhythm is driven by the signing milestones, and version parallelism, unsigned receipts, and inconsistent date conventions often occur, so field-level comparison must be done first before entering review.
Configuration and implementation checks
This step is executed by the tool calling node in the workflow (the model decides whether to call, and the node executes), outputting the tool call result (the input parameters and return in the call record). The "discrepancy list" is then completed by a subsequent AI node or manual verification. Based on the tool introduction, parameter introduction, and whether parameters are required, the model determines whether to call the tool this time.
| Object | Check | Verification action |
|---|---|---|
| Project task book | Whether the name, date, and signature are consistent with the ledger | Open the tool node introduction field and verify the name, start and end dates, and signature column item by item; run a trial with a question missing a required parameter to see whether it asks first, and observe whether the input parameters of toolChoice and functionCall land on the task book fields |
| Subject task breakdown table | Whether the subject name and quantity match the task book split | Verify that the subject names in the breakdown table correspond one by one to the subject names in the task book; compare the quantity field with the number of task items in the task book; check whether the parameter introduction specifies the value source; confirm that the functionCall return does not contain values that do not exist in the materials |
| Budget book | Whether the funding amount, account, and date are consistent with the task book | Verify the budget book amount against the task book funding field; compare the date convention with the signing date; check whether the required item corresponds to the material field; run a trial with a question missing that field to see whether it asks first rather than directly fabricating |
| Tool calling node connection | Whether the diamond interface is connected to the target tool | Verify the diamond connection and node status on the canvas; confirm that after multiple tools are connected in series the results do not cross over; check that the toolChoice trigger path is consistent with the call record |
Three common errors
- Symptom: The name, quantity, and date of the same project do not match across two materials. Cause: The compilation conventions differ and the versions are not synchronized, the tool call only retrieves fields from one of the materials, and the discrepancy is not located.
- Symptom: The task book has been revised, but the breakdown table and budget book still use the old version, and the signature or receipt is missing. Cause: The update rhythm is not aligned, the tool calling node retrieves values according to the old parameters, and the returned result is inconsistent with the current ledger.
- Symptom: The model does not call the tool and directly gives an answer, or the returned result contains values that do not exist in the business materials. Cause: The tool introduction does not specify the purpose and returned result, and whether parameters are required does not correspond to the material fields.
How to verify the setup
Acceptance of this function: run a trial with a question missing a required parameter, check the input parameters and return in the call record, and confirm whether it asks first or calls according to the introduction; at the same time, check the trigger records of toolChoice and functionCall to see whether the two items, parameter introduction and whether required, correspond to the material fields.
Business test: use a real record to find a field inconsistent with the ledger, submit the discrepancy list to the reviewer for confirmation and write it back; if quoted content is involved, check the tokens of the quoted text, record the number of array items separately, and quoteMaxToken is only used as the quoted content budget.
- Open the tool node introduction field and check whether this description can be understood when taken out alone, specifying the purpose, when it should be used, and what result it returns.
- Open the parameter configuration one by one and verify the two items, parameter introduction and whether required; run a trial with a question missing that field to see whether it asks first rather than directly fabricating.