Course Catalog and Curriculum Approval Software: Why Does the SIS Enforce Rules the Catalog Never Approved?

Why the catalog and the system of record stop agreeing

A student appeals a graduation denial in April. She followed her advisor's plan and the catalog page she printed in her first year. The degree audit says she is short a three credit requirement, because in year two the department revised the major and the change was scribed into the audit for all students rather than for the incoming catalog year. Nobody did anything wrong on purpose. The proposal went through committee, the catalog was published, and a separate person entered the change into the audit system from an email summary. Three systems, three interpretations, one student in the registrar's office with a printed page.

The stack is familiar: Banner, Colleague, PeopleSoft Campus Solutions or Workday Student holding the course master and program rules, DegreeWorks or Stellic holding the audit logic, CourseLeaf, Coursedog, Acalog with Curriculog or Kuali Curriculum handling proposals and publishing, a SharePoint site of committee minutes, and a shared drive of Word forms that departments still use because the online form is worse. The catalog produced by that stack is a document. The rules enforced against students live somewhere else entirely.

This is the structural fact worth naming. Your catalog is a contract with students, and in most institutions it is a publishing artefact that was typed a second time into the systems that actually enforce it. Every rekeying is a place where drift enters. It surfaces years later as graduation appeals, financial aid eligibility questions when a program's credit total changed but the aid setup did not, and an accreditation visit where the approved program and the delivered program are not the same thing.

In curriculum projects we have delivered, the recurring load is a registrar's office spending weeks each spring keying approved changes into the course master and the audit, plus a standing queue of appeals that trace back to a change applied to the wrong catalog year. Both are avoidable, and neither is fixed by a better looking catalog website.

Problem 1: your approval chain is written in bylaws, not in a workflow template

A new course in the college of arts and sciences goes department, college curriculum committee, then general education committee only if it carries a general education attribute, then faculty senate curriculum committee, then senate, then provost. A new degree program adds the board of trustees, your state coordinating board, and a substantive change notification to your regional accreditor. A course number change below 500 skips three of those steps. A cross listed course needs both departments and neither wants to be the owner of record.

Curriculog and Kuali both support configurable workflows and they are honest tools. Where institutions hit the wall is conditional routing that depends on the content of the proposal rather than its type, quorum and voting rules that mirror senate bylaws, and the fact that your bylaws change by amendment on a schedule that has nothing to do with your software release cycle. The usual result is a workflow configured once, then abandoned in favour of email once it stops matching how the committee actually votes.

What a custom build does: express routing as rules over the proposal's own attributes. Carries a general education attribute, therefore add that committee. Increases program credits above the threshold, therefore add the state packet step. Crosses colleges, therefore require both deans. Voting is modelled properly, with quorum, abstentions, recorded dissent and the ability to return a proposal to a specific step rather than to the start, which is the single feature faculty ask for most and the one that most tools handle badly. Every action is timestamped with the person, so when a dean claims a proposal sat in the provost's office for four months, there is a record instead of an argument.

Problem 2: publishing the catalog is the easy half, and vendors sell you that half

CourseLeaf, Coursedog and Acalog produce a good catalog website. That is genuinely valuable and none of this is a criticism of their publishing. The gap is downstream. An approved course change has to land in the Banner course master, the prerequisite structure, the degree audit scribe blocks, the schedule build for the term it takes effect, the financial aid program setup if credits changed, and the state program inventory. Some tools push some of that. Almost none of them validate that the push produced what the proposal actually said.

So the registrar's office keys it, and the audit office scribes it, and the two interpretations of the same senate motion diverge in ways nobody notices until a student appeals.

What a custom build does: treat the approved proposal as the source and generate the downstream artefacts from it, with a diff shown before anything is written. The system proposes the exact course master record change, the exact prerequisite expression, and the exact audit rule, a human approves the diff, and it writes. Then it reads back and confirms. Prerequisites deserve specific attention: they are boolean expressions with concurrency and minimum grade conditions, and they are entered as free text in the proposal by faculty. Building a structured prerequisite editor into the proposal form, so faculty pick courses and operators rather than typing a sentence, removes the largest single source of translation error in this whole category. That one feature usually pays for itself in reduced appeals.

Problem 3: catalog year is a version, and most systems treat it as a label

A student is bound to the requirements of the catalog year they entered, with rules about when they may elect a newer one. That means every program, every course, and every requirement has a validity range, and a change approved this year takes effect for a specific future term and specific future cohorts. It is version control with a legal consequence.

Where this breaks in practice is the mid year change. A department discovers a prerequisite error in November and wants it fixed immediately. Someone edits the current record. Now the catalog page for the current year no longer matches what the catalog said when students enrolled, and there is no record of what it used to say.

What a custom build does: store the curriculum as immutable versions with effective terms and never edit in place. A correction creates a new version with a documented reason, and the prior version stays queryable, so the question of what the catalog said on the day a student enrolled has an answer that takes one second. Advisors get a view that shows a specific student's requirements under their own catalog year rather than the current one, which is what they actually need and rarely have. This is also what makes the graduation appeal conversation short.

