What this category's data looks like
This page addresses the scenario of school safety hazard inspections and campus incident reporting. Materials include safety inspection checklists, hazard rectification ledgers, and emergency incident reports. Safety inspection checklists are updated weekly or monthly, hazard rectification ledgers roll forward with rectification status, and emergency incident reports are archived one by one per incident. Field characteristics center on inspection items, hazard descriptions, rectification responsible persons, rectification deadlines, review conclusions, incident process, handling results, report dates, and signature receipts. After entering scheduled tasks and automation, safety inspection checklists serve as the periodic trigger source, hazard rectification ledgers serve as the change record object, and emergency incident reports serve as the reference synchronization object. Together, the three support the version ledger and change records, ensuring the current version is unique, old versions are traceable, and references are synchronized.
Configuration and implementation checks
This step is executed by trigger configuration and tool nodes (scheduling capability is not in the tool introduction), outputting trigger records and execution results. The "version ledger and change records" are completed by business processing according to records or supplementary runs. Whether tool calls are executed is decided by the model based on the tool introduction; when the model does not need to summarize again, a tool call termination node can be attached at the end of the tool to end this call.
| Object | Check | Verification action |
|---|---|---|
| Safety inspection checklist | Whether inspection items, inspection date, inspector signature, and review conclusion are complete, and whether the name, quantity, and date of the same record match across the two materials | Check the introduction fields and process connections, view whether the table in the trigger records is executed on time, and compare the dates and signature fields in the table |
| Hazard rectification ledger | Whether the hazard description, rectification responsible person, rectification deadline, review date, and receipt are consistent, and whether the version number is updated synchronously with content changes | Change one hazard description and see whether the version number and references are updated synchronously; confirm that old versions are traceable and the current version is unique |
| Emergency incident report | Whether the incident process, handling results, report date, signature or receipt are complete, and whether the knowledge base or external documents referencing this report are synchronized | Check the number of reference entries and the tokens of the reference text; array entry counts are recorded separately, and quoteMaxToken only verifies the reference content budget |
| Trigger configuration and tool nodes | Whether the trigger is connected to the corresponding tool node, and whether the termination node is attached at the end of the tool when no summary is needed | Look at the process connections and trigger records, confirm on-time execution and execution only once, and that after execution it is not summarized again by the model |
Three common errors
- Symptom: It did not execute on time. Cause: The trigger was not connected to the corresponding tool node, or the tool introduction did not clearly state when it should execute, so the model did not decide to call it.
- Symptom: The name, quantity, and date of the same record do not match across the two materials. Cause: The version was not synchronized, the old version is still referenced, and references were not updated with content changes.
- Symptom: Missing signature or receipt. Cause: When the materials entered automation, the signature and receipt were not treated as change record fields, and they were not backfilled during supplementary runs.
How to verify the setup
This feature acceptance: look at the trigger records and execution time, and confirm on-time execution and execution only once.
Business test: change one piece of content and see whether the version number and references are updated synchronously.
- Check the introduction fields and process connections, confirm the trigger is connected to the corresponding tool node, and view the trigger records and execution results.
- After changing one piece of content, check in the version ledger and change records that the current version is unique, old versions are traceable, and references are synchronized.