What this category's data looks like
School safety hazard inspections and campus incident reporting involve three types of materials: safety inspection checklists, hazard rectification ledgers, and emergency incident reports. Safety inspection checklists are updated weekly or monthly and include inspection items, locations, dates, and inspector signatures; hazard rectification ledgers are updated on a rolling basis as rectification progresses and include hazard names, quantities, responsible persons, rectification deadlines, and acceptance signatures; emergency incident reports are submitted immediately when an incident occurs and include incident names, number of people involved, occurrence dates, and handling receipts. When these three types of materials enter workflow orchestration, they play different roles: safety inspection checklists serve as the trigger entry point, generating items pending rectification; hazard rectification ledgers serve as process records, taking on items and tracking closure; emergency incident reports serve as an independent reporting branch, running in parallel with inspection records. Differences in update cadence make it easy for the same hazard's name, quantity, and date to diverge between the checklist and the ledger. When versions are not synchronized, the old version is still referenced, and missing signatures or receipts make records untraceable.
Configuration and implementation checks
This step is executed by workflow nodes (user selection and branching), outputting branch directions and interaction state records. The "version ledger and change records" are completed by subsequent nodes continuing execution according to the branch. When the user selection node is triggered, the conversation enters an interactive state and records the workflow state. After the user completes the selection, execution continues along the branch corresponding to the selected option.
| Object | Check | Verification action |
|---|---|---|
| Safety inspection checklist | Fields include inspection items, locations, dates, and inspector signatures; the same hazard name and quantity must be consistent with the ledger | In the node, check the options and branch connections one by one to confirm whether checklist items enter the rectification branch or the reporting branch |
| Hazard rectification ledger | Fields include hazard names, quantities, responsible persons, rectification deadlines, and acceptance signatures; dates must align with the corresponding records in the inspection checklist | In subsequent nodes, reference the selection result variable and run a trial once to check whether the ledger version number and references are updated in sync |
| Emergency incident report | Fields include incident names, number of people involved, occurrence dates, and handling receipts; receipt signatures must not be missing | Trigger a user selection once and check whether the node status and branch direction in the run record match the selected option |
| Version ledger and change records | The current version is unique, old versions are traceable, and references are synchronized; after changing one piece of content, the version number and references must be updated in sync | In the node, check the options and branch connections to confirm that after change records are written, old versions remain traceable |
Three common errors
- Symptom: The same hazard's name, quantity, and date do not match between the safety inspection checklist and the rectification ledger. Cause: The two materials are maintained separately and do not use workflow nodes to unify values and synchronize.
- Symptom: The old checklist version is still referenced by subsequent nodes, and the current version is not unique. Cause: Changes do not trigger a version number update, and references are not replaced in sync.
- Symptom: The emergency incident report lacks a handling receipt or acceptance signature. Cause: The reporting branch does not complete the interactive state, and subsequent nodes do not continue execution according to the branch.
How to verify the setup
Functional acceptance: run trials for each option one by one, check the branch direction and interaction state in the run records, and confirm that each option corresponds to one branch, variables have been passed to subsequent nodes, and nodeId points to the correct node.
Business testing: change one piece of content and see whether the version number and references are updated in sync; check and record the tokens of the referenced text and the number of array items separately, and verify quoteMaxToken separately as the reference content budget.
- In the user selection node, check the options and branch connections one by one, confirm that each option corresponds to one branch, and after a trial run check the node status in the run records.
- In subsequent nodes, reference the selection result variable and run a trial once to confirm that after the interaction is completed the process continues downward and the version number and references are updated in sync.