The planning layer institutions still do not have

What the public data already shows

Why freeform constraints matter

Freeform input is not there to do something flashy. It exists because real student planning requirements are too complicated to reduce to a small menu of fixed constraint types. It is easy to build a UI where a student picks something like pair_classes and chooses two courses. That does not solve the real problem.

Students do not think in isolated rules. They think in layered, conditional logic: only pair two classes if they are in summer; only do that if there is no lab as well; avoid chemistry and physics together; allow biology with chemistry only when the term is under four courses; never take physics and biology together; take only three classes this fall because of an internship; keep ENGL 101 immediately before ENGL 102; try to graduate by Spring 2030. That level of customization is almost impossible to express in a rigid builder alone.

This is also why what-if planning matters. A student cannot ask an advisor to manually run twelve different schedules with wildly different constraints just to understand the possible routes to graduation. In most institutions, that analysis is too expensive in staff time to perform consistently and too unstructured to track afterward. Our solver was designed specifically to handle this kind of academic logic at scale.

That language is parsed into a formally specified model: decision variables (for example, which courses land in which terms), domains fixed by catalog rules and offerings, and logical or arithmetic relations that encode the student's preferences alongside institutional policy. The proprietary solver then performs combinatorial feasibility search over that model—proving feasibility or optimizing an objective—rather than improvising a narrative answer.

What this adds for platform owners