Problem 4: nobody knows what a change breaks until it has broken it

A department wants to retire a course. It is a prerequisite for four courses in two other colleges, a required course in three programs, an approved elective in eleven, part of a general education category, listed in two articulation agreements with community colleges, and named in a state approved program description. The person retiring it knows about one of those.

Impact analysis is available in some form in the commercial tools, usually as a search for the course code. That finds text mentions. It does not find the audit rule that references it inside a scribe block, or the articulation agreement in a PDF on the transfer office's drive.

What a custom build does: model the curriculum as a graph and make impact analysis a first class step in the proposal. Before a proposal can advance, the system lists every program, requirement, prerequisite chain, general education category, and articulation agreement that references the affected course, and notifies the owning departments automatically with a comment window. This turns a category of political ambush into a procedural step, and provosts tend to value it more than any other single feature because it is the thing that stops a curriculum fight from reaching their office.

Problem 5: the proposal form is ninety fields and faculty route around it

The form asks for learning outcomes, assessment methods, library resource impact, facilities impact, a syllabus, CIP code, delivery modality, a rationale, and a market justification. A faculty member proposing a title change fills in ninety fields to change four words, so instead they email the associate dean, who fixes it directly in Banner, and now there is a course in the system that the senate never approved.

What a custom build does: make the form conditional on what is actually changing. A title correction shows four fields. A new degree program shows the full instrument including the state packet requirements, prefilled where the data already exists in your systems. Save and return without losing work, because faculty write proposals across weeks. Attach the syllabus and keep it with the version. Where AI earns its place is narrow and worth naming: pull the previous approved syllabus and the proposal text and check them against each other for contradictions in credit hours, contact hours and prerequisites before a human reviewer sees it, and flag missing learning outcomes against your own template. That is a checking task, not a writing task, and it removes a large share of the back and forth that makes committee cycles take two extra months.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, the honest shape for curriculum systems is this. A focused first release, meaning a conditional proposal form, rule based routing that matches your bylaws with real voting, immutable catalog year versioning, and a validated write into the SIS course master with a diff step, runs $65,000 to $140,000 and ships in 12 to 16 weeks. A full platform adding degree audit rule generation, prerequisite structured editing, impact analysis across the curriculum graph, state program inventory packets, articulation agreement tracking, and public catalog publishing runs $160,000 to $350,000 phased over 6 to 12 months.

What drives price up specifically in this category: the number of approval bodies and how conditional the routing is, because five bodies with content dependent rules is far more than five times one body. Whether you must write to the SIS or only read from it, since write access to a Banner course master has a governance conversation attached that is longer than the engineering. Degree audit generation, because scribe syntax is unforgiving and generating it correctly takes real iteration. Multi campus or system wide governance where a system office approves after the campus does. And state coordinating board packet formats, which are their own documents in their own shapes.

What keeps price down: starting with course level proposals only, leaving new program creation and the state packets to phase two. Course changes are the overwhelming majority of volume and they teach the whole pattern.

Build versus buy, and when buying is the right call

Buy if you are under roughly 2,500 students, your curriculum is stable, you have one or two approval bodies with straightforward rules, and your main need is a decent catalog website. Acalog with Curriculog or Coursedog will serve you and building would be an expensive way to get a worse catalog. CourseLeaf is a serious product and if your governance genuinely fits its model, use it.

Build when two or more of these hold. Your approval routing depends on the content of the proposal and not just its type. You have documented drift between the published catalog and what the SIS or degree audit enforces, and you are handling appeals because of it. You need generated degree audit rules rather than a second person interpreting the same motion. You operate multiple campuses or a system office layer with its own approval step. Or your faculty have routed around the official form to the point where changes are entering the SIS without going through governance, which is a compliance problem wearing a usability costume.

Our position: the catalog website is the least valuable part of this category and it is what vendors demo. The value is the guarantee that what was approved is what is enforced, in the right catalog year, in every downstream system. Buy the publishing if you like it. Build the guarantee.

How to choose a developer for curriculum and catalog software

Ask them to explain how a course change becomes a degree audit rule. A developer who has done this will talk about prerequisite expression trees, scribe block generation, effective terms and a human approved diff. A developer who says they will sync via API has not looked at what a degree audit rule actually is and will discover it three months in.

Ask how they will handle a mid year correction to a published catalog. If the answer involves editing the record, they do not understand that the catalog is a contract and you will lose the ability to answer what it said on the day a student enrolled.

Ask what write access they need to your SIS and how they will get it approved. The right answer starts with your DBA and integration governance team and includes a staged validation, not a claim of experience with Banner. The politics of writing to the course master is a real project constraint and a developer who has done it will raise it before you do.

Ask who owns the code and the curriculum data, in writing, before kickoff. You should own the repository, the cloud accounts and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit. Your curriculum history is legally significant to every student who ever enrolled, and it should not live in a vendor account you cannot access.