Suggested Student Status Taxonomy

§Purpose & Scope

Every enrolled student needs to sit in exactly one clear status at any given time, and that status needs to drive real system behavior — who can register, who shows up on a graduation list, who counts toward enrollment reporting. This document lays out the status taxonomy the Registrar's office needs CampusOS SIS to support, grouped by where a student sits in the lifecycle: Admissions, Active, Graduate, and Non-Active.

Audience: CampusOS engineering (does the SIS have this today, and if not, what to build) and the CampusOS project manager (scoping this as a feature request).

§Why This Matters

This isn't just labeling — it's what the registrar's office runs on

A vague or missing status model doesn't just look messy in the SIS — it breaks specific, everyday registrar functions:

• Registration eligibility. A student in SAP Failure or carrying a Financial Hold has to be blocked from registering without the registrar manually intervening every term.
• Accreditation reporting. MSCHE's AIU indicators — enrollment FTE, retention rate, graduation rate — are only as accurate as the status data behind them. If "withdrawn" and "on leave" and "dismissed" aren't distinct, tracked states, those numbers can't be trusted or defended in a review.
• The admissions funnel. Knowing how many applicants are stuck at Pending Signature vs. Pending Payment is the difference between a clean enrollment forecast and a guess.
• Financial operations. Graduated with a balance is a materially different case from Graduated — transcripts, diplomas, and collections all key off it.

1Admissions Statuses

From application to first day of class

2Active Statuses

Currently enrolled, with standing that can vary

Active → Academic Warning → SAP Failure → (Suspended or Dismissed, see Non-Active) is a real, sequential escalation path per UMF's SAP policy — useful if the SIS needs to enforce valid transitions rather than a free-form status dropdown.

3Graduate Statuses

Completing the program

4Non-Active Statuses

Not currently enrolled, for different reasons

Withdrawn, Stopped-Out, Dismissed, and Suspended all mean "not enrolled" but carry very different implications for whether — and how — a student can come back. LOA and Reentry/Readmitted (Admissions Statuses) are the two ends of the same journey: a student goes on LOA, then eventually re-enters through Reentry, not through New Applicant.

§Implementation Notes

Open questions for CampusOS engineering

• Does CampusOS SIS have a status field today, and how flexible is it? Confirm whether statuses are hardcoded, or admin-configurable per tenant — the latter is needed since institutions vary in exactly which statuses they use.
• Primary status vs. hold flags. Financial Hold and (arguably) Graduated with Balance read as flags layered on a primary status, not additional primary statuses themselves. Recommend a single status field plus a separate holds multi-select, rather than growing the status enum indefinitely.
• SAP escalation as a state machine. Active → Academic Warning → SAP Failure → Suspended/Dismissed is a real, ordered progression per UMF's SAP SOP — worth enforcing as valid transitions rather than a flat dropdown, and worth surfacing the specific SAP component that triggered a Warning (GPA, pace, timeframe, or participation) rather than just the status name.
• Valid transitions. Not every status should be reachable from every other status (e.g. Deceased shouldn't transition back to Active). Worth defining an allowed state-transition map rather than a free-form dropdown.
• Reporting rollups. Each status needs a clear mapping to how it counts in MSCHE AIU reporting (enrolled / not enrolled / graduated) so retention and graduation rate calculations stay accurate without manual reclassification.

§Checklist

Status taxonomy readiness