Caries
Cariology
0.35
mAP50
Real but weak — trained on bootstrap data only. Expected to improve once proprietary Nigerian radiographs are annotated.
Platform status
Every capability the project touches, with an honest label. Four levels are used throughout the specification and they are used here unchanged. Do not build against a not started or later phase capability as if it will respond today.
| Capability | Source | Status | Note |
|---|---|---|---|
| FDI tooth numbering (Stage 1) | Story 50 | mAP50 0.904. The anchor every finding attaches to. | |
| Caries detection | Stories 1, 2, 3, 5 | mAP50 0.35 on bootstrap data. Real, weak, and expected to improve with local annotation. | |
| Deep-caries depth precursor | Cariology | mAP50 0.50. A coarse binary signal, not E1–D3 staging. | |
| Periapical detection (panoramic, Story 17) | Story 17 | mAP50 0.31 across 9 validation boxes. Deferred in the sprint; not a trustworthy number either way. | |
| Periapical detection (intra-oral PA, Story 16) | Story 16 | The actual committed endodontic beachhead. No trained model yet. | |
| POST /api/v1/analyze | Live service | One image in, one tooth-anchored findings response out. No auth, no persistence, no banding. | |
| Image quality gate (Stage 0 / F11) | Story 51 | A browser-side heuristic pre-check stands in for it today, clearly labelled as such. | |
| PHI redaction (F12a) | Story 52 | Share and export stay blocked until redaction is real and verified. | |
| Persistence (tooth + date + model version) | Story 53 | Implemented in this platform: every finding carries its provenance triplet and a full audit trail. | |
| Findings overlay UI | 8-week proposal §2 | Implemented in this platform: colour-coded overlays, per-layer toggles, per-finding callouts, review controls. | |
| Confidence banding | 8-week proposal §2 | The UI is built around bands; the thresholds behind them need Week 7 validation data and are not invented here. | |
| Local validation harness | 8-week proposal §2 | Week 7. No in-app accuracy claim is made before this gate is met. | |
| On-device packaging (ONNX / TFLite) | 8-week proposal §2 | Today's models run server-side on Modal. Offline chairside inference needs this. | |
| Authentication & practice accounts | Implicit necessity | Implemented in this platform: sessions, roles and per-practice scoping. | |
| Progression / registration (F12b) | Stories 8, 9, 53 | Chronological per-tooth history is available now. Image-to-image registration — the actual differentiator — is not built. | |
| Surface B — PMS integration | MVP Spec v0/v1 | Open Dental first, then Dentrix/Eaglesoft. Not committed in this engagement. | |
| Periodontology, OMFS, Orthodontics, Restorative | 53-story PRD | — | |
| Conversational LLM narrator | MVP Spec (post-MVP) | The structured-findings schema is designed to drive it. Explicitly out of scope for this build. | |
| CBCT / cephalometric analysis | MVP Spec | Endodontics Stories 18–24 depend on it; the required model is licensed, not open source. |
Finding types trained today
Reported mAP50 comes from training against public bootstrap datasets. None of these figures has been measured against Nigerian radiographs, so none of them is an accuracy claim. Read the caveat before quoting a number.
Deep Caries
Cariology
0.50
mAP50
A coarse binary depth signal, not the full E1–D3 staging the 53-story vision calls for.
Periapical Lesion
Endodontics
0.31
mAP50
This is DENTEX's panoramic-modality class (Story 17, deferred) — not the Story 16 intra-oral periapical model, which has no trained weights yet. Nine validation boxes; not a trustworthy number in either direction.
Outside the committed clinical scope of this sprint.
Impacted Tooth
OMFS (incidental)
0.91
mAP50
Comes along for free from the shared dataset. Strong result, but outside this project's committed clinical scope — presented muted and unemphasised.
Outside the committed clinical scope of this sprint.
Screens
The specification's screen-by-screen inventory, with what exists in this application.
§5.1
Capture / Import
The front door: capture or import a radiograph and tag its modality.
Depends on: No AI service — pure capture/import UX.
Empty (first run)PopulatedPermission deniedImport failed
Open §5.2
Image Quality Gate
Classify a capture before any diagnostic model runs, with a specific reason rather than a bare retake.
Depends on: Stage 0 model — not started. A browser heuristic stands in.
AnalysingPassFail with reasonOverride confirmed
Open §5.3
Analysing state
Transient state while inference runs, with cancel and retry.
Depends on: POST /api/v1/analyze.
NormalSlow / cold model loadFailedOffline
Open §5.4
Tooth chart & numbering
Every detected tooth with its FDI number, tap-to-filter, and manual correction.
Depends on: F1 tooth-numbering model — built and verified.
NormalNo teeth detectedPartial detectionManually corrected
Open §5.5
Findings overlay
The centrepiece: colour-coded lesion overlays over the tooth-numbered radiograph.
Depends on: /api/v1/analyze. Story 16's real PA model is not started.
Findings presentNothing detectedLow confidence onlyClinician disagrees with the model
Open §5.6
Finding detail card
Drill-down on one finding: zoomed crop, exact score, provenance, accept/dismiss.
Depends on: Same models as 5.5.
StandardDismissed by clinician
Open §5.7
Case summary & report
One-screen roll-up of every finding across every image in a visit, with the audit line.
Depends on: Persistence layer.
Single imageMulti imageEmpty
Open §5.8
Share / Export
Send a case onward with PHI auto-redacted first.
Depends on: PHI redaction (F12a) — not started. Sending stays blocked.
Redaction in progressVerifiedUncertain — blocks send
Open §5.9
History & progression
The same tooth compared across visits, with trend direction.
Depends on: Persistence (built) + F12b registration model (not started). Chronological only for now.
Information architecture only
Open §5.10
Settings / device & model info
Model versions in play, service reachability, storage and the full disclaimer.
Depends on: None beyond the app itself.
OnlineInference unreachable
Open §5.11
Cross-cutting error & edge states
A checklist every screen must handle — not a screen of its own.
Depends on: —
No teeth detectedZero findingsStorage fullCold startWrong-tooth attachment
Open Market-specific requirements
The strategic focus makes these non-optional rather than nice-to-have.
Offline-first
A result must be producible with zero network connectivity. On-device inference also means the raw radiograph need never leave the device — a real mitigation for the open NDPA cross-border question, though not a full answer once findings sync.
A forgiving, informative quality gate
The target environment includes older sensors, digitised film and phone-camera captures. A gate that rejects images without explanation reads as broken, not helpful.
Performance on low/mid-range Android
The specific target device is still undefined — an open assumption that needs answering before Week 6.
Data-usage consciousness
Connectivity cost is a real constraint for target clinics, not just a reliability concern. Model updates and sync must be deliberate.
Open questions for the product owners
None of these block the core build, but each needs an answer before the item it touches can be finished.
- 1
Mid-range Android device target
Still TBD per the proposal's own assumptions. Needed to scope Week 6 on-device packaging precisely.
Blocks: Week 6 packaging
- 2
Confidence band thresholds
Need the Week 7 local-validation harness's real numbers. Cannot be guessed responsibly, so this platform ships the band UI with the thresholds absent.
Blocks: Confidence banding
- 3
Is Surface B in scope for this engagement?
The web viewer plus PMS integration may be a separate future workstream. This platform's data model supports it without a rewrite either way.
Blocks: Roadmap sequencing
- 4
Is a separate practice-owner dashboard wanted?
Multi-chair overview, user management and billing, distinct from the clinician viewer. Not addressed in any existing document.
Blocks: Information architecture
- 5
Language and localisation
No planning document specifies whether the UI needs a language other than English.
Blocks: Content layer
- 6
Auth / account model
Single dentist login, practice-level login, or per-chair? Affects the persistence schema, so worth deciding early. This platform assumes practice-scoped accounts with per-user roles.
Blocks: Persistence schema