Phase 0 — co-author search in progress

Open-Source K-12 Accountability Analytics

A two-phase EDM/LA research plan built on a real, working K-12 education data stack. Looking for a co-author or case-study partner.

scroll

EDM 2026 accepted 126 papers. None of them use a real, open, K-12-scale dataset.

Most published EDM 2026 work draws on higher-ed data (OULAD, ASSISTments, Khan Academy) or controlled lab studies. The single most-cited gap across the 32 full papers: we have no shared, open, real-world K-12 systems that practitioners can build on.

The few K-12 datasets that exist are proprietary. The few K-12 systems that exist are vendor-locked. There is no open K-12 NL→SQL stack for the community to study.

126
EDM 2026 papers analyzed
0
papers on real-world K-12 NL→SQL systems
4
CA School Dashboard indicators tracked: CA, Suspension, ELA, ELPI
"The single most-cited gap across the 32 full papers."
— synthesis of EDM 2026 accepted papers

It's not a research prototype. It's a shipped system.

Open-source on GitHub. Open-weights on HuggingFace. Live demo running on HF Spaces. Real users, real failure modes, real data.

Sources
Aeries + CDE
Student records, attendance, discipline, accountability metrics
Warehouse
DuckDB
~30 tables, PII-hashed, 5 storage layers
NL→SQL
Qwen2.5-14B LoRA
Fine-tuned on Aeries schema, open on HuggingFace
Dashboards
Rill
4 indicator views, aligned to CA Dashboard
Sources
Aeries SIS + California Department of Education

Aeries is the dominant Student Information System in California (~60% of districts). CDE publishes statewide accountability data through the California School Dashboard. Both are the actual systems a CA district IT team uses — not a synthetic stand-in.

Warehouse
DuckDB, ~30 tables, PII-hashed

Five storage layers — core (raw Aeries), staging (CDE-loaded), obt (one-big-table for accountability), analytics (derived marts), cross (multi-source joins). Student IDs are SHA-256 hashed. The schema is open and the framework is MIT-licensed.

NL→SQL Model
Qwen2.5-Coder-14B-Instruct LoRA (r=64)

Fine-tuned on hand-curated + auto-generated NL→SQL pairs over the warehouse schema. Published on HuggingFace under the KDDSTLC org in two variants (v1 r=32, v2 r=64) plus a GGUF quantization for local inference. The model is administrator-facing — the user is a school principal or analyst, not a student.

Dashboards
Rill — 4 indicator views

Built in Rill, the dashboards surface the four California School Dashboard indicators: Chronic Absenteeism, Suspension Rate, ELA (English Language Arts), and ELPI (English Learner Progress). Each is a drill-down view, filterable by school, reporting category, and year.

Two papers. Four months. Co-author first, benchmark second.

A case study grounds the benchmark with a real user story; the benchmark characterizes where the LLM components fail on accountability-metric semantics. Together they fill the gap EDM 2026 didn't.

Jul 10
NOW · Aug 6
Nov 5
Phase 0 Jul 10 – Aug 6

Co-author search + case-study prep

Outreach to HF community, CA CS-ed faculty, and CA district IT/data folks. Reading EDM 2026 demo/industry papers for structure. Recording a 3-minute screencast of the Gradio app in action.

Deliverable: locked co-author + 1-page case-study outline
up next
Phase 1 Aug 7 – Sep 10

Case-study paper

8-page EDM format. 3 research questions: adoption, failure modes, equity. Mixed methods: 30-day log analysis + 3-5 semi-structured interviews. Four narrative arcs developed.

Target venue: EDM 2027 Industry / Demo track, or IJIET
Phase 2 Sep 11 – Nov 5

K12-Bench: accountability-metric reasoning

220 frozen prompts across 4 indicators × 5 difficulty tiers. 6 models evaluated (LFED LoRA, Qwen base + 32B, GPT-4o-mini, Claude Haiku, DeepSeek, Llama-70B). Failure-mode auto-tagging.

Target venue: EDM 2027 Full Paper

