What this category's data looks like
The materials for regular higher education institution admissions and enrollment filing mainly consist of enrollment plans, filing rules, and admission rosters issued by provincial admissions and examination institutions. The sources are annual admissions documents and system-exported data, and the update cadence changes with batch progression and adjustment of supplementary volunteer applications. Enrollment plans contain fields such as institution professional groups, planned numbers, selected examination subjects, and tuition fees; filing rules contain provisions such as filing ratios, tie-breaking ranking, and volunteer grade differences; admission rosters contain candidate numbers, names, scores, majors, admission status, and signature fields. When entering workflow orchestration, the enrollment plan serves as the plan baseline, the filing rules serve as the basis for determination, and the admission roster serves as the result evidence. The three must each be marked with a version number and effective date in the version ledger, old versions must retain a traceability path, and references must simultaneously point to the current version.
Configuration and implementation checks
This step is executed by workflow nodes (user selection and branches), outputting branch directions and interaction status records. The "version ledger and change records" are completed by subsequent nodes continuing execution according to the branches. When a node is triggered, the conversation enters an interaction 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 |
|---|---|---|
| Enrollment plan | Whether the fields, dates, and signatures are consistent with the current version, and whether the names and quantities can be matched between the two materials | In the node, check the options and branch connections one by one, confirm that the plan version branch points to the current version, and that the old-version branch retains traceability; use variables to record the version number |
| Filing rules | Whether the dates and signatures of provisions such as tie-breaking ranking and filing ratios are complete, and whether the version is updated synchronously | Trigger a user selection node once and check the node status in the run record; check the nodeId connections between the rule branch and the plan branch to confirm that references are synchronized |
| Admission roster | Whether candidate numbers, names, scores, majors, and admission status are consistent with the plan and rule records, and whether signatures or receipts are missing | In subsequent nodes, reference the selection result variable and run a trial once, check whether the roster branch output and the ledger branch output are consistent, and separately mark items missing signatures |
| Version ledger and change records | Whether the current version is unique, old versions are traceable, and references are synchronized | After changing one piece of content, run a trial, check whether the version number and references are updated synchronously, and check the values of variables and nodeId in the run record |
Three common errors
- Phenomenon: The name or score of the same candidate does not match between the two materials. Cause: The enrollment plan and admission roster are maintained independently, and field-level comparison and signature/receipt verification were not performed in the version ledger.
- Phenomenon: The filing rules have been updated, but the reference still points to the old version. Cause: The version was not synchronized, the branch connections were not adjusted with the current version, and the old-version traceability path is mixed with the current version.
- Phenomenon: The admission roster is missing signatures or receipts, but the process still continues. Cause: The user selection node only records the interaction status and branch direction, while signature and receipt verification is handled by subsequent nodes, and the branch does not cover this determination.
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, confirm that each option corresponds to one branch, that the selection result variable has been passed to subsequent nodes, and that variables and nodeId are queryable in the run record.
Business test: change one piece of content, see whether the version number and references are updated synchronously, and confirm that the current version is unique, old versions are traceable, and references are synchronized.
- In the node, check the options and branch connections one by one, confirm that the respective branches for the enrollment plan, filing rules, and admission roster point to the current version, and that the old-version branches retain traceability paths.
- Trigger a user selection node once, check the node status in the run record, and in subsequent nodes reference the selection result variable for a trial run to check whether the branch direction and interaction status records are consistent.