Documenting your institution's guiding principles and formatting decisions will ensure a consistent experience in Stellic audits for your students, staff, and faculty. As is the case with most degree audit systems, there are many ways to accurately build a curriculum requirement in Stellic. Providing a consistent experience in structure, naming conventions, and constraints will benefit all users at your institution. Documenting your decisions during implementation will also help you provide institutional consistency in coming years as you version your audits for future catalogs and potentially bring on new team members in the future.

As your audit library grows, implementing structured management practices becomes essential for maintaining clarity, consistency, and usability. These best practices can help you establish a sustainable audit ecosystem that scales with your institution's needs while minimizing administrative overhead.

A student may have programs that cross multiple schools and departments. Using standard structure and naming conventions across schools and departments will provide consistency throughout the student's record, where they and their advisors see audits for each of their programs. This does not mean that every audit will look identical, of course, because there will be natural variations in curriculum across your institution, but at a high level you'll want to help users feel as if they are having a unified, consistent experience.

Using a standard structure and naming convention will make it easier to test and validate accuracy across your audits.

The way you choose to group courses and requirements in the audit will impact reporting and filters. For example:

The way you structure your audit will impact how you will make exceptions, such as substitutions and waivers.

For example: If you know that you regularly need to modify the credits a student must take for MUSC 490, it may be helpful to build MUSC 490 into its own sub-requirement with a total credit constraint that can be modified without impacting other courses.

Establish a clear, consistent naming system for all audits to improve searchability and organization. Version audits only when requirements change. For example:

Which catalog are you building? Examples:

We always recommend that you build a single catalog version first, then validate and test, and then version back and forward as needed to ensure that you've captured catalog versions for all students who are included in the launch cycle.

What is your naming convention for all audits? Examples:

The name is for display and visual orientation only. It has no functional purpose in the application of audits.

Stellic does not require that you create a new audit version each year, which means you will make a decision about versioning and how you want to have your audit names reflect your versioning principles.

Stellic's recommended best practice is to only create an audit version when there is a change in requirements. This allows you, for example, to have versions 2020, 2022, and 2025 and know that there have been exactly 3 changes in curriculum requirements over a 5-year period of time.

Create guidelines for audit construction to ensure consistency across your team and provide direction for future builders.

What should be included at the top program level for every program? Examples:

Are there any double counting rules that should be applied broadly? Examples:

Other common examples:

Add subsections as needed to provide specific guidance for program-level requirements across groups of audits, such as:

How would you like requirements, also called categories, named within the audit? Each time you add a requirement, it will need a name.

Keep in mind that the names of requirements are what will be dragged into pathways and student plans to become placeholders. "Choose one of the following" is not especially helpful in a student plan. "ENG 340 or LAT 350" is much more clear.

The name of a requirement has no impact on the computation of the audit. So while you may choose to include credit numbers in the name of the requirement (such as Required Courses, 9 credits), including "9 credits" in the name of the requirement is for display only and will not perform any function.

The most common place to make decisions about preferred constraints are when you will use Fulfill All/Any versus a Course Set constraint. As you come across other nuances in your catalog that will apply in multiple use cases, we recommend you make and document your decisions. A common example: Whenever the catalog notes that "other courses may be approved by the dept chair" we will add the "other pre-approved courses may count" constraint to provide visual clarity to students and advisors that substitutions are commonly accepted here.

Considerations:

If the catalog says "any upper-division course" - what does that mean? Provide explicit examples for how these should be built in Stellic. Examples:

If the catalog says "any Social Work elective" - how is that defined? Outline explicit course lists, subject codes, and any needed ranges or patterns.

Plan when you'll revise and update audits, with your institution's curriculum or catalog cycle being an ideal opportunity.

Only create new versions when changes are necessary.

Set up different access levels (viewing, editing, publishing) to maintain audit integrity while enabling collaboration.

Refrain from publishing audits during peak hours, as this process can slow down the user experience by recomputing audits for all affected students.