WHY THIS PROJECT EXISTS
A small EHR.
A real test of Foundry.
MiniEHR is a dogfood project: we use Foundry to build a small application, test its engineering workflow, and uncover the gaps that need to be filled.
“Dogfooding” means using your own tools on a real project. Rather than relying on a demonstration alone, we give Foundry work that has rules to enforce, failures to investigate, and results to prove.
THE ENGINEERING TOOL WE ARE TESTING
What is Foundry?
Foundry is the engineering control plane for this project. It manages assigned work, ownership, agent sessions, supervised execution, evidence, and review gates. Agents write and investigate code within that workflow; human owners sign policies and approve integration.
MiniEHR asks a practical question: can that workflow support a C# application, with its own tools and tests, while keeping the work attributable and the results honest?
Visit the Foundry app ↗Foundry governs
Assign work, supervise execution, and record evidence.
Workers build
Implement the application, investigate failures, and repair code.
Humans approve
Set the trusted policy and make integration decisions.
A FOCUSED APPLICATION WITH MEANINGFUL RULES
Why an electronic health record?
A small EHR gives us more to test than a page that simply loads. Patients need unique identifiers. Updates must not overwrite newer changes. Encounter content must stay permanently closed, even when requests arrive at the same time.
The scope is deliberately small: patient management, encounters, vital signs, clinical notes, and permanent encounter closure. The backend uses C#, ASP.NET Core, and SQLite; the frontend uses HTML, CSS, and JavaScript.
TURN OBSERVATIONS INTO BETTER TOOLING
Finding gaps is part of the outcome.
A working application is one result. Understanding where Foundry needs improvement is another. We record what actually ran, what failed, how it was investigated, and what still needs a repair or an independent review.
For example, the C# application tests have passed, but Foundry’s multi-project test discovery has prevented it from accepting complete evidence. The project also exposed gaps in failure reporting, validation visibility, and retention of investigation reports. These are documented repair requirements, not claims that every gap has already been fixed.
That distinction matters: passing tests does not automatically mean the workflow has proved complete coverage, passed independent review, or received approval to merge.
Read the recorded Foundry gaps ↗LEARN FROM THE SAME PROJECT
You can follow along without knowing C#.
The tutorial explains the language before walking through the code. You’ll follow a patient request from the browser to the controller, through the application rules, into SQLite, and back. Then you’ll learn how closure, tests, and Foundry’s engineering workflow fit together.
What you’re seeing today
This website hosts the tutorial and a read-only patient demo. The example records live in frontend fixtures; they are not saved to a hosted C# backend. This is the intended hosted experience, with the functional application available locally through Foundry.
Paid backend hosting is deferred. Online registration and editing can be considered later; they are not required for the current demo scope. Accepted Foundry evidence, browser verification, independent reviews, and human-approved main integration remain pending.