What this category's data looks like
This page addresses the scenario of school safety hazard inspection and campus incident reporting. Materials include safety inspection checklists, hazard rectification ledgers, emergency incident reports, as well as the institution's current safety management system and emergency plans. Sources are the original records and stamped versions filled in after daily patrols, special inspections, and incident handling at each institution. The update cadence follows the inspection cycle and occurs immediately upon incidents, with centralized archiving at the end of the semester. Field characteristics center on inspection items, hazard descriptions, rectification responsible persons, rectification deadlines, re-inspection conclusions, incident course, handling measures, reporting time, signatures, and receipts. When materials enter this function, the safety inspection checklist provides inspection basis entries, the hazard rectification ledger provides evidence of rectification closure, the emergency incident report provides the basis for incident reporting and handling, and the system and plans provide the current version baseline. Workflow orchestration is responsible for breaking cross-material basis retrieval into entries that can be traced back to the original text, for use when responding to parents or writing into plans.
Configuration and implementation checks
This step is executed by workflow nodes (user selection and branches), outputting branch directions and interaction state records. "Basis entries that can be traced back to the original text" are completed by subsequent nodes continuing execution according to the branch. When a node is triggered, the conversation enters an interaction 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 | Inspection items, dates, and signatures must be consistent with the current system version; hazard descriptions can be traced back to the original text | In the node, check options and branch connections one by one, and reference variables to confirm that the selection result variable has been passed to subsequent nodes |
| Hazard rectification ledger | Rectification responsible person, deadline, re-inspection conclusion, and receipt must be complete; the same record name and quantity must match between the two materials | In subsequent nodes, reference nodeId and run a trial once, then check the node status and branch direction in the run record |
| Emergency incident report | Incident course, handling measures, reporting time, and signature must be synchronized with the emergency plan version; missing signature or receipt means inconsistency | Trigger a user selection node once, check whether the interaction state is recorded, and confirm whether subsequent nodes continue execution according to the option |
| Safety management system and emergency plans | The current version must be consistent with the referenced versions in the checklist, ledger, and report; dates and names must not mismatch | In the node, check options and branch connections one by one, and confirm that each option corresponds to one branch and that no default branch is mistakenly taken |
Three common errors
- Phenomenon: The name, quantity, or date of the same hazard does not match between the two materials. Cause: The checklist and ledger are filled in separately, without cross-material field verification.
- Phenomenon: The basis comes from an old version of the system and conflicts with the clauses of the current plan. Cause: The version was not synchronized, and after the materials were updated, they were not written back to the checklist and ledger.
- Phenomenon: The rectification record lacks a signature or receipt, and the incident report lacks reporting time. Cause: The filling stage did not validate the signature and receipt fields, and no re-check was performed before archiving.
How to verify the setup
Acceptance of this function: run a trial for each option one by one, check the branch direction and interaction state in the run record, and confirm that variables and nodeId are correctly referenced in subsequent nodes.
Business test: ask a cross-material basis question and see whether the answer provides a traceable source.
- In the node, check options and branch connections one by one, and confirm that each option corresponds to one branch and that no default branch is mistakenly taken.
- In subsequent nodes, reference the selection result variable and run a trial once, confirming that the process continues execution after the interaction is completed and does not stall.