What this category's data looks like
This page focuses on progress records and statistical verification for school safety hazard inspections and campus incident reporting, and involves three types of materials: safety inspection checklists, hazard rectification ledgers, and emergency incident reports. Safety inspection checklists are generated weekly or per inspection, with fields including inspection date, location, and inspector signature; hazard rectification ledgers are updated on a rolling basis by entry, with fields including hazard name, rectification deadline, responsible person, and acceptance signature; emergency incident reports are filed separately by incident, with fields including occurrence time, reporting time, handling process, and receipt. When these three types of materials enter this function, their roles differ: safety inspection checklists and hazard rectification ledgers serve as the source of original records for progress statistics, while emergency incident reports are separately marked as exception items. In terms of update cadence, checklists are updated with inspection batches, ledgers are updated with rectification progress, and incident reports are updated with handling milestones. Field characteristics are concentrated in four categories: dates, names, quantities, and signatures. The same hazard may appear with inconsistent names, quantities, or dates across different materials, versions may be out of sync, or signatures/receipts may be missing, all of which must be stated item by item in the statistical scope description.
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 call result (the inputs and returns in the call record). The "progress table and statistical scope description" is then completed by a subsequent AI node or manual verification. Based on the tool description, parameter descriptions, and whether parameters are required, the model determines whether to call the tool this time.
| Object | Check | Verification action |
|---|---|---|
| Safety inspection checklist | Whether fields, dates, and signatures are complete, and whether the name, quantity, and date of the same record match across the two materials | Verify the three items: inspection date, location, and inspector signature; compare hazard names and quantities item by item with the hazard rectification ledger; open the tool node description fields and confirm that the descriptions are independently readable |
| Hazard rectification ledger | Whether the rectification deadline, responsible person, and acceptance signature are consistent with the checklist, and whether versions are in sync | Take one week of ledger records and verify the rectification deadline and responsible person; compare the name, quantity, and date of the same hazard in the checklist and ledger; verify the acceptance signature and receipt |
| Emergency incident report | Whether the occurrence time, reporting time, handling process, and receipt correspond to the exception items in the ledger | Verify the incident occurrence and reporting times; confirm the handling process and receipt signature; mark the incident separately as an exception item in the statistical scope |
| Tool-calling node connections | Whether the diamond interface is connected to the target tool, and whether the parameter description and required-or-not items correspond to the material fields | Verify the diamond connections and node status on the canvas; open each parameter configuration and verify the description and whether it is required; check whether the settings related to toolChoice and functionCall are consistent with the tool description |
Three common errors
- Symptom: the name, quantity, and date of the same hazard do not match between the checklist and the ledger. Cause: the two materials are entered separately, without field-level comparison and version synchronization.
- Symptom: the ledger lacks an acceptance signature or the incident report lacks a receipt. Cause: the rectification progress is not closed-loop, and the signature step is not included in the statistical scope description.
- Symptom: the model does not call the tool and directly gives an answer. Cause: the tool description does not state the purpose and return result, or the required parameters have no suitable values in the context.
How to verify the setup
Acceptance for this function: run a test 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; at the same time, verify whether the settings related to toolChoice and functionCall are consistent with the three items: tool description, parameter description, and required-or-not.
Business test: use one week of records to verify the totals and see whether the scope and exceptions are clearly stated; compare the names, quantities, dates, and signatures in the three materials—safety inspection checklist, hazard rectification ledger, and emergency incident report—and confirm that the record counts and statistical counts match.
- Open the tool node description fields and check whether the three items—purpose, when to use it, and return result—are independently readable; open each parameter configuration one by one and verify the parameter description and whether it is required.
- Run a test with a question missing that field and observe whether it asks a follow-up question first instead of directly fabricating; verify the diamond connections and node status on the canvas and confirm that they are connected to the target tool.