Data Quality SLOs for K–12: Concrete KPIs, Alert Thresholds and Remediation Playbooks

Most schools already track "data quality" in some vague sense. Someone notices attendance looks off, someone else finds a batch of students missing home languages, a counselor complains that half the withdrawal codes are wrong. But almost nobody has written down what "good enough" actually means as a number. That gap is where problems live.

An SLO — a service level objective — is just a target you commit to and measure against. Not aspirational. Not "we try to keep attendance accurate." A real one looks like: daily attendance must be finalized within 90 minutes of period close, 95% of school days. When you phrase it that way, two things happen. You can tell when you're failing, and you can tell who owns the fix.

This post is narrow on purpose. It's about setting concrete SLOs for the two datasets that cause the most downstream chaos in K–12 — attendance and enrollment — plus the alert thresholds, sampling rules, and owner playbooks that make those SLOs mean something. If your data eventually feeds state submissions, the interoperability and monitoring pipeline work sits downstream of everything here. Bad SLOs upstream guarantee bad submissions downstream.

Why "accurate" isn't a target

The core mistake is treating data quality as a binary — either the data is right or it isn't. Real data is never fully right. There's always a teacher who hasn't submitted, a new enrollment that hasn't cleared, a code that's temporarily blank while someone verifies it. The question isn't whether the data is perfect. It's whether it's good enough, fast enough, consistently enough for the decisions that depend on it.

That reframing forces you to pick dimensions and thresholds. Attendance has a latency problem (how fast it settles) and a completeness problem (how many teachers actually submitted). Enrollment has a completeness problem (how many required fields are populated) and a consistency problem (do the same students exist across SIS, state file, and food-service roster). Each of those is a separate measurable thing with a separate owner.

A pattern worth noticing: schools that struggle most with data quality usually have plenty of dashboards but no thresholds. They can see that attendance completeness is at 82%, but nobody agreed that 82% is a failure. So nobody acts. A number without a threshold is just decoration. For a longer look at dashboards that appear useful but don't actually drive decisions, the piece on common KPI and reporting pitfalls covers that failure mode in more depth.

Attendance latency: the SLO everyone underestimates

Attendance latency is the time between when attendance should be recorded and when it's actually finalized and usable. In most middle and high schools this is a per-period problem, not a once-a-day problem, and that's where it gets ugly.

Here's how the delay actually plays out. First period ends at 8:45. The teacher is supposed to submit during the passing period. Some do. But a substitute doesn't know the workflow, a veteran teacher submits at lunch, and two teachers forget entirely until the office prints a missing-submission list at 11am. By the time the attendance clerk chases everyone down, it's early afternoon — and the automated absence calls that were supposed to go out at 10am either didn't fire or fired with wrong data.

A realistic SLO set for a comprehensive high school looks like this:

1. 1
   Period attendance latency

   90% of periods finalized within 30 minutes of period end; 98% within 2 hours.

2. 2
   Daily attendance close

   100% of enrolled students accounted for (present, absent, or excused) by 2:00pm on instructional days.

3. 3
   Attendance completeness

   ≥97% of scheduled teacher submissions received without office intervention.

Notice the completeness metric measures teacher submission behavior, not just whether the day eventually closes. That distinction matters because a day that closes at 2pm only because a clerk manually chased 14 teachers is not a healthy day, even though the final number looks fine. The manual effort is the hidden cost, and it's invisible if you only measure the end state.

Alert thresholds that actually trigger action

The trick with alerts is tiering them so you don't train people to ignore the dashboard. One flat "attendance is late" alarm becomes background noise within a week.

The yellow tier is the one people skip building, and it's the most useful. Yellow means "not broken yet, but trending wrong" — which is exactly when a two-minute nudge to three teachers prevents a red afternoon. Red should be rare. If you're hitting red weekly, your thresholds are wrong or your workflow is broken, and either way that's worth figuring out before it becomes a submission problem.

Enrollment completeness: the fields that break everything later

Enrollment completeness is deceptively simple to state and painfully hard to hit: are the required fields populated, valid, and consistent for every active student? The failure isn't usually a missing student — it's a student who exists but is missing the one field some downstream process needs.

In practice this usually surfaces weeks after enrollment, when someone runs a report and finds 60 students with no primary language, 40 with a blank lunch-eligibility status, and a dozen with a grade level that doesn't match their scheduled courses. None of those blocked enrollment. All of them break something later — state reporting, meal reimbursement, English-learner services, or the master schedule.

The reason it happens is that enrollment is done by many hands under time pressure during a two-week window, and the SIS lets you save a record without every field filled. Optional-at-entry becomes permanently-blank because nobody circles back.

A workable completeness SLO defines a required-field set per student type and measures against it:

1. 1
   Core demographic completeness

   ≥99.5% of active students have valid entries for name, DOB, grade, home address, and guardian contact.

2. 2
   Program-eligibility completeness

   ≥98% populated for primary language, lunch status, and special-program flags within 5 business days of enrollment.

3. 3
   Cross-system consistency

   ≥99% of students match on ID and grade across SIS, state extract, and food-service roster, checked weekly.

That five-business-day window on eligibility fields is the part most schools omit. Without a time-bound, "eventually" becomes "never," and the blanks calcify.

Sampling rules — because you can't hand-check everything

You don't have time to eyeball 1,400 records. You need sampling rules that catch systemic problems without pretending to audit everything.

1. 1
   Full scan on the automatable checks. Presence-of-field, format validity, and cross-system ID matching should run against 100% of records — a machine can do that nightly, so there's no reason to sample it.
