The AI piece that was missing from a dental product that already works

Chapter 14 of the Sprint DGX series (from Chapter 1). How the VLM trained on H100s connects to the dental PMS that was already in production.

Quantum Howl doesn’t start from scratch. The product, a dental PMS with an AI layer, has been deployed for a while in a real clinic, treating patients every day. It’s not a demo or a PowerPoint roadmap: it’s software in production. What the DGX sprint builds isn’t “the product,” but the hardest piece of all: the vision brain, trained on DGX-class infrastructure, ready to slot into the system that already exists. This chapter tells how that new layer connects to the product without touching anything that already works, what the dentist gains when it comes in, and why the integration is almost a cable swap: the same contract as always, better intelligence underneath.

The product that already existed

The product is a dental PMS with an AI layer in production. It lives in its own repository, independent of this sprint, and has been deployed for a while in a partner dental clinic. Its operational components:

Layer	Technology	Status
Frontend	React + Tauri (desktop app + web)	production
Backend API	FastAPI + PostgreSQL + MinIO + Neo4j	production, high uptime
Agentic layer	a dozen or so orchestrated agents + system prompts	production
Dental VLM	vision-language model with dental fine-tuning	production on-prem
Knowledge graph	on the order of twelve thousand nodes and twenty-five thousand SNOMED/ICD/MeSH relationships	production Neo4j
Data	~5,000 patients, hundreds of thousands of DICOM images	production
Containerization	a dozen or so orchestrated Docker containers	production
Anonymization	DICOM tag stripping + PII filter	GDPR-compliant

It does concrete things in the clinic: diagnostic chat, appointment scheduling, no-show prediction, patient reminders, pharmaceutical assistance with allergy / pregnancy / anticoagulant checks, inventory management, billing. The system runs 24/7 on on-prem hardware in the clinic. Cumulative uptime is high and without significant incidents.

The product already exists. The sprint doesn’t compete with that or replace it. It trains a specific layer, the specialized dental VLM, on DGX-class infrastructure, and leaves it ready to slot into the system that’s already in production.

The layer the sprint trains

The specialized dental VLM that the sprint produces (Gemma 4 31B-IT with stages 1+2+3 trained, the canonical checkpoint v0bis-2) brings three properties that substantially raise the quality of the intelligence layer:

1. A larger, more capable base model (31B): more clinical reasoning capacity, especially in ambiguous cases where smaller models fall short.
2. A real multimodal VLM: panoramics, intraorals, and periapicals processed with integrated vision, not with a textual description of the images generated externally.
3. Natively bilingual ES/EN: statistical parity verified on our own probes, not assumed.

These properties require hardware with memory headroom, and that’s where the sprint’s target comes in: an NVIDIA DGX Spark with 128 GB of unified memory, where the full BF16 model fits comfortably, without trimming precision. It’s the piece that the on-prem infrastructure will be able to serve once it reaches the clinic.

How it integrates

The integration path doesn’t require refactoring the product. The PMS client already speaks OpenAI-compatible chat completions natively. We serve the VLM with vLLM over OpenAI-compatible REST, exposing exactly the same contract that the previous inference layer already consumed.

The primary deploy architecture, described in prose: in the clinic, on-prem, the Tauri (React) desktop app talks to the FastAPI orchestrator that’s already in production. That orchestrator is the piece that doesn’t change shape: the only thing that changes is the VLM endpoint URL, which now points to a local vLLM serving Gemma 4 31B-IT in BF16 over unified memory. The agentic routing continues on its own side, with its base model and its system prompts. The target hardware is a DGX Spark with 128 GB of unified memory.

┌─────────────────────────────────────────────────────────────┐
│ On-prem clinic (end customer)                               │
│                                                             │
│  ┌──────────────────┐    ┌────────────────────────────────┐ │
│  │  Desktop app     │    │ FastAPI orchestrator           │ │
│  │  Tauri (React)   │◄──►│ (the PMS already in prod)      │ │
│  └──────────────────┘    │                                │ │
│                          │ - Wraps the vLLM endpoint      │ │
│                          │ - Agentic routing              │ │
│                          └─────────────┬──────────────────┘ │
│                                        │                    │
│       ┌────────────────────────────────┴────────────┐       │
│       │                                             │       │
│  ┌────▼──────────────┐                  ┌───────────▼─────┐ │
│  │ vLLM serve        │                  │ Agentic layer   │ │
│  │ Gemma 4 31B-IT    │                  │ (base model     │ │
│  │ BF16, unified mem │                  │  + system       │ │
│  │ REST OpenAI-compat│                  │  prompts +      │ │
│  │ /v1/chat/         │                  │  registry-level  │ │
│  │ completions       │                  │  safety)         │ │
│  └───────────────────┘                  └─────────────────┘ │
│                                                             │
│  Hardware: NVIDIA DGX Spark 128 GB of unified memory        │
└─────────────────────────────────────────────────────────────┘

