Why it exists
I asked a surgeon what tool they wished existed. The answer was not admin software. They wanted to see the specific anatomy they were about to operate on: not a textbook figure or a pre-built model, but a view shaped by their approach and their patient's variation.
How it works
- The surgeon describes the case in plain language. SeeIn asks the clinically relevant clarifying questions.
- Parallel research branches build an evidence dossier. Nothing is generated until the surgeon approves it. That gate is deliberate.
- The model writes React Three Fiber source for the scene, compiled with esbuild inside a sandbox that only allows React, Three.js and the anatomy atlas.
- Every required view is rendered in real Chromium with Playwright, and Gemini inspects the PNGs against the approved intent.
- A scene is accepted only when every view passes at the same source revision. Any source fix invalidates earlier passes.
The hard part
A model that can describe the hepatocystic triangle perfectly in prose will place the gallbladder floating six inches outside the abdomen.
The fix was to separate registration (where structures live) from morphology (what they look like). Zod placement contracts make every structure either registered from the atlas or anchored to named landmarks from research, and validators reject anything out of bounds or mis-scaled.
Code review of the generated scene caught nothing useful. What worked was rendering real pixels and making the model look at them. Runtime, AI calls, source repairs, QA targets and research rounds are all bounded, so a run cannot loop forever.
There are no silent fallbacks. For a clinical tool, a plausible-looking wrong answer is worse than an error message.
What is next
Fewer compile and placement retries, validation sessions with practising surgeons, real-time voice interaction for the minutes before an operation, and custom modules so departments can register their own approaches.