Personalized Learning Technology: The Infrastructure Underneath It

Adaptive and personalized learning tools differ enormously in pedagogy and hardly at all in what they need underneath. Strip away the instructional model and the same four requirements appear: a student can reach a device at the moment the sequence expects them to; the connection carries the content at the moment the whole class needs it; the student's identity and class enrollment resolve without a helpdesk ticket; and something sensible happens when the connection is not there.

Those four requirements are not equally visible during procurement. Device counts appear in every board presentation. Bandwidth appears in the E-rate filing. Rostering and offline behavior usually appear for the first time in August, in a conference room, two weeks before students arrive. That ordering is the single most common reason a well-chosen platform lands badly.

The rest of this piece is written for the person who has to make the infrastructure carry the decision — not for the person choosing the instructional model. Every question below can be asked of a software vendor in writing, before the contract, and answered with a specification rather than an opinion.

The distinction that matters is not "1:1 versus carts." It is whether the software's session model tolerates interruption. A tool that assigns a weekly practice block works fine on a shared cart: the student picks up a device, works, signs out, and the platform stores progress server-side. A tool that runs a continuous adaptive sequence — where the next item depends on the last twelve responses, and the sequence is expected to resume mid-thread — behaves badly when the device is not available on the day the sequence expects it, or when the student lands on a device that has to re-authenticate and re-sync before it is usable.

So the procurement question is not "how many devices" first. It is: does this platform's session state live entirely server-side, does it resume cleanly on any device, and how long does a cold start take on the hardware we actually own? Ask for the answer against your device spec, not against a demo laptop. A cold sign-in that takes ninety seconds on a five-year-old machine costs a class period a week across a fleet.

Where the answer points to per-student availability, the device budget is the constraint and staggering the refresh matters more than the sticker price. Where periodic use is genuinely adequate, charging carts remain a defensible model — but the charging and check-out workflow becomes part of the instructional design, and someone has to own it.

One honest caveat on our side: we sell hardware. Recommending more devices is the answer that suits us, which is exactly why the test above should be the software vendor's written answer and not ours.

Personalized learning platforms are usually media-lighter than streaming video and usually chattier than a static LMS: many small requests, frequently, from every seat at once. The load profile that breaks a district is not the average day, it is the twenty minutes when four hundred students start the same adaptive block, plus the state assessment window, plus whatever else is running. Size against that peak, per concurrent seat, not against enrollment.

We are not going to restate the circuit-sizing arithmetic here, because it has its own page. Our network readiness guide for 1:1 districts carries the published per-user planning targets, the WAN figure, the access-layer calculation underneath them, and the reason a correctly sized circuit still fails behind a 1 Gb uplink feeding forty classrooms. Read it alongside this one — the card block below links straight to it — and treat the network as a precondition of the software decision rather than a consequence of it.

Personalized learning depends on the platform knowing which student is in which class with which teacher — and knowing it again the morning after a schedule change. That is rostering, and in US K-12 it is usually done with 1EdTech's OneRoster standard, which defines how people, courses, enrollments, organizations and grades move between a student information system and downstream applications.

OneRoster is implemented two ways, and the difference is operational, not academic. The CSV profile is a file exchange, typically produced overnight — simple, well supported, and inherently a day behind. The REST profile is a live web service that supports real-time queries. A district running CSV should expect a schedule change made Tuesday afternoon to reach the platform Wednesday morning; a district that assumed otherwise will spend September manually adding students to classes.

So the questions to put in writing are specific: which OneRoster version does the platform support, does it consume the CSV profile or the REST profile, what is the sync interval, and what happens to a student who moves between sections mid-term. Separately, 1EdTech's LTI standard handles the launch — the secure hand-off from your learning platform into the tool — and is a different integration with a different setup. A vendor that answers "yes, we integrate" without naming the standard, version and profile has not answered the question.

Two more items belong on the same list, because they fail silently: what identity provider the platform federates with, and whether account provisioning is automatic or manual. A platform that requires manually created accounts will not survive a 4,000-device rollout, no matter how good the instructional model is.

Every district has rooms where coverage is imperfect, buses that carry devices home, and homes without reliable service. The right procurement move is not to pretend otherwise; it is to make the software's degraded behavior an explicit, written specification.

There are three answers a vendor can give, and all three are acceptable if stated honestly. The tool can be fully online-only, in which case the district plans around it and does not assign work that depends on home connectivity. The tool can cache content for offline reading but not accept offline responses, which is workable if teachers know it. Or the tool can queue work locally and sync on reconnect — the most forgiving answer, and the one that needs the hardest follow-up question: what happens if the same student works offline on two different devices?

What is not acceptable is discovering the answer in November. Put it in the RFQ next to the rostering questions.