What we're actually studying

Open-source K-12 education analytics — combining a privacy-preserving DuckDB warehouse, a fine-tuned NL-to-SQL model, and state-accountability-aligned Rill dashboards — can be deployed in a district and meaningfully shift who has access to accountability data.
— Phase 1 thesis statement

Three research questions

RQ 1

Adoption

How does a district administrator actually use the LFED stack to interrogate accountability data? What workflows does the NL→SQL layer enable that weren't possible before?

RQ 2

Failure modes

Where does the system break? What categories of accountability-metric questions does the LoRA fail on, and how does a non-technical user work around it?

RQ 3

Equity

Does open-source tooling change who asks the data questions? Does it shift from "IT team runs SQL" to "principal runs a natural-language query"?

Four narrative arcs

Click each arc to read the full story. The case study will develop Arc A and Arc C in parallel (principal + superintendent, the simplest and broadest users). Arc B is held in reserve unless the audit angle resonates with a co-author. Arc D is long-tail and requires an intervention partner.

Setting: An elementary principal at a 400-student school. Her district is on the California School Dashboard red list for chronic absenteeism. She wants to see her school's chronic absenteeism rate by grade for the last 3 years, broken out by English Learner status.

Story: The principal doesn't write SQL. IT is busy. She opens the LFED Gradio app, types the question, gets a chart. She uses the chart in a staff meeting the next morning. The chart ends up in the LCAP (Local Control and Accountability Plan) draft.

Failure mode: The LoRA returns 2023-24 rows when the principal asked for 2023-2024 attendance from Aeries. CDE uses "2023-24" format; Aeries uses "2023-2024". The principal notices the chart looks "off" relative to her mental model and manually edits the SQL in the Gradio UI.

Why this is a strong arc: Concrete, relatable, ties directly to CA Dashboard accountability. The failure mode is a real domain-semantic mismatch, not a generic SQL bug.

Setting: A district data analyst preparing for the annual equity audit. She needs to verify CDE's pre-computed Status/Change/Color against raw Aeries data for chronic absenteeism.

Story: The analyst uses the Rill dashboard to identify candidate discrepancies. For each suspect, she uses the NL→SQL app to pull raw Aeries counts. She reconciles in a Python notebook.

Failure mode: The LoRA doesn't know about the is_suppressed column. It includes suppressed rows in the average, producing a different number than CDE. The analyst spots the divergence and asks for a "filter suppressed rows" prompt — a prompt the LoRA has never seen.

Why this is a strong arc: Audit/cross-validation is a high-stakes use case. Strong equity angle. Held in reserve unless the audit angle resonates with a co-author.

Setting: Superintendent presenting to the school board tomorrow night. She needs four charts: chronic absenteeism, suspension, ELA, ELPI — all broken out by reporting category (race/ethnicity, EL status, SWD, etc.).

Story: The superintendent opens the Rill dashboard, asks the LoRA to pull the OBT (one-big-table) mart for the four indicators, gets the multi-indicator query in 30 seconds. The four charts render in the same view. She exports a PDF and sends it to the board chair.

Failure mode: Reporting category code confusion. The LoRA is asked for "Black students" but the CDE reporting category code is RB (and "African American" is sometimes a separate code). The LoRA invents an alias, returns wrong rows, the chart looks plausible but is wrong.

Why this is a strong arc: High-visibility, ties to all 4 indicators equally. The reporting category bug is a perfect example of accountability-semantic failure.

Setting: A simulator that, given a help-seeking log, decides LLM-route vs. human-route based on signals (keystroke confidence, time-on-task, prior mastery).

Status: Held in reserve. Requires a real intervention partner and empirical help-seeking data the project doesn't currently have. If a CS-ed faculty member with an active intervention study joins, Arc D becomes the natural research-design conversation.

Why this is on hold: Novelty is high, but effort is 12+ weeks. Doesn't fit the 4-6 week Phase 1 case-study window.

Three ways to be involved

