Title: When Our AI Demonstration Became an Apollo 13 Problem Summary: How three high school students recovered a locally hosted educational AI demonstration minutes before presenting it at NJIT. Minutes before presenting a locally hosted educational AI system at NJIT, three high school students discovered that the network connection their demonstration depended on was unavailable. On June 4, 2026, I arrived at the New Jersey Institute of Technology prepared to demonstrate an AI-powere… Key Ideas: 1. Building AI Around a Real Educational Problem 2. Keeping the System—and the Data—Local 3. The Network Path Was Gone 4. Watching Teachers See the Possibility 5. What the Failure Taught Us Permalink: https://aiaieducation.org/blog/apollo-13-local-ai-demo Full Post Body: On June 4, 2026, I arrived at the New Jersey Institute of Technology prepared to demonstrate an AI-powered educational analytics system that my teammates and I had spent months designing and building. I did not expect the demonstration to turn into our own much smaller version of Apollo 13. We were attending NJIT’s NASA Conference for K–12 Teachers in Artificial Intelligence, Machine Learning, Space Weather, and Cyberinfrastructure. The event brought together educators, researchers, students, and technologists interested in how emerging technologies could shape science and education. The featured speaker was Fred Haise, the lunar module pilot of Apollo 13. Listening to him describe the mission placed our own work in an entirely different context. Apollo’s onboard guidance computer operated with only a few thousand words of erasable memory—astonishingly limited by modern standards. Yet the system had been carefully designed for its purpose, and the astronauts and engineers supporting the mission understood how to work within its constraints. What impressed me most was not simply the technology. It was the response when that technology was no longer enough. The Apollo 13 crew and the engineers on the ground survived by remaining calm, understanding the resources they still had, and solving one problem at a time. Less than an hour after hearing that story, we would need to practice a much less dangerous version of the same approach. ## Building AI Around a Real Educational Problem Under the guidance of our teacher, Mr. Jeffrey Lai, my teammates Jake Ellengold and Manuel Escobar and I developed a project called **Saving Teachers’ Time with Local AI**. Only a few months earlier, the three of us were still learning what technologies such as containers, vector databases, data pipelines, and Kubernetes were supposed to do. By the time we arrived at NJIT, we had assembled those concepts into a functioning educational AI system. The project began with a straightforward question: **What work are teachers doing manually that software could help them complete more quickly?** The teachers we interviewed consistently described the same challenge. Schools collect large amounts of assessment data, but turning those records into useful instructional insights can require hours of sorting through spreadsheets, comparing questions with standards, and identifying patterns across different classes and student groups. By the time a pattern becomes obvious, the class may already have moved on. Our system was designed to shorten that delay. A teacher could ask a question such as: > “Show me mastery by standard for this section.” The system would process real district assessment data and return a visualization showing which New Jersey learning standards students had mastered and which ones required additional attention. Instead of manually comparing rows of grades with curriculum documents, the teacher could see the most important patterns in seconds. The goal was not to replace the teacher’s judgment. It was to help the teacher reach that judgment sooner. ## Keeping the System—and the Data—Local Behind the dashboard was a complete locally hosted AI stack. We ran a large language model, a web application, a vector store, a relational database, and an extract-transform-load pipeline on a DGX Spark server located in our school. The relational database stored structured information such as assessments, classes, questions, and scores. The vector store supported semantic retrieval. The data pipeline cleaned and organized incoming records. The language model translated teachers’ questions into interactions with those systems, while the web interface presented the results. Most importantly, the architecture was designed so that sensitive student information would remain within the school’s infrastructure rather than being sent to a public cloud-based AI service. For a school, that distinction matters. A useful educational AI system cannot be evaluated only by how impressive its answers appear. It must also be evaluated by where its data travels, who controls the infrastructure, and whether educators can understand and trust the results. At NJIT, we were ready to show what that approach could make possible. Then we attempted to start the demonstration. ## The Network Path Was Gone Minutes before we were scheduled to present, we discovered that the network path our demonstration expected was not available in the conference environment. Individually, the major parts of the system still existed. The server was running. The model was available. The databases and application code were there. But the connections between the pieces no longer worked the way they had in our school. The browser could not simply reach the application through the route we had prepared. A system that had worked before leaving our building suddenly appeared unusable. For a few moments, panic took over. We had teachers waiting to see the project. We had traveled to NJIT specifically to demonstrate it. The featured presentation had just described one of history’s most famous engineering emergencies, and now our own technology was refusing to cooperate. Of course, our situation was nothing like the danger faced by the Apollo 13 crew. But the principle we had just heard was immediately relevant: Stop focusing on what you expected to have. Determine what you still have. Then begin solving the problem in front of you. We examined which services were already running on the server, which dependencies were available locally, and which parts of the demonstration could be rerouted without relying on the missing network path. With Claude Code assisting our debugging process, we began reconfiguring the demonstration around the resources already available on the machine. One problem led to another. We found an inaccessible connection and replaced it. We found another dependency and redirected it. We tested the application, discovered the next failure, and continued. For approximately forty-five minutes, the demonstration remained uncertain. Then, only minutes before we were due to present, the site loaded. The dashboard was alive again. ## Watching Teachers See the Possibility The booth continued operating for the rest of the day. Teachers approached the demonstration and asked the dashboard questions about student performance. They watched as the system transformed assessment data into standards-based visualizations within seconds. The most memorable moment was not seeing the technology function again. It was seeing educators understand what the technology could mean for their work. A teacher could identify on Monday that a class was struggling with a particular standard and adjust Tuesday’s lesson accordingly. They would not have to wait until the next major assessment—or until they found time to manually analyze several spreadsheets—to discover the problem. That faster feedback loop could give teachers more time to respond while the information was still useful. It also clarified something important for us as student developers. The real accomplishment was not that we had assembled a large language model, a vector database, a relational database, and an ETL pipeline. Those technologies mattered, but they were not the purpose of the project. The purpose was giving a teacher back some of the time currently consumed by repetitive analysis. ## What the Failure Taught Us Recovering the demonstration felt like a success, but the failure also exposed a weakness in our design. A locally hosted application is not automatically an offline-ready application. Even when every major service runs on local hardware, the system may still depend on network routes, authentication services, configuration files, development tools, or assumptions about the environment in which it will operate. A resilient demonstration needs a degraded mode. It needs a clearly documented local access path. It needs to be tested from an unfamiliar network before the audience arrives. Most of all, the team operating it needs to understand the system well enough to rebuild connections when the original plan fails. That may have been the most valuable part of the experience. AI helped us build and debug the system, but AI could not replace our responsibility to understand it. When the environment changed, we still had to reason about the architecture, identify the failing dependencies, and decide what to change. The lesson was not that AI can magically rescue a broken demonstration. The lesson was that students can use AI to attempt projects far beyond what they previously thought they could build—and, in the process, learn the engineering judgment required when those projects inevitably break. As a line from *The Martian* puts it: > “You solve one problem and you solve the next one, and then the next. And if you solve enough problems, you get to come home.” We solved enough problems to make the dashboard come home. And then we showed it to the teachers it was built to help.