What this category's data looks like
The core materials for school safety hazard inspections and campus incident reporting are safety inspection checklists, hazard rectification ledgers, and emergency incident reports. Safety inspection checklists are filled in weekly or monthly by the inspector, with fields including inspection item, location, date, and signature; hazard rectification ledgers record the hazard name, quantity, responsible person, rectification deadline, and receipt; emergency incident reports include the incident course, number of people involved, reporting time, and acknowledgment. When these three types of materials enter question-answering intake, they serve respectively as the source for inspection basis, rectification tracking, and incident characterization. In terms of update cadence, checklists roll forward with the inspection cycle, ledgers are appended as rectification progresses, and incident reports are supplemented at reporting milestones. The field characteristic is that the same hazard may have inconsistent names, quantities, and dates across different materials, and versions may be out of sync or signature receipts missing, so missing-item follow-up requires first checking the correspondence between materials.
Configuration and implementation checks
This step is executed by the HTTP node in the workflow, which outputs the response body, status code, and returned fields. The intake record and the supplemented follow-up items are parsed from the response by subsequent nodes, or handled by an external system according to the agreement to complete the process. The request URL, path parameters, request headers, and request body can all reference global variables, system variables, or upstream node outputs via variables, and authentication is passed in Authorization as required by the external system.
| Object | Check | Verification action |
|---|---|---|
| Safety inspection checklist | Fields include inspection item, location, date, and signature; a missing signature is treated as a missing item | Check whether the request body fields correspond item by item to the original checklist fields, and use responseData to see whether the response marks missing items |
| Hazard rectification ledger | When the name, quantity, and date of the same hazard do not match across the two materials, it is judged inconsistent | Compare the hazard name, quantity, and date in the ledger and the checklist, and confirm whether the follow-up items point to the inconsistent fields |
| Emergency incident report | The reporting time, number of people involved, and acknowledgment receipt must match the report; if the version is out of sync, follow-up is triggered | In the request preview, view the complete rendered URL and request body, and check the report version and receipt fields |
Three common errors
- Symptom: the name, quantity, and date of the same hazard do not match between the checklist and the ledger, and the follow-up items point to unclear targets. Cause: the two types of materials are entered separately, without field mapping or version comparison.
- Symptom: the emergency incident report version is out of sync, and the old version's number of people is inconsistent with the new version. Cause: the external system's return does not carry a version identifier, and the intake record continues to use the old fields.
- Symptom: the checklist lacks a signature or receipt, and after follow-up there is still no material basis. Cause: the signature and receipt fields are not included in the request body, and the returned fields cannot mark missing items.
How to verify the setup
Acceptance of this feature: preview the rendered request, check the status code and returned fields, then compare the result against one sample; confirm that variables and Authorization resolve to actual values, and that the missing-item markers and follow-up items in responseData are readable.
Business test: submit a question missing key information and see whether it asks a follow-up question before answering.
- In the variables panel, check the source of each placeholder and confirm that the
variablesin the request URL, path parameters, request headers, and request body can all be traced to global variables, system variables, or upstream node outputs. - Use one sample request to compare the return, checking whether the response body fields are consistent with the fields, dates, and signatures of the safety inspection checklist, hazard rectification ledger, and emergency incident report, and whether missing items are identified and followed up.