Overview of Audits
Audits are central to the Stellic platform. They help students understand the requirements for their program of study and allow advisors to track a student’s progress. Audits consist of requirements (the courses and categories needed to complete the program) and constraints (which define when a requirement has been fulfilled). This section describes how to create and manage an audit, in addition to best practices and use cases.
Understanding Programs
Requirements and constraints are essential components of managing a student's academic progress, ensuring they fulfill the necessary conditions to complete a degree or program.
In Stellic, there are different types of audits and requirements:
Programs: Programs, such as majors, minors, and certificates, come from the Student Information System (SIS). Each program may house one or more program audit versions, representing the requirements that have changed over time, per the institution’s curriculum and catalog. Those program audits then automatically attach to a student’s plan based on their declared programs coming from the SIS. Program audits form the foundation of a student's academic path.
General Requirements: These are also programs in Stellic, but they are created within Stellic by the institution, rather than coming from the SIS. General Requirements automatically attach to a student's plan based on criteria defined by the institution, such as program, department, school, or student tag. These requirements apply either to individual students or entire groups. An example would be first-year students across all majors being required to complete a university writing seminar. Rather than adding this requirement to each individual program audit, it can be applied automatically as a General Requirement based on the student's first-year status.
Subrequirements: Within all types of Stellic audits, you'll find subrequirements, which are the building blocks you see when adding components to an audit. These can include courses, milestones, categories, or shared requirements.
Shared Requirements: These are not stand-alone audits. They are blocks of requirements that can be centrally managed and then embedded within program audits or General Requirements. Common examples include a Science Core, where Physics, Biology, and Chemistry majors all take the same set of introductory common courses. That Science Core can be built and managed as a Shared Requirement, and then embedded in each of the Physics, Biology, and Chemistry program audits. If this Science Core was updated, administrators only need to update the Shared Requirement once rather than modifying each program individually.
Programs (from the SIS), Shared Requirements, and General Requirements
See the attachment method and visibility for each type of program and audit.
Requirement Type | Attachment Method | Visibility to Students |
Program (from the SIS) | Automatically attached to student plans based on declared programs from the SIS | Visible to students in their Progress tab Visible to students to browse in the Programs catalog for what-if scenarios |
General Requirement | Automatically attached to student plans based on scope criteria set by the institution | Visible as a separate program in their Progress tab |
Shared Requirement | Manually attached during audit creation | Visible only when added within a Program or General Requirement that applies to the student |
About Constraints
A constraint refers to a limitation or restriction applied within requirements, or the “rules” in the audit that determine which courses can count. Institutions can set and customize constraints to ensure that students meet specific academic conditions or avoid conflicting course requirements. Constraints help institutions enforce rules, such as course exclusions or program restrictions.
Primary constraints: These define what can count for a specific requirement. You can see these constraints when you first begin building your audit, before adding any other constraints to the category. Each requirement has only one primary constraint. The primary constraint sits at the top of the requirement and sets the initial definition of which courses are eligible to be considered for the requirement. A primary constraint can be used on its own and may or may not have secondary constraints below it.
Secondary constraints: These only appear once you have defined a primary constraint. You cannot use these constraints independently. They filter the requirements in specific ways after a primary constraint has been set. Important note: A secondary constraint can never add to the courses permitted to count by the primary constraint. The primary constraint sets the broadest eligible set of courses available for the requirement. The secondary constraints then narrow that list. They cannot expand it.
Program-level constraints: Most primary and secondary constraints can be used either at the program level (to govern the entire program audit) or within individual sub-requirements within the audit. There are, however, some constraints that are only available at the program level. These govern the entire audit.
To learn more about building requirements and using constraints in your audit, see Audit building: Requirements.
Hierarchy of an Audit
In general, the audit checks for requirements to be fulfilled in a top-to-bottom hierarchy. This means that when you design audits, the most specific requirements should be at the top and most general lower down. This hierarchical approach makes Stellic audits simpler. In general, you can think of it this way:
Location in the Audit | Types of Courses | Examples |
Top | Specific required courses | Example: PHIL 380 |
Middle | Groups of courses to choose from | Example: Fulfill any 2 from the following list of specific Philosophy courses, patterns, or ranges |
Bottom | Broad groups of courses to choose from, such as open electives | Example: Complete at least 10 credits from any courses in the PHIL 100-400 range. |
In the case above, you would not need to explicitly exclude PHIL 380 from counting in the Middle or Bottom categories. When PHIL 380 is planned or registered, the audit starts at the top to look for a place where the course is eligible. Because PHIL 380 is picked up by the top category, it is no longer available to be considered by the middle and bottom categories.