What this category's data looks like
The materials of primary and secondary school admissions organizations mainly consist of admission plans, application material checklists, and admission lists. They come from education authorities, school admissions offices, and application system exports. The update rhythm is concentrated at three points: before the admissions season, the application deadline, and the admission announcement. The admission plan contains the admission scope, time nodes, and admission rules; the application material checklist contains fields such as household registration, real estate, and residence permit, as well as signature fields; the admission list contains names, ID numbers, batches, dates, and receipts. When these three types of materials enter the workflow, the admission plan serves as the basis for branch judgment, the application material checklist serves as the verification baseline, and the admission list serves as the result confirmation object, each taking on a different role. In terms of field characteristics, dates, names, quantities, signatures, and receipts are the key items for cross-material comparison. When the same record appears in two materials, it must be aligned item by item.
Configuration and implementation checks
This step is executed by workflow nodes (user selection and branching), outputting branch directions and interaction status 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 status. After the user completes the selection, execution continues along the branch corresponding to the selected option.
| Object | Check | Verification action |
|---|---|---|
| Admission plan | Whether fields, dates, and signatures are consistent with the current version | Check the options and branch connections one by one in the node, and confirm the plan version number and reference location |
| Application material checklist | Whether names, quantities, and dates match the admission list | Reference the selection result variable in subsequent nodes and run a trial once, comparing the checklist and list fields |
| Admission list | Whether it still enters the next branch when signatures or receipts are missing | Trigger the user selection node once, and check the node status and branch direction in the run record |
| User selection node | Whether options and branches correspond one-to-one | Check the transfer relationship between nodeId and variables, and confirm that the interaction status is recorded |
Three common errors
- Phenomenon: The names, quantities, and dates of the same record do not match between the admission plan and the application material checklist. Cause: The two materials are maintained separately, and field-level comparison has not been done in the version ledger.
- Phenomenon: The version is not synchronized, and the old plan is still referenced. Cause: When updating the knowledge base or external documents, reference synchronization was not triggered, and the uniqueness of the current version was not checked.
- Phenomenon: The admission list still enters the next branch when signatures or receipts are missing. Cause: The branch judgment does not cover the signature and receipt fields, and the interaction status record has not been rechecked.
How to verify the setup
Acceptance of this function: Run trials for each option one by one, check the branch direction and interaction status in the run record, and confirm that nodeId, variables, and option branches correspond.
Business test: Change one piece of content, see whether the version number and references are updated synchronously, and check the fields, dates, and signatures of the admission plan, application material checklist, and admission list.
- In the user selection node, check the options and branch connections one by one, and after triggering once, check the node status in the run record.
- Reference the selection result variable in subsequent nodes and run a trial once, confirming that the references in the version ledger and change records are updated synchronously.