Audits at Stellic

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 and Requirements

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 requirements and groupings:

Credentials: A credential is a grouping of programs that represents what a student will receive upon graduation—typically a degree or certificate. Credentials sit at the top of the data hierarchy and contain one or more programs (such as a major with a minor, dual majors, or a standalone certificate). All programs within a credential must be completed simultaneously to complete the progress towards that credential because they collectively represent one degree or certificate being awarded. This way Credentials can also be used to clear a student for graduation. Credentials may correspond to specific Student Information System (SIS) records or serve as conceptual groupings defined by your institution.

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. Programs form the foundation of all degree audits.

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.

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 is updated, administrators only need to update the Shared Requirement once rather than modifying each program individually.

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.

Programs (from the SIS), Shared Requirements, and General Requirements

See the attachment method and visibility for each type of program and audit.

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:

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.