The minimum viable partner is one who'll go on the byline and give 1-2 hours of interview time and a quote. But there are three roles here — pick the one that fits.

Co-Author

For CS-ed or LA researchers who'd join the byline and shape the failure-mode analysis. Realistic ask: 5-10 hours over 4-6 weeks, mostly async.

1-hour kickoff call to align on the case-study outline and your role in the methods section.
Async review of the failure-mode analysis draft (one round of edits).
A quote for the discussion section on what would generalize beyond one district.
Byline on the published EDM paper (or IJIET if we pivot).
You get
  • • Authorship on a published EDM-track paper
  • • Access to the warehouse schema and the eval harness
  • • Co-design credit on the K12-Bench benchmark (Phase 2)
  • • A worked example for your own deployment or course
  • • Co-presentation rights if the paper is accepted as a talk

Reviewer

For senior researchers who'd give one round of feedback before submission. Lower time commitment, still a material contribution to acceptance odds.

30-min call to walk through the failure-mode analysis.
One round of written feedback on the full draft (2-3 hours of reading).
Acknowledged in the paper (with permission) for review contributions.
You get
  • • Early visibility on the failure-mode findings
  • • An open invitation to co-author Phase 2 (K12-Bench)
  • • A line in the paper's acknowledgments
  • • A clear-eyed view of where LMs fail on K-12 ed data

District Partner

For CA district IT directors, data analysts, or principals who'd test the system in their district for 30 days and share their experience. No SQL required.

1-hour onboarding call to set up access to the live demo.
30 days of usage — ask real accountability questions through the NL→SQL layer, log what works and what doesn't.
1-hour exit interview at the end of the month about your experience.
Optional byline as a district partner if the case study is publishable from your data.
You get
  • • A working NL→SQL interface for your accountability data
  • • The Rill dashboards configured for your 4 indicators
  • • Continued access after the study ends (MIT-licensed)
  • • A case study that documents your workflow for the field
  • • Documentation for your IT team on how to operate it

What success looks like

For the field

A real, open K-12 NL→SQL system

A reproducible schema, a working LoRA, an eval harness, and a 220-prompt benchmark. Future researchers can build on it without starting from scratch.

For the partners

Authorship and a working deployment

Co-authors get a published EDM paper. District partners get a working NL→SQL interface for their accountability data, with documentation their IT team can operate.

For the project

Two papers, grounded in real users

The case study gives K12-Bench a real user story. The benchmark gives the field a reproducible failure-mode analysis. Together they fill the gap EDM 2026 didn't.

Want to talk?

If you're at a California district that might test this, even informally — reply.

If you're a CS-ed or LA researcher who'd review or co-author — 30 min on a call would shape the paper.

If you've starred the HF Space or commented on the model — I'm casting a wide net for this.

For collaborators and reviewers — read deeper

Two public-facing research notes go behind the scenes of this project. The synthesis covers the literature, the case-study plan, and K12-Bench. The strategic-pressures doc lays out the four risks we identified and the decisions we made. Both are open to feedback.

Or copy a starter email
Subject: Quick question — are you using open-source ed-data tooling in your district?

Hi [name],

I'm reaching out because [shared context: HF community / your paper / mutual contact / district IT lead].

I'm putting together a case study paper for EDM 2027 on open-source K-12 accountability analytics. The artifact is a local-first warehouse + fine-tuned NL→SQL model + Rill dashboards, all open-source:

  - github.com/flucido/local-data-stack
  - huggingface.co/KDDSTLC/lfed-qwen2.5-coder-14b-sql-lora-warehouse-r64
  - Live demo: huggingface.co/spaces/KDDSTLC/LFED

I'm looking for a co-author (or just a 1-hour interview) from a CA district who's actually tried the system — IT director, data analyst, or principal who uses the NL→SQL interface to ask accountability questions.

If that's you (or someone on your team), I'd love to set up a 30-min call.
No prep needed — I'm just trying to understand real workflows.

Best,
[Your name]
LFED Research Project · Part of the local-data-stack open-source initiative.