Why 'enrolled student' has five definitions

An institutional research office gets a request that sounds simple: how many students are enrolled this fall? The data is sitting right there in the student information system. The query takes a minute. And the honest answer is a question back: enrolled by whose definition?

This is the part of the work that rarely makes it into a job description. The raw data (an IPEDS file, a warehouse extract, a student record) arrives as rows and columns, and loading it is mechanical. What turns those rows into something leadership can decide on is the layer of meaning sitting on top: what each field counts, what it excludes, which rule applies in which context. That interpretation layer is the actual product of an IR office. The data is just the input.

In primary research with 20 IR and IE professionals across 13 states, the Clema research team kept finding the same thing: when this layer is missing or inconsistent, the failure looks like a data problem but is not one. The numbers are usually fine. What is broken is the meaning attached to them. This post is about why one term resists a single definition, the places that ambiguity lives, and what it costs when it goes undocumented.

A definition that holds up has two dimensions: a functional one (what the term means to a person who does not write SQL) and a technical one (exactly how it is calculated, down to what gets included and what gets excluded). Most documentation that offices call a definition has only the first, or only the second. A glossary entry that reads "students currently enrolled" tells you nothing about whether study-abroad students count. A SQL snippet tells you the logic but not why anyone chose it.

A complete definition pins down both, plus the context around them. Of the 20 offices in the study, exactly one maintained definitions this complete, with active governance, versioning, and access for people outside the IR team. Everyone else had pieces. In practice the full picture comes down to seven parts.

Here is the trap that makes this more than bookkeeping. Imagine a table with a column literally named "master," and next to it an unlabeled computed flag that quietly applies the real eligibility rules. The column called "master" looks authoritative. It is not. The flag is.

A person who knows the data catches that in a second. A system reading the data dictionary at face value does not. It sees a field named "master," assumes that is the source of truth, and produces a classification that looks right and is wrong. The name was never the definition. The logic was. That gap between the label and the logic is exactly what a complete definition is built to close, and it is the gap that quietly defeats any tool you point at the warehouse without it.

Part of why a single term resists a single definition is that it gets defined in more than one place, by more than one authority, for more than one purpose. A term like "full-time" or "completer" can carry a distinct, official meaning at each of eight layers at once. None of these layers is wrong, and none is going away. Federal reporting will always differ from a state mandate, which will differ from what a dean needs on a dashboard.

So the goal is not to collapse eight definitions into one. That is neither possible nor desirable. The goal is to document which definition applies in which context, and make that documentation something other people can actually reach. The eight layers look like this.

None of this is hypothetical friction. In the same study, 75% of offices reported a trust-erosion event: conflicting or incorrect numbers reached leadership, and confidence in the data took the hit. Half said inconsistent definitions had invalidated their peer benchmarking, because you cannot compare your number to a peer's when the two were built on different rules. One director estimated that 20% to 30% of annual IR time goes to definition-related clarification, rework, and reconciliation: time spent working out which version of a number someone meant, not producing anything new.

The cost compounds quietly. Institutional memory erodes as the people who held the definitions move on. Shadow interpretations multiply across offices, each one internally consistent and mutually incompatible, so two reports can both be right and still disagree. Dashboards lose adoption because nobody trusts which number is the real one. And the chain runs all the way to students: an early-alert program acts on whichever definition decides who is "at risk," so a wrong definition groups the wrong students. The same goes for the story a number tells in a leadership meeting; if the definition underneath it is contested, the narrative is too.

This is a diagnosis worth taking seriously, and it has a name. We call it the institutional intelligence gap, and the next post in this series walks through how to assess your own exposure to it. The post after that lays out a six-step framework for governing definitions so they survive the person who wrote them. If you want the near-term version, our best practices for IR and IE data requests cover the habits that stop new ambiguity from piling up.

Clema is an AI data-intelligence platform built for IR and IE teams. It connects to nine federal data sources (IPEDS, College Scorecard, EADA, Pell Grants, DAPIP, PSEO, and others) and lets you query institutional and federal data in plain language.

Relevant to everything above: it flags where the same term resolves to different numbers across sources, and it maintains both a technical dictionary for analysts and a plain-language glossary for requestors from the same underlying definitions. The meaning layer lives in the system rather than in one person's memory, and that memory persists past any single tenure. Around 35 institutions use it today. None of this removes the human judgment a definition needs. It gives that judgment somewhere durable to live.