Build notes
Building Vail Edge: The Decisions Behind Our District AI Platform
District AI · Limited beta
A principal asks a straightforward question: Which students were chronically absent last year, how is their attendance now, and what else do we already know that could help us support them?
Answering it requires information from several systems, the right permissions, and someone who can bring the results together. That is the problem we are building Vail Edge to address.
Where Edge fits
Edge is a district-hosted AI application, currently in limited beta. Its application and data infrastructure run on our hardware; the first version uses cloud-hosted language models. That distinction matters. A central design decision is separating the information a model needs to help answer a question from the identifiable records an authorized staff member needs to see.
We already use MagicSchool, Gemini, and NotebookLM for other purposes. Those tools have a place in our district. Edge adds a governed way to work with Vail’s institutional data and documents. When a request belongs in another tool, Edge redirects it there.
I want staff to have tools that fit the work they are trying to do. That means broadly available tools for everyday work, additional capabilities for people who need them, and Edge for questions that depend on our district information and access rules.
My role and the architecture
As CTO, my role is to connect those needs with the architecture, governance, and rollout decisions, and stay involved in building the application. AI tools help with implementation, while decisions about access, data sharing, and readiness remain our responsibility. Feedback from the people testing Edge is shaping the work throughout.
The application uses a Next.js frontend, a FastAPI gateway, Postgres with pgvector, and LiteLLM to manage model requests. Duo single sign-on and district identity groups establish who is using the system.
I want to share why we put those pieces together this way, because those decisions are a big part of what we are learning as we build.
The design decisions
Keep district data under district control while using cloud models
For the first version, we chose to concentrate our effort on data integration, permissions, and the information sent to models. Operating our own model infrastructure would introduce another substantial responsibility.
Use reviewed tools for operational questions
Edge does not generate and execute arbitrary SQL against the warehouse. Each supported question type relies on a reviewed, parameterized tool. That makes expansion slower: a new capability requires implementation and review. It also gives us a defined place to enforce access rules and inspect behavior.
Use retrieval and citations for policy questions
A question about board policy needs relevant source material and a way to check the answer. A question about attendance needs a controlled data query. Those are different workflows, and the application treats them differently.
Separate model inputs from record display
For student-data queries, the model receives aggregate counts and column information. Identifiable records are displayed separately to authorized staff and kept out of model prompts. The “what the AI saw” view makes that boundary visible to users.
Build access decisions into the application
District sign-on establishes identity, and role and school mappings determine access. When the application cannot establish someone’s scope, it should deny the request clearly. An unresolved mapping must never become permission to see everything.
Keep the product focused
A request that does not need Vail’s data may be better served by another district tool. Redirecting that request is part of the design. It also helps us understand what staff are trying to accomplish and where existing tools fit.
What district-hosted means for privacy
Privacy takes more than a statement on a landing page. Contracts, district governance, and technical controls need to work together. For Edge, that means making deliberate decisions about what data enters the application, what reaches a model, which records a person can access, and how access is logged.
It also means being precise about what “local” means. Staff receive authorized records in their browsers. Cloud models receive the information needed for their part of the workflow. Hosting the application in our building does not, by itself, answer every question about privacy. The boundaries between those steps need to be understandable and testable.
What the beta is teaching us
The beta includes a small group of administrators, achievement teachers, and site technology staff. Their questions are exposing both useful opportunities and places where the application needs to be clearer.
One lesson is that access failures need their own user experience. An empty attendance table can look like “there are no absences.” A clear access message tells someone that their school or section mapping needs attention. Those are very different situations, and the interface needs to communicate the difference.
Another lesson is that aggregate data still requires judgment. Small groups and sensitive classifications can make a count revealing. We are refining those rules around the viewer’s existing access, the type of information involved, and whether a comparison crosses school boundaries. “It’s only a number” is not a sufficient explanation.
Capability gaps matter too. When Edge cannot answer a question, it should say so clearly and make that gap useful feedback. Staff should not have to guess whether the system lacks the data, lacks the capability, or cannot grant access. A missing feature should not become a suggestion to export a roster into another chat tool.
Some of my favorite moments so far have started with a miss. Someone asks a useful question, Edge cannot handle it yet, and we build that capability in quickly. The whole team’s ideas are shaping what Edge becomes. The roadmap is a conversation with the people using the system.
What comes next
We are still early. The next stage is learning which workflows people return to, where answers need improvement, and how to measure whether the application makes their work easier.
If you are exploring something similar in your district, these are the questions I would spend time on: which information reaches the model, who can see the underlying records, what happens when access cannot be established, and how those boundaries are tested.
We are continuing to work through those questions with the people testing Edge. I am excited about what we are building together, and I want us to be able to explain how it works as clearly as we can demonstrate what it does.