Learning infrastructure that needs no infrastructure.

For communities where the nearest reliable internet connection is a bus ride away, most EdTech is unusable by design: it assumes a live connection to a cloud service. Kul inverts that assumption. Course content, quizzes, learning records, and user accounts all live on the device itself, in an embedded database. When the box does get connectivity - at a district office, over a staff member's phone hotspot, during a supply run - it syncs new content down and learning data up, then goes fully offline again.

This paper documents what Kul currently does, drawn directly from its production codebase, and proposes it as a candidate for a pilot in low-connectivity school settings across Africa.

Across much of rural and peri-urban Africa, the binding constraint on digital learning is not devices or willingness - it is the network. Grid power is intermittent, fibre and 4G coverage thin out sharply outside major towns, and the recurring data cost of a cloud-hosted platform is often the line item that kills a program after the pilot year ends. Most learning platforms treat connectivity as a given and offline mode as an afterthought - a cached page, a "sync when you're back online" banner. That model breaks down completely in a setting where "back online" might mean once a week.

The practical requirement is different: software that is fully functional with zero connectivity, that treats an internet connection as an occasional, opportunistic event rather than a dependency - and that fits on hardware already common in these regions, an Android phone, rather than requiring a server room, a satellite link, or a subscription.

The box runs a standard web server and database on the phone itself: an embedded Postgres instance (no external database to install or maintain), a session-based login system that verifies credentials against that local database rather than calling out to an identity provider, and a content library stored on disk. Learner devices connect to the phone's hotspot exactly as they would to a home WiFi router, open a browser, and are on the platform - no app installation, no SIM, no data plan.

When the box is provisioned with connectivity - for initial setup, or a periodic refresh - it pulls new or updated course content from a central content system and pushes accumulated usage and learning-record data back up. The rest of the time, that link simply doesn't exist, and nothing in the classroom experience depends on it.

The interface itself keeps this state visible rather than implicit: a persistent indicator shows whether the box currently has an internet path or not, so a tutor never has to guess why a sync hasn't happened - offline is a normal, expected state, not an error condition the UI tries to hide.

Offline-capable learning tools generally fall into one of three patterns:

• Single-device offline apps (branded mobile-app offerings from several large LMS vendors) cache content and progress locally on one learner's phone, then reconcile with a cloud Learning Record Store the moment that phone reconnects. The offline period is a gap the cloud fills in afterward - there is no local server, and no classroom-wide view until connectivity returns.
• Open-source offline content platforms built for low-resource settings (Learning Equality's Kolibri is the best known) run a local server well suited to distributing curated content packages to a lab or classroom of devices. Their xAPI support is documented as content-package interoperability - importing lessons authored elsewhere - rather than an on-device Learning Record Store generating and storing new xAPI activity data from local usage.
• Hardware classroom-in-a-box kits (BRCK's Kio Kit is the reference point in Kenya) bundle a rugged router with a tablet fleet preloaded with third-party apps - Khan Academy, eKitabu, and similar. Content hosting is local, but the apps are separate products with separate progress data, and the fleet's usage dashboard syncs through a cloud service rather than an on-device store.

None of these combine a phone-hosted classroom hotspot, a local LRS that both generates and stores xAPI statements from day one, and native rendering of working documents - with a single teacher device able to drive every connected screen through a synchronized lesson. That combination is what Kul is built around, and it's the basis for the comparison below.

Working with children's data in a low-resource setting raises the bar on data handling, not lowers it - and Kul's offline-first architecture happens to align with that bar rather than fight it.

Data stays on the device by default

Accounts, sessions, course content, and learning records live in an embedded database on the phone. Nothing is sent to a third-party cloud unless and until the box is deliberately synced - there is no background telemetry call a field team needs to trust or audit, because for most of a box's operating life there is no network path for one to travel on.

Sessions are verified locally

Login uses signed, locally-verified sessions rather than a call out to a remote auth provider, so authentication keeps working indefinitely without connectivity - a school does not lose the ability to log learners in because the nearest tower is down.

xAPI as the analytics language

Rather than a bespoke event schema, learning activity is recorded as xAPI statements against a local Learning Record Store. xAPI is a widely adopted interoperability standard for learning data - records captured on a Kul box in one region are structurally compatible with any downstream xAPI-consuming reporting or research system, which matters for a programme that needs to aggregate outcomes across many independently offline sites.

Encrypted transport, hardened by default

The on-box web server terminates TLS locally and applies a restrictive content-security policy out of the box, rather than relying on network-level protections that don't exist on an offline LAN.

A Kul box is one Android phone. Setup provisions the hotspot, local DNS, web server, and database directly on the device, with a scripted backup-and-restore path for cloning a working box's configuration and content onto replacement hardware - a practical necessity when the nearest repair shop is a day's travel away.

What a site needs

• One Android phone per classroom or cluster (the server), rated for the deployment's power situation - mains, solar, or battery bank.
• Any WiFi-capable learner devices - no data plan, no SIM.
• An occasional, non-critical internet window for content refresh and data sync - at setup, and periodically thereafter.

What a site does not need

• A server room, rack, or dedicated PC.
• A fixed internet connection or ISP contract.
• Cloud infrastructure spend that scales with the number of classrooms.

xAPI (Experience API): an open standard for recording learning activity as portable, structured statements, independent of the platform that generated them.

LRS (Learning Record Store): the database that stores xAPI statements - here, running locally on the box rather than in the cloud.

RBAC (Role-Based Access Control): restricting what a user can do based on an assigned role rather than per-user configuration.

White-label: the ability to rebrand a platform's name, logo, and visual identity per deployment without changing its code.