What this category's data looks like
This page addresses the scenario of student disciplinary and appeal handling. Materials include three types: disciplinary fact materials, disciplinary decision documents, and appeal statements. Disciplinary fact materials are formed during the investigation stage, recording the course of conduct and evidence; disciplinary decision documents are issued during the deliberation stage, stating the basis and conclusion; appeal statements are submitted by students, stating objections and demands. After the three types of materials enter the workflow, each assumes a different role: fact materials are used to compare names, quantities, and dates; decision documents are used to verify clause citations and effective dates; appeal statements are used to locate disputed fields and signature receipts. Materials are updated along with process nodes, versions use receipt acknowledgment as the synchronization marker, and field characteristics are concentrated in name, student ID, number of disciplinary items, dates, and signature fields.
Configuration and implementation checks
This step is executed by workflow nodes (user selection and branching), outputting branch directions and interaction state records. The "discrepancy list" is 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 |
|---|---|---|
| Disciplinary fact materials | Whether names, quantities, dates, and signatures correspond item by item with the ledger | Check options and branch connections one by one in the node, reference variables to compare fields, and record nodeId |
| Disciplinary decision documents | Whether clause citations, effective dates, and receipt signatures are consistent with the fact materials | Trigger one run to view the node status in the run records, and check the date and signature fields in variables |
| Appeal statements | Whether the names, quantities, and dates of disputed fields are synchronized with the decision document version | Reference this variable in a subsequent node and run a trial once, and check the branch direction corresponding to nodeId |
| Discrepancy list | Whether inconsistent fields have been marked with the source material and discrepancy type | Hand over to the reviewer for confirmation and write back, and check whether the fields in the discrepancy list are consistent with the ledger |
Three common errors
- Phenomenon: The number of disciplinary items for the same record does not match between the fact materials and the decision document. Cause: Field-level comparison was not performed when entering the two sets of data, and quantities and dates were filled in independently.
- Phenomenon: The decision document version referenced by the appeal statement is inconsistent with the currently effective version. Cause: The version was not synchronized, and the old version of the material was not updated and replaced along with the process nodes.
- Phenomenon: The disciplinary decision document lacks a signature or the receipt field is blank. Cause: The acknowledgment step was not included in the verification items, and the signature field was not validated when the material entered the workflow.
How to verify the setup
This function acceptance: Run trials option by option, check the branch direction and interaction state in the run records, and confirm that variables have been passed to subsequent nodes and that nodeId corresponds to the correct branch.
Business test: Use one real record to find fields inconsistent with the ledger, mark the discrepancy type, and hand it over to the reviewer for confirmation and write-back.
- Check options and branch connections one by one in the node, and confirm that each option corresponds to one branch and that no default branch is mistakenly taken.
- Trigger the user selection node once, view the node status and
variablespassing results in the run records, and confirm that the process continues after the interaction is completed.