Govtech

Designing for data in the open

DATA PRODUCTAI INTEGRATIONGOVTECHONGOING

A national platform for the U.S. Department of Education, serving data on 500K+ students. I build its most technical layer: an API that turns one query into data, charts, or narrative, and an MCP server (now in production) that opens the same data to any external AI assistant. On top sit a custom visualization system, an agentic workflow that turns questions into purpose-built tools, and a web app whose telemetry shapes what each user sees next. I own the infrastructure under all of it. Ongoing through December 2026.

The problem

The client is the United States Department of Education, which runs a national education data program informing policy at the federal, state, district, and school level. The mandate was open: identify meaningful AI integration for the next iteration of the program’s data infrastructure. Before anything could be built, an undefined scope had to survive 50+ federal, state, and district stakeholders with competing institutional priorities, different mental models of what the engagement could produce, and veto power over its direction. We aligned that scope through facilitated workshops and primary research; I then moved to designing and building the systems it called for.

The key question

How do you present national assessment data so that researchers, policymakers, and the public can actually use it, and get external probabilistic AI systems to accurately and reliably reference and work with the data?

Constraints

TimelineSynthesis had to be fast enough to inform live stakeholder conversations, not delivered weeks later.
Stakeholders50+ federal, state, and district stakeholders, each with institutional priorities that felt non-negotiable.
Data / domainLongitudinal national assessment data with uncertainty, suppression, and comparability rules attached to every number; misreading any of them produces a wrong headline.
Business needExternal AI systems already consume this public data, reliably or not. The platform had to make correct machine consumption the easy path.
Stakeholders scoring concepts on a sticky-note grid during the scope-setting workshop
SCOPE-SETTING WORKSHOP · REFRAMED PRIORITIZATION CRITERIA

Key decisions

Every choice had to hold up twice: to stakeholders who could veto it, and to engineers who would build on it.

Decision #1: Sensitive data never leaves the machine

The stakeholder interviews were too sensitive to send to a third-party API and too valuable to leave as static transcripts. I built a fully local RAG pipeline, transcripts embedded into a vector database, retrieval feeding a local LLM, so the team could interrogate stakeholder perspectives on demand. When others needed access, I exposed the app through a tunnel instead of moving the data.

Decision #2: AI resolves language; deterministic code answers

The service is split at a hard seam. An AI resolver turns natural-language queries into resolved parameters, and a deterministic core produces the data, whether the request arrives over REST or through the MCP tools I designed for external AI assistants. Identical resolved queries return identical results, every response echoes how it was resolved, and the AI never touches the numbers. That is what lets researchers and newsrooms cite the output.

Decision #3: AI points, never invents

When the resolver maps open vocabulary onto assessment concepts, its output is a pointer into a human-authored registry of official, cited definitions, never a freeform claim. The model can pick the wrong entry, which is visible and testable; it cannot fabricate an equivalence.

Decision #4: One API, every output form

Instead of an endpoint that returns rows and leaves presentation to the caller, I designed a contract where the same query can return data, an embeddable interactive chart, a static visual, or a written narrative, each carrying its citations and methodology notes. A newsroom, a researcher, and an AI assistant hit the same service and each gets the form they can actually use.

Decision #5: Design for data in the open

Once data is public, interpretation belongs to whoever opens the file; no caveat survives contact with a deadline. So uncertainty is drawn inside the visualization itself, methodological context appears at the point of use, and when a query invites misinterpretation the LLM redirects it toward sources instead of answering badly.

The system

One contract, two surfaces. A REST API and an MCP server share a single request schema, so researchers, newsrooms, and external AI assistants all hit the same deterministic core. Every response carries citations, methodology notes, and decoded data flags; definitions are quoted verbatim from official sources, never paraphrased.

THE LIVE MCP SERVER · AN EXTERNAL AI ASSISTANT QUERYING NATIONAL ASSESSMENT DATA

The server is deployed and public. A reader asks a loose question in their own words — what were the reading and math grades in 2024? — and what comes back is the part that matters: scale scores by grade and year, each change marked significant or not, the reminder that reading and math sit on different scales and cannot be compared to each other, the note that every 2024 figure is still below 2019, and a citation naming the source. The guardrails travel with the numbers, into a conversation happening somewhere I will never see.

Live in production
https://api.next-gen-naep.ai/mcp

Deployed on AWS, open to the public. Add it as a custom connector in Claude’s settings, or point any MCP-compatible client at the endpoint, and the national assessment data is queryable inside the conversation.

On top of the service sits the presentation layer: a visualization design system and chart taxonomy built from scratch, with prediction uncertainty over longitudinal data drawn into the views themselves, and a crosswalk layer that judges, with cited verdicts, whether an external dataset can validly overlay onto the assessment data at all. LLMs run through the whole pipeline, powering the web app, the API, and the MCP server alike. The AI integration strategy behind it was scoped to researched use cases from primary research with 20+ stakeholders, so every capability maps to demonstrated demand.

CROSSWALK HARNESS · TESTING WHETHER AN OUTSIDE DATASET CAN VALIDLY OVERLAY

The crosswalk is where most of the misreading risk lives. Someone arrives with a county-level CDC vulnerability file or a Census income series and wants it on the same picture as assessment scores. An AI reads the unfamiliar column shapes into geography, year, and value — it maps, it never renames or merges — and then the harness says out loud what the join actually costs: that the assessment score exists at state level only and cannot be pushed down to a county, that no assessment was administered in the years being charted so the nearest one is shown for context and never substituted, that the two sources share axes of place and time but keep their own scales. Every overlay is stamped approximate, and the resolved request is left open for inspection at the seam.

Outcomes

500K+
students whose assessment data the platform presents and the recommendations shape
1 query → 4 forms
the same request returns raw data, an interactive chart, a static visual, or written narrative, each carrying its own citations and methodology notes
50+
federal, state, and district stakeholders aligned on a scope that did not exist when the engagement began
Live
REST API and MCP server both in production and public — any researcher, newsroom, or MCP-compatible AI client can query the data today

Fifty-plus stakeholders aligned on a scope that did not exist when the engagement started, and that scope is now running code. The API and the MCP server have both moved from local pilots to a production deployment I built and maintain, so the guardrails I designed — verbatim definitions, decoded flags, comparability warnings, citations on every response — travel with the data into any client that connects to it. Work continues through December 2026.

What’s in motion

Let’s work together — 

I’m open to full-time roles starting January 2027 —
and I’m always free for a coffee.

apetronedesign@gmail.com © 2026 Crafted by Angela Petrone · Privacy-friendly, cookieless analytics ↑ Back to top