Administration

The college operating system, described before it is built.

Pillars Leadership College will be run from one connected institutional system, not a collection of spreadsheets. This page documents that system: who may do what, how admissions and academic records will work, and where the boundaries sit. Nothing on this page operates today.

Read this first

There is no administrator account, no student record, no application, no payment and no grade anywhere in this system. The secure institutional database is not yet connected. What follows is the architecture that database will be built on — deliberately written down first, so that admissions, teaching, finance and credentials end up as one institution rather than four disconnected tools.

What is live today Credential verification

One institution, one record

A person moves through the College once. The same record follows them from the public website to alumni status — no parallel systems, no re-keyed data, no second definition of a programme hidden somewhere else.

Public website
Admissions
Enrolment
Student record
Digital Campus
Academic delivery
Finance
Completion
Credential
Alumni

Roles and least privilege

Each role sees only what its work requires. A role name is a label, never the protection itself: the database and the server will enforce every boundary below, so that changing a value in a browser cannot grant anyone anything.

Applicant

Their own application, their own documents and messages sent to them by admissions.

Must never reach

Internal admissions notes
Reviewer assignment
Their own decision status as an editable field
Any other applicant's record

Student

Their own enrolment, learning, attendance, results, financial account, credentials and support cases.

Must never reach

Another student's record of any kind
Unpublished results
Staff notes
Any administrative list view

Lecturer

Only the cohorts, modules, classes, attendance registers, assignments and grading assigned to them.

Must never reach

Students' payment history or balances
Cohorts they are not assigned to
Admissions decisions
Institutional settings

Admissions officer

Applications, review workspace, internal admissions notes, applicant messages and admissions reporting.

Must never reach

Grades and academic results
Financial adjustments and refunds
Role assignment
Security and audit administration

Finance officer

Charges, payments, receipts, instalment plans, outstanding tuition, reconciliation and finance reports.

Must never reach

Grades, submissions or academic results
Admissions decisions
Credential issue or revocation
Role assignment

Administrator

Authorised institutional administration: programmes, cohorts, classes, faculty records, communications and support.

Must never reach

Silently changing published grades
Role escalation
Integration credentials and service keys

Super administrator

Institution-wide oversight, role management, security centre, audit log and institutional settings.

Must never reach

Any secret displayed in plain text
Editing an audit record after the fact

Privileged actions

These actions change the institution. Every one of them will be executed on the server, checked against the acting person’s role, and written to the audit log.

Change an application's review status or record a decision
Server function with role check plus row-level policy; every change appends to application_status_history.
- admissions officer
- admin
- super admin
Assign or change a user's role
Separate roles table, security-definer role check, audited; self-promotion structurally impossible.
- super admin
Change a student's status
Server-controlled transition table; arbitrary transitions rejected.
- admin
- super admin
Record, adjust or reverse a payment
Provider-verified webhooks only; manual adjustments require a reason and are audited.
- finance officer
- super admin
Issue a refund
Server-side, provider-verified, audited, never triggered by a browser redirect.
- finance officer
- super admin
Publish or correct a result
Lecturer limited to assigned modules; corrections keep full history with actor and reason.
- lecturer
- admin
- super admin
Issue or revoke a credential
Requires satisfied completion requirements; payment alone never issues a credential.
- admin
- super admin
Publish a programme or open admissions
Explicit status transition, audited; drafts are never publicly readable.
- admin
- super admin
Change institutional settings or integrations
Secrets stored server-side only and never returned to any interface.
- super admin

Founder command centre

Not a wall of charts. The executive view is designed around the questions leadership actually asks, and every measure will be computed from real records — or shown as empty until they exist.

What is happening at PLC right now?
What requires my attention today?
How is admissions performing?
How is tuition collection performing?
How are students progressing?
Which classes need attention?
Which channels actually produce enrolled students?
What decision does leadership need to make this week?

Measures, and where each will come from

Applications

—

How many applications exist, by stage?

Source: applications

Pending admissions reviews

—

How many are waiting on a reviewer?

Source: applications + reviewer assignment

Admitted

—

How many offers have been made?

Source: applications (admitted)

Enrolled

—

How many admitted applicants actually enrolled?

Source: enrolments

Active students

—

How many are studying right now?

Source: enrolments (active)

