What this category's data looks like
This page addresses the graduate admissions re-examination and enrollment scenario. Materials include the re-examination plan, candidate score sheets, transfer lists, and a progress table recorded weekly. The re-examination plan contains assessment dimensions, time nodes, and signature fields; the candidate score sheet contains candidate ID, subject, score, date, and review signature; the transfer list contains candidate ID, original applying institution, proposed transfer major, date, and receipt. When these three types of materials enter the tool calling node, each plays a different role: the re-examination plan is used to verify process nodes and signature requirements, the score sheet is used to verify score and date fields, and the transfer list is used to verify list counts and versions. The update cadence is weekly aggregation; each week, newly generated records are appended to the progress table, with source materials and exception notes marked. In terms of field characteristics, the same candidate's name, quantity, and date may be inconsistent across different materials; when versions are not synchronized or signatures are missing, these must be listed separately in the scope notes.
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 inputs and returns in the call record). The "progress table and statistical scope notes" are then completed by subsequent AI nodes or manual verification. Based on the tool description, parameter description, and whether parameters are required, the model determines whether to call the tool this time.
| Object | Check | Verification action |
|---|---|---|
| Re-examination plan | Check whether the assessment dimensions, time nodes, and signature fields in the re-examination plan are consistent with the progress table records | Open the tool node description field and confirm that the purpose and return result description can be understood independently; check the parameter description and whether required, and inspect the values of toolChoice and functionCall in the call record |
| Candidate score sheet | Check whether the candidate ID, subject, score, date, and review signature in the score sheet correspond to the transfer list | Run a trial with a question missing a required parameter (e.g., candidate ID) and observe whether it asks a follow-up question or calls according to the description; check the inputs and returns in the call record and confirm that no values appear that do not exist in the materials |
| Transfer list | Check whether the candidate ID, original applying institution, proposed transfer major, date, and receipt in the transfer list are consistent with the score sheet | On the canvas, check the diamond-shaped connections and node status of the tool calling node and confirm that it is connected to the target tool; check whether results from multiple tools connected in series are mixed up with each other |
| Progress table | Check whether the number of records in the progress table matches the statistical count, whether the scope is written in the header, and whether exceptions are clearly stated | Use one week of records to verify the total, check the header scope notes and exception annotations; confirm that the tokens of the referenced text and the number of array items are recorded separately |
Three common errors
- Symptom: The same candidate's name, quantity, and date do not match between the score sheet and the transfer list. Cause: The two materials are updated separately, no cross-check is performed, and versions are not synchronized.
- Symptom: The re-examination plan lacks a signature or receipt, but the progress table still records it as completed. Cause: The signature field is not included as a required parameter, and the model calls directly according to the description without asking a follow-up question first.
- Symptom: Values appear in the returned results of the call record that do not exist in the business materials. Cause: When there are no required parameters, the model fabricates parameter values on its own, or the tool description does not clearly state the return scope.
How to verify the setup
Acceptance for this feature: run a trial with a question missing a required parameter, check the inputs and returns in the call record, and confirm whether it asks a follow-up question or calls according to the description; check the values of toolChoice and functionCall in the call record and confirm that there are no fabricated parameters.
Business test: use one week of records to verify the total and see whether the scope and exceptions are clearly stated; check whether the fields, dates, and signatures of the re-examination plan, candidate score sheet, and transfer list are consistent.
- Open each parameter configuration one by one, check the parameter description and whether required, and confirm that they correspond to fields that actually exist in the business materials.
- On the canvas, check the diamond-shaped connections and node status of the tool calling node, confirm that it is connected to the target tool, and check whether results from multiple tools connected in series are mixed up with each other.