Deploy characteristics:

• Patient data never leaves the building: 100% on-prem deploy, with no cloud calls for inference.
• Same OpenAI-compatible contract: the FastAPI orchestrator already in production only changes the VLM endpoint URL.
• Same agentic model: the routing keeps working with its base model, its system prompts, and its registry-level safety checks. What improves is the quality of the inference underneath.

What the product gets from the sprint

Four assets flow from the sprint into the product:

1. The canonical VLM v0bis-2 (Gemma 4 31B-IT after stages 1+2+3): an inference upgrade. The same product features (diagnostic chat, panoramic reading, etc.) with better clinical quality. Verifiable metrics: +6.72 pp on MMOral closed in English (p=0.0027), +7.13 pp in bilingual Spanish (p=0.0001), zero catastrophic forgetting.
2. The GDPR-clean DICOM pipeline: operational anonymization and chain of custody. The product can onboard new patients and process images with documentable formal guarantees.
3. The bilingual panoramic and intraoral probes: an in-house test battery that integrates into the product’s CI for regression testing of future model updates.
4. The DICOM anonymization script: a reusable data-onboarding pipeline for future clinics, which takes the raw images and leaves a version with no residual PII.

What changes for the end customer

On the UX side, practically nothing. The doctor opens the same Tauri app, sees the same interface, chats with the same agent. The change is underneath:

• Better clinical response quality on complex queries.
• Real multimodality over panoramics and intraorals: responses can refer to specific regions of the image, not to a generic description.
• Bilingual parity: queries in Spanish have a verified accuracy equivalent to those in English, with no internal fallback to English.
• Consistent latency: the clinician doesn’t wait arbitrarily.

What does NOT change:

• The same doctor workflow.
• The same DICOM ingestion pipeline.
• The same Tauri UI.
• The same on-prem deploy.
• The same safety guarantees (agentic base model + system prompts + registry checks).

The product is still the product

The sprint produces assets, not a product. The product existed before day 1 and will exist after day 60. What’s delivered at the sprint’s close is:

• An improved AI layer ready to integrate (the canonical checkpoint v0bis-2).
• A validated OpenAI-compatible REST integration pipeline, which fits into the orchestrator without a refactor.
• Reproducible documentation of how it was trained and why the decisions that were made were made (this series of chapters).
• An on-prem deploy plan on DGX Spark backed by BF16 benchmarks and memory-fit analysis.

The end customer buys the product, not the sprint. The sprint makes the product better. That’s the correct relationship.

State at the close of the sprint

• The canonical VLM v0bis-2 merged and ready to deploy on DGX Spark.
• The OpenAI-compatible REST integration pipeline validated.
• The PMS operational, now with an updatable AI layer.
• The product keeps producing value in the clinic since day 1, with no downtime during the sprint.
• Post-sprint roadmap: deployment of the new vision layer on DGX Spark in the clinic, and extension to new clinics as they come on board.

FAQ

Does the dentist have to change anything in their day-to-day? No. They open the same app, see the same screen, and chat with the same agent. The new vision layer improves the quality of the responses underneath, especially on complex and multimodal cases, without asking them to change their workflow.

Why does it run on-premise and not in the cloud? Because not a single patient image leaves the building. The full model fits in an NVIDIA DGX Spark with 128 GB of unified memory inside the clinic itself, so there’s no health data traveling to a third-party server and no dependency on the connection. In a sector where the data is especially sensitive, “it stays home” is a starting advantage.

What does this layer add over the previous version? A larger, more capable base model, real multimodal vision over X-rays, and verified ES/EN bilingual parity tested with our own probes: +6.72 pp in English (p=0.0027) and +7.13 pp in Spanish (p=0.0001) on a public dental-knowledge exam, with zero catastrophic forgetting. Better clinical intelligence, same integration contract.

Next chapter: day 60, what remains built after 60 days. A model that sees the X-ray, reasons in two languages, and lives on-premise, ready to bring to more clinics.