Memory Forge: Rounds

• 

Inspiration

Memory Forge started from a frustration I had as a medical student: useful feedback often stays inside the case discussion where it was given. I might understand why an answer was incomplete, but there was no simple way to make that exact reasoning gap return later as focused practice.

For Build Week, I decided to test a very specific idea: what if a missed concept could move directly from a clinical case into a learner-controlled review queue? That became Memory Forge: Rounds, built around the line “Every mistake becomes future practice.”

I deliberately did not make an open-ended medical chatbot. The model needed enough freedom to understand a learner's own words, but not enough freedom to invent the patient, the evidence, or the next clinical state. That constraint shaped the entire project.

What it does

Rounds is an account-free clinical-reasoning exercise built around one synthetic acute-chest-pain case. It follows the learner through five short phases involving aortic dissection and acute coronary syndrome.

At each phase, the learner explains their reasoning in English or Japanese. The system separates the response into concepts that were recognized, concepts that were missed, unsafe assumptions, and unsupported claims. It then shows short feedback and fixed educational evidence. The case can branch, but the branch is chosen by deterministic application logic rather than by the model.

The important part happens after the case. Instead of ending with a score, Rounds turns the learner's misses into possible recall prompts. Each prompt can be edited, approved, or rejected. Nothing is scheduled automatically. Only prompts the learner approves are passed to a browser-local FSRS scheduling preview.

The public version includes both Live Mode and Fallback Mode. Fallback Mode uses verified local fixtures, makes no OpenAI API call, and is visibly labeled. I included it so the entire experience remains testable without credentials and without pretending that prerecorded output came from a live model.

How I built it

I built Rounds with Next.js, React, strict TypeScript, Zod, Tailwind CSS, the OpenAI Responses API, and ts-fsrs.

I separated the system into a small set of explicit boundaries: a versioned synthetic case and evidence set, a GPT-5.6 adapter, a deterministic fallback adapter, strict response schemas, phase-specific evidence allowlists, a deterministic branching engine, and a browser-local FSRS adapter.

The most important architectural decision was the division of responsibility. GPT-5.6 interprets language. Deterministic code owns the patient state, diagnosis, allowed evidence, branch, risk change, final review-card content, FSRS rating, and due date. Model output must pass both JSON Schema validation and Zod validation, followed by a current-phase allowlist check, before it can affect the interface.

The public demo requires no account, database write, API key, or patient data. The case is entirely synthetic.

How I used Codex

I used Codex as an engineering partner at the repository level, not just as an autocomplete tool. It helped me inspect the existing code and Git history, narrow the Build Week scope to one complete case, implement and review the vertical slice, and add tests around the boundary between model interpretation and deterministic control.

Codex was especially useful when a failure crossed several layers. I used it to trace behavior from the UI through the API adapter and schema validation, compare the result with the case fixture, run the relevant tests, and verify the final production build. It also helped me test English and Japanese flows on desktop and mobile and prepare an accurate submission record.

I still made the product and safety decisions myself: what the model was allowed to do, what had to remain deterministic, when an external API call was authorized, what could be deployed publicly, and whether a result counted as verified.

How GPT-5.6 is used

In Live Mode, GPT-5.6 Sol has one narrow job: interpret the learner's free-text reasoning. It identifies recognized and missing concepts, flags unsafe assumptions and unsupported claims, selects from evidence IDs supplied in the request, writes concise feedback, and suggests missed concepts that may be worth reviewing.

It does not create the patient, choose the diagnosis, invent evidence, control the branch, calculate risk, write the final approved review card, or decide the review date.

The request uses a strict JSON Schema, bounded output, low reasoning effort, and store: false. Unknown evidence IDs, overlapping categories, malformed output, refusal, timeout, or schema failure are rejected before they can change the case.

I also ran a budget-controlled smoke test against the real model. GPT-5.6 returned the expected structured response for the initial phase. In the following safety-pause phase, however, it referenced evidence outside that phase's permitted boundary, and the deterministic validator rejected the response. This confirmed that the validator rejected an out-of-bound reference as designed, but it was not a successful end-to-end Live run. Judges should use the labeled Fallback Mode for the fully reproducible path.

Challenges

The hardest question was not how to use GPT-5.6, but where to stop using it. Free-text reasoning benefits from semantic interpretation, while case truth and safety boundaries need predictable behavior. Getting that division clear took more work than the prompt itself.

The second challenge was making fallback behavior honest. Silently replacing a failed model call with a fixture would make the demo look smoother, but it would also make the result misleading. Live and Fallback therefore have separate providers and visible interface states.

The third challenge was scope. I chose one synthetic case and completed the entire learning loop instead of adding many shallow cases. I also added English and Japanese support without turning the week into a full internationalization rewrite.

Accomplishments

The result is a complete path from a learner's free-text answer to a learner-approved future review item. Clinical state, evidence, branching, risk, and scheduling remain deterministic, while GPT-5.6 is limited to the language-understanding work it is good at.

The implementation passed 58 Vitest files with 274 tests, four Playwright flows covering English and Japanese on desktop and mobile, a 24/24 deterministic medical benchmark, strict type checking, linting, and the production build.

I am also proud that the demo is explicit about its limits. It does not use real patient information, does not claim to provide medical advice, does not silently persist public-demo data to an account, and does not present Fallback Mode as a live GPT response.

What I learned

I began with the idea that the model's main value would be generating feedback. By the end, I thought its more useful role was narrower: understanding how a learner expressed an idea, locating the gap, and proposing what might deserve another attempt.

I also learned that a strong AI feature can be defined by what happens after the model responds. Schema validation, evidence allowlists, learner approval, and deterministic scheduling are not supporting details; they are what make the output usable.

Finally, the failed Live safety-pause phase was useful. It showed that the boundary was doing real work. A smooth demo was less important than refusing an evidence reference the current phase did not allow.

What's next

My first next step is to reproduce and diagnose the Live evidence-boundary failure without weakening the allowlist, add a deterministic test for its cause, and then run one more budget-controlled synthetic smoke test.

After that, I would connect approved review items to a signed-in learner's durable queue with explicit consent, add more synthetic cases only after evidence review, and study whether returning to a specific reasoning mistake improves retention. Memory Forge will continue to use synthetic or properly authorized educational data and will not replace clinical judgment.

Build Week work disclosure

Memory Forge already had a private PDF-to-learning foundation before the Submission Period. The official pre-period baseline is commit 8c9600b.

During Build Week, I extended that foundation with product events, onboarding, medical taxonomy and routing, grounded recall repair, a deterministic medical benchmark, and the complete Rounds experience.

The Rounds-specific commits run from ce7eb1f through d1b1f9d. They contain the synthetic case, GPT-5.6 structured-evaluation adapter, deterministic validation and branching, explicit fallback, after-action review, approved-only FSRS preview, submission materials, and English/Japanese support.

Built With

• codex
• css
• fsrs
• gpt-5.6
• next.js
• openai
• playwright
• react
• responses
• supabase
• tailwind
• typescript
• vitest
• zod