Skip to main content
DoneThat

AI Adoption GuideEducationCredential

Automated Degree Audit

A rule engine augmented with an LLM maps completed coursework to degree requirements and flags substitutions for registrar review.

Education processRecruitAdmitEnrollTeachAssessCredentialGraduateAdvance

By Don, DoneThat’s AI coach · updated

What a cited degree audit must produce

A quality automated degree audit is a row-by-row map from the catalog to the student record. Each requirement row either cites a completed course that satisfies it or stays empty. Empty is the correct output when no matching course exists. The engine does not invent a substitution, does not mark a row met on a near-match, and does not post an exception. The registrar still posts exceptions.

The audit is a working document for degree-audit staff, not a diploma. Registrar and admissions platforms (Ellucian, Workday, Anthology, Slate) remain the system of record. Mapping reads their extracts. It does not replace posted exceptions or the conferred degree.

What the audit must show for every row:

  • The catalog requirement identifier and the catalog text that defines it (term, program, and requirement group).
  • The completed course used as evidence, or a blank evidence field.
  • The cite: course subject, number, title, term, credits, and grade, plus the catalog row those values were matched against.
  • A status limited to met, unmet, or flagged for review. Flagged is not met.

If a row has no matching course, leave the evidence field blank and the status unmet. Do not fill it with a similar course, a transfer placeholder, or a competency statement that was never posted.

Load catalog rules and completed courses before any mapping

Load two sources before the model sees a single requirement. First, the catalog rules for the student's catalog year, program, and any declared concentration: required courses, credit totals, distribution groups, sequences, residency, GPA floors, and mutually exclusive groups. Second, the completed-course file: posted institutional courses, posted transfer credit, and posted prior-learning credit. Draft registrations and in-progress courses stay out of the completed file unless policy labels them provisional on the audit.

Do not load a narrative transcript and ask the model to "see if they can graduate." The catalog is a set of rows with identifiers. The student record is a set of posted courses with identifiers. Mapping is a join with a cite on both sides.

Pull transfer coursework only after transfer credit evaluation has posted an equivalent or a residual. An unposted transfer line is not a completed course. The same rule applies to prior learning assessment evaluation: assessed credit that has not been posted is not evidence on a degree audit.

Catalog load checks that matter in practice:

  • Catalog year matches the student's locked year, not the current year.
  • Inactive or replaced courses in the catalog still appear if the student's year used them.
  • And/or groups, sequences, and "choose n from list" groups keep their group identifiers so a course cannot satisfy two exclusive rows.
  • Minimum grade and repeat-for-credit rules travel with the course row, not as free text in a prompt.

If the catalog extract and the student extract disagree on a course identifier, stop. Do not guess an equivalent.

Map each requirement row to coursework with cites

For each catalog row, search the completed-course file for an exact match on the identifiers the rule names. When a match exists, write the cite: this course, this term, this grade, against this catalog row. When several courses could satisfy a distribution group, apply the catalog's own selection rule (first qualifying course, highest grade, or staff-configured priority) and record which rule you used. When no course matches, leave the row empty.

A large language model can help read messy catalog prose and propose a candidate course for a loosely worded distribution group. It does not get to declare the row met. The rule engine owns the match. The model proposes. The cite must still point at a real completed course and a real catalog row.

Illustrative path, not a measured result: a biology major's catalog year requires CHEM 201 and CHEM 202 as a sequence. The student completed CHEM 201 on campus. Transfer credit posted CHEM 2XX for a sophomore organic course taken elsewhere, with no departmental equivalent. The engine cites CHEM 201 against the first sequence row and leaves the CHEM 202 row empty. It may flag CHEM 2XX as a possible substitution for registrar review. It does not mark CHEM 202 met, does not rewrite CHEM 2XX as CHEM 202, and does not invent a "sequence complete" summary.

That empty CHEM 202 row is also the input for graduation requirement gap alerts. Gap alerts only work if unmet rows stay unmet.

Refuse these mapping shortcuts:

  • Treating a same-prefix elective (CHEM 2XX, CHEM 399) as the named course.
  • Using a failed or below-minimum grade as evidence because the subject matches.
  • Splitting one course across two exclusive requirement groups without a catalog rule that allows it.
  • Filling an empty row from a sibling student's audit or from a previous catalog year.

Keep substitutions as flags the registrar posts

A substitution is an exception, not a mapping. When the engine finds a completed course that is close to a named requirement (same discipline, overlapping title, transfer residual, topic course), it flags the pair: catalog row, candidate course, and why the exact match failed. The status on the requirement row stays unmet until the registrar posts the exception in the SIS.

Do not auto-post a substitution. Auto-posting writes an exception into the student record without the review that your substitution policy, faculty agreement, or state authorization may require. Once posted, later audits treat that exception as if the catalog had changed for that student.

The review queue should show the cite both ways: the catalog row that is still unmet, and the completed course being offered as a substitute. The registrar (or the delegated audit lead) accepts, rejects, or returns for more evidence. Only an accepted post changes the row from unmet to met-by-exception.

Keep the flag distinct from competency transcript generation. A competency statement can describe what a student can do. It is not, by itself, a degree-requirement cite unless your catalog defines that competency as the requirement and the competency has been posted to the record.

Do not treat a draft audit as a posted credential

Three failure modes turn a useful draft into a false credential.

Auto-posting a substitution. The engine writes the exception, the next audit shows the requirement met, and commencement lists are built from that state. Staff never see the near-match. Reverse the post only after someone notices, which is often after the student has been told they are clear.

Inventing a requirement as met. The model infers that lab science is satisfied because a field methods course has a lab-like title, or it treats an unmet row as met because the rest of the program looks complete. The cite is missing or points at a course the catalog does not name. Empty must stay empty.

Treating a draft audit as a diploma. Advisors forward the PDF, students screenshot "all requirements met," and a clearing process uses the draft instead of the posted SIS audit. A draft is a review artifact. Graduation and transcript remarks follow the posted audit after exceptions are entered and the degree is conferred.

Operational guardrails:

  • Draft audits carry a watermark and an as-of timestamp tied to the extract, not to "today."
  • Only registrar roles can post exceptions; mapping users can flag.
  • Clearing for graduation reads the posted SIS audit, not the latest model output.
  • When catalog rules or posted courses change, regenerate the draft; do not edit last week's PDF.

Run the mapping on a current catalog extract and a current completed-course extract, produce cites or empty rows, flag substitutions, and stop. The registrar reviews the flags and posts what policy allows. That is the whole loop.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first