Faculty

—

How many lecturers are assigned and active?

Source: faculty + faculty_assignments

Active programmes

—

What is currently being delivered?

Source: programmes (published)

Active cohorts

—

Which groups are running, in which language?

Source: cohorts

Upcoming classes

—

What is scheduled in the next seven days?

Source: live_sessions

Attendance rate

—

Are students showing up?

Source: attendance

Completion rate

—

Are students finishing?

Source: enrolments + results

Gross tuition billed

—

What has been charged?

Source: charges

Payments collected

—

What has actually been received and verified?

Source: payments (verified)

Outstanding tuition

—

What is owed?

Source: charges − verified payments

Masterclass revenue

—

What did masterclasses bring in?

Source: masterclass_registrations + payments

Masterclass conversion

—

How many masterclass participants became students?

Source: masterclass_registrations → applications → enrolments

Open support cases

—

Who is waiting for help?

Source: support_tickets

Requires attention

The queue is empty because there is nothing to queue. These are the rules that will fill it — no alert will ever be manufactured to make the screen look busy.

Applications awaiting reviewstatus = submitted or under_review, no decision, older than the review target
Students with outstanding tuitioncharges exceed verified payments past a due date
Classes without an assigned lecturerlive_session has no faculty assignment
Upcoming classes without meeting informationlive_session within 48 hours and no protected meeting link
Low attendancestudent attendance below the threshold set in academic settings
Assignments awaiting gradingsubmissions with no result past the grading target
Students approaching completioncompletion requirements nearly satisfied
Credentials awaiting approvalcredential status = pending review
Unresolved support casesticket open or waiting beyond the response target

Administrative workspaces

Each workspace has a purpose, a set of operations and boundaries that the backend must enforce. The state on each card is honest.

Founder command centre

Architecture ready

One executive view of the institution and the decisions it needs.

Institutional measures
Requires-attention queue
Period comparison
Drill-through to the underlying list

Enforced boundaries

Super administrator and administrator only
Every measure computed from real records or shown empty

Admissions operations

Secure system required

Receive, review and decide applications professionally.

Application queues by state
Reviewer assignment
Review workspace
Decisions
Applicant messages
Admissions reports

Enforced boundaries

Internal notes never reach an applicant
List views omit unnecessary personal data
Only admissions staff may change state

Student records

Secure system required

The student information system: identity, programme, progress, finance, support.

Student lookup
Student profile
Status changes
Academic history
Financial account
Credential status

Enforced boundaries

Compartmentalised by role
No student sees another student
Status transitions are server-controlled

Faculty management

Secure system required

Appointments, assignments and the separation of public profile from private account.

Faculty record
Programme and cohort assignment
Module and class assignment
Public profile visibility

Enforced boundaries

Private contact and security information never reaches the public faculty page

Programmes and cohorts

Architecture ready

One definition of each programme, shared by the public site and the campus.

Programme details and status
Curriculum and modules
Language tracks
Cohorts
Admissions availability
Completion requirements

Enforced boundaries

Draft programmes are never publicly readable
No duplicate programme definitions anywhere in the codebase

Class operations

Secure system required

Scheduling, delivery, materials and recordings for each cohort.

Schedule a class
Assign a lecturer
Attach materials
Publish a recording
Class status

Enforced boundaries

Meeting links are released only to authorised participants and never indexed

Attendance

Secure system required

An accurate, correctable, auditable register.

Mark present, late, excused or absent
Correct a register with a reason
Attendance history and rates

Enforced boundaries

A lecturer reaches only their assigned cohorts
Every correction keeps the previous value and the actor

Assignments, assessment and results

Secure system required

Set work, receive it, grade it, moderate it, publish it.

Create assignments
Review submissions
Feedback and grading
Moderation
Publish results
Corrections with history

Enforced boundaries

Nothing publishes automatically
Administrators oversee but do not casually alter grades
Every correction is audited

Finance

Secure system required

Tuition billed, collected, outstanding, refunded and reconciled.

Student accounts
Charges and payments
Instalment plans
Receipts
Refunds
Reconciliation
Finance reports

Enforced boundaries

Gross revenue is never presented as profit
No balance is editable from a browser
Payments are verified with the provider server-side

Masterclass administration

Secure system required

