ForgeMap

Inspiration During my junior year, I developed a fully autonomous thermal-regulation system for photovoltaic cells to investigate whether operating temperature could be decoupled from solar efficiency. The experiment taught me something unexpected: the hardest part of experimental research is often not building the system, but preserving the reasoning behind it. As I iterated on the prototype, I repeatedly lost track of which configurations I had tested, why I had chosen particular designs, and how I had solved earlier failures. Photos were scattered across devices, notes were incomplete, and important decisions existed only in memory. I realized that physical research lacked something software engineering had solved decades ago: a persistent, structured history of how a system evolves. That observation became the foundation for ForgeMap. Software developers use Git to preserve every meaningful change to a codebase—what changed, why it changed, and what came next. Physical builders have no equivalent. In robotics, hardware engineering, and experimental science, progress is still largely recorded through disconnected photographs, notebooks, and informal documentation. We wanted to bring the reproducibility and institutional memory of software development to the physical world. This is especially important in robotics and experimental engineering, where every failure can contain information as valuable as a successful result. A continuously evolving record of hypotheses, design decisions, failures, and solutions can transform an individual project into a knowledge base that future researchers can build upon. What We Built ForgeMap is an AI-native version-control system for physical projects. A user begins with an idea, and Physical Git transforms it into a structured project roadmap containing required materials, estimated costs, dependencies, and step-by-step instructions. As construction progresses, the user uploads photographs of the physical system. The AI compares each new image against the project's current state and determines what has actually changed. It then generates a commit documenting that change, updates the project's roadmap, and identifies the next actionable step based on the dependencies of the remaining tasks. The result is more than a project-management tool. It creates a machine-readable history of physical experimentation. When the project is complete, Physical Git synthesizes the entire sequence of commits into a final build document, preserving not only what was constructed, but also the design decisions, iterations, failures, and reasoning that produced the final system. How We Built It We designed the system as three independent services connected through a fixed API contract established before implementation: AI service: Generates project plans, interprets construction images, reasons over task dependencies, and produces technical documentation. Backend: Owns project state, the database, commit history, and roadmap. Frontend: Provides the interface through which users create projects, upload evidence, and interact with their evolving build history. The AI layer communicates with Claude through Backboard, using specialized prompts for each reasoning task. A central design principle was epistemic grounding: the models were explicitly instructed to reason only from information actually present in the project state and submitted evidence rather than filling gaps with plausible-sounding assumptions. That distinction is critical for scientific and engineering applications. A system that confidently invents a component, connection, or completed task could corrupt the experimental record. Our architecture therefore treats trustworthy documentation as a first-class engineering requirement rather than an incidental property of the model. Challenges We Faced One of our most difficult problems involved multimodal image analysis. We initially assumed that uploading an image and immediately requesting an analysis would be a straightforward API operation. In practice, the image-processing pipeline involved asynchronous state transitions that were not obvious from the documentation. We had to experimentally characterize the system: upload the image, verify when processing had completed, and only then submit it for analysis. This forced us to think of external AI systems not simply as functions that return outputs, but as distributed systems with observable timing and state.We encountered a second, subtler failure while optimizing the pipeline. We introduced a safety timeout intended to prevent requests from hanging indefinitely. Instead, we accidentally set the threshold below the normal response time of successful model calls, causing legitimate requests to fail. Rather than guessing whether our integration was broken, we isolated the external API and measured its raw response latency independently of our application. That experiment demonstrated that the delay was expected model behavior rather than an integration failure, allowing us to correct the timeout based on evidence. For me, that debugging process captured the larger philosophy behind Physical Git: engineering is not simply making a system work—it is building mechanisms that allow us to understand why it works, why it fails, and what can be learned from both.