How requirement groups model a degree audit

How requirement groups model a degree audit

Behind every credential in a catalog is a question a student eventually has to
answer with a registrar: have I completed what this degree requires? A printed
catalog answers it in prose, with headings, indented lists, and phrases like “choose
one of the following” or “complete twelve credits in the major.” Kenii stores the same
information as structured data so that it can be displayed consistently, validated,
and reasoned about. This article explains the shape of that structure, why it is
built the way it is, and how its pieces line up with the language a degree audit
actually uses.

The scope here is the requirements model for a credential: blocks, sections, groups,
and the rules and sources attached to them. It does not cover how to enter
requirements in the editor, and it does not describe the credential page layout
beyond what is needed to understand the model. Those are referenced at the end.

Why a nested structure rather than a flat list

The simplest way to record degree requirements would be a single list of courses.
That falls apart almost immediately, because real requirements are not flat. A degree
has a general education portion and a major portion. Within the major there might be a
core everyone takes and a set of electives where the student chooses some but not all.
Within the electives there might be a rule that says “at least nine credits, and no
more than six from any one subject.” Prose handles this with indentation and
qualifying sentences. To represent it faithfully, the data has to nest, and each level
has to be able to carry its own rule about how much of it is required.

Kenii uses four nested levels for this: blocks contain sections, sections
contain groups, and groups draw on a source of courses. Each level exists to
capture a distinct kind of structure that appears in real catalogs, and the rules
attached at each level are what turn a static list into something that behaves like a
degree audit.

The four levels

A block is the outermost grouping, the equivalent of a major heading in a printed
plan of study. A block has a title and can note a credit total, and it holds one or
more sections. Blocks let a single credential separate, say, its general education
requirements from its program requirements without flattening them together.

A section is a coherent requirement area within a block, such as “Major Core” or
“Restricted Electives.” A section carries a title, an optional explanatory note, and,
crucially, a rule that says how the section is satisfied. It holds one or more groups.

A group is where the actual courses live, or rather where the courses are drawn
from. A group has its own title, note, and rule, and it points at a source. The
distinction between a section and a group is what lets Kenii represent “choose one of
these three tracks, and within your chosen track take everything”: the section rule
governs how many groups are required, and each group’s rule governs how that group is
completed.

A source is the pool a group draws from, and it comes in two forms. A source can be
an explicit list of courses, each identified by its code, name, and credit value. Or it
can be defined by subject, naming one or more course prefixes (for example, any course
in a given subject area), optionally excluding certain levels and capping how many
credits count from any single subject. The subject form exists because catalogs
routinely phrase requirements as “any twelve credits of humanities” rather than naming
every eligible course, and pinning that to a fixed list would be both tedious to
maintain and wrong the moment a new course is added to the subject.

Rules are what make it an audit rather than a list

The structure alone would just be a tidy outline. What makes it behave like a degree
audit is the rule attached to each section and group, because the rule expresses the
condition under which that piece counts as done. Kenii recognises a small, closed set
of rules, and each one maps onto a phrase a student or advisor would recognise.

A rule of all means everything in scope is required. A rule of choose one means
exactly one item satisfies the requirement, the classic “one of the following.” A rule
of credits with a number means the student must accumulate that many credits from
the pool, which is how open elective requirements are usually written. A rule of
courses with a number means a count of courses rather than credits. And a rule of
groups with a number, which applies at the section level, means the student must
complete that many of the section’s groups, which is how “choose one track” or “complete
two of these three concentrations” is represented.

These are not arbitrary internal codes; they correspond directly to how the requirement
reads in plain language. The system can render each rule as a short human phrase (for
instance, a credits rule becomes “take N credits” and a groups rule becomes “complete N
groups”), which is what keeps the displayed catalog readable while the stored form stays
precise. The value of naming the rules explicitly, rather than freeform text, is that a
named rule can be checked and counted, whereas a sentence can only be read.

Validation, and why the model is opinionated about it

Because the rules are a closed set, Kenii can reject requirement data that does not fit.
A rule type outside the recognised set is refused, a rule that asks for a negative number
is refused, and a source type that is neither an explicit course list nor a subject
definition is refused. Subject sources are held to a further standard: a prefix named in a
subject rule has to correspond to a course prefix the catalog actually knows about, so a
requirement cannot silently reference a subject that does not exist. This strictness is a
deliberate position. A degree audit that quietly accepts a malformed rule is worse than
one that refuses it, because the malformed rule will misinform a student at exactly the
moment accuracy matters most. The model would rather fail loudly at entry than mislead
quietly at graduation.

There is a reasonable counter-view here worth acknowledging. A stricter model is less
forgiving of the messy, footnoted, exception-laden way some catalogs really read, and a
requirement that does not fit the block-section-group-source shape has to be reworked to
fit rather than transcribed verbatim. Kenii accepts that cost on the grounds that a
requirement precise enough to audit is more useful than one flexible enough to hold any
prose but too loose to check. The structure is meant to be a model of the requirement, not
a photograph of the catalog page.

How the pieces fit together

Reading the model from the top down: a credential’s requirements are one or more blocks;
each block is one or more sections; each section has a rule for how many of its groups are
required; each group has a rule for how it is completed and a source of courses to complete
it from; and each source is either a named list of courses or a subject-defined pool. A
student satisfies the credential by satisfying every block, satisfies a block by satisfying
its sections, satisfies a section by completing the number of groups its rule demands, and
satisfies a group by meeting its rule against its source. That top-to-bottom chain is the
audit, expressed as data.

Because the requirements are stored on the credential itself, this same structure is what
the credential’s detail page reads from when it presents requirements to a visitor, and it
is what any future validation or advising feature would consult to determine completion.
The model is designed once, precisely, so that everything downstream can trust its shape.

Related reading

• The post types and taxonomies reference
  documents the credential type that carries these requirements and the course prefix
  taxonomy that subject sources are validated against.
• The shortcodes reference describes the credential detail
  display, which renders the requirements model for visitors.
• About the catalog year lifecycle explains why a
  credential’s requirements belong to a specific edition, since a degree audit is only
  meaningful relative to the catalog year a student enrolled under.