Operate masterclasses on the same institutional record as everything else.

Masterclasses
Registrations
Attendance
Payments
Communication
Source and conversion to programme

Enforced boundaries

The existing public masterclass pages are untouched by administration

Credentials

Secure system required

Approve, issue, verify and where necessary revoke.

Eligibility from academic record
Approval
Issue
Public verification
Revocation with reason

Enforced boundaries

Payment alone never issues a credential
Wording awaits the College and legal review

Communications

Secure system required

Institutional announcements to a defined audience.

Audience segmentation
In-platform announcements
Email
WhatsApp notification

Enforced boundaries

Nothing is sent today
No message leaves an unverified institutional address

Student support

Secure system required

A queue, not an inbox.

Queues by area
Ticket lifecycle
Assignment
Resolution and history

Enforced boundaries

Student communications are confidential to the student and authorised staff

Institutional reporting

Secure system required

Admissions, students, academic, finance and marketing reporting from one model.

Report families
Filters and periods
Authorised export

Enforced boundaries

No figure is ever estimated, smoothed or invented

Security, audit and settings

Secure system required

Who may do what, what was done, and how the institution is configured.

Authorised staff
Role management
Security events
Session controls
Audit log
Institutional settings

Enforced boundaries

No password, token or service key is ever displayed
No one can promote themselves
The founder account is established through the backend, never hard-coded

How staff will navigate

Grouped so that the system stays usable as it grows. On a phone, only the items marked for priority stay in the main navigation; the rest move behind a single menu, so administration is genuinely usable at 390 pixels wide.

Overview

The command centre: what is happening, and what requires attention.

Command CentrePhone
Requires AttentionPhone

People

Applicants, students and faculty as institutional records.

ApplicationsPhone
StudentsPhone
Faculty

Academics

What is taught, to whom, by whom, and how it is assessed.

Programmes
Cohorts
Curriculum
ClassesPhone
AttendancePhone
Assessments
Results

Finance

Tuition billed, collected and outstanding — never confused with profit.

Payments
OutstandingPhone
Finance Reports

Engagement

Masterclasses, institutional communication and student support.

Masterclasses
Communications
Support

Institution

Credentials, reporting, auditability and institutional configuration.

Credentials
Reports
Audit
Security
Settings

Controlled states

Applications, students, programmes, payments, credentials and support cases each move through a defined set of states. Nothing jumps arbitrarily from one to another.

Application

draft
→ submitted, withdrawn
Applicant
submitted
→ under review, withdrawn
Admissions (applicant may withdraw)
under review
→ more information required, admitted, not admitted
Admissions
more information required
→ under review, withdrawn
Applicant supplies information; admissions resumes review
admitted
→ withdrawn
Admissions or applicant
not admitted
Terminal state.
Terminal
withdrawn
Terminal state.
Terminal

An applicant can never admit themselves, change a review status, assign a reviewer, read an internal note or alter a staff decision.

Student

Admitted — Offer made, enrolment not yet completed.
Pending enrolment — Accepted the offer; enrolment steps outstanding.
Active — Enrolled and studying. Student number is permanent from here.
On hold — Temporarily paused with institutional agreement.
Completed — All completion requirements satisfied.
Withdrawn — Left the programme.
Suspended — Access restricted by an authorised decision.

Programme

Draft
Published
Admissions open
Admissions closed
Inactive
Archived

A draft programme is never publicly readable, by accident or otherwise.

Payment

Pending — Initiated, not yet verified by the provider.
Verified — Confirmed server-side from the provider, never from a browser redirect.
Failed — Provider rejected or abandoned.
Refunded — Returned in full, provider-confirmed.
Partially refunded — Part returned, balance recalculated.
Reversed — Charged back or reversed by the provider.

Support

Admissions
Academic
Technical
Finance
General

Open
In progress
Waiting for student
Resolved
Closed

Student numbers

Every enrolled student receives one permanent, human-readable number in the form PLC-[YEAR]-[SEQUENCE] — for example PLC-2026-XXXXXX. No number exists yet, and none will be issued before a genuine enrolment.

Issued only on genuine enrolment — never at application, never at payment.
Generated server-side from a controlled sequence; never chosen by a browser.
Permanent once issued; never reused, never recycled after withdrawal.
Database UUIDs remain internal and are never shown as the human identifier.
The year segment records the enrolment year, not the current year at display time.

