AT&EPS Admission / Technical documentation

Technical Requirement Document

This document describes the architecture, technology stack, security controls, requirements, and implementation constraints for the applicant tracking and enrollment processing system.

1. Overview

The AT&EPS platform is built as a server-rendered PHP application using MySQL as the primary persistence layer. It supports public application intake, staff review workflows, and a student dashboard for status tracking, document review, and enrollment milestones.

Application type

CRUD-based admissions management system with session-based authentication.

Primary language

PHP 8.x for server-side logic and rendering.

Database

MySQL with PDO prepared statements and relational schema.

UI layer

Responsive HTML, CSS, and JavaScript for public, staff, and student views.

2. Technology stack

  • PHP 8.0+ with PDO extension enabled.
  • MySQL / MariaDB database engine.
  • XAMPP Apache + MySQL runtime environment.
  • HTML5 for page structure and form rendering.
  • CSS for responsive layout and visual styling.
  • Vanilla JavaScript for navigation and demo/tutorial interactions.
  • Secure session handling using PHP built-in session APIs.

3. Architecture

Presentation layer

Public pages, staff pages, and student portal pages are rendered with shared templates for consistent styling and navigation. Static assets are stored in the assets directory and loaded through the page headers and footers.

Application layer

Core PHP controllers perform request parsing, validation, authentication checks, database queries, and redirect handling. Shared functions centralize session assertions, CSRF validation, HTML escaping, and route redirects.

Data access layer

Database access is isolated in the application bootstrap and function helpers. All update operations use prepared statements, explicit parameter binding, and transactional handling where needed.

4. Data model

  • applicants: stores personal demographic and application data.
  • staff_users: stores staff login details and access credentials.
  • student_accounts: stores applicant-specific dashboard credentials.
  • student_notifications: stores messages shown to applicants in the student portal.
  • application_status_history: tracks changes to applicant status over time.
  • document_requirements: defines required admissions documents and statuses.
  • enrollment_checklist: stores required enrollment milestones and verification status.

5. Security requirements

Authentication

  • Staff and student logins must use PHP sessions with secure cookies.
  • Passwords are stored via password_hash() and checked with password_verify().
  • Session IDs are regenerated after successful sign-in to mitigate fixation.

Authorization and validation

  • Student pages verify the logged-in applicant ID before rendering data.
  • Staff-only workflows are protected by admin session checks.
  • Input values are trimmed, type-checked, and validated before database use.

Injection defense

  • All SQL queries use prepared statements with bound parameters.
  • Output is escaped before rendering to protect against XSS.
  • CSRF tokens are included on form submissions that carry state changes.

6. Integrations and constraints

  • The system is designed for local development via XAMPP and does not rely on a framework runtime.
  • Email notifications are optional and depend on the environment's configured mail transport and APP_URL value.
  • No payment or external identity integrations are currently included.
  • Document uploads are intentionally not implemented in this version; requirements are tracked as status items rather than file storage.
  • Role enforcement is built into page-level controller checks rather than a separate external auth system.

7. Validation and QA

  • Validate form submission and validation messaging for empty, invalid, and duplicate values.
  • Confirm session redirects for protected staff and student pages when unauthenticated.
  • Verify that database writes succeed with prepared statements and transaction boundaries.
  • Test queue filtering and applicant detail pages after status changes.
  • Confirm event history and notifications reflect approved workflows and staff notes.

8. Deployment

Environment variables

DB_HOST, DB_PORT, DB_NAME, DB_USER, DB_PASS, APP_URL, MAIL_FROM, and related runtime values should be set outside the project in a secure deployment environment.

Operational requirements

Use HTTPS in production, keep PHP and MySQL patched, enforce secure backups, and restrict access to the staff authentication area.

Local setup

Run the schema and create the first staff account using the setup page under the XAMPP environment.

Maintenance

Monitor session security, data integrity, and role-based access while preserving application history and enrollment status logs.