Program
Command

How can a department see future constraints before they become scheduling problems?

Annual schedules distribute courses, rooms, faculty capacity, release time, enrollment demand, and student pathways across a shared calendar. A static spreadsheet can record the answer; it does not make the competing constraints easy to inspect.

The schedule is not the final artifact. It is the operating model behind enrollment, workload, and a student’s route through the program.

Put the schedule, evidence, and rules in the same field of view.

Program Command combines the public schedule with enrollment analysis, faculty workload, capacity planning, conflict checks, and four-year pathway planning. Meeting patterns and labels come from versioned department profiles rather than being buried throughout the interface.

That makes the system reusable without pretending every program works the same way. Local rules remain explicit configuration.

Production separates public reading from controlled action.

• PublicRead-only schedule with year and term selectionLive
• EditorScheduling application with persistence, dirty-state protection, and role gatesControlled
• AnalyticsEnrollment trends, workload, capacity, and forecasting surfacesOperational
• SchemaDepartment Profile Schema v1 for meeting patterns, labels, and defaults02 profiles
• QATest and onboarding checks required before manual production deployGated

The product was hardened around boundaries, not just features.

1. Split public reading from editing. The root serves a read-only schedule; the editing app lives on a separate surface.
2. Move program assumptions into profiles. Day patterns, time slots, text, and defaults are configuration, not scattered constants.
3. Gate deployment. Production publishing is manual and refuses a commit that has not passed required test and onboarding checks.
4. Add advising as a linked model. Four-year pathways expose downstream effects without collapsing advising into schedule editing.

Carry planning forward without hiding its assumptions.

The advising layer is present, but it still needs continued validation against real program sequences. Broader onboarding depends on proving that the profile boundary is sufficient for another department rather than merely renaming one program’s rules.

Some server-dependent functions, including spreadsheet export, still require local hosting. A future production host must preserve the public/editor boundary while restoring those operations.