Where students come from

The first touch that brought a person to the College is recorded once and never silently overwritten, so the College can eventually see which channels produce enrolled students rather than merely traffic.

WhatsApp
Facebook
TikTok
Hot TV
World Pillars Church
Pastor referral
Friend or family
Google
PLC event
Direct
Other

Source, medium, campaign, content, referrer and UTM values travel with the application and the enrolment.

Reporting and exports

Admissions

Applications by programme
Applications by country
Decision rates
Application conversion

Students

Active students
Programme distribution
Language distribution
Country distribution
Completion

Academic

Attendance
Assignment completion
Assessment progress
Completion

Finance

Gross billed
Collected
Outstanding
Refunded
Revenue by programme
Revenue by masterclass

Marketing

Applicants by source
Applicants by campaign
Applicant conversion
Enrolment conversion
Cost per applicant (only where ad spend is supplied)
Cost per enrolled student
Revenue attributed to source

CSV for lists, PDF for formal institutional documents.
Every export containing personal data is authorised by role and written to the audit log.
Exports are generated server-side; the browser never assembles a full dataset.
Lists are searched, filtered, sorted and paginated on the server — never thousands of rows loaded into a phone.

Audit

Serious institutions can say who did what, and when. These events will always be recorded.

Admissions decision recorded
Reviewer assigned or changed
Role granted or removed
Student status changed
Payment recorded, adjusted or reversed
Refund issued
Grade published or corrected
Credential issued or revoked
Programme published or archived
Institutional setting changed
Data export containing personal data

What each record holds

Actor (user id and role at the time of the action)
Action
Entity type and entity id
Timestamp (UTC)
Safe metadata: before/after values for non-sensitive fields, and a reason where required

What it never holds

Passwords or password hashes
Authentication tokens or session identifiers
Service keys or integration secrets
Full payment instrument details

Notifications

Application submitted — Applicant, admissions queue
Information required — Applicant
Admissions decision — Applicant
Payment verified — Student, finance
Upcoming class — Cohort
Assignment deadline approaching — Students with no submission
Result published — Student
New announcement — Selected audience
Credential issued — Student

Event-driven, never scheduled blasts.
One digest rather than many separate messages for the same event group.
Every channel has an opt-out except statutory academic and financial notices.
No notification is ever sent from an unverified institutional address.

The institutional data model

One normalised model, not one per department. None of these exist yet — no table has been created, because the secure database is not connected.

profiles
roles
applications
application_status_history
admissions_notes
programmes
programme_tracks
cohorts
enrolments
faculty
faculty_assignments
modules
lessons
live_sessions
attendance
assignments
submissions
assessments
results
announcements
student_accounts
charges
payments
receipts
masterclasses
masterclass_registrations
credentials
support_tickets
communications
marketing_attribution
audit_logs

Relationships that must hold

Student → Enrolment → Cohort → Programme
Programme → Modules → Lessons
Cohort → Classes → Attendance
Assignment → Submission → Student
Student → Financial account → Charges and Payments
Student → Completion → Credential
Applicant → Application → Admission → Enrolment → Student
Marketing attribution → Application → Enrolment (first touch preserved)

Institutional settings

College identity and official logo
Contact information
Academic settings (terms, attendance thresholds, grading scheme)
Admissions settings (intakes, review targets, required documents)
Finance settings (fees, instalments, currencies, due dates)
Communication settings (sender identities, templates, opt-outs)
Credential wording
Integrations
Security policy

Integration credentials live server-side only and are never shown to an administrator or sent to a browser.

Backup and recovery

Automated daily database backups with tested restoration — not assumed, verified.
Point-in-time recovery for the finance and audit tables.
Credential records preserved independently of programme changes.
Audit logs append-only and retained beyond the operational record.
A written incident recovery procedure with named responsibilities.
No backup claim is made publicly until the infrastructure genuinely provides it.

Still needed from the College

Official institutional email address
Official telephone and WhatsApp number
Registered physical address and office hours
Programme fees, instalment terms and currency
Intake and cohort dates
Masterclass dates and fees
Faculty appointments and biographies
Certificate and credential wording, after legal review
Any accreditation or approval only where genuinely held and documented

Send this information