Kerala IT@School pilot deployment

This is the political path. The federation's technical foundation is now ahead of what its institutional foundation can use, and the institutional foundation needs to catch up. The catalogue contains 63 bets across protocol correctness, per-user adapters, federated training, and audit infrastructure; the institutional progress count is 0 — no warm intros to KITE (Kerala Infrastructure and Technology for Education), no contact with K-DISC (Kerala Digital Sciences and Cybernetics), no application to the IndiaAI Compute Portal, no published paper that an institutional partner could read and cite. The technical work has overtaken the institutional work, and the institutional work has to start now.

The Kerala IT@School deployment is the catalogue's flagship deployment scenario. The numbers — 215,000 student laptops, ~1 GB pooled RAM each, 210 TB total pooled memory, KFON / BSNL backbone — are large enough to validate the federation's "community-owned at fleet scale" thesis, but small enough that a pilot is operationally tractable. Kerala has the right combination of public technology infrastructure, edtech political will, and pilot-friendly governance to be the federation's first real-deployment partner. None of that translates into "happening" without explicit institutional work.

The numbers

The Kerala IT@School fleet at full scale:

215,000 student laptops across the state's public school system.
~1 GB pooled RAM each = ~210 TB of pooled memory across the fleet.
5–6 hours per day of low-utilisation desktop work during school hours; the rest is idle or sleep — substantial headroom for federation participation.
KFON (Kerala Fibre Optic Network) backbone — the state has a public fibre network with district-level reach, connecting most schools to a backbone with reasonable bandwidth.
BSNL last-mile to many schools; private ISPs to others. Mixed but generally usable.

If the federation thesis holds, this fleet is the largest single addressable pool for community-owned distributed LLM inference in India, possibly globally. The technical work in this catalogue (federation primitives, per-user adapters, byzantine robustness, throttle-invariance, ternary + norm-only wire format) targets exactly this kind of deployment.

The economics are good. 210 TB of pooled memory, even at 50% utilisation, is enough to host a 1T-parameter model with substantial KV-cache budget — comparable to what a major datacentre offers, but distributed across student laptops. Per-user adapters at 9 KB × 215k students = 1.9 GB total. Operationally tractable.

Why this is open

The technical work has outpaced the institutional work. The bets harness has 63 entries — a coherent research artifact spanning protocol correctness, per-user adapters, byzantine-robust training, glass-box attribution, and reproducibility methodology. The artifact has a website. The artifact has a methodology chapter, an open-questions chapter, and explicit pre-registration discipline.

The institutional progress count is 0:

No warm intros to KITE. KITE (Kerala Infrastructure and Technology for Education) is the parastatal that runs IT@School. They are the gatekeeper for any pilot. We don't have a relationship with anyone there, haven't sent an email, haven't been to any of their public events.
No contact with K-DISC. Kerala Digital Sciences and Cybernetics is a state research/development arm focused on AI and digital infrastructure. They are a natural research partner — our work fits their remit. We haven't reached out.
No application to IndiaAI Compute Portal. The Government of India's compute-credit programme provides modest GPU time for AI research. A successful application would give the federation's centrally-trained specialists a compute path that doesn't depend on private cloud. We haven't applied.
No published paper that institutional partners could reference. Institutional partners read papers, not GitHub repositories. Bet 04 (mixture combiner with provable Jensen bound) plus Bet 60 (noise-floor negative control with the regularisation-vs-personalisation reframing) is the minimal publishable pair — clean math result plus clean methodology result. We haven't written it.

The technical work isn't useful in a vacuum. It only matters if it gets deployed somewhere. Kerala is the obvious somewhere — open enabling environment, deployable hardware, government with a track record of edtech ambition, the right scale for a pilot. But "obvious" doesn't translate into "happening" without explicit institutional work.

What the pilot would look like

A concrete, scoped first pilot:

