What this category's data looks like
This page addresses the primary and secondary school teacher training credit management scenario. Materials include training notices, credit recognition forms, and attendance rosters. Training notices come from education administrative departments or schools and are updated by project batch; fields include project name, start and end dates, credit hours, and seal. Credit recognition forms are filled in by teachers or organizers; fields include name, ID number, training project, recognized credits, signature, and date. Attendance rosters are provided by the organizing institution; fields include name, unit, training project, attendance days, and receipt. When the three types of materials enter the Q&A intake and missing-item follow-up function, their roles differ: training notices serve as the basis for rules and dates, credit recognition forms serve as records to be verified, and attendance rosters serve as the base list for comparing headcount and attendance. The update rhythm advances by training batch and semester. The same record often shows inconsistencies in names, quantities, and dates, with versions not synchronized or missing signatures and receipts. After materials enter the workflow, the tool calling node triggers retrieval and comparison based on model judgment, returns the calling result, and provides it for subsequent nodes to organize intake records and complete follow-up items.
Configuration and implementation checks
This step is executed by the tool calling node in the workflow (the model decides whether to call it, and the node executes it), outputting the tool calling result (the input parameters and return in the calling record). The "intake records and completed follow-up items" are then completed by subsequent AI nodes or manual verification. The model decides whether to call the tool this time based on the tool description, parameter descriptions, and whether parameters are required; when there are no required parameters, the model may fabricate parameter values on its own, and when there are required parameters but no suitable value in the context, it may not call.
| Object | Check | Verification action |
|---|---|---|
| Tool calling node connection | The diamond interface is connected to the target tool, and the node status is runnable | On the canvas, check the diamond connection and node status to confirm that the tool calling node can receive upstream branches |
| Training notice | Project name, start and end dates, credit hours, and seal are complete, and the dates match those in the credit recognition form | Open the original notice, check the fields, dates, and signature item by item, then compare with the same project's dates in the recognition form |
| Credit recognition form | Name, training project, recognized credits, signature, and date are complete, and the quantity matches the attendance roster | Check each recognition form's fields and signature one by one, and compare with the same project's headcount and names in the attendance roster |
| Attendance roster | Name, unit, training project, attendance days, and receipt are complete, and consistent with the recognition form records | Check the roster fields and receipt, and compare with the same project's names, quantities, and dates in the recognition form |
Three common errors
- Symptom: The project name and dates for the same record do not match between the training notice and the credit recognition form. Cause: The two materials use different filling standards, versions are not synchronized, and field-level comparison was not performed.
- Symptom: The headcount in the attendance roster is inconsistent with the recognized headcount in the credit recognition form. Cause: After the roster was updated, it was not written back to the recognition form, and the quantity field lacks cross-checking.
- Symptom: Values that do not exist in the business materials appear in the returned result. Cause: When there are no required parameters, the model fabricates parameter values on its own, or the tool description does not specify the return boundaries.
How to verify the setup
Acceptance for this function: run a test with a question missing required parameters, check the input parameters and return in the calling record, and confirm whether it asks a follow-up question or calls according to the description; at the same time, check whether toolChoice, functionCall, and the tool calling node connection work as expected.
Business test: ask a question missing key information and see whether it asks a follow-up question first before answering.
- Open the tool node description field, check whether this description can be understood when read on its own, and verify the two items: parameter descriptions and whether required.
- Run a test with a question missing that field to see whether it asks a follow-up question first rather than fabricating directly; then check whether the results from multiple tools connected in series interfere with each other.