← ALL WORK
Flagship · 01Degree audit

CatalogOps

A conflict engine that catches 20 real catalog contradictions before a student ever feels them.

requirements, term swimlanes, and prerequisite flow in one view
fig.01 — requirements, term swimlanes, and prerequisite flow in one viewflagged: why · who · fix
detection
20
real conflict types caught before a degree plan broke
triage
3
severity tiers, so the highest-stakes breaks surface first
single view
1
place to see every conflict, its owner, and its fix
Problem

A course catalog is a promise. When it contradicts itself, a student pays for it — in a semester, a tuition bill, or a delayed graduation.

Prerequisite loops, credit mismatches, requirements that reference courses that no longer exist — these contradictions hide inside thousands of catalog entries, invisible until an advisor stumbles on one or a student's plan collapses late. Catching them by hand doesn't scale, and the cost of a miss lands on the person least able to absorb it.

Approach

CatalogOps models the entire catalog as structured data, then runs a rule engine that looks for 20 distinct kinds of contradiction. But detection was never the hard part — acting on a finding is. So every conflict the engine surfaces carries three things a person can use immediately:

Why

the exact rule broken, in plain language

Who

the department or owner who can resolve it

Fix

the concrete change that clears the conflict

Architecture

Findings are organized around the person who acts on them — ranked by severity, each carrying its Why, Who, and Fix.

A flat list of 200 errors is noise. Ranked by severity with the owner and the fix named on every finding, the same data becomes a work queue: the highest-stakes breaks surface first, and each one arrives ready to act on. That single organizing decision is what turned a detection script into something an institution could actually run.

Catalog data Rule engine · 20 checks Findings + Why/Who/Fix Severity-ranked queue
Walkthrough
01

Scan the whole catalog at once

All 20 checks run across every program in one pass — no sampling. A hunch becomes a complete, repeatable inventory.

the Health view — every conflict for a program, grouped and explained
a finding expanded — the why, the fix, and the exact courses in scope
02

Open a finding, see the whole story

Each conflict expands into its Why, Who, and Fix. No interpretation step — the reader already knows what broke, who owns it, and what to do.

03

Fix it at the source — in Colleague

Every finding names the exact configuration to correct, so the fix happens where the data lives — directly in Colleague. The next scan confirms the conflict is gone, and the catalog stays fixed for everyone downstream.

correcting a subrequirement specification in Colleague (SRSP)
Why it matters

The student never sees CatalogOps. They just get a degree plan that works — and never find out how close it came to not.

That's the point of the whole thing. The best version of this tool is one no advisor thinks about and no student ever hears named. The catalog is simply correct now, and the work of keeping it that way fades into the background.

Built with Structured catalog model · Rule-based conflict engine · SQLite · Standalone HTML review interface
Next · Flagship 02
The Accelerator