One school, one classroom, 30 laptops. A small, contained pilot. Enough hardware diversity to measure real-WAN throughput across actual home/school ISP conditions, real heterogeneous student usage patterns, and real failure modes (laptops that get reformatted, students who graduate or transfer, machines that get repurposed for non-federation workloads).
A sized base model + per-student norm-only adapters. 1B+ base, downloaded once per laptop at deployment time. 9 KB per-student adapter, trained on each student's own writing (with consent, with clear data-handling documentation, with the option to opt out). The per-student adapters are stored on-device; the student's text never leaves the laptop except via federation-mediated inference.
Audit-trail UI. Bet 18's glass-box LLM is the deployment-blocker for any educational pilot — a school administrator must be able to see which specialists contributed to each generated token. Already validated in the harness; needs a UI that a non-technical school administrator can use. This is engineering, not research.
Real-WAN measurement. The first pilot's primary technical deliverable is data on cross-ISP throughput at small fleet scale. 30 laptops on KFON / BSNL last-mile is the first measurement; the answer at that scale informs sizing decisions for a 300-laptop or 3,000-laptop pilot.
A measurable educational outcome. The pilot has to do something educationally useful, not just "run the federation." Concrete options: a writing-assistance application for students learning English (with the per-student adapter capturing individual writing style), a programming-tutor application for students learning Python (with the per-student adapter capturing the student's coding patterns), a Q&A system over local-curriculum content. The application should be modest enough that the federation can deliver it reliably and useful enough that students actually use it.
A privacy / consent framework. Student data is sensitive — minors, education-context, in some cases extracted from student-authored work. The pilot needs explicit consent (from students and parents/guardians), explicit data-flow documentation (what leaves the device, what doesn't), and an audit mechanism (parents/teachers can inspect what the system did). The federation's audit-on-by-default property is a foundation; the user-facing version requires careful UX.

What's needed to start

Concrete next actions, ordered by leverage:

A warm intro to KITE. A 30-minute conversation with the right person at Kerala Infrastructure and Technology for Education. Probably reachable through Kerala's startup community, through K-DISC, or through someone in the ed-tech research network. The first intro is the hardest; subsequent ones are easier.
A short, plain-language whitepaper. What the federation does, what the pilot would look like, what the costs and risks are. Not a research paper — a deployment proposal. ~5-10 pages. Focused on the institutional reader, not the ML reader.
An IndiaAI Compute Portal application. The application needs a concrete project description, modest compute budget, and clear deliverables. The federation's centrally-trained specialists need GPU time; this is the cheapest path to that.
A published paper that institutional partners can reference. Bet 04 (mixture combiner) + Bet 60 (noise-floor control) is the minimal publishable pair. Plus Bet 18 (glass-box) for the regulatory-deployment story. Submission target: arXiv first, then a workshop or conference (ICLR / NeurIPS workshops, or something more applied like FAccT or CHI).
A relationship with at least one Kerala-based researcher. Someone who can do warm intros, who can be a co-author on the institutional-facing paper, and who can vouch for the project's seriousness with KITE / K-DISC. This is the highest-leverage relationship to build first.

Why this is the highest-leverage open question

Every other open question in this chapter is gated on "the federation actually exists at scale." The Kerala pilot is the smallest path to "exists at scale." Without it, the catalogue is a research artifact. With it, the catalogue is a research artifact and a deployable system.

The technical work will keep happening — the catalogue's bet count will continue to grow, more open questions will close, the methodology will sharpen. None of that resolves the "does this actually deploy?" question. That question is institutional, not technical, and the catalogue can't answer it through more bets.

The bets will still be there next week. The KITE relationship won't build itself. Time spent on institutional work is currently the highest-leverage time available to the project.

This is a difficult adjustment to internalise. The technical work is gratifying — clean experiments, well-controlled results, satisfying STRICT-PASS narratives. The institutional work is unglamorous — emails to people who don't reply, meetings about budget and procurement, papers that take six months to publish, partnerships that take a year to form. The catalogue's discipline is to acknowledge that the unglamorous work is now the load-bearing work.

How this connects to other open questions

The Kerala pilot is the institutional anchor for the deployment chapter. Resolving it (in either direction) cascades through the other open questions:

Real-WAN throughput is the technical gate; the Kerala pilot is the institutional gate. They're complementary — a pilot without WAN measurement is incomplete; a WAN measurement without a pilot has no real workload to measure. The first pilot's real-WAN data is the bridge.
1B+ scale personalization depends on having real-user data. The Kerala pilot is the path to that data, with appropriate privacy controls. Student-volunteer corpora (with consent) at the pilot's scale would be the federation's first real-user dataset for the 1B+ adapter shootout.
On-device phone validation is downstream of the pilot. Once schools are deployed, students on phones become the next worker tier. Phone deployment as a research question gets clearer once we have school-scale deployment data.

The dependency graph collapses if Kerala happens. None of it moves if it doesn't. The federation's technical work, however polished, is on hold until the institutional work catches up.

Why this stays open

This question stays open because the institutional work hasn't started. The bets harness can't move it forward — no number of additional protocol-level results substitute for an email to KITE. The catalogue's role is to keep this gap visible, to be honest about the project's status (technical foundation strong, institutional foundation absent), and to make explicit that the next phase of high-leverage work is on the institutional side, not the technical side.

When this question resolves — when the federation has its first deployed pilot — the catalogue will reframe substantially. The current catalogue is an in-progress research artifact; the post-pilot catalogue would be a research-and-deployment artifact, with deployment data folded back into the bets. That's the version of the catalogue the federation ultimately needs.

Until then, the catalogue is honest: 63 bets, 0 institutional partnerships, deployment story technically grounded but operationally aspirational. The Kerala pilot is the path from "aspirational" to "real." The clock is running.