Top Level

The degree audit program kicks off a degree audit by automatically generating a top-level plan specification that says what to include using the include mechanism.

The program stars with the following template:

audit <UWID> "<LASTNAME>, <GIVEN_NAMES>" {
  # Global course specifications
  allCourses = ^([A-Z]+)_(([0-9]+X*|XXX|1X000)[A-Z]*)

  # Insert includes here for each plan
}

allCourses defines a starting course set of all the courses the student has taken. This could probably get away with just ^[A-Z]+_.* but the expression given corresponds to “real” courses in the database and excludes some anomolies. More about what these characters mean in Course Sets.

Into this template are inserted include statements for each of the student’s plans. There are three cases to distinguish.

Changes expected

2025-06-23: Changes are expected to the format of include:

  • baseCourseDefs will be required to be inside the included file.
  • block will disappear.
  • include will move the plan group to be the first argument.
  • The search path will be included in square brackets to more clearly identify it as a composite argument.

Plans with no program

The simplest are plans that do not link to a program, minors being the most common. They result in an include such as

block {
    include(baseCourseDefs,1201, uw.u.sci.cred.biol,
                         uw.u.sci,
                         uw.u)
    include(BIOLMIN, 1201, uw.u.sci.cred.biol, uw.u.sci.cred.biol)
}

The first include uses a standard name baseCourseDefs and the include search mechanism to any faculty-specific course set definitions. In this example, if uw/u/sci/baseCourseDefs-<TERMID>.plan (for some suitable term) exists, those definitions will be loaded. If they do not exist, then the defaults in uw/u/baseCourseDefs will be loaded. The part of this includes file that says uw.u.sci.cred.biol is NOT a place that will be searched, it is the plan group.

The second include loads the plan specification itself. Both of these are contained in a block to establish that the course definitions and plan belong together.

In both cases, the 1201 is the student’s requirement term for this plan.

Plans linked to a program

The most common cases are plans linked to a program. This includes the student’s “Plan10”. They result in a somewhat more complicated include. Here’s an example:

block {
  include(baseCourseDefs,1201, uw.u.sci.bac.scidean.other,
                         uw.u.sci,
                         uw.u)
  include(SCIH, 1201, uw.u.sci.bac.scidean.other, uw.u.sci.bac.scidean.other)
    ( include(USC25, 1201, uw.u.sci.bac, uw.u.sci.bac)
    )
}

Again, the first include provides an opportunity to establish some faculty-specific course definitions.

The second include is for the plan specification for SCIH. Inside that specification, it will include the associated USC25 program requirements. In other words, the resulting structure will be something like:

block {
    sci = ^(BIOL_|CHEM_|EARTH_|MNS_|PHYS_|SCI_).* - ^SCI_237
    # Other Science-specific course definitions

    plan SCIH 1201 using all passedCourses {
        # Requirements from uw.u.sci.bac.SCIH-1189.plan

        all of "USC25 program requirements" {
            # Requirements from uw.u.sci.bac.USC25-1189.plan
        }
    }
}
Note

These includes are automatically generated. No need to write these yourself, although understanding at a high level will help you understand how degree audit works.

Specializations

The third case is a student with a specialization. They are handled differently in the triple-counting rule and so are included within the associated plan.
The following is automatically generated for a real Arts student with two majors, each having a specialization, plus a minor. Some comments have been added to explain.

audit 20654079 "Price, Calvin" {
     
    # Global course specifications
    allCourses = ^([A-Z]+)_(([0-9]+X*|XXX|1X000)[A-Z]{0,2})$
     
    block {
         
        include(baseCourseDefs, 1179, uw.u.arts.bac.psci, uw.u.arts.bac.psci, 
                                                          uw.u.arts, 
                                                          uw.u)
         
        includePlan(uw.u.arts.bac.psci, PSCI16HC, "Political Science 16 HC", 1179, 
                    includePlan(uw.u.arts.cred.psci, PSCBUS16SP, 
                                "Politics & Business SP", 1209), 
                    includeProgram(uw.u.arts.bac, UAR15, "Arts HC", 1171, 
                                   uw.u.arts.bac.psci))
    }
    block {
         
        include(baseCourseDefs, 1201, uw.u.arts.bac.econ, uw.u.arts.bac.econ, 
                                                          uw.u.arts, 
                                                          uw.u)
         
        includePlan(uw.u.arts.bac.econ, ECON16HC, "Economics, Honours Co-op", 1201, 
                    includePlan(uw.u.arts.cred.econ, ECONFN16SP, "Fin Spec", 1209), 
                    includeProgram(uw.u.arts.bac, UAR15, "Arts HC", 1171,
                                   uw.u.arts.bac.econ))
    }
    block {
         
        include(baseCourseDefs, 1209, uw.u.arts.cred.psci, uw.u.arts.cred.psci, 
                                                           uw.u.arts, 
                                                           uw.u)
         
        includePlan(uw.u.arts.cred.psci, INTTRADMIN, "International Trade MN", 1209)
    }
     
    # University-wide requirements
     
    include(uwRequirements, 1171, uw.u, uw.u)
}

Pro Tips

If you wish to know how a plan you are writing is structured, add the clause --auditSpec when running your degree audit from the terminal (using degreeAudit). This will display the top level to you.