2. 2
   Stratified manual sample on the judgment checks. For things a machine can't fully verify — is this address plausible, does the guardian relationship make sense — pull a stratified sample: roughly 5% of records per enrollment clerk, weighted toward new entries and toward any clerk whose error rate ran high last cycle.
3. 3
   Trigger-based deep dives. If the automated scan finds a field failing above its threshold (say, primary language blank on more than 2% of records), escalate to a full review of that field rather than waiting for the next scheduled sample.

“

Automate the full-scan reports to run overnight and surface exceptions each morning so clerks can correct records before downstream processes run.

The underlying logic: sampling and full scanning are for different problems. Machines full-scan the mechanical stuff. Humans sample the judgment stuff. Mixing those up — hand-checking things software could verify, or trusting software to judge address plausibility — is where teams waste hours and still miss errors.

Owner playbooks: the part that turns metrics into fixes

An SLO with no named owner is a wish. Every threshold above needs a person and a documented response, so that when yellow or red fires, the answer isn't "someone should look into it."

A remediation playbook doesn't need to be long. It needs to answer four things: who's alerted, what they check first, what they do to fix it, and when it escalates. Here's an attendance-latency playbook as an example:

Attendance latency — Red alert (>8% submissions missing at +30 min)

1. 1
   Owner

   Attendance clerk, backup is front-office lead.

2. 2
   First check

   Is this concentrated in substitute-covered rooms or spread across regular teachers? Concentration points to a sub-onboarding gap; spread points to a system or bell-schedule issue.

3. 3
   Immediate action

   Push targeted reminders to the specific non-submitters — not an all-staff blast. Verify absence-notification jobs are paused until submissions clear, so families don't get wrong calls.

4. 4
   Escalation

   If not resolved by 12:30pm, notify assistant principal; day cannot close late two days running without a documented cause.

Program-eligibility completeness — Yellow (field blank on 3–5% after 5 days)

1. 1
   Owner

   Registrar.

2. 2
   First check

   Is the gap tied to one clerk, one enrollment day, or one student type (e.g., mid-year transfers)?

3. 3
   Immediate action

   Generate the exception list, assign records back to the originating clerk with a 48-hour completion window.

4. 4
   Escalation

   If the same field breaches threshold two cycles in a row, treat it as a workflow defect — the entry form or training is the problem, not the people.

A quick diagram of the incident response workflow helps teams visualize who acts at each tier and when escalation happens.

That last line matters. When the same metric fails repeatedly with different people, stop blaming the people. The process is allowing the error.

A real scenario

A mid-sized district — around 5,200 students across nine campuses — kept blowing its state attendance submission because daily numbers weren't settling until late afternoon, and the extract ran before every campus had closed. On any given day roughly 8–12% of period submissions were still outstanding at noon, and two campuses routinely closed after 3pm.

They didn't buy anything new to start. They wrote three SLOs (period latency, daily close time, submission completeness), set the tiered thresholds, and assigned a named owner per campus with the four-line playbook above. The first two weeks were noisy — lots of yellow and red — because they were finally seeing the real state instead of the cleaned-up final number.

Within about six weeks, on-time daily close moved from roughly 70% of days to the low 90s, and the noon unaccounted-for rate dropped to around 3%. Nothing magic happened. They made the failure visible, gave it an owner, and stopped letting late days pass without a documented cause. The state submission errors that had been eating a day of rework each cycle mostly disappeared.

Where automation earns its place — and where it doesn't

Once the SLOs and playbooks exist on paper, the repetitive parts are worth automating: nightly full-scan completeness checks, tiered alerts that fire to the right owner, exception lists that route blank fields back to the clerk who entered them. This is exactly the kind of monitoring an AI-assisted operations platform handles well — running mechanical checks against 100% of records, watching thresholds continuously, and generating targeted work lists instead of an all-staff email nobody reads.

What automation should not do is set your thresholds or make the judgment calls. A tool can tell you primary-language is blank on 4% of records; it can't decide that 2% is your acceptable ceiling or that mid-year transfers deserve a different rule. It can flag an implausible address for review; it shouldn't silently "correct" it. Keep the judgment human and let the software carry the repetitive monitoring load. That split is what keeps the whole system trustworthy.

When tight SLOs make sense — and when they don't

Strict, tiered SLOs are worth the effort when your data feeds something with real consequences: state funding, meal reimbursement, EL services, compliance deadlines. The cost of a wrong number is high enough to justify the monitoring overhead.

They're overkill for datasets that are internal, low-stakes, and rarely reported. Setting a 99.5% completeness SLO on a field that three people ever look at is ceremony. A small school with one registrar and one attendance clerk probably doesn't need nine-campus-style tiering — it needs two clear SLOs and a habit of checking them, not a governance framework.

The failure mode to avoid on both ends: setting no thresholds because it feels like overhead, or setting so many that everyone stops reading the alerts. Start with the two or three datasets that actually break things, write real numbers, name owners, and let the rest wait.

The short version

Data quality in K–12 stops being vague the moment you attach numbers and names to it. Pick your highest-consequence datasets — for most schools that's attendance latency and enrollment completeness. Write SLOs as concrete targets, not aspirations. Tier your alerts so yellow warns and red demands action. Full-scan what machines can check and sample what needs judgment.

Give every threshold an owner with a four-line playbook so a breach triggers a fix instead of a conversation.

Do that, and the reports that used to surprise you at submission time stop surprising you. Not because the data got perfect — it never will — but because you finally decided, on paper, what good enough looks like and who's responsible when it isn't.