Admissions Reports and Compliance
Epic summary
The Admissions Reports and Compliance epic turns operational admission records into trusted registers, management views, authority submissions, and audit evidence.
Reports are generated from the same seat, candidate, decision, and movement records used by the operational screens. They are not maintained as separate spreadsheets that can drift from the source.
Actors and access
| Actor | Access |
|---|---|
| Directorate/University/Trust Admissions Officer | Consolidated reports across permitted descendants |
| Admission Nodal Officer | Full operational reports for assigned cycles |
| Counselling Coordinator | Seat, round, allotment, and vacancy reports |
| Specialist officers | Reports limited to their own operational area |
| Authorised Dean/Principal | Decision, override, and exception reports |
| Student Section Officer | Enrolment-handoff reports |
| Internal Auditor | Read-only compliance reports and authorised evidence export |
Report viewing and report exporting are separate permissions where candidate personal information is involved.
Screen structure and data captured
The workspace contains Report Catalogue, Filters, Preview, Export Controls, Submission History, and Saved Reports. Reports read approved operational records; they do not create alternate admission figures.
Report filters
| Field | Entry type | Meaning |
|---|---|---|
| Report type | Selected | Operational position, admission register, seat utilisation, joined list, vacancy, exception, refund, document, clearance, or audit report |
| Entity scope | Selected/defaulted | Governance entity, institution, department, or programme permitted to the user |
| Academic session/cycle | Selected | Time and intake boundary |
| Programme offering | Selected | Institution, programme, and speciality filter |
| Authority/process/round | Selected | Counselling source filter |
| Seat pool/quota/category | Selected | Seat-distribution filter |
| Candidate/admission state | Selected | Reporting, verification, clearance, decision, joining, movement, or enrolment state |
| Date type and range | Selected/entered | Allotment, reporting, decision, joining, movement, or audit time |
| Exception/control state | Selected | Blocking, warning, overridden, unresolved, or resolved |
| As-of timestamp | System/defaulted | Reproducible reporting cut-off time |
Report and export fields
| Field group | Fields |
|---|---|
| Preview | Column set, grouping, sorting, totals, source timestamp, and applied filters |
| Saved report | Name, description, owner, permitted viewers, schedule, and retained filter version |
| Export | Format, template/version, purpose, sensitivity classification, masking rule, and included columns |
| Approval | Required approver, approval decision, reason, time, and approved version |
| Transmission | Recipient authority, channel, sent by/at, reference, acknowledgement, and response state |
| Audit | Requesting user, entity scope, row count, generated file checksum, download/view events, and expiry |
Candidate identifiers and sensitive fields are included only when the report purpose and user’s field permissions allow them.
Use case 1: Run an operational admission report
As an Admission Nodal Officer
I want to see current operational counts and candidate lists
So that I can manage the admission cycle.
Acceptance criteria
- Reports can be filtered by entity, cycle, programme, authority, round, seat pool, category, and case state.
- Summary figures link to the candidate or seat records behind them.
- The report shows the data-as-of time and active source versions.
- The same filters produce consistent totals across summary and detail views.
- Users cannot report on entities outside their hierarchy.
Negative cases and alternate flows
- Incomplete data: Mark the report incomplete and identify missing imports or reconciliations.
- No results: Show the applied filters and an empty-state explanation.
- Long-running report: Process it as a background task and notify the user when ready.
Use case 2: Produce the admission register
As an Internal Auditor or Admission Nodal Officer
I want to produce the official admission register
So that the institution can demonstrate who was admitted and under which authority.
Acceptance criteria
- The register includes the approved candidate, programme, batch, authority, round, seat pool, category, decision, and joining details required by the configured format.
- Withdrawn, cancelled, upgraded, or relieved candidates remain identifiable with their effective status.
- The register identifies the source cycle and report version.
- Generated output is retained or reproducible from locked source records.
- Sensitive data not required by the report is excluded.
Negative cases and alternate flows
- Cycle not closed: Label the register Provisional.
- Locked record later corrected: Produce a new version and retain the earlier report.
- Export access absent: Permit on-screen review without downloadable candidate data.
Use case 3: Review exception and control reports
As a Directorate/University/Trust Admissions Officer
I want to review high-risk admission events
So that governance can investigate unusual or non-standard activity.
Acceptance criteria
- Reports cover eligibility overrides, waived requirements, post-cutoff attempts, late reporting, reopened rounds, post-joining cancellation, and reconciliation differences.
- Each event links to its reason, authority, approver, and evidence.
- Attempted blocked actions are distinguishable from completed actions.
- The report supports entity and time filters.
- Viewing restricted evidence follows the user’s field-level permissions.
Negative cases and alternate flows
- No exception: Show a clear zero-event result rather than omitting the report.
- Sensitive medical basis: Show the authorised outcome without unnecessary clinical detail.
- Missing evidence: Flag the governance deficiency separately from the operational outcome.
Use case 4: Export authorised evidence
As an Internal Auditor
I want to export an authorised evidence package
So that I can support a university, regulator, or internal audit request.
Acceptance criteria
- The auditor selects an approved report or evidence scope.
- The system previews included candidate information and documents.
- Export requires the specific export capability.
- The export records user, time, scope, reason, and file fingerprint.
- Watermarking or confidentiality labelling is applied where configured.
- The package excludes records outside the user’s scope.
Negative cases and alternate flows
- Over-broad request: Require narrower scope or additional approval.
- Restricted evidence: Omit or redact it and disclose that the package is redacted.
- Export generation failure: Retain the request and provide a safe retry.
Success outcome
Operational teams, management, and auditors receive consistent reports derived from the same controlled records, with every sensitive export authorised and logged.