Every time Arcline onboards a new district, we inherit a puzzle. The district might run PowerSchool for their student information system, or Infinite Campus, or Skyward. Their assessment data might live in iReady or NWEA MAP or a state-specific platform. Finance could be Munis, Tyler Technologies, or something built in-house twenty years ago. Every district is a different combination, and no two combinations produce data that looks the same.
Early on, we considered the obvious approach: write a custom integration for each system pair. PowerSchool-to-Arcline. Infinite Campus-to-Arcline. iReady-to-Arcline. MAP-to-Arcline. Munis-to-Arcline. That list gets long fast. And the moment a district switches vendors or a state adopts a new assessment, you're back at the drawing board. We needed something different.
The Problem Isn't Technical — It's Semantic
The hard part of connecting district systems isn't the API calls or the file parsing. Most SIS platforms export CSVs or expose REST endpoints. The hard part is meaning. When PowerSchool says a student is "enrolled," it means one thing. When Infinite Campus says the same student is "enrolled," it might mean something slightly different — active enrollment versus historical, headcount versus Average Daily Membership, enrolled-as-of-October-1 versus enrolled-right-now.
These aren't bugs. Each system is internally consistent. The problem surfaces only when you try to put data from two systems next to each other and ask a question that spans both. A superintendent asking "How many students are chronically absent?" doesn't care which SIS the attendance data comes from. But the answer depends entirely on how that system defines an enrolled student, what attendance codes it uses, and whether it counts by calendar days or instructional days.
We spent months cataloging these discrepancies. Not in a lab — with real district data coordinators who had been manually reconciling these differences in spreadsheets for years. They knew every edge case. We just had to listen.
The Normalization Layer
What we built is a normalization layer that sits between every source system and Arcline's query engine. When data flows in from a district's SIS, assessment platform, or finance system, it passes through a set of translators that map vendor-specific schemas into a single unified model. The backbone is the Ed-Fi data standard, which gives us a common vocabulary for student demographics, enrollment, attendance, assessments, and more. But Ed-Fi alone isn't enough — we extended it to handle finance data, intervention tracking, and several state-specific reporting fields that Ed-Fi doesn't cover.
Here's what this looks like in practice. Take a district running Infinite Campus for their SIS, iReady for assessments, and Munis for finance.
Infinite Campus: Attendance
Infinite Campus stores attendance as individual period-level records with status codes specific to the district's configuration. A student absent third period gets a different record than a student absent all day. The codes vary — "A" might mean unexcused in one district and excused in another, depending on how the district configured the system during setup.
Our translator reads the district's code mapping, converts each record into a standardized daily attendance event, and flags students who cross the chronic absenteeism threshold (missing 10% or more of enrolled days). The normalization happens at ingestion, so by the time anyone queries the data, it's already in a consistent format.
iReady: Assessments
iReady reports student performance using its own scale scores, percentile ranks, and placement levels. NWEA MAP uses RIT scores. State assessments use proficiency bands that change every time the state updates its cut scores. None of these scales are directly comparable.
We don't force them into a single scale — that would destroy information. Instead, we normalize the metadata: which student, which subject, which assessment window, what grade level, and what the vendor-defined proficiency status is. A query like "show me all third-graders below grade level in reading" works regardless of whether the district uses iReady, MAP, or a state assessment, because "below grade level" maps to each vendor's own definition of that threshold.
Munis: Finance
Munis organizes expenditures by fund, function, and object codes that follow state-specific accounting frameworks. Tyler Technologies uses a similar but not identical structure. Our finance translator maps these into a common model organized by funding source (Title I, IDEA, general fund), spending category (personnel, materials, services), and school-level allocation. When a CFO asks "What are we spending per pupil at Lincoln Elementary?", the system can answer that whether the underlying ledger runs on Munis, Tyler, or an export from the county office.
Where We Got It Wrong (At First)
The first version of the normalization layer handled the straightforward cases well. Standard enrollment records, basic attendance, assessment scores with clean identifiers. Then we started onboarding districts in states with non-standard reporting requirements, and the edge cases multiplied.
A few examples that cost us weeks:
- Dual-enrolled students. A student attending both a traditional school and a career-technical center shows up as two enrollment records in some systems and one record with a secondary school code in others. If you count headcount naively, that student gets doubled. If you deduplicate naively, you lose the career-tech enrollment. We had to build logic that preserves both records but identifies them as the same student for aggregate reporting.
- Attendance code sprawl. One district we onboarded had 47 distinct attendance codes. Forty-seven. Some were legacy codes that hadn't been used in years but still existed in historical data. Others were COVID-era additions for remote learning that no one had cleaned up. Our code mapping had to handle all of them — including codes that meant different things in different school years.
- Mid-year vendor switches. A district that switches from PowerSchool to Infinite Campus in January doesn't get a clean break. Half the year's data lives in one system, half in the other. Student IDs don't match. Attendance records use different code sets. Our normalization layer had to stitch a continuous student record across both systems using demographic matching when IDs didn't carry over.
Every one of these edge cases came from a real district. We didn't anticipate them in a design doc — we discovered them during onboarding and built the handling into the system afterward. The data coordinators who work with these systems every day were our best source of knowledge. They'd been solving these problems manually. We just had to encode their expertise.
What This Means for Districts
The practical outcome is that onboarding a new district takes days, not months. When we connect to a district's systems, the normalization layer does the heavy lifting. We configure the translators for the specific combination of vendors the district uses, validate the output against known data points with the district's team, and once it checks out, the full historical dataset is queryable.
When a district changes vendors — say they move from iReady to MAP for diagnostic assessments — we add support for the new data source without the district doing anything on their end. Their historical iReady data stays in the system, fully queryable, and new MAP data flows in alongside it. A principal looking at a student's reading trajectory sees a continuous line, not a gap where the vendor switch happened.
When a state changes its assessment framework or accountability metrics, we update the normalization rules centrally. Every district in that state benefits immediately.
Infrastructure Should Be Invisible
A superintendent shouldn't need to know that their attendance data comes from Infinite Campus, their assessment data comes from iReady, and their finance data comes from Munis. They should be able to ask "How are our Title I schools performing compared to last year?" and get an answer that draws from all three systems without anyone having to manually pull reports, align date ranges, or reconcile student counts.
That's what the normalization layer does. It makes the plumbing disappear. The data coordinators who maintain these source systems keep doing their work exactly as they always have. Arcline just makes sure that work adds up to something a district leader can actually use — without a spreadsheet, without a three-day turnaround, and without the quiet worry that the numbers might not match.
The best infrastructure is the kind nobody thinks about. It just works, and the people who need answers get them.