What this category's data looks like
The materials of primary and secondary school enrollment organizations mainly consist of enrollment plans, application material checklists, and admission lists. They come from various internal business units and external system exports, and their update cadence advances by enrollment batch. Fields include name, quantity, date, and signature field. The enrollment plan defines the rules and time nodes, the application material checklist corresponds item by item to certificates and receipts, and the admission list carries the final destination. When the three enter the conversation logs and auditing function, they respectively serve as the rule basis, the verification ledger, and the result evidence, and are used to trace an anomalous record back to the original materials.
Configuration and implementation checks
This step is executed by the conversation record interface (by application and session dimension), which outputs the session message list and the total record count, including role and reference information. The "exception list and review conclusion" is then completed manually or by an external system. The interface only retrieves session evidence and does not write to business ledgers.
| Object | Check | Verification action |
|---|---|---|
| Conversation record interface | Paginate and pull by application and session dimension, returning the total record count and response code of 200 | Use chatId to pull two pages in a row, compare the offset and total record count, and sample one entry to look at role, reference, and elapsed time |
| Enrollment plan | The batch name, quantity, date, and signature field in the plan must be consistent with the application material checklist | Compare the name, quantity, and date of the plan and the checklist item by item; separately register any missing signature or receipt |
| Application material checklist | The certificate name, number of copies, and receipt date in the checklist must match the admission list | Verify name, quantity, and date record by record; mark the source batch for any version not synchronized |
| Admission list | The list fields must be supported by original records and traceable to the source materials | Take one anomalous record and use dataId and value to trace it to the corresponding message and reference |
Three common errors
- Symptom: the name or date of the same student does not match between the plan and the admission list. Cause: the two materials are maintained by different business units, versions are not synchronized, and there is no unified receipt.
- Symptom: the quantity in the application material checklist is inconsistent with the quantity in the admission list. Cause: after the checklist was updated, it was not written back to the list, the signature field is blank, and the anomalous record has no original record support.
- Symptom: the interface returns empty but there are sessions in the interface. Cause: the sources of the application and session identifiers are inconsistent, pagination only retrieves the first page, and the exported records lack references.
How to verify the setup
This feature's acceptance: page through by total record count to retrieve everything, sample one entry to verify role, reference information, and time, and confirm that _id, dataId and value can correspond to one another.
Business test: create an anomalous record, see whether it can be traced to the source materials, and verify the name, quantity, date, and signature of the enrollment plan, application material checklist, and admission list.
- Pull two pages in a row and compare the total record count and offset, confirming response
codeof 200 and that each message has an identified role in the list. - Open one record to verify the reference and elapsed time fields, record the number of references separately by array length, and for the reference upper limit verify the tokens of the reference text.